That UIAlertView thing: Deprecation and dinosaurs

Are you surprised at how many devs are focused on developing new iOS 7-specific applications this late into the game? iOS 7 has a 2 – 3 month ticking time bomb on it and yet every day, I encounter developers whose primary focus is getting their iOS 7 apps into shape for this autumn rather than building iOS 8 for launch this fall.

Sure iOS 7 and iOS 7 compatibility aren’t going away for a while. Even those devs aware of UIAlertView deprecation are focused on bigger deployment issues. Nearly all of them have irrational partners and bosses who insist on backwards compatibility to roughly the jurassic period. If a new iOS 7 app will work on iOS 8 that’s all they want or need. Taking advantage of iOS 8 features, well that’s for other people.

When you work on books, it’s awfully easy to get stuck in Apple headspace. Take UIAlertView. It’s been deprecated and I keep coming back to that, mostly because deprecated classes aren’t even available in Swift these days. Somehow this keeps resonating to my “It’s dead, Jim! I’m a doctor not a miracle worker” senses. I have to keep reminding myself of the day-to-day realities of the app store as it exists, not as Apple would have it. And yet when developers come to me asking how to build HUDs based on UIAlertView this late in the game, I start going UIAlertController ballistic.

The way I see it, ever since App Store started offering platform-specific upgrades, the pressure to back-support all devices all the time was gone. Unless you’re developing something new but specific to older devices (there’s a big market out there if you’re prepared to fight the tool suite, hi Chris S!), why not keep pushing forward with new releases? It’s not as if older systems can’t still do business with you. And when they upgrade, your newer versions are ready for them to download.

How much back compatibility do you think is necessary, especially if you put out regular updates?  If the world is upgrading with you, what are you gaining from supporting those 10% of users who have access to your product but may not be running the latest version of your software? What am I missing here?

I’m really curious to hear what you have to say.


  • App upgrades are not the same as OS upgrades. Everybody I know who has an older device has been bitten by OS upgrades making them slower or worse in some way. All of them, as non technical users, have vowed to never upgrade their OS again, because they are afraid any more upgrades will break their devices more.

    One of them went even went to apple care support all the way and all they could do is shrug him off since there is no way back and he can’t use his ipad any more on iOS5 as he used in iOS4 due to memory problems and random crashes he previously didn’t experience with Apple’s own apps.

    Crazy those users, eh? It’s all nice an shiny when you are not that 10%, but people expect their devices to keep working after upgrades. Once they learn this isn’t necessarily true they question any upgrade.

  • I work with a group whose primary target market is pretty niche (in this case, Indoor Cycling / Spinning instructors). Some purchase Apple devices just to run our app. We’re just now dropping iOS6 support now that we’ve got a rich and stable enough feature set that we can leave them with.

    Dropping iOS7 support is pretty much out of the question because we have folks still using iPhone 4, and we want them to participate in new upcoming features for as long as we can make it happen.

    We’ve got in-app purchase so we get revenue from them, plus pretty much all of our users are highly energetic and visible members of the instructor community (which overall is surprisingly large), so jettisoning them just so we can use the new shiny would be a bad business decision. The app is also used to up-sell to other things such as instructor certification and an online training center.

  • Its just one OS down and ones pragmatic thinking in software development is already pitted against the cross-road of Abandon Road or Support Road. Sure we can implement all kinds of checks and conditions but in the long run, code base gets messy, ugly and hard to maintain.