OPINION: San Francisco might well have been the logical place for Microsoft to unveil the missing pieces of its Windows 10 developer strategy as it's a city defined by its bridges. And building bridges was a theme that executives returned to again and again, unveiling new ways to work with its cloud services and new ways to build and deliver Windows applications.
Microsoft remains the underdog in today's developer world.
Certainly Microsoft is bullish about the Windows 10 developer opportunity, promising a billion Windows 10 devices within two to three years of launch.
But Microsoft remains the underdog in today's developer world. Android, iOS, and the web are the new platforms of choice, while Windows 10's new Windows Universal App platform has to compete with entrenched existing Windows development models and especially with Win32. So how can it bring developers from other platforms to Windows and, perhaps more importantly, how can it do it without offending that army of developers already working with Windows?
At Build 2015 Microsoft gave more details of its Windows Universal Apps, noting that it took Tencent a month to convert its WeChat Windows Phone Silverlight app to a universal app running on PCs and tablets as well as phones. It also showed how USA Today could quickly extend a desktop app to Xbox One, using filters to make it a video player.
As big as they are for Windows, Universal Apps are only part of the Windows 10 Windows Store story. The store now extends deep into Windows, surfacing on the new Windows Spotlight lock screen, on the Start Menu, in the new Edge Browser, and in Cortana. It's also now reaching out beyond traditional Windows developers, with tools to bring apps from other platforms onto Windows.
First and foremost was Terry Myerson's announcement that developers would be able to bring Java and C++ code from Android apps to Windows Phone. Microsoft is taking a big risk here, gambling an entire platform on the hope that it can reduce the fabled app gap. Certainly the demos were convincing, with Android apps working with Windows Phone platform services, including device hardware APIs. The approach it's taking is very different from BlackBerry's Android emulator and Amazon store so you won't be able to take an Android app package and run it on your Windows Phone.
Instead Microsoft is taking advantage of its existing hardware abstraction technologies to provide a translation subsystem that can be called from Android code, giving access to Windows features without needing a full rewrite. Apps running on Windows 10 Mobile will be native apps, and will be delivered from the Windows Store. It's unclear as yet how Microsoft will help developers recompile Android apps for use on Windows 10, but it's likely that the process will be similar to the way Amazon helps developers produce apps for its app store and its Fire devices.
Myerson quickly followed the Android on Windows bombshell with the announcement that iOS Objective C code would be able to compile to Windows as well, with an SDK handling the transition between iOS UI and Windows. Surprisingly the iOS conversion tools are already in use, converting iOS projects into Visual Studio solutions and allowing rapid conversion of iOS apps King only needed a few modifications to bring Candy Crush Saga to Windows Phone 8.1 this way.
Providing tooling to bring iOS and Android apps to Windows makes a lot of sense, but it does add risk to the Windows Universal Apps development model Microsoft is putting at the heart of Windows 10. While Windows Universal Apps will scale from IoT to phone to PC to Xbox and beyond, there's going to be little incentive for developers with existing mobile apps to write a Windows version of their app if all they have to do is convert their code to reach Windows 10's promised billion users.
So it's not surprising to see Microsoft not only building bridges to those mobile developers but also to the wider pool of Windows developers, offering them the tools they'll need to sell apps in the Windows Store. Details are still a little scarce as to how developers will get access to Store APIs, but apps will be delivered using a variant of the Windows App-V container technology so apps will be isolated from the rest of Windows, reducing the risk of one app affecting the rest of your PC.
Then there's the option of providing a wrapper to existing web apps that will allow them to access Windows features while still running on your server. You could imagine a company like Spotify using this to wrap its Play web app, adding the option to purchase tracks using the Windows Store payment mechanisms (which are being extended to work with carrier billing on all Windows platforms, as well as offering subscription support). It's a quick way of putting an app in the Windows Store, letting you add new features to existing code without changing your current in-browser experience.
Microsoft dropped several bombshells on developers at BUILD 2015, taking considerable risk in doing so. While bringing other ecosystems into the Windows Store might make it harder for developers to justify building new Windows apps, bridging the app gap should make it easier for Microsoft to sell phones and tablets, allowing it to bootstrap its own ecosystem. That should allow a rich Windows 10 universal app platform to build on the process.
It's a risky bet, but one that Microsoft thinks it can pull off. Talking to various senior members of the Windows team it's clear that a lot of thought has gone into this. By making sure that apps are rebuilt for Windows there's an opportunity for developers to bring Windows-specific features into apps that were originally designed for another platform with the aim of encouraging them to move to developing Windows 10 native apps once they've seen the value of the Windows Store.
That's why Microsoft is building those bridges. It needs a busy store with apps that update regularly, and these new routes to Windows are intended to fill that store and to deliver those apps that bring users back again and again and hopefully ready to spend their hard earned cash.
