Very disturbing that one of the biggest companies around can't keep 32-bit support, at least in some capacity.
Removing 32 bit support hurts users.
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.
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.
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.
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.
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.
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.
> Nobody wants to carry support for both 32- and 64-bit forever.
Support means money and developer time, no one wants to waste money unless they really have to. In this case they don't have to, because everyone should have already updated whatever they use that was first made only for 32bit to 64bit.
imho the actual blame lies on whoever have resisted moving to 64bit(again mostly because of money).
On the other hand, yes Apple has great margin but companies are not charities, they don't stop making money when they have "enough". When they make more money than expected, their stock rises, they pay some dividend, CEO gets a nice bonus and everyone gets back to work to figure out how to make even more money.
You can argue that Apple is already charging a premium to be user friendly, and 32bit support is also an item that can count as being user friendly. That would be a valid argument.
Actually this might be the reason they are only now stopping it and have been ok with supporting it until now(2019). Similarly there is a reason Apple computers don't have CD-ROMs anymore, this is because the vast majority of their users, don't care about CDs at this moment, the industry has mostly left it behind to better alternatives, those who have not(think medical devices that are expected to be function for 50 years because they are expensive) make support agreements for 20 years or something with corporate friendly manufacturers/developers such as Oracle and Microsoft etc. or just write their own OS that no one can deprecate. See how Redhat Support of Python 2 for example, Python 2 will be ancient on January 1 2020, but Oracle needs to support it because that is how they make money, being very very reliable in terms of supporting stuff. [1]
Finally actually Apples' profits has been dropping as far as I remember because of decrease in iphone sales year over year, so they need to do something to cut costs and get back to the "largest margins" you mentioned again.
If you run `otool /System/Library/Frameworks/AppKit.framework/AppKit -f` you'll see 2 slices, one for "cputype 16777223" (CPU_TYPE_X86 | CPU_ARCH_ABI64) and one for "cputype 7" (CPU_TYPE_X86).
This is exactly what Linux distros are planning to do.
Linux solves it differently, it uses separate binaries for separate architectures. You can install the libraries into separate paths, have separate dynamic loader and everything works. Apple has no such option.
(This even applies to the base Unix system calls. Go previously did syscalls by hand but recently switched to dynamically linking against libSystem and using its wrappers, because they’re the only guaranteed-stable interface.)