Apple has stopped shipping 32-bit phones, and software developers are quickly moving their apps to being 64-bit only. This seems odd from a user’s point of view. But there are a number of reasons:

Business Sense

All 32-bit CPUs are only on old iPhones. That means not only are these phones limited to an older iOS version (as Apple no longer updates that OS), and are thus missing many libraries that apps may rely on, but also that the majority of the owners of these phones have likely not spent money on a new phone or new apps in a while, and are unlikely to do so in the future.

So why add code to replace missing Apple libraries if the majority of old-phone users will not buy your app, when you can invest that money into new features and attract new users with new phones, or users who spend money on new phones and apps?

Cost of Testing

Supporting older phones is also expensive as, technically, you need to test on every type of phone you support. So if you support armv7 CPUs, you need to buy several models of iPhone 4, one for each version of iOS they may be running (these are expensive, as Apple does not support downgrading phones, so once a phone has been upgraded to its latest OS version, there is no way to get back to an older one that some users may have stayed on). Since Apple users upgrade pretty consistently, such phones are harder and harder to get.

Screen Sizes

And then there is the issue of screen sizes. You generally do not want to build several user interfaces (as it costs more to have an engineer do work twice), so if you support small screen sizes, you usually design for content to fit the smallest screen then scale it up (think number of buttons etc. that may be on one page) - you can’t just remove features on a small screen, that would be stupid.

So in general, the fewer different phone devices you support, the fewer different UIs your engineers have to build, the fewer test devices you need to buy, the less time you need to spend testing variations, and the more users per euro spent you make happy. That is why companies stop supporting older hardware, like 32-bit ARM.

Apple Makes it Harder

There is also the issue that Apple provides the developer tools for making iOS apps, and Apple fairly quickly stops supporting making apps for older hardware (for the above reasons, too). So if you download a current version of Xcode, it might no longer let you create a 32-bit iOS app. (I think it currently still does, but in a year they’ll probably throw out the compiler needed to create 32-bit apps). And Apple’s app store contractually requires apps to be built with the newest version of Xcode.

The Mac Story

On macOS, the above reasons are exacerbated. The Mac has two Objective-C runtimes, the old 32-bit runtime inherited from NeXT, and the “modern runtime” introduced with Objective-C 2.0 when macOS moved to 64-bit CPUs (iOS arrived late enough that its 32-bit runtime already is the “modern runtime”).

The modern runtime solves the fragile base class problem, adds zeroing weak references and makes some of the runtime’s data structures opaque, giving Apple more freedom to change the system libraries, and also allowing for safer code. Given this required changes to the Application Binary Interface, for example by adding an extra level of indirection to every instance variable access, Apple could not activate these features for existing 32-bit apps, though.

This effectively limited Apple to not using any modern runtime features in system libraries. So dropping 32-bit support on the Mac gives Apple a huge amount of freedom to fix and optimize the system libraries.