Much has been said about how Apple's (AAPL) ecosystem still allows it an intrinsic advantage over competitors such as Google's (GOOG) Android or Microsoft's (MSFT) Windows Phone. What I will add in this article, however, is my belief that an architecture decision by Apple has also given it an intrinsic and durable advantage over Google's Android OS.
This intrinsic advantage allows Apple to run Apps in its devices faster than those same Apps would run on Android devices with comparable hardware specs; or alternatively, to consume less power when running at the same speed. This is non-trivial for Apple, for both performance and power consumption come at a premium in battery-reliant mobile devices. It's also non-trivial because an architecture decision is something which stays rather immutable over long periods of time, so any advantage gained is hard to overcome. Here it goes …
Objective C compiles to native code, Java does not
To make an App for iOS, programmers usually use Objective C (C and C++ can also be used). These programs are then compiled into native code that runs directly on iOS devices. As for Android, the programmers will usually use Java, which will get compiled into Dalvik-compatible bytecode. Then, at runtime, these programs will rely on the Dalvik JVM (Java Virtual Machine) to translate the bytecode to native code on the fly. The JVM can also use JIT (Just In Time) compiling to produce native code for instances where such can render faster code execution.
The problem here is that translating code at runtime, or compiling at runtime, can have a serious impact on performance versus just running native code directly. Theoretically the JIT compiler could target the specific hardware the program is running on and produce faster code, but since Apple's compiler also targets a very limited set of hardware, such advantage is nullified. What isn't nullified, though, are the disadvantages introduced by the need to translate or compile at runtime.
This, in turn, produces the unsung Apple advantage. Apple gets, for the same hardware specs, an intrinsic performance advantage. Apple doesn't really lean on this advantage to produce much faster devices, though. What Apple has done is, it has kept its CPUs at a lower clock frequency (even the A6 CPU on the iPhone 5 clocks at "just" up to 1.3Ghz) - something most of the public doesn't know or care. This lower CPU frequency when compared to top-end Android devices, though, allows Apple's devices to, at the same performance level due to the unsung advantage, consume less power - something most of the public actually cares about. It can also conceivably lead to cheaper or higher-yielding CPUs. And the advantage doesn't end there. Having to translate or compile code at runtime also implies a much larger number of CPU instructions and each of those burns power while producing the performance disadvantage, once again reinforcing Apple's decision as being the right one.
Furthermore, it's not just the Android Apps themselves that have to go through the Dalvik JVM. In Android, even a large part of the OS doesn't run natively, it's also going through the Dalvik JVM, adding further overhead. Not so in iOS, where the OS is compiled to run natively in Apple's hardware.
So there you have it, through 2 structural decisions - limiting the hardware diversity of its devices, and making compiled native code execution the standard - Apple gets a structural advantage over its main competitor. Google's decision to make the standard using Java in a JVM was probably informed by the need for portability over the hardware diversity it expected.
Not a coincidence
It's perhaps not a coincidence that Google ended up launching the Android NDK, which allows for native execution of C++ code although with some severe disadvantages and complexity. It's also perhaps not a coincidence, then, that Microsoft, having followed a path similar to Google's with Windows Phone 7, has now reversed course and made native code the standard for Windows Phone 8.
The wrong way Android goes about it
Conceptually, and not just in this Dalvik JVM case, Android makes a bet: that the hardware evolution will smooth away any disadvantages or shortcomings of the architecture that was chosen for it, while keeping the advantages. However, both the underlying performance of the mobile devices and the demands put on them have increased side-by-side. This, in turn, has allowed Apple to keep its structural advantage gained from having gone with the different architecture allowing it to run code faster for any given hardware specification, or alternatively, allowing to run code at the same speed while consuming less power.
Android's structural disadvantage can also be seen from the way implementing alternative architectures to run Apps in the same hardware can yield much better performance. For instance, here's a comparison between Dalvik, Mono C# and Sun's ARM JRE, showing how Dalvik slows things down horribly.
Not the only instance where native code shows itself to be important in mobile devices
At some point, HTML5 was seen as a menace to specific ecosystems such as Apple's iOS. The idea was that HTML5 would allow for cross-platform standards-reliant Apps which could run in any ecosystem, and thus eliminated the need to buy into any particular ecosystem to have access to those Apps. By making the ecosystem less relevant, it would destroy the barriers to displacing those same ecosystems in the market. It would thus allow customers to choose their mobile devices with less attention to what ecosystem they were reliant in.
However, once again a problem similar to that faced by Android's architecture choice, but even more pronounced, emerged. The reason is simple. HTML5 Apps are interpreted; they don't run directly on native code. Here, too, making an App in HTML5 incurs a huge performance hit. So, in performance and battery-limited devices, HMTL5 was quickly dethroned by much more efficient Apps written in native code, and the ecosystems once again regained their prominence. The menace faded way, and HTML5 is now relegated to specific and less performance-hungry applications.
As an example of this, I can point to Facebook's (FB) abandonment of HTML5 for its iOS App, reverting to developing it using Objective C. The end result was a 100% improvement in performance. Likewise, Facebook is also going the same way with Android, swapping out HTML5 for native code.
Apple's decision regarding its development environment has given it a structural advantage regarding performance and power consumption in a field -- mobile computing -- where both come at a huge premium.
Although Windows 8 will seek to narrow this advantage by adhering to an architecture which will also easily allow for native code, Google's Android -- Apple's main competitor -- will for now remain wobbled by this architecture decision, which should help in ensuring Apple's dominance of the mobile space will remain unchallenged for some time longer. This is all the more relevant when Apple's valuation now discounts Apple's fall from grace on a rather short timeframe, given Apple's ex-cash FY2013 P/E stands at just 8 times (considering $121 billion in cash and investments, $50.05 FY2013 EPS estimate, 941 million shares, $527.68 share price).
Due to this unsung advantage and other effects, it would at this point seem -- as Mark Twain would put it -- that news of Apple's death are greatly exaggerated. Not to say, though, that at some point Apple won't lose its unique market position and margins, so the market's fears, which right now seem exaggerated, could at some point in the hopefully distant future become reality.
Disclosure: I have no positions in any stocks mentioned, and no plans to initiate any positions within the next 72 hours.