How Microsoft might escape the Windows Phone “App Trap”

Microsoft’s Windows Phone operating system is a platform beset on all sides. Though the OS grew slightly in terms of units sold in 2014 to 34.9 million, that’s dwarfed by the 192.7 million units sold by Apple or the whopping 802.2 million Android phones shipped. Microsoft lost market share because the size of the market grew so fast, a growth mostly absorbed by Android. Even Apple lost market share, slipping a third of a percentage point in spite of the untapped demand for larger form factor iPhones sated by the release of the iPhone 6.

A mobile market dominated by Android and iOS

With 80 percent of the market in 2014 going to Android, how on Earth is there room for a third ecosystem when even the second ecosystem loses ground in spite of a new version that generated record sales?

Market recognition is certainly an issue. Although most technology readers have heard of Microsoft’s efforts, we are, in a word, “weird.” Lack of recognition is mostly linked to a dearth of apps for the platform. Companies make mobile apps and advertise their presence through icons indicating availability in the Apple App Store or GooglePlay. Users rarely see icons for the Windows Phone version (because they don’t exist), and thus, familiarity diminishes.

What’s worse is that the network effects of dominant mobile platforms make the development road to market share growth that much steeper. I’m involved in a lot of mobile development these days, and it’s rare to find helper libraries to support one on the path of Windows Phone development. Want to integrate PayPal payments into your smartphone app? There are iPhone and Android widgets available, but nothing for Windows phone. Want to use that camera to recognize credit cards, and do security validation? Similar problem: they only have iPhone and Android widgets (though you can roll your own if you want, as most have generic service APIs). The app disproportionality is mirrored by developer tools, which is logical, as why bother making tools if few will use them?

Android apps on Windows Phone?

Some have suggested that Microsoft should support Android apps on Windows Phone and maybe even beyond, on desktop Windows. That’s a fast chute to the trash bin of history… just ask Blackberry, who has supported Android apps for quite a while. It didn’t make much measurable difference and worse, reduced the likelihood that anyone would bother to write for their platform.

If you want to play the platform game, there is simply no alternative to getting people to write for said platform. The alternative is to march in step with the needs of a competitor, and there is no more aggressive a competitor than Google where Microsoft is concerned.

A possible solution presents itself in the strategic positioning of Windows 10 and the frameworks that run on it. Windows accounts for over 90 percent of computers in 2014, and over 57 percent if you take into account Windows 7 and up. A key goal with Windows 10 is to make an app platform that will let developers deploy a store app to all the platforms that support Windows 10. To encourage widespread adoption, most users of existing systems with Windows 10 receive upgrades for free.

As Windows 10 will work on PCs, tablets, phones, the Xbox One and embedded devices, that means that the target market for Windows store apps will be much bigger than just the PC slice of the programming ecosystem. Granted, there will be work involved in dealing with the diversity of form factors, but layout idiosyncrasies are a lower hurdle than wholesale API incompatibilities.

If you’re focusing on Windows, then that’s pretty cool. What if there was a way to extend that to other platforms? What if your app could work on most of the 800 million Android devices that shipped in 2014?

Taking .NET beyond Windows

Microsoft is taking the .NET stack beyond Windows and onto Linux and Mac OS X (Mono got there first, but this would be Microsoft-supported). Further, the .NET native compiler will convert .NET assemblies to code that can run directly on a target platform. Most of this native magic will happen behind the scenes. Developers will upload store apps to Microsoft, and as noted in this blog post by the .NET Team:

“Our compiler in the cloud compiles the app using .NET Native in the Store, creating a self-contained app package that’s customized to the device where the app will be installed.
In the end, your app is optimized for your user’s device, whatever platform, architecture, OS or form factor it might be running. The end result – apps just get faster.” (Emphasis mine)

Android would be particularly well-suited to this approach, as the baseline platform is open to an extent that iOS is not. I’m sure some framework pieces would be best pre-installed to support the adapted store app, which could prove a barrier. On the other hand, Microsoft has considerable leverage over Android OEMs in the form of patent licensing. Could they use that to get a baseline framework pre-installed that would make a “Windows Store apps everywhere” approach work? Would Google respond by tightening the mostly secret terms imposed on OEMs to prevent them from doing this?

What about Windows Store apps in the Google Play store?

Could Windows store apps appear in the GooglePlay store? Amazon’s Fire devices are built on an Android base, but only the Android Open Source Problem (AOSP) portion, which is the part that lacks all the essential Google services that make Android “Android.” They also can’t install the GooglePlay store, the apps for which wouldn’t run anyway due to the lack of that proprietary Google layer. As a result, Amazon’s custom store is a lot smaller. Amazon is not a company short on resources, and their failure to crack this nut reveals the considerable difficulties.

Yet, Microsoft — unlike Amazon — controls the platform used by an important portion of the computing family tree. There are lots of Windows developers who would jump at the chance to write their Windows apps in a way that made them available on Android platforms.

Further, Android devices would — unlike Amazon’s offerings — still be the Google-blessed sort. Users would still have access to the Play Store, along with all the extra services that make full Android different than the AOSP baseline.

User interface (UI) conventions matter to some extent, though one can argue that they matter less as the market has matured. There was once a time when pundits spoke of the importance of making apps look like integrated parts of the operating system. Then, mobile Facebook happened. The importance of building a UI brand that spans across mobile platforms started to matter more.

Some conventions still matter. Apple has a single button. Android and Windows have three, though two of them do broadly similar things. Even so, modern app users seem more willing to deal with apps that deviate from convention.

The exception, as always, is Apple. Apple’s interfaces tend to be very consistent, a consistency Apple imposes via its control of the app store. And though Apple under Jobs eventually backed down from restrictions on applications that were transcoded to native, something that saved frameworks like Unity, among others, they still wield a degree of control over apps that has no parallel on Android. And then, of course, there is the Apple in-app purchase tax. There’s no real way around that.

But, as the numbers from IDC show, though Apple’s share of profits, and the tendency of iPhone users to download apps to a greater degree than Android users, gives them outsized influence, they are still only 14.8 percent of the market in 2014. Stated differently, this is the year when the iPhone 6 [Ed. – And larger iPhone 6 Plus] appeared, form factors that Apple fans have waited years to see.

Apple is unlikely to repeat that trick in 2015, and Android will continue to march triumphantly across the globe.

Android is the bigger fish in this game and due to its open core, it’s an easier catch. I don’t doubt there are difficulties. Microsoft can’t just install a .NET runtime and call it a day. It has to be something that is snappy and responsive, and doesn’t bog down the performance of apps written for Android the normal way. It will have to integrate with native APIs to a high degree.

Further, Google has leverage over Android licensees. As noted, they may attempt to impose restrictions that hinder such a strategy. On the other hand, 80 percent of the market, combined with its dominance in web search, make Google an interesting target for antitrust regulators. Google will want to avoid the chain put around Microsoft’s neck in the late 90s at all costs.

Some may note that this is comparable to the cross-platform client strategy Sun Microsystems attempted with Java in the 90s. To an extent, that is true, though Microsoft has advantages Sun lacked. Sun never had much of a presence in the client platform space. Microsoft does.

Pitfalls abound, if getting Windows store apps into the Play store proves impossible, they would have to create a parallel store. That would be expensive, and require a great deal of marketing, but highly lucrative, if successful.

Microsoft is the best positioned of any company to try. They have a large developer community, a growing stable of services available for iOS and Android, and products that could lure consumers over the line. It leverages the success of Android as a distribution medium, while not simply accepting Android API domination. Further, it doesn’t alter the core unification message of Windows 10. If anything, it would give it more reach than it could manage on its own.

Microsoft jettisoned Android-based Nokia X as a platform soon after buying Nokia’s mobile phone business. Perhaps it should reappear soon, though in a shape no one expects.