Apps Not Busy Being Born Are Busy Getting Killed Off
I thought Matt Deatherage wrote a particularly good counterpoint, explaining that supporting older apps also leaves Apple maintaining some support legacy and deprecated APIs in newer versions of iOS:
Technical debt describes the cost of not making software changes that you know you should make because they’re too difficult or expensive. Today, iOS carries the technical debt for thousands of applications that did not keep up with changes in the OS. At some point, that debt has to devolve back onto the developers that didn’t make changes, rather than accumulating on Apple because it updated and modernized the operating system.
Apple has been better on backward compatibility than most of its competitors, but everything has limits. The new Mac Studio does not run the original MacPaint binary — nor will it run any PowerPC binaries (a feature lost 11 years ago in Mac OS X 10.7), and only runs Intel binaries through Rosetta 2 translation. iOS in turn dropped support for 32-bit binaries nearly five years ago. It’s unreasonable to require a major hardware change to allow iOS to shed years of patches to benefit developers who haven’t kept up.
This ruthless commitment to pushing its platforms forward has surely reduced Apple’s technical debt. There are not many parts of MacOS or iOS that feel like an archaeological dig in the way Microsoft Windows often does. But Apple’s decision to drop support for legacy apps is not merely a technical decision; Apple has decided to drop availability of these apps for all devices, even very old ones.
One of the main differences between iOS and just about any other consumer platform is the control wielded over app distribution. Many of the side effects of that strategy have been written about to death, but I had not previously considered is how this reduces device lifespan. On other platforms, it is not possible to make older software unavailable to future buyers. I have a Nintendo GameCube for which I can still purchase new-to-me games from the secondhand market. I am writing these words on a decade-old MacBook Air that is stuck on MacOS Catalina and sometimes requires older builds of third-party software. To Deatherage’s point, you could today buy a copy of MacPaint and a system to run it on, even if neither has been updated in decades. But even if I kept an iPhone 4 in good working condition, I would have a hard time finding software from other developers that would still function.
Increasingly, that is because some pieces of software require web-based components that may be incompatible with older versions. Sometimes, the developer will want to make API changes; other times, it is for security reasons. In either case, it is usually the developer choosing when to drop support, not a big platform company.
But there are plenty of applications that have few to no web-based components and which could work perfectly on old devices. Developers will sometimes pull these apps from market if they no longer wish to support builds for older devices. But that still leaves an unknown number of apps that Apple is choosing to make disappear. That means users of older devices may find themselves in a situation where they are no longer able to download an otherwise fine app because it is no longer popular enough to keep stocked on the virtual shelves.
Surely there are technical solutions to this. What if software like this had support for minimum and maximum operating system versions? What if these apps were only made available for users of older devices?
Making choices like these do not come for free. Apple would have to continue storing products on its servers for which there is little demand. There would need to be a way for developers to mark this software as unsupported to acknowledge its legacy status. Software that relies on web-based SDKs would need to be handled separately. One of the advantages of Apple’s current App Store process is how, for the most part, apps available for download generally just work; there is often no need to check for system compatibility.
But perhaps an elegant solution is the price Apple ought to be paying for being the sole source of native applications for iOS and iPadOS, its two most successful platforms by device sales. The App Store knows what device a user is browsing from, so it should only be offering compatible software anyway. That is possible regardless of whether the software was last updated yesterday or ten years ago.
To Apple’s credit, its long-term device support is generally pretty good; iOS 15 works with devices as old as the first-generation iPhone 6S, released in 2015. And, after this round of app culling started generating press coverage, Apple helpfully clarified its rationale. There is still some fuzziness: apps that have “not been downloaded at all or extremely few times during a rolling 12 month period” are subject to removal, but there is no indication of what “extremely few times” means.
I am not generally opposed to the App Store distribution method. It has plenty of advantages for users over other models, though it does present different compromises for developers. This elimination of older apps has underscored for me how tethered an iOS device is to Apple’s decisions and processes, even in old age. Is it proper for Apple to make the decision about when to excise otherwise functional apps from its store, simply because of age or popularity? Given how the App Store is the only venue for native apps on iOS, I am not sure that answer ought to be an easy yes.