Why Apple might kill 32-bit support (and should Android follow suit?)

After debuting 64-bit processor support back in 2013, it’s looking like a future version of Apple’s iOS, quite possibly iOS 11, will drop support for 32-bit applications, completing the move over to an entirely 64-bit ecosystem. This news comes courtesy of an error message discovered in the first iOS 10.3 beta, which appears when attempting to run a 32-bit app, suggesting that those apps won’t work on future version of Apple’s mobile operating system.

This isn’t the first time that Apple has given preference to 64-bit support either: towards the end of last year the company removed a number of non-compliant apps from the App Store and sent an email out to developers reminding them to include 64-bit support in their builds.

Usually we’re not too concerned about what Apple does with iOS, but given that Android has also been a 32-bit/64-bit compatible operating system for a little while now, it’s possible that Apple’s anticipated decision could have implications for Google’s mobile ecosystem as well. So let’s explore how and why Apple might be making such a move, and whether or not Android should look to follow suit.

32-bit vs 64-bit

First a brief background to 32 and 64-bit. Essentially this number defines the size of the data registers supported by a processor’s architecture. A 64-bit CPU has registers that are twice the size of a 32-bit equivalent, allowing it to handle higher precision data and even processing some pieces of data faster.

In order to tell a CPU what to do with these registers we use instructions, and ARM’s transition from its 32-bit ARMv7-A to 32/64-bit ARMv8-A architectures introduced a number of new instructions to make use of these enhanced capabilities, known as the AArch64 instruction set.

In order to ensure backwards compatibility with the move to ARMv8, the architecture was designed to support the company’s existing AArch32 and Thumb-32 instruction sets. However, this means that portions of the CPU’s core pipeline, and therefore precious silicon space, are still dedicated to ensuring that these legacy instructions work alongside the new hardware options.

Importantly, it is not possible to use code from these two execution states (ARMv7 and ARMv8) within a single application. There is no interworking between A64 and A32 or T32 instruction sets. Therefore, code written in A64 for ARMv8 processors cannot run on ARMv7 Cortex-A series processors.

However, code written for ARMv7-A processors can run on ARMv8 processors in the AArch32 execution state. That means that for iPhone customers, older ARMv7-only handsets like the iPhone 5 probably won’t work with iOS 11.

The how and why

The revelation about Apple ending 32-bit app support suggests that the company is looking to move over solely to the AArch64 execution state. This would ensure that all future versions of iOS and apps are using some of the unique features only available with AArch64.

These include larger address pointers to access larger memory pools, a simplified assembler, automatic event signaling, double-precision float point and advanced SIMD operations, and hardware accelerated cryptography with up to 3 to 10 times the performance. However, developers will lose access to the old AArch32 and Thumb-32 instructions in the process, hence the need to update apps.

As well as forcing software developers to make use of the latest architecture features, there are also some interesting implications for Apple’s next in-house CPU design.

While we’re not entirely sure about exactly what Apple will be able to get away with, it’s possible that the company is looking to free up as much silicon space as possible by dropping old architecture support. This could reduce silicon manufacturing costs, or perhaps the saved space could be used to beef up the rest of the CPU, GPU, or to introduce some other features.

It’s possible that Apple may be able to further optimize its CPU design for 64-bit use only by ditching some, if not all, of the legacy hardware required by supporting 32-bit instructions. Providing this doesn’t break the company’s licensing agreement with ARM, that is.

Normally, ARM mandates that CPU designs based on its architectures support the entire instruction set, so perhaps Apple will have to design a chip with the bare minimum AArch32 and Thumb-32 support to pass ARM’s conformance test. However, ARM’s own Cortex-A32 is a 32-bit only version of its ARMv8 architecture, so there seems to be some flexibility about exactly which instruction sets are mandatory.

Should Android follow suit?

There are pros and cons to going solely 64-bit, but it’s not unfeasible that Google and smartphone processor developers, such as Qualcomm and MediaTek, could do the same for exactly the same reasons listed above.

Of course the Android ecosystem is much larger than Apple’s, so the sheer number of hardware configurations immediately makes such a change much harder to organize without causing disruption. Still, Google could, in theory, do something similar and mandate that apps destined for Google Play move over entirely to 64-bit.

Such a situation might be fine for even today’s low cost smartphones and tablets, as entry-level smartphones are shipping with 64-bit capable processors these days. However, Android is also used on devices with processors that aren’t as powerful, many of which aren’t 64-bit compatible and/or are reliant on optimizations available in the Thumb-32 instruction set that would be lost in the move to 64-bit only.

A number of Android Auto infotainment systems are built on older ARMv7-based processors, as are a selection of even top of the line smartwatches. The HUAWEI Watch, Sony Smartwatch 3, and the LG Urbane 2nd Edition are all powered by a 32-bit ARM Cortex-A7. Google also recently unveiled the Android Things platform for Internet-of-Things development, and a number of the development boards are also based on chips that won’t work with 64-bit apps.

This isn’t to say that Google couldn’t push smartphones towards making the most of what 64-bit has to offer. In fact, we’re already in a situation where Nougat won’t be coming to devices that can’t support Google’s latest encryption standard. However, keeping comprehensive support for legacy and lower power technologies, while also allowing developers to make the most of modern improvements and easily port their software is a best of both worlds solution. So it’s likely that Android will be sticking with 32-bit support for the foreseeable future.