Windows Phone Bids for iPhone and Android Apps

Windows phone

You have to give Microsoft credit for its efforts to get just about any app on the Windows Phone. The need is obvious. Microsoft is selling to a small part of the phone market at a time when the requirements of iOS and Android take up most of the development time. That leaves the apps in short supply for Window Phone, and thus leaves a shortage of reasons to buy.

Microsoft is hoping its phones will find an easier time using apps made for Android and iPhone products. The plan of pulling this off is a lot better than the processes tried in the past for Windows programs on IBM OS/2 and Android apps for the BlackBerry phone. But that raises the question of what the developers must do to find it worthwhile.

Two approaches. Microsoft announced two approaches at the Build conference[1]. Project Astoria creates a way to handle apps based on Android by processing the Androids API for Windows 10 (in theory, this would work as well on a Windows PC too, but there is little indication of a desire for Android use on PCs). You don’t just install an Android app on Windows. Instead, the procedure is to make it relatively easy to make an Android work without needing to change its code to Windows APIs.

Project Islandwood is very different approach to a similar result to run iOS apps on Windows. It is a Universal Windows Platform Bridge toolkit that lets you process code written in Apple’s Objective-C as Windows apps. Microsoft says Islandwood lets you convert Apple’s Xcode process into Microsoft’s Visual Studio, make Windows code with minor changes to the iOS code, make Windows services available, and extend the ability of iOS apps to take advantage of Universal Windows Platform features. [pullquote]To some extent, the success cannot be judged until the new processes are finished and Islandwood is running behind Astoria.[/pullquote]

That’s a lot of promise there and a lot of potential work. To some extent, the success cannot be judged until the new processes are finished and Islandwood is running behind Astoria. The big question is how appealing working with the whole deal will be.

The Windows gap. The Windows Phone, of course, has suffered from a standard market gap. The popularity of buying the phones has been held back by a dearth of apps. And writing apps has been discouraged by the poor sales of Windows Phones. Only increasing development of apps is likely to be a movement for positive change, but the developers need to be convinced Microsoft will come up with good ways of producing programs and strong demand for loading them.

Microsoft tried something along these lines once before. As early as Windows Phone 8, Microsoft offered an app called Switch to Windows Phone that could convert from an Android app (not an iPhone) to a Windows app and build up the data. Switch’s version was offered through the Windows Phone App Store, but it was marked as “no longer published” last year–and only had a dismal 2½ stars.

They’re likely to do a lot better this time. Microsoft clearly recognizes the value in matching computing devices, especially under the leadership of Satya Nadella. But there are still challenges standing in the way of both Android and Islandwood.

[1] Excellent, and lengthy, detail on the Build descriptions are available in Peter Bright’s analysis on Ars Technica.

Published by

Steve Wildstrom

Steve Wildstrom is veteran technology reporter, writer, and analyst based in the Washington, D.C. area. He created and wrote BusinessWeek’s Technology & You column for 15 years. Since leaving BusinessWeek in the fall of 2009, he has written his own blog, Wildstrom on Tech and has contributed to corporate blogs, including those of Cisco and AMD and also consults for major technology companies.

5 thoughts on “Windows Phone Bids for iPhone and Android Apps”

  1. With MS these days, I find it important to remember that there’s the strategy, and then there’s the execution.

    On the strategy side, getting apps for Windows Mobile is vital. Whatever the figures say, many important apps are still missing, a lot of the available apps are crap – if that: many smack of scams – , plus there’s the absence of all the Google apps. That’s only one leg for a mobile platform though, you also need good devices (MS have that covered for the low+mid range, but the high end ?), a good OS (I think WinMobile is good not great, easy but lacking some stuff I’m used to on Android), branding + distribution (which are probably OK).
    Getting apps (especially if they’re only halfbaked recompiles) removes an issue, it doesn’t create motivation. It isn’t doing much for BlackBerry nor Amazon’s Fire phone…

    On the execution side, we’ll need to see 1- how many apps do get ported and 2- if they work well.
    Devs still need to port their apps (apparently there *is* a way to sideload unported Android apps provided they don’t use unavailable APIs, but I don’t think that’ll go mainstream). Devs need to.. not be Google ^^, not require unavailable APIs, think the effort worth it, and keep their support over time. Not an automatic decision.
    Then the apps do need to not only be there, but work well too: aside from the basic look&feel and reliability challenges, the Android apps are basically wrapped in a quasi-VM, that’s potentially resource- and battery- intensive. iOS ones are recompiled so end up more “Windows-native”.

    I’ve been wondering for a while if AOSP-Android isn’t becoming the mp3 of apps: a format that runs anywhere (realizing Java’s old promise), on many types of devices (from watches to desktops) and ecosystems. Aside from the host of “AOSP+” ecosystems (mostly in China + Amazon), non-Android ecosystems can run Android apps too:WinMobile, WinDesktop, MacOS, Linuxes, BlackBerry, even Tizen… iOS is the only major one missing. A pity GMS aren’t in there.

Leave a Reply

Your email address will not be published. Required fields are marked *