Why REMOVE 32bit Libraries?!

For app developers, this 64-bit transition process started at OS X 10.4 Tiger.

Diagnostics visible to end-users around the problematic future of 32-bit apps started in with High Sierra 10l13.4.

Some compatibility is absolutely essential to a complex software product. Some. But application programming interfaces have to evolve. Old application programming interfaces (APIs) have old bugs, and old limits, and old issues. Old software gets retired. Software licenses change in incompatible fashions. User requirements change. Hardware changes. Capacities around memory and storage increase. The world, well, the world around the software—and the user requirements—changes.

Absolute API compatibility—the approach you're seeking here—is an unmitigated, absolute, complete, total, utter, and massive disaster for an evolving product. That's in the most polite of terms, too. That is, API compatibility provides exactly what you say you want. It also locks the rest or us behind your old and unmaintained apps, and behind your old app designs, and behind the bugs and limits that you’re either willing to accept, or are not encountering. It means we increasingly cannot fix things.

Absolute API compatibility means the death of the platform. Not immediately, but as the difficulty of making the design and code changes increases. And compatibility absolutely means that development and testing difficulties and efforts increase. In aggregate, making eventually meaningful changes become impossible, and that latent bugs and even security problems and security-related limits can never be removed.

Complete compatibility? You’ll be able to run your PolarBear79.app forever. The rest of us... will slowly be forced over other platforms, and to other choices, and away from macOS, as macOS becomes more calcified, and accreted.

As a specific example of a problem—this from another operating system—one API returns a password hash value into an eight-byte return buffer in the calling code. The returned password hash must fit into that eight byte buffer field. Advances in computing and in hardware have made that eight-byte return woefully inadequate. Modern password hashes such as Argon2 need to be longer. Typical secure password hashes now are 16 or 32 bytes in size, and potentially longer. You cannot fit a 16- or 32-byte hash into an 8-byte buffer. Which means any dreams of absolute upward-compatibility are utterly incompatible with reality. And once you break an API “a little”, you might as well break the other problematic parts and fix the other problems latent in the same area at the same time.

If you want information on this topic directly from Apple:

https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/HighLevelAPIs/HighLevelAPIs.html

Few vendors will invest in maintaining old and now-deprecated APIs. If you need a 32-bit app, then stay with High Sierra or Mojave or earlier, or build and boot a High Sierra or Mojave guest in a virtual machine and use that, or seek updates or alternatives to the required apps. Or seek funding for the necessary app update work.

You can make your voice heard— Apple Feedback http://www.apple.com/feedback

You can read a bit more on the topic:

https://www.techrepublic.com/article/apple-planning-to-replace-intel-cpus-in-macs-with-custom-arm-processors-by-2020/

You're not talking to Apple here, only other users like yourself. So best contact them with your request.

This tells much more of the story, and much better than MrHoffman did.

I've been in the SW world for over 40 yrs and have been with Apple through all of those transitions. The Carbon API was a great help and I look forward to something similar to help SW move to this new T1/T2 ARM based world.

I spent the last decade and a half debugging ARM based processors and 7 or the last 10 years porting a Multicore Debugger for them (ported from Micro$oft MFC to Linux QT5.x); 9 different distros, 32 and 64 bit builds. I built the Debian and RPM package scripts myself.

It will be a wild ride; however, it -is- sad to say goodbye to several well loved programs that could have lived another year...but it had to happen sometime I suppose.

Farwell my friends.

Products built using the T1 and T2 Arm system-on-a-chip processors have been shipping for a while.

While it helped the transition from older Mac OS to OS X, Carbon was largely deprecated a while back and then became unsupported several years ago.

As for other APIs and other app migrations and app compatibility going forward, Apple’s shown Catalyst, and there’s Swift. Neither of which were small projects.

We’ve been programming and using Arm processors with the Apple development tools for most of a dozen years; with iOS and now iPadOS. Including a 32- to 64-bit app transition on iOS, too. And with API and app deprecations there, too.

Given your Linux and Arm experience, you’ll undoubtedly be familiar with discussions of even having ARMv7 / ARM32 around as compared with ARM64, and with the compatibility problems that led to Linux seeking use of SBSA.

And coincidentally, the T1 to T2 was a 32- to 64-bit transition too, not that end-user developers had to particularly directly deal with that one.

But any large development project and particularly those with lots of app dependencies are still finding their work forced to remove the more problematic of the existing APIs as part of new development work, as otherwise some of desired changes and enhancements become constrained and increasingly difficult, and some app and API problems become otherwise unfixable.