Inside Apple's 64-bit iOS 7 and the prospects for a 64-bit Android

Met with much skepticism

There's no shortage of pundits and self-described experts asserting that Apple's shift to a 64-bit architecture is either a hoax, a pointless marketing ploy that will deliver no real benefit, or an inevitable shift that everyone will eventually follow anyway at some point, and therefore neither newsworthy nor deserving of any credit.

Reports have frequently tried to harmonize all this skepticism by basically asserting that the move to 64-bit in itself will have no real immediate benefit on the iPhone 5s, while acknowledging that it might have some use later for other devices, such as in the next crop of iPads.

Brooke Crothers, writing for CNET, carried a subhead stating that "the company's move to a 64-bit chip is necessary. And it's meaningful that Apple got there first," but even his report concluded, "Do all apps benefit from a 64-bit processor? No. Many, if not most, apps won't see any meaningful benefit."

Stephen Shankland, also writing for CNET, was more forcefully dismissive of Apple's 64-bit announcement.

"Don't swallow Apple's marketing lines that 64-bit chips magically run software faster than 32-bit relics," his subhead warned, adding "64-bit designs don't automatically improve performance for most tasks."

An even more incendiary report by Joel Hruska of ExtremeTech insisted "the 64-bit A7 chip is marketing fluff and won’t improve performance."

These opinions are at odds with what Apple is telling iOS developers in its Cocoa Touch 64-bit transition guide."An app that supports 64-bit processing almost always gains improved performance when compared with a 32-bit app running on the same device" - Apple

"An app that supports 64-bit processing almost always gains improved performance when compared with a 32-bit app running on the same device," the company states in relation to Cocoa Touch development on iOS.

Even if Apple were simply blowing marketing smoke about the value of a 64-bit CPU on a mobile phone, lying in private to its developers about the merits of adding 64-bit support to their apps would serve no purpose; it would actually be quite counter productive.

If the 64-bit A7 brought no real immediate advantage to App Store apps, Apple would really be better suited having its third party partners working on other strategic advancements, of which there are many. Initial skepticism by members of the media is clearly in error, as was the case with the original iPad at its launch three years ago.

Not all 64-bit transitions are identical

Some confusion about the benefits of moving to 64-bit architectures may be related to the fact that for PowerPC, the 64-bit transition didn't initially do much for many apps besides inflate their memory use.

However, that was because PPC originated as a scaled down version of IBM's 64-bit POWER architecture, a design that gave it plenty of registers from the start. PPC also existed as a 32-bit platform for just over a decade before scaling back up to 64-bits with the G5. That relatively young transition to 64-bit didn't require a major architectural overhaul.

For Intel's x86, however, the move to 64-bit x86 processors also brought with it a solution to a long-standing issue of being "register starved," because the x86 family had originated as a 16-bit architecture that was incrementally enhanced into a 32-bit CPU. By the time 64-bit PCs arrived, the x86 design was nearly 25 years old.

Like Intel's x86, ARM's existing chip architecture similarly benefits from new 64-bit hardware features that come as part of the 64-bit package, because the ARM architecture is also now approaching its 25 year anniversary and subsequently due for a architectural leap on the high end.

Apple notes that its new A7 has twice the general purpose and floating point registers (both of which act as small scale storage for addresses and data within the CPU, preventing software from having to access external RAM as frequently) of its 32-bit predecessors.

At the same time, anyone who's been around long enough to remember the PPC and x86 desktop transitions to 64-bit should also remember that Macs and PCs of the era were commonly shipping with less RAM (256-512 MB in the PowerMac G5, for example) than today's iOS devices now have, making the argument that you need at least 4 GB of RAM before you can realize any benefit from a 64-bit architecture particularly bizarre.

And now, from the horse's mouth

"Among other architecture improvements," Apple states, "a 64-bit ARM processor includes twice as many integer and floating-point registers as earlier processors do. As a result, 64-bit apps can work with more data at once for improved performance. "Generally, 64-bit apps run more quickly and efficiently than their 32-bit equivalents" - Apple

"Apps that extensively use 64-bit integer math or custom NEON operations see even larger performance gains. In a 64-bit process, pointers are 64 bits and some integer types, once 32 bits, are now 64 bits.

"Many data types in system frameworks, especially UIKit and Foundation, have also changed. Generally, 64-bit apps run more quickly and efficiently than their 32-bit equivalents. However, the transition to 64-bit code brings with it increased memory usage. If not managed carefully, the increased memory consumption can be detrimental to an app’s performance."

iOS 7 & managing memory in 64-bits

Apple wants developers to recompile their apps for 64-bit, and it makes it easy to do this, handling much of the transitional heavy lifting itself in its Xcode development tools. This delivers a "fat binary" package (aka Universal Binary) that seamlessly deploys both 32- and 64-bit code in the same app package.

The move to 64-bits on iOS also benefits from unrelated enhancements to iOS 7. Apple recommends: "if you have an existing app, you should first update your app for iOS 7 and then port it to run on 64-bit processors. By updating it first for iOS 7, you can remove deprecated code paths and use modern practices."

The company also outlines why it will be beneficial for third party apps to release 64-bit versions of their titles for users, even if those apps don't in themselves score massive gains from the move to 64-bits: the key result will be lower memory use for the end user.

"When iOS is executing on a 64-bit device, iOS includes separate 32-bit and 64-bit versions of the system frameworks. When all apps running on the device are compiled for the 64-bit runtime, iOS never loads the 32-bit versions of those libraries, which means that the system uses less memory and launches apps more quickly," Apple explains.

"Because all of the built-in apps already support the 64-bit runtime, it is to everyone’s benefit that all apps running on 64-bit devices be compiled for the 64-bit runtime, especially apps that support background processing. Even apps that are not performance sensitive gain from this memory efficiency."

Pros & cons of making the 64-bit leap

In short, the benefits of moving iOS apps to 64-bit include the hardware advantages of the A7's 64-bit cores (including more registers, and likely more cache), the improvements and optimizations inherent in the new 64-bit ARMv8 instruction set, and the requisite API enhancements that come along with iOS 7.

The primary downside to the transition is additional system memory consumption in cases where iPhone 5s users can't transition all their apps to 64-bit. This makes moving Apps Store titles to 64-bit a big priority for Apple and, subsequently, is something it will push its third party developers to support.

Even apps that don't do heavy number crunching will therefore benefit from Apple's 64-bit transition, in part because the common libraries and frameworks of iOS 7 they use have already been optimized to take advantage of the new 64-bit hardware, and in part because the transition brings additional side benefits via modern APIs, aiding to refresh the entire App Store library of titles in conjunction with the new appearance, design aspects and other enhancements of iOS 7.

64-bit hurdles for Google's Android

Whether Google's Android will ever make a transition to 64-bit is also difficult to pin down. The Linux kernel Android uses has already been ported to 64-bit architectures, and potentially even ARMv8, although not with the intent of building mobile-optimized devices, a subject "the other guys were not even talking about yet" when Apple announced the A7.

However, Android apps are not Linux processes; they are Dalvik executables that run on a Java-like virtual machine. Typical Android ".dex" apps are not native code in the way all iOS Cocoa Touch apps are.

Instead, they are more akin to Adobe Flash middleware or JavaScript code running within a native browser's JavaScript engine (which is essentially what Google's ChromeOS is, too). Redesigning Android's Dalvik/Java VM architecture to make effective use of a 64-bit processor is not a trivial undertaking.

64-bit Android makes little engineering sense

Unlike Apple's iOS, Android's Dalvik VM wasn't designed with the intent of bringing "desktop class" apps to mobile devices. Google's Android project began as a way to embrace and extend Sun's Java Mobile platform into an open source project Google could use without licensing fees; the Dalvik VM was expressly created to run simple applets on a slow processor without much RAM. Only after the iPhone debuted did Android change course to catch up.

Porting Android's Dalvik to 64-bit would be like converting a subcompact econobox into an all terrain SUV. It would make far more sense to throw it away and start from scratch, where scratch is, for Google, ChromeOS.

There are also "Native" Android apps, often games, that run without using the Dalvik VM for performance purposes. This segmented native/virtual rift further complicates Google's efforts to make Android a truly 64-bit environment, even if it were interested in doing so.

Getting both native and VM apps to work in 64-bit while maintaining 32-bit compatibility for both types of existing software will involve memory management issues of its own, for a platform that already requires more RAM than iOS to work acceptably.

64-bit Android makes little business sense

It's also not clear what benefits a 64-bit CPU would deliver for a platform with few novel and significant apps outside of the cross-platform basics like Facebook and Angry Birds and the large swaths of Google Play titles that are essentially wallpapers, ebooks and music albums, like Samsung's Jay Z market research app.

Android phones are conspicuously lacking console-style video games like Epic's Infinity Blade series. Additionally, efforts to put Android on new form factors, from tablets to dedicated video game consoles to cameras to music players, have all delivered extremely modest results, not just with minimal sales, but also in targeting devices focused at the very low end.

While the media can't stop congratulating Android for shipping on lots of White Box tablets in developing countries, there's no business case for putting high-end 64-bit processors in $39 tablets that are already failing to sell profitably when equipped with bottom of the barrel components.

Apple is maintaining premium device sales of iPhone and iPads that rival the size of the entire Android platform, which is largely composed of nearly profitless low-end devices. Hardware comparable to Apple's, from Samsung's high end phones to Google's Nexus 7 tablet, are not selling in Apple-like quantities, and are earning much lower margins.

Producing a 64-bit luxury Android device on the level of Apple's iPhone 5s would purely be an exercise in corporate self-esteem, comparable to Google's ChromeBook Pixel or its small batch handcrafted Moto X, Samsung's vast array of big tablets with small sales, LG's luxury Prada phone or the gold-plated Porsche Design Blackberry for 20,000 Euros that failed to spare the company from irrelevance.

Delivering such a technically involved transition to 64-bit would also come as Google itself is turning its attention to Chrome, rather than doubling down on Andy Rubin's Android-centric strategy, which so far has primarily amassed significant legal problems related to its cavalier approach to intellectual property and built the company a fan base of users who don't like to pay for things, and in particular, software.

Samsung's 64-bit situation

These realities might force Samsung to virtualize 32-bit Android on top of its promised 64-bit chip for spec's sake, resulting in a truly "hoax 64-bit" done for benchmarking theatrics rather than real performance gains, the very thing the tech media has been quick to accuse Apple of ever since it dropped the A7 bombshell.

There's also another complication involved in Android moving to 64-bit apps. A key problem for Android as a platform is that developers are not actually exercising it. It's not a premier platform for novel, interesting apps. Additionally, developers aren't even taking serious advantage of existing Android 3.x/4.x features, in large part because the largest fraction of the Android installed base is still suck on Android 2.x.

Peruse Google Play, and you'll be hard pressed to find very many apps that require Android 4.x or take any special advantage of the new features it debuted years ago.

Google excludes large portions of Android's installed base in its pie chart depicting the active users of Google Play, but it still can only report that two years after launching Android 4.0, it still only represents half of Play's active app downloaders, and even that segment of Android 4.x is split across three API levels (and two dessert names).

As of this month, Google reports that only 8.5 percent of its active users were equipped with a version of Android 4.2, which was released last November! That's up from 2.3 percent a quarter ago. At that pace, last year's Android won't be above 15 percent by the end of this year.

How many years would it take for a new 64-bit edition of Android to accumulate even a tenth of the platform's userbase, given that the majority of phones sold by Samsung and other licensees are low end devices?

That being the case, if Samsung delivered a theoretical 64-bit high-end "Galaxy S6," it would be unlikely to result in developers generating useful new applications that could benefit from the new chip architecture, resulting in all that work contributing mostly to the increased RAM usage Apple describes as a side effect of mixing old and new apps.

Samsung's alternative is to finish and ship Tizen, the Linux melting pot of abandonware that merges Samsung's Bada, Intel's Moblin and Nokia's Maemo. Tizen could potentially give Samsung its own "pure" mobile Linux platform.

Porting Tizen to 64-bit would be easier because there's currently no 32-bit legacy app ecosystem existing around it. That's also the downside to Tizen.

Tizen could also fragment Samsung's internal development efforts by adding a third supported platform alongside Android and Windows Phone. Alternatively, were Samsung able to successfully launch Tizen as its preferred platform, it would immediately implode Google's Android market share.

More likely is a moderate alternative scenario where Samsung launches a 64-bit Tizen to run on its promised 64-bit hardware while hosting existing 32-bit Android apps in a compatibility environment, similar to BlackBerry's PlayBook OS, although that strategy worked about as well as the gold plated Porsche Design phone.

In any event, it appears that Apple will enjoy a year or two exclusive in selling a 64-bit iPhone and (assuredly) iPad, and be able to transition its library of App Store apps to 64-bit savvy long before any 64-bit alternatives reach even the bleeding edge of adoption on any other mobile platform.

There's also another roadblock standing in the way of 64-bit followers of Apple's A7, and it helps to explain why Apple invested billions to achieve the A7 architecture before anyone else even began thinking about 64-bit in the context of a mobile phone. It will be considered in a future segment.