What Does 64-Bit iOS Mean?

Part of the Apple announcement for the iPhone 5S was the move to a 64-bit processor. This isn’t entirely a surprise, and frankly, was inevitable. It was a question of who would do it first. But what does this mean for anyone building apps for iOS?

What Does 64-Bit Mean?

Basically, it means the native “word size” for the processor is 64-bits wide. That means that an unsigned number can have a value between zero and 2 to the 64th power, or 18,446,744,073,709,551,616. That’s a huge number. It also means that you can address more memory. A 32-bit processor can address up to 4 gigabytes of memory. Going to 64-bit moves into staggering memory sizes, at least hypothetically. On paper, it would allow up to 16 exabytes of memory for a single process. Needless to say, that is far more memory than any smartphone has today. But it will allow smartphones to have more than 4GB of memory installed in the future.

For most apps, 64-bit processors means somewhat better math performance for larger numbers (because the 64-bit math is now native, and not done in software). It can mean a performance boost because the amount of data being moved in and out of the processor (and between caches and RAM) is larger, presuming that the databus between the processor and RAM is also widened to 64 bits. It won’t mean double the performance, but it helps, along with the increase in clock-speed. For most apps, 64-bit means very little in functional terms.

Bigger Numbers

Except for some very niche apps, being able to address more than 4GB of memory has minimal value right now. Given that most iPhones don’t have anywhere near that much RAM installed, it means that practical process sizes remain relatively modest. If your app is doing any kind of arithmetic, then the 64-bit word size might help. iOS already had the “long long” type, representing a 64-bit value, but that value is now native, rather than something the compiler has to “figure out”, so arithmetic will be a bit faster.

It will mean slightly higher memory usage, though, given that object references (which are essentially pointers into memory) are now twice as big. For any object or data structure that references objects, that means each instance of those will take up slightly more memory than before. If your app tends to hold on to thousands or tens of thousands of object references at a time, you can expect to see a bigger memory footprint when your app runs.

Older Models Still 32-Bit

In order to support older devices, apps still have to be able to work properly in a 32-bit environment. What does this mean? The biggest impact will be around integer types. If your app has been using int to represent integers, things are unchanged. The int type remains a 32-bit number. However, if you have been using long or NSInteger, the size of those types depends on the processor. They will be 32-bit on older processors, and 64-bit on the new A7 processor. For older apps that assumed a maximum value for these types, this probably isn’t a problem, because the new maximum is now bigger, not smaller. If you depend on the number wrapping, then you are for a surprise (I don’t want to know why you would depend on that “feature”). A problem can arise with newer or updated apps that depend on being able to use values beyond 2+ billion for signed numbers. If you’ve been using long long, then all is good, because that type doesn’t change in size. If you start to assume that long is 64-bits, then your app could run into trouble on 32-bit machines.

What if I’m using floating point? There, the news is mostly “unchanged”. The float type remains a 32-bit number and double remains 64-bits. The only change is CGFloat, which moves from 32-bits to 64-bits in size. Again, probably not an issue for older apps, but newer or updated apps may have to be aware of upper limits to avoid problems on 32-bit processors.

So Why Bother?

Some may be tempted to ask “why bother with 64-bit?” Mainly, the answer is that it was inevitable. All new PCs being sold today are 64-bit machines, and have been for several years now. In time, we can expect to see 32-bit versions of some operating systems, like Windows, to eventually disappear. OS X is now a 64-bit only system. For desktop and notebook systems, this isn’t a surprise. Moving to 64-bits allowed for machines with more than 4GB of RAM installed, and far larger process sizes for those tasks that require a lot of memory.

This change was coming to mobile devices. It wasn’t a question of “if”, it was a question of “when”. Apple has had a lot of experience moving between hardware architectures, so I expect that this transition will be handled equally well. What will be more interesting is to see how Google and the Android manufacturers handle it. There isn’t a lot of experience or history in the Linux world in handling 32-bit and 64-bit simultaneously. In most cases, you compiled for one or the other, and that was it. Apple is one of the few companies that have built platforms where a single software image could be built to run on multiple processor architectures. It can be tricky, and it certainly isn’t perfect, but it can be made to work for a lot of software.

Sure, the move to 64-bit could be seen as “change for the sake of change”, but at some point, smartphones and tablets are going to have (and need) more than 4GB of memory. Bigger word sizes means more speed when moving data around, and that can happen without having to increase clock speed. And part of it is simply because all of our other computing is now 64-bit. And given the tremendous response to the iPhone over the opening weekend, it’s clear the consumers are willing to buy it, even if they don’t know what it means or won’t really benefit from it early on.