By now you have proooooooooobably heard that iOS 11 will consider apps that still have not been ported to 64-bit mode as obsolete. In practice, by refusing to run them.
Now this post is not on the how to port to 64-bit (I mean, if that is your concern Apple has been encouraging you to do so for years now…), rather on the why Apple did so. Why obsolete perfectly good 32-bit code and apps? I do not have all the answers, but I have a few. Let us first see why 64-bit is the better choice if we have to choose between the two, and why Apple chose not to maintain both.
Why 64-bit only is better than 32-bit only?
That one is an open and shut case: in this earlier post I already presented how the then-new iPhone 5S 64-bit environment was overall a benefit; and the benefits have only grown since then (as I wrote: “native 64-bit math is a plus for some specialized tasks and the future”), so there really is no question. If Apple had to drop one, it had to be the 32-bit environment.
Why not both?
In theory, Apple could save silicon surface on their post-iOS 11 hardware designs (iPhone 8, 8+, and X) by omitting parts that serve only for ARM/A32 mode execution in their processor design (which they have the power to do, remember they design their own ARM CPUs now). Indeed, while the cleanup from ARM/A32 to ARM64 was not nearly as dramatic as x86 to x86-64, some instructions and instruction semantics were dropped, though how far this could could save in terms of execution units is way beyond my expertise; more important probably are the savings for the instruction decode circuits: not only is there no need to support Thumb, but the instructions formats were completely overhauled between ARM/A32 and ARM64, with the former being quite convoluted (plenty of non-uniform formats, one-off cases, and split fields).
In practice, I wonder if this is worth the trouble. I think ARM processors are meant to start up in 32-bit mode before being raised to 64-bit, anyway, and there may be additional compatibility constraints (e.g. with drivers, hypervisors). Even if they did take advantage of this, this is not the main driver.
That is the part where the real savings are. Through the equivalent of app thinning, Apple could already eliminate the 32-bit parts from their kernel and built-in applications, but they would still have had to provide the 32-bit slice of the library stack (everything from libSystem to AppKit) so that 32-bit apps could keep running. And that does take up some space on your iPhone or iPad storage (which I have not measured, to be honest)… but more importantly, this slice would take up space in RAM, next to its 64-bit equivalent (always present since built-in apps use it), just as soon and any time a 32-bit app would be running.
This is the message that Apple has been not-so-subtly telling users already when they warned of 32-bit apps that running them would slow down the device: iOS devices have traditionally been quite RAM-constrained, and even if that eased a bit in recent years, any RAM savings are worth taking: they allow more tabs to remain active without having to be reloaded, more apps to remain frozen and only have to be (quickly) thawed instead of having to be relaunched, etc., improving the overall experience. And so to keep having the 32-bit library stack loaded in RAM in most iOS devices just next to the 64-bit library stack was starting to look like a waste of precious resources.
Was it worth it?
Heck if I know. I do not think I will be too much affected through the apps I own, but I am always worried about such obsolescence, especially from a digital preservation perspective. That being said, for the purposes of saving such history it is best to rely on a historical device (such as one that can’t be updated to iOS 11), because they are many other reasons why historical iOS software just stops running anyway. I keep my old iPhone 3GS for that purpose, and it is already loaded with a number of apps that simply don’t run any more on my iPhone 5S running iOS 10.