Android apps on Windows Phone sounds like a great idea

As my friend and ZDNet colleague Mary Jo Foley reports, Microsoft is pondering the idea of letting Android apps run on Windows.

This is one of two Android-slash-Windows Phone ideas that are currently floating around, the other being that Microsoft should give up on Windows Phone entirely and move over to Android.

Splitting

That last idea is either terrible, or pointless depending on the way you look at it. It's pointless because Microsoft already has an operating system that runs on phones, and it's called "Windows Phone".

Basing their OS on Android itself doesn't help, not least of all because Android is split into two halves. The first half -- the Android Open Source Project (AOSP) -- is properly open source. The other half, Google Mobile Services (GMS) is certainly not free. GMS does all the actual magic stuff that makes Android good.

The more direct issue is that GMS ties the device into Google's ecosystem. Amazon's Kindle Fire offering doesn't have GMS, which gives Amazon the freedom to tie the device and its owner into the Amazon ecosystem. Similarly, the rumoured Nokia Android device would not have GMS, and as a result Nokia would tie the device into the Nokia ecosystem.

So we come full circle. Microsoft cannot create an Android device with GMS without breathing life into Google's ecosystem. They won't do that, and seeing as Windows Phone is as good or better than the baseline AOSP offering, there's no point not to keep plugging away at Windows Phone.

BlackBerry

With BlackBerry 10 (BB10), BlackBerry offered the ability for users to run Android apps on the new operating system. The major issue was that they needed to be repackaged in order to run.

This repackaging process was a bit of an effort in its own right, but the bigger issue was getting hold of the raw ".apk" file (Android Package file) needed to install an Android app.

The Google Play app on a proper GMS-linked Android device acts as a marshal between the device and Google's services to obtain a proper ".apk" file that can be installed. Software vendors do not make the .apk files publicly available.

In BlackBerry 10.2.1 the process is easier in that you don't need to go through the re-signing step, but you still need the .apk file from somewhere. And, as the original vendor would not put their .apk files up publicly outside of the store, by definition you're exposing yourself to moral issues and/or security problems by going out on the hunt for the .apk files from other sources.

Whichever way you looked at it the only way to get an Android app running on a BB10 was if the vendor had the good grace to put it up on BlackBerry world.

But at least this process short-circuited some development effort. The only reason why Skype exists at all on BB10 is because Microsoft re-packaged the Android version and put it up on BlackBerry World.

Third-place

For a long time we've been talking about the "platform in third-place", and that platform is now Windows Phone.

The rationale for BlackBerry allowing Android apps to run on BB10 was to ameliorate this problem that nascent platforms have no app support. Although not ideal, but allowing Android apps to more easily be ported to BB10, some of that argument goes away.

Back in October I wrote a piece about whether Windows Phone would ever get any love from developers. The argument I put forward there was that, commercially, any organisation will target platforms in a "dominance priority" in order to reach their largest possible customer base. iOS and Android are the dominant platforms, and offer the broadest sweep across the possible customer base.

The problem comes in that the amount of resources a company has to invest is limited. Once you've satisfied the two platforms you must hit, there's only a small amount of resources left to satisfy the platforms you could hit.

If it were possible to repackage Android apps for Windows Phone in the same way you can repackage Android apps for BlackBerry 10, the app coverage problem suddenly looks a whole lot better.

(There is, it must be said, a little simplification here. Some Android apps are dependent on features contained within GMS, not AOSP. As GMS would not be supported on Windows Phone at all, that mismatch would stymie a straightforward port in some cases.)

Conclusion

Personally, I'm struggling to see the downside with this approach. It may even be something that Microsoft can manipulate such that Google's own strength is used against them.

One argument is that Windows Phone developers will be seriously annoyed. By definition, there can't be many of them, because self-evidently Windows Phone is not a big platform.

Some of them will hate me saying this, but the developers that are supporting Windows Phone cannot be commercially relevant compared to iOS and Android developers, because today Windows Phone is not commercial relevant when compared to iOS and Android. The health, and size of developer community for any platform or tool is tied to the commercial ecosystem that supports their work.

Developers polishing their skills in Windows Phone are, arguably, wasting their time. If they put that effort into Android, and Microsoft supported running Android apps on Windows Phone, surely that has to be a much better career move? A developer doing that could hit a huge swathe of devices, and be very much in demand.

For consumers, the story is also good. People who own Windows Phone seem to love it. The only downside to Windows Phone today is that the app support is severely limited compared to iOS and Android.

Actually, scratch that. The problem is that the "app gap" problem isn't changing. Windows Phone will always lag.

Plugging in Android support will fix that, and in a way entirely transparent to non-technologist users. All they'll see is the apps they want magically appearing in the Windows Phone store at the same time that their friends and family on iOS and Android see them on their stores..

What do you think? Post a comment, or talk to me on Twitter: @mbrit.