It’s not that they can’t keep 32-bit support, it’s that they don’t want to. Apple has a history of forcing people in to the future that they envision. Much like they did with removing the disk drive and the headphone jack. Seems like that is what they are doing here by killing 32-bit applications.
This is more like when they dropped support for PowerPC emulation. It's less about forcing people into the future than about forcing Adobe and friends into the present.
Adobe wasn't 64-bit clean at the time that Apple announced they would be deprecating 32-bit binary compatibility. At the very least, Apple forced Adobe to update their DRM to something that didn't require running 32-bit code.
However, I think it's worth asking, who was that hurting? Users certainly aren't going to notice, and license activation isn't performance-critical code.
I'm sure for Apple it's QC, build process, documentation, examples, and constraints around building new things--maybe sharing stuff between iOS or preparing for a transition to ARM. Who knows? Apple tends to support the old OS for a few years, so while it does suck, it should be manageable.
It drives me nuts that installers and license managers are old and crufty. I do understand why. A few times now I've encountered situations where the installer cannot run even though the software it installs is fine.
I understand why it benefits Apple. I think the idea that it benefits users by forcing app developers to write better apps is a load of nonsense.
Separately, I feel like Apple should deal with it. They're one of the richest companies in the world and they can afford to maintain extra copies of libraries, possibly indefinitely. No one is asking them to go full-on Microsoft and explicitly test against old 3rd party apps. But, Apple clearly doesn't care, and I can't do much.
> and license activation isn't performance-critical code.
No, but DRM is pretty likely to require your OS to remain exactly bug-compatible with older versions. After all, the entire point is for it to cause trouble if it detects unexpected changes in system configuration or behavior, even if those changes are within the scope allowed by loose API definitions or undefined/unspecified behavior. E.g. it's pretty much expected that when an OS tightens security restrictions, it'll break a lot of DRM and video game anti-cheat systems. Inserting a new compatibility shim is also likely to be mistaken by those systems as a circumvention tool.
Well, that assumes the DRM is stringent. I don't think Adobe's ever was, it was certainly cracked easily enough. CS6's activation system has also survived _many_ macOS updates, up until this moment when Apple outright ripped out 32 bit. Maybe that's because Apple was purposefully maintaining compatibility with CS6 explicitly, but given how they operate, I kind of doubt it.
The real issue is that some people are relying on unmaintained software. If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working.
I hear a lot of post hoc justifications from Apple fans about how hard to maintain the compatibility layers are. But. It strikes me that a job has fun and not so fun parts. If there is really an ongoing maintenance issue generating more work release-to-release maybe look to re-design how the compatibility layer works.
> If they want to serve customers, IMO, the platform vendor should make a best-effort attempt to let unmaintained software keep working.
I agree. The problem is when the major ISVs abuse this and force Apple to keep doing high-priority QA to preserve binary compatibility with major applications that are mission-critical for many Apple users and are still maintained to some degree.
Users of unmaintained applications are generally somewhat understanding or accepting of gradual breakage driven by real technical necessity. Users with an active subscription to Adobe CC rightfully have higher expectations that their software continue to work without being broken by OS updates - but Adobe was trying to make that entirely Apple's problem, just as they did for migrating away from PowerPC and Carbon APIs.
