Android and iOS apps on Windows: What is Microsoft doing—and will it work?

At its Build developer conference last week, Microsoft made a pair of announcements about Windows development that were more than a little surprising: Windows will support applications developed for iOS and Android.

Neither OS/2 nor BlackBerry 10 has made a success of this capability. There are two major problems with supporting foreign applications on a niche platform. The first is straightforward: it removes any incentive for developers to bother with the native platform. Investing in developing for a minor platform is already something of a gamble, and by telling developers "Oh hey, you can just use your existing Win16 or Android program..." as IBM and BlackBerry (respectively) did, you're implicitly sending them a message. "Don't bother learning our platform or writing native apps for it."This immediately felt like a dangerous move. Windows will not be the first operating system to run foreign applications. Famously, IBM advertised OS/2 as a "Better Windows than Windows" in the 1990s, boasting that its platform would run all your existing Windows applications with greater stability and performance. More recently, BlackBerry 10 included support for Android applications, with BlackBerry licensing the Amazon App Store and using it as its gateway to a world of Android-compatible software.

It turned out as expected for both platforms. While a few true OS/2 applications were created—and similarly there are some true BlackBerry 10 apps—they're relatively unusual. After all, what's the point? If IBM is going to boast about just how well OS/2 will run Win16 apps and those Win16 apps can be sold both to OS/2 users and to Windows 3.1 users, why would a developer write anything other than a Win16 app?

This capability cedes a lot of control. By being dependent on apps developed for a third-party platform, you give the owner of that third-party platform the power to choose how to evolve its APIs and add new features. This bit OS/2 hard: while IBM was busy promoting how well OS/2 could run 16-bit Windows applications, Microsoft was busy encouraging developers to create new 32-bit Windows applications and end-users to buy the 32-bit capable Windows 95. This new world of 32-bit software wouldn't run on OS/2, and so the big OS/2 feature that IBM heavily marketed was rendered semi-useless. OS/2 found some niche success, but it was ultimately a failure.

Supporting Android apps creates similar risks. If Android software constitutes a major part of a platform's software ecosystem, any changes to Android (new APIs or capabilities, say) that Android software expects to be able to take advantage of have to be replicated. This is, however, tempered by Android's uniquely poor update situation. Most Android phones don't have access to the latest and greatest version of Android or the latest and greatest Android features, so most Android software has to refrain from demanding such capabilities. This means an Android-compatible platform could trail Google's cutting edge by a year or more and still be highly compatible with Android apps.

This is less true of iOS. A platform striving for compatibility with iOS will have to aggressively keep pace with Apple's developments, because Apple's developer community demands nothing less.

These concerns are why the idea of Android apps on Windows was met with what can at best be described as confusion when it was first rumored last year. It seemed like Microsoft was simply preparing to make the same mistakes others had made before, one last-ditch effort to prop up its phone platform.

The way Microsoft presented the Android and iOS support on stage last week wasn't particularly encouraging. The way that Projects Astoria and Islandwood—the codenames for Android and iOS app support, respectively—were promoted in the keynote presentation, one might think that the Android and iOS support were pretty solid substitutes for the Universal Windows Apps that are native to Windows 10 on all the hardware form factors it will support. It seemed like porting apps from those platforms would be an effective alternative to any plans to develop native Windows applications.

The risk that Astoria and Islandwood will further diminish native Windows development is certainly real. The repercussions of this support could be every bit equivalent to IBM making OS/2 compatible with Win16 software, or BlackBerry 10 promoting the Amazon App Store. But the situations are notcompletely equivalent. While it's certainly not certainty, one can see how things might turn out differently for Microsoft than they did for IBM and BlackBerry.