In the upcoming months and until a short while after Apple’s inevitable autumn event where they’ll publicly release their new operating systems, computer magazines and news sites will try to create headlines about how Apple is killing off tens or hundreds of thousands of apps. What’s true and what’s not about this?
Well, yes: iOS 11 kills the support for 32-bit apps. Any such apps on your iPhone or iPad will stop working the day you upgrade to the upcoming operating system. I had a discussion with a friend the other day, regarding Apple’s decision to drop 32-bit OS and app support. He didn’t really like that decision, but I would like to put it in perspective with this beautiful table:
Year | 2012 2013 2014 2015 2016 2017
------+------------------------------------------
Model | 5. 5s. 6. 6s. 7. 7s/8.
------+------------------------------------------
| ^ ^
|This is the This is the
|last iPhone first iPhone
|that requires that will be launched
|a 32-bit OS without OS support
| for 32-bit apps
What I’m trying to indicate is that we have two conflicting ways of approaching the problem of legacy software:
One way would be to try to avoid rocking the boat, keeping backwards compatibility even at cost. The good thing about this is what we see in the Windows ecosystem: As long as the computer’s CPU is capable of running in emulation mode for the bitness required1, software just keeps on working. Particularly in business applications, not breaking backwards compatibility may be worth significant sums of money.
The bad thing is a lack of incentive on the part of software manufacturers to update their programs. A “Change is Bad” attitude easily develops when changes are few and far between: people don’t get enough practice in performing change in a safe way, and change management and reliability suffers as a result.
The other way to approach legacy software is to enforce changes for users who want to stay up-to-date. This is the approach Apple has chosen in many areas, for good and for bad. Since they control both their software and their hardware platforms, Apple are in a very good position to simply stop supporting old ways of doing things, and provided they wait a reasonable amount of time this shouldn’t cause a lot of problems. As evident of my table earlier in this post, the last iPhone unable to run a 64-bit environment will turn 5 this year. Considering the evolution of mobile hardware, I’d say anybody who still uses their iPhone 5 has gotten pretty decent mileage out of them – remember that every new software update up until this fall will have worked on that device.
But suppose you actually are heavily invested in some older app; how can you know whether it supports 64-bit iOS versions?
Look at the Version history field in the App Store. If an app was first published in January 2015 or later, or if it was last updated later than June 1 2015, it had to be able to run in a 64-bit environment.
There’s no stopping the wheels of time – iOS and Apple hardware will move on. I could recommend freezing a device, not upgrading it beyond a certain OS version. I won’t, because I consider that a terrible idea, at least for any device connected to the Internet, and for any device used for production work.
Luckily, we won’t see another bitness update in the foreseeable future. The two latest ones were exciting enough.
Footnotes
1 An x86 compatible CPU can by design not run 16-, 32-, and 64-bit code simultaneously, but can switch between 32/16 and 64/32 modes after a hard reset.