Android phones offer more apps, compatibility, consistent UX—why should MSFT bother?

Prolific leaker evleaks, whose stock in trade is smartphone-related rumors, has said that Microsoft is going to produce a Lumia phone running Android, branded "Nokia by Microsoft."

This isn't the first time that this kind of rumor has been floated, with both Windows and Windows Phone talked of as candidates for running Android apps. The logic is very simple: developers aren't writing apps for Windows's Metro environment or Windows Phone. They are writing apps for Android. Put those apps on Windows and Windows Phone and the app problem is instantly solved.

Of course, the downsides of this approach are quite clear. If Windows Phone or Windows can run Android apps, why should developers looking at Microsoft's platform bother writing Windows Phone and Windows apps? Might as well just write Android apps and have an app that works both on Microsoft's platform and beyond. This logic applies even to those developers who have taken the plunge and created Windows or Windows Phone apps; why bother maintaining them when an Android app could target the very same users plus many more?

We've arguably seen this in practice already—on BlackBerry 10. BlackBerry 10 supports (some) Android apps, and while it's hard to be certain, it seems that this facility (combined, no doubt, with BlackBerry 10's minuscule market share) has stifled the development of BlackBerry-native applications. There are signs that BlackBerry has largely given up the fight, with the news earlier this week that it has adopted Amazon's Android app store on BlackBerry. This more than doubles the number of apps available for the platform but essentially concedes that developers are unwilling to write native apps for BlackBerry 10.

The difficulties actually run deeper still, in a number of different ways. Perhaps the biggest issue is one we touched on before: the unforkability of Android.

If you buy a Samsung Galaxy S5, for example, it will contain a range of Google-developed software. Parts of this software, such as the operating system kernel, the Java-like virtual machine used to run many Android applications, the basic user interface, are freely available open source (called the Android Open Source Project, or AOSP). Other parts, however, such as the "OK Google" search, the Gmail application, the fancy caller ID that does reverse lookups for you, and the Google Play Store, are not open source. They're closed source components that are not freely distributed or modifiable, and in principle these are only licensed for use on devices that meet Google's compliance criteria.

Moreover, these proprietary parts include various APIs. For example, while AOSP includes a basic geolocation API, the closed source components include a newer, more capable geolocation API. While one can develop apps that use the AOSP API, Google encourages developers to use the closed source API so that they can take advantage of additional features such as geofencing. Collectively, these apps and APIs are known as the Google Mobile Services.

If Microsoft made its platform compatible with Android, it's likely that it would only make it compatible with AOSP. Compatibility with AOSP is more straightforward; Microsoft could, for example, run AOSP inside a virtual machine. This may be a little inelegant, but it would at the very least ensure good compatibility.

But there's no such straightforward route with the Google Mobile Services. Microsoft can't simply bundle those proprietary components with its Windows or Windows Phone devices. It would have to negotiate a license for them. While, technically, this is possible (assuming Google would be willing), it would mean bundling apps such as Gmail, Google Drive, and the Google Play store with Windows and Windows Phone.

From a software compatibility perspective, the impact of including AOSP but not the GMS varies. In some markets, the lack of GMS is not such a big deal. In China, for example, many tens of millions of phones are sold that use AOSP in conjunction with third-party, non-Google storefronts. Apps are routinely built to take advantage of these alternative storefronts, and they use non-Google services for capabilities such as in-app purchasing.

Microsoft even has one of these alternative storefronts of its own, courtesy of the AOSP-powered Nokia X that the company continues to support and update.

But in the US and EU, the Google apps and services are much more important. Vendors, most notably Amazon, have shipped tablets (and, imminently, phones) that use AOSP without the Google apps and services, but the experience of these devices falls short of what most people in these markets expect. For example, want to run the Starbucks app on your shiny new Fire Phone when it's released? No can do. At the time of writing, the app is only available through Google's storefront.

This is, of course, not set in stone. With the release of each new Kindle Fire tablet, Amazon has announced an array of big-name Android apps available for its new tablets; the Fire Phone is likely to repeat this. Developers can modify their applications to work with Amazon's set of services instead of Google's, and it appears that they are willing to do so, at least occasionally.

What's not evident, however, is a long-term commitment to support Amazon's services. Amazon was proud to announce that it had Plants vs. Zombies when it launched the Kindle Fire. But that's where it stops. The smash hit Plants vs. Zombies 2 is nowhere to be found. Given the choice, Electronic Arts has opted not to bother making an Amazon-compatible version of the new game. Likewise, while many of King's games are available on Amazon's store, including Candy Crush Saga, the new release Bubble Witch Saga 2 isn't there.

It's this gap, among other things, that leads none other than Sundar Pichai, who oversees Android at Google, to say that he doesn't view phones such as the Amazon Fire as "Android Devices." He categorizes most of the phones in China as being "'Android open source' rather than Android."

Unless Microsoft included or cloned GMS, its own Windows and Windows Phone devices would be in the same boat as Amazon's. Yes, they'd work with lots of AOSP-compatible apps, and yes, Microsoft could offer alternative APIs for things like geolocation and in-app purchasing, so apps could be ported if developers wanted to. But if you wanted to call an Uber taxi? No go. Sext someone in Snapchat? No official app. Show off your lunch to all your Instagram buddies? No official app. More generally, whenever you see someone advertising an app with this logo:

There's a pretty good chance that it won't be available for your hypothetical Windows Phone. This is in spite of the work required to port being really quite light overall. Developers have shown that they can't really be bothered.

To emphasize this point further: porting an Android app to Amazon's fork is (in general) tremendously easier than porting that same app to Windows Phone. And yet, if you want official, first-party apps for, say, Instagram or WhatsApp, Windows Phone has them. Amazon doesn't. Both platforms have a range of unofficial, third-party apps for these services.

It's not impossible that, given sufficiently many users, developers would support Microsoft's Android in a way that they haven't with Amazon's. But getting there is hard work: Microsoft would need to somehow draw people to its platform's second-rate Android experience in order to get a long-term good one.

Microsoft could look at this and decide that it's still worth doing. Sure, it won't really make a big difference for the important brand-name apps and latest games, but it will mean that Windows and Windows Phone can start to offer the same ridiculously high app counts (and the endless breadth of crap) found on other platforms. This leads to another problem—it's going to be quite hard to do.

It's easy for Amazon to offer this level of compatibility, because Amazon runs AOSP on the bare hardware. It's going to be rather harder for Microsoft to do the same on top of the Windows kernel. Android applications are split into two kinds; those written in Java, running on either the Dalvik or ART virtual machines, and those written in C and C++. While most apps are the former type, the native C++ is valuable for things such as high performance game engines, signal processing, and physics simulation.

One option would be for Microsoft to just ignore the native apps and stick to the Java ones. Adapting the AOSP runtime to work on Windows wouldn't be trivial, but equally, it shouldn't be prohibitively difficult. This is similar to the route taken by BlackBerry; BlackBerry 10 can run repackaged Android apps, but only Java ones. Native applications must be ported to BlackBerry OS.

This would, however, further limit the range of Android applications that are actually usable.

An alternative approach might be to run a full AOSP installation inside a virtual machine. This is the approach taken by BlueStacks, a piece of software that lets Windows users run Android apps already. However, it's extraordinarily heavyweight, with the VM taking a non-negligible time to boot and using a substantial amount of memory. That might be tolerable on a PC or a tablet, but it's likely to be prohibitive on a phone—especially as Windows Phones with 512MB RAM continue to be made and sold.

Even with the software running, there's an obvious problem that Android apps aren't Windows or Windows Phone apps. Android apps have their own particular style for layout, menus, interactions with the rest of the operating system (for example, for sharing between apps). Windows and Windows Phone apps all do these things differently. Stylistically, the differences might be reduced as Android developers start to follow Google's new "Material" guidelines, but nonetheless they're going to look and feel alien on Microsoft's platform.

Android apps on Windows Phone will hurt native development and provide a poor experience for users, plus incompatibilities will mean that, particularly in the EU and US, many of the big-name apps that might be lacking on Microsoft's platform still aren't filled.

And yet, these problems don't appear to quell the rumors. Paul Thurrott suggests that these efforts are some sort of Plan B. If Windows and Windows Phone can't ever get the app support that Android offers, then Microsoft goes the BlackBerry route: run the same apps, or at least a subset of them.

The Verge's Tom Warren goes further suggesting that the Nokia X is some kind of long term play, perhaps that AOSP is Microsoft's long-term bet for its own smartphone platform.

Both options mean giving up. Giving up on attracting developers to Windows and getting them to build applications. And perhaps, if the company switches to AOSP, giving up on Windows entirely.

In neither case is any kind of coherent, viable strategy evident.

For example, the rationale that many have offered for the Nokia X is that it doesn't matter that it isn't running Windows Phone. Nokia X is built to use Microsoft's services such as OneDrive, Skype, and Outlook.com, and long term these are where the revenue comes from.

This explanation, while popular, is sorely lacking. Microsoft isn't in business to accumulate users of its services. It's in business to make money. How much money is made from a OneDrive user who never needs to buy any extra storage? Nothing. Or from an Outlook.com user who only uses an e-mail app and hence never sees an advertisement? Nothing. A Skype user who never calls a regular phone line? Nothing.

Worse than nothing, in fact; they all cost money.

This might be OK if there's enough money to be made from, say, app sales. The cut taken by the store owner can make a nice business, as long as app sales are high enough. Without a truly vast number of users (and sales), however, the money to be made here is negligible. If Microsoft were to go further and support non-Microsoft stores—as it does on Nokia X—then this becomes even more tenuous.

The real way to make money on smartphones, of course, is to sell high-end handsets at substantial markups like the Apple iPhone 5s and Samsung Galaxy S 5. But this too is problematic. Those high price, high-end handsets need the big name apps that US and EU customers look for. Those apps, in turn, need Google Play. An app selection that's comparable to the Nokia X or Amazon store isn't going to cut it. This kind of AOSP strategy is a low-end, low margin strategy.

There's also the deeper question: if you're after Android apps, what would possess you to buy a Windows Phone to run them when they'll always be better on a real Android phone? The Android phone will offer a wider selection of apps, with better compatibility, a more consistent user experience, and potentially richer functionality. Microsoft isn't going to be able to offer a "better Android than Android."

The reason such rumors are even given credence in the first place is that Microsoft's strategy isn't very clear right now. Windows on the desktop remains strong, and while PC sales have dropped, they're still substantial. Windows and Office have the enterprise desktop market locked up, and as Satya Nadella made clear in his company-wide e-mail, Microsoft is going to continue to ensure that Windows will continue to be "the most secure, manageable and capable OS for the needs of a modern workforce and IT."

Nadella's e-mail also indicated that Microsoft doesn't intend to give up on the consumer market, to the extent that he doesn't even see distinct consumer and enterprise user-bases. He writes that Microsoft "will think of every user as a potential 'dual user'—people who will use technology for their work or school and also deeply use it in their personal digital life."

But beyond that, the company's plans are a bit of a conundrum. The older goal of "Windows Everywhere" seems, officially at least, to be a relic of history. Again, from Nadella's e-mail: "[Microsoft's apps] will be built for other ecosystems so as people move from device to device, so will their content and the richness of their services—it's one way we keep people, not devices, at the center."

Enabling Android apps on Windows or Windows Phone, or even switching from Windows Phone to something AOSP-powered, could be a next step consistent with this. After all, if Microsoft is already building high quality apps for Android, and if Android powers the devices that people want to use, adopting (or perhaps even co-opting) Android for its own mobile platform would make sense.

Countering that, however, is the way Microsoft appears to quietly still be pushing for "Windows Everywhere."

As a purely practical matter, "Windows Everywhere" has never really been possible until perhaps this year. Sure, Microsoft might very much have wanted Windows to be everywhere for much longer than that, but prior to Windows Phone 8.1, the company never had one singular "Windows" that could really run everywhere. Windows just didn't run on enough kinds of hardware. Windows Phone 8.0 did a lot to get the Windows kernel ready for running on phones and other small hardware, but it wasn't until Windows Phone 8.1 that Microsoft actually had a single platform—kernel, application model, APIs—that could run everywhere.

And Microsoft clearly wants it to run everywhere. The company decided to make Windows licenses for small "Internet of Things" devices, and has seeded developers with Intel Galileo development kits, which is Intel's x86 competitor to the Arduino microcontroller.

Nadella backed this up in his e-mail, writing that "Windows will create a broad developer opportunity by enabling Universal Windows Applications to run across all device targets." At the very least, Windows apps will be everywhere, and that tends to imply that Windows itself will be. Nadella also suggests that Windows is going to continue to evolve to enable it to fit into more places, writing "Windows will evolve to include new input/output methods like speech, pen and gesture and ultimately power more personal computing experiences."

This all sounds an awful lot like "Windows everywhere" and if that is indeed the goal then supporting Android apps, much less switching to AOSP, would run directly contrary to this.

One thing is clear: Google wants its platform everywhere. At I/O it announced that it would be bringing Android apps to Chrome OS, letting Android developers target not just phones and tablets, but also laptops and desktops. Even if Microsoft gives up on its desire to encroach on what has become Google's territory—the smartphone—Google shows no signs of giving up its efforts to take a piece out of Microsoft's. With Google offering competitors to all of Microsoft's major desktop software, Microsoft's support of Android looks like an increasingly risky proposition: it strengthens Google's platform, while weakening Microsoft's own. Giving up Windows on the phone is one thing; making Android and Chrome OS a viable competitor on the corporate desktop is quite another.