https://github.com/kstenerud/iOS-Universal-Framework

This project provides a single installation shell script that will add a new Project Template to XCode, one that can be used to build universal iOS frameworks. Now this wouldn’t be a big deal (and in all rights, shouldn’t be a big deal), if not for the fact that for some unspecified and frustrating reason, XCode has no built-in ability to create such frameworks. This means that up until recently if you had an iOS library that you wanted to use across many projects, or that you wanted to distribute for other developers to use in their projects, you had only a few not-very-good options:

• Include your source code in every project that uses your library (increased compilation time, hooray!).
• Build two library versions, one for armv6/armv7 and one for x86.
• Screw with the linker to manually create a “fat” library.
• Use the Bundle Hack and hope that it works.

It’s worth noting here that the first three options listed above do nothing to help with the management of any shared header files needed to actually make use of the library code. The fourth option does allow you to include public headers in your build artifact, but the setup to do so is tedious, and the entire thing is basically a giant hack besides. None of these options are really very convenient or useful from the developer’s point of view.

What developers really need, what they should have access to, and what XCode should have supported at least since the release of iOS 4.0, is the ability to build true universal iOS frameworks that are “real” frameworks in the same sense that UIKit and CoreGraphics are real frameworks. And that’s exactly what the iOS-Universal-Framework project gives you. Just install it and you get a handy XCode Project Template that can be used to build a universal iOS framework. This lets you build real iOS frameworks that include libraries for both x86 and armv6/armv7 in a single package, automatically bundled with your public header files. You (or anyone else) can then use the generated framework inside of other projects in the same way as any other iOS framework; just add it to your “Link With Binary Libraries” build phase, and away you go.

All told, the iOS-Universal-Framework Project Template is great and works exactly as advertised. Just install it and you’re good to go. I’ve only come across one minor caveat worth mentioning, which is that although the template does correctly produce a universal iOS framework, the build product shown in XCode will actually point to an architecture-specific version of the framework. In order to find the correct, universal framework it is necessary to do a “Show in Finder” on the build product shown in XCode (or otherwise navigate to your project output directory), and then go up a level (or two) in the filesystem to find the folder that contains the universal version of the framework (edit: as per Karl’s comment below, this has now been fixed. Hooray!).

Apart from that minor annoyance this little XCode extension is really quite excellent, and I encourage you to give it a try. My personal thanks to Karl Stenerud for putting this together.

Now I’ve spent enough time in the tech industry to recognize that on many occasions this comic is as accurate as it is humorous. When working on any project of substance it is far more often the case that the requirements are a moving target, a living and breathing entity being pushed and pulled and cajoled and mutated by any number of external influencers, from the UX department who have just completed Yet Another Usability Study™ and concluded that The Entire UI Needs To Be Redone™ to the lead architect who wants to restructure the internals to use his new design that will Solve All Problems Forever™ to the engineers working deep in the code who have just discovered that The Feature You Want Is Not Feasible™.

The pragmatic coder is left with two basic options, often punctuated with an Unreasonable Deadline™; either code fast and try to meet the requirements before they change, or do things correctly and hope the requirements don’t change too much before you get there. More experienced coders know how to code fast better and/or how to code well faster, but the basic options remain the same, and often you will still be faced with scenarios where you’ve coded yourself into a corner, or had the requirements change before you got there.

So what to do in these situations? As much as I appreciate the tongue-in-cheek humor of the original comic, I believe there is a simple solution to the problem that it poses. Namely, refactoring. Refactoring fits in like so:

Refactoring is the art of transforming What I Have™ into What I Need™ and getting from I Finally Made It Work™ to I Can Make It Work Anywhere™ without having to throw away and rewrite 90% of your code, and the ability to refactor effectively is often the only thing truly separating good engineers from poor ones.

This is a subject that should be covered in any serious computer-science curriculum, yet unfortunately the first experience many engineers will have with refactoring will be when their first employer asks them to turn That Really Old Codebase That Nobody Understands™ into The Next Big Thing™. At this point one of two things will happen. Either they will refactor That Really Old Codebase That Nobody Understands™ into Something I Can Work With™, or they will decide that We Have to Rebuild It From Scratch™. Either approach can take a long time, but one is guaranteed to be far more disruptive and risk-prone than the other.

Embrace refactoring. It won’t save your life, lead you to salvation, or guarantee you eternal paradise, but it just might save your project, or even your company, from failure.