Microsoft confirmed this weekend that it has delayed, if not killed entirely, Astoria, a tool designed to make it easy for Android apps to run on Windows 10 phones and tablets, according to Re/Code. Microsoft's stated strategy for the Astoria project was to enrich its app store with some of the 1.5 million Android apps that, after displacing Google's cloud services within the apps, the company could monetize with its own cloud services.

Microsoft's ambitions may not be achievable in the time the company allotted itself. Microsoft complicated the project by orders of magnitude when it linked the porting of Android apps to Windows 10 with replacing Google's cloud services. Microsoft wrote an app interoperability library that traps and converts Google cloud APIs for things like payments and advertising to Microsoft's APIs. Microsoft's anemic smartphone market share, 2.6% according to IDC, gave the company no choice but to do all the heavy lifting to acquire Android apps, because a developer-intensive port from Android to Windows wouldn't be justified by its tiny market share.

Microsoft

This slide, presented at Build 2015 by Microsoft's director of OSG John Justice, tells the whole story. The scale of the project as defined in the slide is huge, and the degree of minutia to create compatibility infinite. Astoria begins with a native Android app that is passed through a static analyzer to identify the Google APIs it uses. Then the app is recompiled from an Android Package Kit (APK) format to a Universal Windows Platform package.

“We are windowizing all the most important experiences…we recreated controls, interactions, and user experiences to match the Windows user experience (UX) to eliminate any clashes of interface concepts,” Justice explained. An automated translation of one computer user interface (UI) to another has never been successfully demonstrated, putting a breakthrough on Microsoft's path.

Porting Android apps to Microsoft's Lumia phones could be easy because they are built using the same reference designs and components that Android phones use. Like more than half the Android phones currently shipping, all of the Windows phones use Qualcomm's Snapdragon CPUs and Adreno GPUs. Microsoft's insignificant market share doesn't justify a proprietary hardware design. Running Windows 10 on these devices leverages Android's dominant 82% market share, yielding hardware economies of scale that would be otherwise unattainable. Microsoft could have implemented both the Android OS and Windows 10, creating devices completely compatible with both ecosystems. It would have been hard to camouflage this nonintegrated dual-boot environment. And Android compatibility would flood the devices, pushing aside the Microsoft-branded UX, limiting brand promotion and the monetization of its cloud ecosystem.

At Build 2015, Justice said “we're not running a second kernel. Instead we've done the harder work of redirecting each of the low-level calls you need directly to the Windows kernel.” In other words, Microsoft took the hard way. Windowizing committed Astoria to evaluate every instruction and translate it from Android to Windows at all levels, from the kernel to the user interface. Android has over 5,000 APIs alone, challenging Microsoft's significant engineering resources.

Microsoft could have taken the easy route and made its phones compatible with Android, gaining 1.5 million apps to attract consumers. Without shifting the ecosystem, though, Microsoft would not earn any income from the app stores and search advertising. Or it could have just made switching to its ecosystem easier and more profitable for iOS and Android developers. The profits from in-app purchases, app stores, and advertising are much more compelling than those from smartphones sales with razor-thin margins, bringing into question the business efficacy of selling phones. Or maybe Microsoft could just choose Android to run on its Lumia line, bringing with it all the apps and a direct relationship with the Android development community that it could influence to build for its cloud. But it chose the most complicated alternative to protect its Unified Windows Platform (UWP) strategy that will one day let apps run across every Microsoft Platform, from game console to high-end server.

Windows EVP Terry Myerson said in an interview with Re/Code last month, “Let's get that developer engagement naturally through users and innovation.” It is puzzling to imagine a scenario where Windows 10 grows substantially that doesn't depend on Apple and Google failing on a BlackBerry scale, or a breakthrough in Astoria porting technology.