Anyone who’s ever opened up Xcode has probably seen this in the project settings and probably thinks it’s all you have to do to support older/newer versions of iOS/OS X and multiple architectures (Universal binaries during the PPC Intel switch). But it isn’t long before you’re writing

iOSv=[[[UIDevice currentDevice] systemVersion] floatValue];
//globally declared float because you're going to be using this a lot
if (iOSv<7.0) { [[UIApplication sharedApplication] setStatusBarStyle: UIStatusBarStyleBlackTranslucent]; }
And it gets worse and worse depending on what we're talking about. UIAppearance customizations, which SEGFAULT if they're called from the wrong part of code or reference incorrectly (which the compiler gives no warnings about) have different quirks under each version of iOS that supports them, which doesn't include iOS 4 so that whole appearance customization block has to be wrapped in an iOSv>=5.0.

It's not just "frivolous" color customizations. Translucent elements like the Status Bar introduce complexity based on wether or not they start at y=0 or y=-20 as far as layout code is concern. "What's so hard about adjust all your y-coordinates by 20?" the fact that it's not always the same. In older versions of iOS, if you programmatically change status bar styles from opaque to transparent or invisible, the top of the screen is at y=-20, but if you change view controllers (or rotate) the top becomes y=0 as you'd expect. The inverse happens when you change the status bar back to opaque. iOS 7 has finally solved this once and for all with the always clear status bar. The top of the screen is always y=0. The "safe area" under the status bar starts at y=20. Setting the status bar to hidden programmatically doesn't change any of this. This means, that when updating iOS 6 code to iOS 7, you either have to throw out all your check for status bar code or wrap an iOSv<7.0 around the whole thing. And let's not forget all the different ways Apple has gone about declaring supported screen auto rotations. A few iOSv<7.0 in your code here and there seems like nothing at first, but when your app has been around as long as some of mine have been, you start to realize you still have some iOS 3.1.3 code in there to support people that somehow have a functioning original iPod touch? Frameworks are where "progressively supporting" iOS versions gets particularly messy. dyld: Library not loaded:
IOS 6 deprecates the Twitter framework in favor of the social framework that also includes Facebook. If you want an app that can share to social networks using the iOS 6+ share sheet but still still tweet and email under iOS 5, you have to weakly link to all of those frameworks, then write a bunch of custom code for iOS 5 because back then to use a mail composer you had to implement all sorts of delegate methods. Oh, and you had to write an interface for presenting all the different share options. The only humane option (besides cutting off support) is what I call “regressively supporting” older versions. No social sharing if you’re not on at least iOS 6. Either that or use some third party sharing library and pray to Atheismo they’ll be ready for your app to be submitted for GM release of the next version of iOS (good luck). In an older version of Auto Adjust, when I added the backlight brightness slider, in iOS 3 I had it present a dialog to use the settings app and that got approved by Apple several times.

By far the worst thing about supporting “legacy” versions of iOS is that you have to keep some old devices around, perhaps intentionally un-updated, for testing, and awkward conversations with visitors who happen to see the pile of them.

And this is just what I encountered while adding iOS 5.1 support to Auto Adjust 4.1. Expect it during the iOS 7 launch day Appvalanche.