We just need some firmware in here and everything will be fine. Photo by 4nitsirk on Flickr.

Microsoft announced at its BUILD conference that it will be providing a way for iOS and Android developers to port – sorta kinda – their mobile apps to Windows 10, so they don’t have to rewrite them from scratch in its coding language.

As Peter Bright described it at Ars Technica:

[In “Project Islandwood] Microsoft has developed an Objective C toolchain and middleware layer that provide the operating system APIs that iOS apps expect. A select group of third parties have been using the Islandwood tools already, with King’s Candy Crush Saga for Windows Phone being one of the first apps built this way. King’s developers had to change only a “few percent” of the code in order to fully port it to Windows Phone.

For Android, there is Project Astoria. Rumors of Android apps on Windows have been floating around for some time, and in Windows 10 Microsoft is delivering on those rumors. Astoria will allow Android apps to run in Windows. Specifically, Windows Mobile (and yes, that’s now officially the name for Windows on phones and sub-8 inch tablets) will include an Android runtime layer that’ll let them run existing Android apps (both Java and C++) unmodified.

Bright then followed up on Monday last Friday (thanks Walt) with an analysis which goes much more deeply into the mechanics of how it will be done, but also points to two examples where companies have tried to make up for the lack of apps on their platform by enabling others effectively to run on them: IBM’s OS/2 platform, and BlackBerry’s BB10.

The point about OS/2 is well-remembered, delving back into PC history when Windows was young and IBM was trying to keep control of the burgeoning PC platform. It failed, because IBM couldn’t update OS/2 fast enough to keep compatibility with the fast-expanding Windows 3.x API base; but also, developers didn’t want to get distracted by having to look after more than one platform.

Indeed, when it comes to porting, Bright observes that “neither OS/2 nor BB10 has made a success of this capability”. He could also have added Amazon’s Android fork, and the Nokia X, which used AOSP (Android Open Source Platform) and tried to replace Google services with Microsoft ones.

We surrender to your platform

The trouble with “compatibility mode” is that it’s so evidently a white flag on the part of the company that enables it. In effect, the company is saying: we can’t attract enough developers to write natively for our platform, so we’ll try to piggyback on the more successful one.

But that’s also a giant red warning flag to developers on that platform. By effectively telling them that other platforms are more successful, it calls into question the future of the development tools on the platform, and the user base; it accepts that there are both more users and more developers elsewhere.

I don’t think Islandwood and Astoria will work. Not because they technically won’t work – Microsoft has scads of smart people who can do clever things with code – but because this is a technical solution to a business problem.

Even worse, it’s a technical solution that makes the business problem worse. If you subscribe to the idea of “moats and castles” (that businesses aim to surround themselves with an advantage that rivals can’t cross), then effectively dumping your own developer kit on mobile so that you can lure people from rival platforms strengthens the rivals’ moats – their loyal cohorts of third-party developers. Why would anyone write first for mobile on Windows, given these two projects?

The business problem

Microsoft’s user base for Windows Phone is around 70m-80m worldwide, out of a total smartphone user base of around 2 billion. Superficially this sounds like the late 1990s, when Apple was just about able to eke out an existence by having around 50m-60m out of 1.5bn PCs.

The crucial difference though is that Apple had the high-end users, who were willing to pay a premium for Apple’s qualities (principally in desktop publishing and graphic design, and lots of consumers in the US). Windows Phone occupies the low end. Its users don’t monetise well. That means developers don’t concentrate on them. A little experiment for you: today, when you see an ad for an app, notice how many mention availability on Windows Phone. If you get above zero, you’re lucky (or browsing a Windows site).

The category error

But, say the the Windows diehards, the access to 1.5 billion PCs and, ahem, Windows Phone will prove irresistible to all those developers currently writing for iOS and Android. All those PCs! Who wouldn’t want to be on those?

This is wrong, for two reasons: context and support costs.
1) apps written for mobile do not, in the main, translate to the desktop/laptop. What would Snapchat on the desktop be like? Or Uber? Apps that rely on the camera or geolocation don’t make sense; others can in general be done in the browser (example: Facebook). John Kneeland pointed this out back in February, before we knew about these initiatives. What he wrote remains true:

The most interesting developers and companies today aren’t shrinking down desktop experiences. They are building entirely new experiences that wouldn’t make any sense — or even be possible — on a PC.

2) the cost of “writing” the app is only the start; after that you have support, updates and compatibility. Imagine an iOS developer who has written an app for iOS 8 (presently covering 81% of users) considering this.

If they’re sensible, they’ll look first at monetisation via Android – after all, it’s the far bigger market, which has a premium (= willing to pay) segment that rivals iOS in size. So they do that. And then clean up, perhaps, with the iPad market too.

Now – Windows Phone via compatibility mode or Android tablets? If they write for “Windows Phone compatibility” they’ll have a product that will need special tweaking on a new platform where because of the comparatively low number of users, a few bad reviews could spell doom. Even if they get it right, Apple will introduce iOS 9 in the autumn, which might or might not tweak or twerk the existing APIs, and will surely kill off some of the older ones. How long will it take Microsoft to update to those? One thing’s for sure – iOS new version adoption will run ahead of Microsoft’s ability to update. This means there are now two versions of the app, on slightly different APIs, not entirely compatible.

When iOS 9 comes out, the iOS developers’ attentions will be on bugfixing and customer support there. This means (because people are finite) less time to attend to the Windows Phone customers. Things don’t get fixed there, bad reviews get left, the app sinks down the store, and.. what was the point of writing for this thing again?

As for Android developers – if we assume that they haven’t already done an iOS version, then do you think they’d want to write something for a platform with over 500m mobile devices in use, or one with 1.5bn users… except that for almost all of those 1.5bn, their app will make no sense at all (if they’re even able to load it – for don’t forget that about half of those PCs are in businesses, and probably locked down)?

Again, this isn’t hard to figure out.

A good try, but doomed

Microsoft had to do something, and people who like clever technical solutions are delighted by this clever technical solution to the fact of developer indifference and incompatible software. But it doesn’t change the fundamental truth: Windows Phone (v10 or whatever) is too small to matter in platform terms on mobile.

Microsoft is surely interested in keeping the mobile side going, as much as anything because of all the lessons it teaches you about things like power management, chip integration, sensor management, and a multitude of other things that are important.

History tells us that software compatibility is a losers’ move. Far better to move the fight to a new battleground and win there – as Apple did, first with the iPod and then the iPhone and then the iPad and then (thus far) the Apple Watch. Seems like a working strategy.

Update: some responses on Twitter have been along the lines of “Oh, no, really, developers will love it!”

Why, I ask? “Azure! The developer environment! Access to Xbox! It’ll get people to switch to Windows!”

In order:
• developers don’t need Windows 10 to use Azure. Vesper, which is resolutely iOS-only, uses Azure, for instance.
• if there’s one thing developers likely don’t want to get accustomed to, it’s yet another developer environment if the payback is small. Also, is there any developer who hasn’t heard that Windows (desktop) has a lot of users? The point is that Windows 10 is not magically going to make those desktop users into mobile users, for the reasons discussed above. iOS and Android have 95% of pretty much any market that’s worth squeezing developer money from. If anyone wants to tell me which niches monetise better on Windows Phone than on iOS and/or Android, I’m all ears.

• Xbox access isn’t worth much. There are about as many Xbox users as Windows Phone users (of the order of 70-80m; Xbox One is replacing Xbox 360, and any new buyers are balanced out by those abandoning as they get older). Games are notoriously difficult to write well; developers need to write “close to the metal”. Porting mobile games to the Xbox isn’t a sensible strategy.

• people do switch to Windows Phone from other platforms. However, just as many (if not more) flow back to the other two platforms because they aren’t happy with the app situation. And if this works, then what’s the reason for switching to Windows? So that you can get the apps that you already had on the smartphone platform you were on before? That doesn’t make sense.

I’m happy to be proved wrong, of course – if those who say I’m going to be wrong are willing to put up some solid numbers here (in the comments) that we can refer back to in a year or so, such as forecast Lumia sales, or Lumia installed base, or forecast length in 2016 of the app gap between other platforms and Windows Phone/10.

I’m charlesarthur on Twitter. Say hi or leave a comment.