Recently, a customer contacted us to see whether our Python library was usable on an older 32-bit Mac running macOS 10.13. The short answer is no, as Apple has chosen to drop support for 32-bit machines in 2018. But we would like to explain why we can no longer release a version of our libraries that works with these older machines, thus dating back to before 2012.
Apple has changed CPUs for Macs several times and, admittedly, has handled these transitions quite well at the time. In particular, there was the transition from PowerPC processors to Intel processors in 2006, then the transition from 32-bit to 64-bit architecture in 2010, and the transition from Intel processors to ARM processors in 2020.
For each transition, Apple has provided tools to publish applications that run on both architectures. For example, currently the applications we publish, such as the VirtualHub, run on both Intel-based Macs and ARM-based Macs.
This magic trick is performed by Xcode which generates two versions of the application (Intel and ARM) and puts them together in a single file. When running the VirtualHub, macOS loads the correct version.
A few years after the transition
This mechanism works well to encourage people to adopt the new platform, but once Apple has made the transition and has stopped selling machines with the old processor for some time, Apple abandons the tools that generate applications for the old processors. In 2010, with the arrival of XCode 4, which supports 64-bit Intel machines, Apple dropped support for the PowerPC architecture. A few years later, in 2018, Apple dropped support for 32-bit processors.
The problem is that this discontinuation is not limited to stopping providing new versions of the tools. To ensure that the old tools are no longer used, the update of the XCode tool removes from the developer's disk the tools needed to make 32-bit binaries. So this is an active measure by Apple to force developers to stop supporting the old machines.
The developer's dilemma
When Apple drops support for a platform, the developers are in an uncomfortable situation. Either they follow Apple's recommendations and drop those platforms and the customers that go with them, or they don't update their development tools and don't support the current generation of machines sold to new customers.
The best solution would be to keep a dual development environment and publish two versions of the application to support all architectures, but this is not always possible. To take the example of 32-bit Intel Macs, it is technically possible to download and install Xcode 9 (the last version to support 32-bit processors), but this version only works on machines that support macOS 10.13, that is those sold before 2018. Supporting 32-bit Intel machines therefore requires having a pre-2018 Mac in working order...
Our position on this problem
We have always tried to support as many platforms, OS versions or languages as possible. For example, our Python library works with versions 3.X and 2.X of the language, even if the latter is no longer supported.
In the case of Apple products, we do our best to support older Macs, but it is not possible to maintain a museum of Macs to run older versions of Xcode. In practical terms, this means that our libraries and the VirtualHub work on Macs with 64-bit Intel processors and on the latest ARM processors.
The solution for 32-bit architecture
However, if you need to use our libraries on a 32-bit Intel Mac, it means that you still have an old Mac that works and can run Xcode 9, so all is not lost. Since we provide the full source code, you can always recompile our libraries with XCode 9. We have an article from 2013 that explains how to use our C++ library in Xcode. This, in the Python case, will allow to compile a 32 bit compatible libyapi.dylib DLL.
For the VirtualHub, you can continue to use the versions we released before 2018. All older versions are available on our site. If you need new features, it's probably easiest to use a YoctoHub instead of the VirtualHub.
