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.

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.

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.”

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 not completely 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.

Inside Astoria

Astoria and Islandwood are superficially similar, but their underlying technology and implementation is very different. For developers, Astoria is probably the more straightforward. Windows has long included the ability to support multiple API families through a feature called subsystems. The Win32 API that almost all Windows software (including Universal Windows apps) use is obviously the biggest and best known of these APIs, and in modern versions of Windows is in fact the only API. But historically, there have been others. The very first versions of Windows NT included, of all things, an OS/2 subsystem that supported certain kinds of OS/2 applications. It was a relic of history, a product of Microsoft and IBM’s once cooperative operating system development.

Windows also included a POSIX subsystem. POSIX is the IEEE-standardized API that essentially defines the Unix API. Operating systems such as Solaris, Linux, OS X, and AIX all implement POSIX or some close approximation thereof. Windows NT included POSIX support because US government regulations at one time required it. Unlike the OS/2 subsystem, the POSIX subsystem was maintained and even expanded for many years, first by third parties (Interix) and later by Microsoft. The Interix tools were bought by Redmond and variously rebranded as Services For UNIX (SFU) and the Subsystem for UNIX Applications (SUA).

The OS/2 subsystem was dropped in Windows 2000. The POSIX subsystem was an optional Windows component as recently as Windows 7, though it isn’t supported in Windows 8. However, the underlying operating system components to support subsystems are still there and still functional, and Project Astoria takes advantage of this. It introduces a new Windows subsystem: the Android subsystem.

The Android subsystem implements a subset of Android’s APIs on Windows. This subsystem offers Android-style APIs for things like filesystem access, graphics, access to sensors and the camera, process and thread creation, security, and networking, leveraging the Windows kernel to provide these core services.

The specific set of supported APIs hasn’t been published or finalized yet, but it’s likely to be a mix of three things, reflecting the way Android is built. Android has a Linux kernel and a handful of open source native libraries that native code apps can use, a set of open source Java APIs that Java apps use, and another set of proprietary Java APIs that tie in to Google services, collectively known as Google Mobile Services (GMS). The first two of these are included in AOSP, the Android Open Source Project. The third is not.

For the open source parts, Microsoft can, in principle, use the open source code in its implementation, presenting apps the same Java APIs that they expect, but redirecting to Windows services as appropriate. The Android sharing API, for example, can be plumbed in to Windows’ sharing system. For GMS, using the source isn’t an option. Instead, Redmond has produced workalikes for at least some of the GMS APIs. For example, GMS includes APIs for in-app purchases and location services, and Microsoft has developed counterparts backed by its own services.

The new subsystem will be a preinstalled, built-in part of Windows Mobile, the new (and very old) name used for the Windows version that runs on phones and small screen tablets. It’s only for ARM processors. Other versions of Windows won’t include it.

The developer experience for Astoria is very similar to the regular Android developer experience. Devs will continue to use Android development environments, such as Eclipse or IntelliJ, and they will continue to produce Android app packages: APK files.

Apps that use only the subset of AOSP APIs that the subsystem supports will not, in principle, need any changes. In fact, the existing APK that’s already distributed to Android users should work without requiring any recompilation or modification at all. Apps that use GMS APIs will need some changes so that they reference Microsoft’s workalikes instead of Google’s code.

Microsoft is also offering some Windows-specific APIs to give Android apps access to features such as Live Tiles. Naturally, developers will need to make code changes to take advantage of these APIs. These are limited, though, and Android apps won’t have full access to all the underlying Windows capabilities.

Microsoft won’t be going the BlackBerry route of supporting the Amazon App Store on Windows. Instead, Android developers will have to submit their APKs to the Windows store. The store will verify that they don’t use any unsupported APIs and then wrap the APK in a Windows AppX package.

Off to Islandwood

One might imagine that a broadly similar set of techniques might be used to get iOS apps on Windows. There’s nothing particularly Android-specific about the subsystem approach, and the use of APKs and the regular Android development process means that it’s very easy for Android developers to ship Windows versions of their apps if they choose.

But Islandwood is completely different from Astoria. Islandwood programs don’t have their own subsystem. They’re just regular Windows apps using the regular Win32 subsystem. Their novelty is that they’re not written in one of the languages that are traditionally used to write Windows apps, such as C++ or C#. Instead, they’re written in the language that is still the mainstay of iOS development: Objective-C.

Microsoft has added support for Objective-C to Visual Studio. The development environment can import Xcode projects and understands Objective-C source files, with color coding and autocomplete and all the other features that developers expect from a development environment. The compiler supports Objective-C and can compile it into regular Windows executables.

This has been done by grafting the Objective-C support from the open source clang compiler, part of the open source LLVM toolchain, onto Microsoft’s existing C++ compiler infrastructure. This is significant because the C++ compiler infrastructure does a lot of important work. It produces debug output in a format that Visual Studio understands, it performs all the magic required to enable interoperability between C++ and .NET and so on. It’s also responsible for imposing various runtime security checks to detect some programmer errors and so on. Objective-C programs built in Visual Studio get all this from the compiler.

This means the compiler will support all the hardware platforms that Microsoft’s C++ compiler handles as well. Right now that’s three platforms—32- and 64-bit x86, 32-bit ARM—and later in the year, they’ll be joined by a fourth, 64-bit ARM.

An iOS-originated app being edited in Visual Studio 2015.

Credit: Microsoft

As for support for Apple’s other language, Swift? It’s being worked on.

Compiling the code is, of course, only part of the story; being able to build Objective-C code doesn’t help if you have to rewrite every single API call. Accordingly, Microsoft has implemented a subset of the iOS APIs on Windows. This includes low-level Objective-C features, such as automatic reference counting and blocks, basic libraries such as CoreFoundation, graphical libraries including UIKit, CoreAnimation, CoreGraphics, and CoreText, 3D support through OpenGL, and some services such as StoreKit and Notifications. As with Astoria, these are plumbed in to Windows features where it makes sense. StoreKit in-app purchases will map to corresponding Windows Store functionality, for example.

This API support library will be bundled with Islandwood apps.

One remarkable aspect of Islandwood is that Microsoft kept it secret. Astoria was apparently started about a year ago and leaked almost immediately. Islandwood appears to be the product of some kind of an acquihire; a startup called Inception Mobile offered a similar facility to port iOS applications to other platforms. Inception Mobile cofounder Salmaan Ahmed presented part of a session on Islandwood at Build, and his LinkedIn profile says that he has worked at Microsoft since August of last year.

Even with Islandwood, porting iOS applications to Windows will require more work than Android apps require. While some Android apps will be 100 percent compatible with Astoria, that won’t be the case with Islandwood. There are differences between the platforms that need handling—Android and Windows Phone have a back button, for example, whereas iOS doesn’t—and devs will have to change code accordingly.

First resident of Islandwood—Candy Crush Saga.

Credit: Sean Gallagher

The impact this has will depend on the app. King’s Candy Crush Saga for Windows Phone is already using Islandwood, and the changes required were described as a “few percent.” CCS supports features including in-app purchases in its Windows Phone version, taking advantage of the StoreKit API mapping. However, as a game, its user interface is largely custom anyway. Apps that lean more heavily on UIKit may well need more work to ensure that their interfaces meet the expectations of Windows users.

The flip side is that these apps are full Windows apps. They can access any Windows APIs, even those with no iOS equivalents such as Live Tiles and NFC. They’re also not going to be limited to Windows Mobile; Islandwood applications will be able to target any Windows 10 platform. Since they use the standard Windows compiler infrastructure, they’ll support mixing languages. A developer could choose, for example, to use C# for its Live Tile support even if a project is otherwise using Objective-C.

Close to the OS/2 and BlackBerry strategy, but not identical

Whether using Astoria or Islandwood, there’s a key difference between what Microsoft is doing and what IBM and BlackBerry did before. Astoria and Islandwood both require some commitment on the part of the developer. The people writing Win16 apps never really cared about OS/2. They were just writing Win16 apps. The occasional OS/2 user may have bought a shinkwrap piece of Win16 software with the intent of using it on OS/2, but this was invisible to the developer.

A similar situation exists for BlackBerry 10. Devs can submit their apps to the Amazon App Store because they have a passing interest in Amazon’s tablets (or perhaps its phone). The fact some BlackBerry 10 users might download those apps is irrelevant and invisible.

With Astoria and Islandwood, the first step must be taken by the developer. That step is potentially not huge—it could potentially be an unmodified APK with no tailoring to Windows at all—but nonetheless every developer must make a deliberate effort to expose their apps to Windows users. Windows may not be their primary platform, but equally, it won’t be a platform that they’re completely ignoring.

This in turn should make those developers a little more sensitive to how well their apps work on the platform. Fail to use Windows features such as Xbox achievements or Live Tiles, and they’ll have an app that gets bad reviews and a poor reception. These won’t be foreign applications that were written oblivious to the demands of Windows.

Islandwood will make these even more acute, since it will require recompilation and some code changes. It will only work for developers that care, at least a little bit, about making a Windows app.

As such, the app experience of ported apps on Windows should be somewhat better than on its historic predecessors.

Microsoft’s approach is also, arguably, less likely to discourage native app development. The limitations on Astoria preclude it from truly replacing native development, and while one could imagine that eventually those limitations will be relaxed, that won’t happen any time soon. Astoria apps will be able to reach phones and small tablets, but the broad range of Windows platforms (laptops, PCs, Xbox One, and one day even HoloLens) will be off-limits. You’ll have to go native for that.

And that’s not entirely insignificant. Windows’ position is very different compared to the positions of OS/2 and BlackBerry 10. While Windows doesn’t have the reach that Microsoft would like in the smartphone and tablet space, it still has a vast number of users running laptops and PCs. Microsoft said that it was hoping to have a billion users running Windows 10 within the first two to three years of its release. That’s why Windows 10 is being offered as a free upgrade for Windows 7 and 8 users. Microsoft doesn’t want its platform fragmented across a bunch of versions; it wants everyone running Windows 10 and everyone able to run Universal Windows Apps.

Even if it only manages half of that, 500 million users is still a substantial audience. There’s probably some money to be made there, and Astoria apps won’t cut it. Microsoft is counting on this to ensure that Astoria doesn’t kill native development for Windows on the phone and small tablet. While Astoria will be a useful stopgap, the company’s bet is that developers won’t want to restrict their apps to only running on the phone. They’ll want to reach the full range of Windows machines, and they’ll have to write a Windows app to do it.

Things get more tricky if developers prove uninterested in this broader market. A developer that only cares about phones could get away with an Astoria app. It might not yield the perfect experience, but it might be good enough, especially if the alternative is not developing a Windows app at all.

As for Islandwood? That’s trickier. Islandwood apps will be equal peers to conventional Windows apps. They’ll be Windows apps written in a weird language and using a large library to translate some of their weird API calls into Windows ones, but they’ll be on an equal footing to other Windows apps… and that includes requiring Windows-specific code to make them work. Arguably, they don’t pose the same threat to native development, because they’ll just be another kind of native development.

Again, the risks of Microsoft’s strategy are real. If the company cannot drum up developer interest in the broader Windows market, Astoria in particular could have a highly corrosive effect on Windows smartphone development. And Microsoft would certainly do well to communicate with its developer community more clearly; while the strategy does have risks, it isn’t the capitulation it may appear to be. That’s something that needs to be explained.