Wow, some interesting announcements in the Microsoft Build 2015 keynote yesterday. Too many to go into in a quick blogpost, but Azure sure is looking great, Hololens is impressive, Docker on Windows, Visual Studio Code on Mac and Linux – wow!

My main interest was what’s happening with Windows 10, and especially on Mobile. Microsoft is doing some interesting things when it comes to its interpretation of cross platform… 

First, if we look at Office 16 and its new JavaScript extensions: finally we can get Xobni like features (remember?) without those obnoxious memory and CPU hogging OCX plugins. Most impressive: it works on Office for Windows but just as well on Office for iOS. Well played.

Windows 10 in itself is starting to look pretty impressive. Personally I’m not really buying into the idea of having my phone act like a desktop when plugged into a monitor, but it looked impressive. And the idea of continuity is something Google, Apple and Microsoft are implementing quite nicely.

The whole idea of Universal Apps is very compelling and a good way to get more developers on the Windows platform, especially Windows Phone, which desperately needs to gain some traction. Purpose built Windows apps are starting to look pretty nice now that they’re starting to borrow some UI paradigms that work from Apple and Google and shedding off some of that first generation Metro blandness. 

But here comes the most interesting part… Besides using C# and .NET to build Windows native apps, you can now also target Windows and the Windows Store with four new technologies. The first one makes the most sense…

Web: you can put your server hosted website on Windows as an app, and actually leverage features like Cortana if you detect that you’re running on Windows. Sounds like a good approach and probably better than the WinJS route that was introduced with WinRT.

Next, we have Win32 / .NET, which basically means that the old style applications now also have a chance to be in the Windows Store. Applications like PhotoShop or PhotoShop Elements are good candidates for this, as they rely on low level graphic processing and are not forced to rewrite in a more limiting framework. Let’s see how this works out when old ugly grey WinForms applications hit the Store. I also assume that these apps will be limited to run on desktop only and not on tablets or phones.

But then… Two more interesting options were announced. 

> Microsoft just out-Blackberried Blackberry. Both an Android subsystem and the ability to cross compile iOS Objective-C on Windows #Build2015

— Roy Cornelissen (@roycornelissen) April 29, 2015

First, Microsoft pulled a BlackBerry on us and announced that Windows Phone will have an Android subsystem, so that it can run Java or C++ Android apps, with “minimal adjustments”. Whoa.

Next, Microsoft has also added the ability to take your existing Objective-C code for iOS, and -again, with “minimal adjustments” – compile and run it on Windows. They went on to demonstrate this with the game hit CandyCrush Saga.

Suddenly the clean – rebuilt from the ground up – Windows 10 operating system is turning into a chameleon OS that adds even more compatibility.

This is an interesting move, and surely a way to make Windows Phone more relevant when it comes to apps. All of a sudden, both Android and iOS developers have an opportunity to target “1 billion” extra devices just by recompiling their apps for Windows. About time, because quite frankly, it was starting to become a bit pathetic when I was discussing tech with my Windows based colleagues.

“Let’s use [communication platform X]!”
– “Er, we can’t, there’s no app for that for my Windows Phone”

Sad trombone.

So, what does this mean for cross platform development?
One may start to wonder what’s the point of doing cross platform development, such as with my personal favorite mobile development tool Xamarin? That’s an interesting question indeed. I mean, why bother with C#, architecting for code reuse, etc. when you can do it fully native and add Windows to the mix while you’re at it?

Well, first of all, you’d still be writing your app twice if you’re targeting Android AND iOS. So that’s Java and Objective-C/Swift. And then you have to choose which of these two you’re going to put into the hands of Windows users.

But more important to me: what is the experience you’re going to give your Windows users? Just as I’m an iOS fanboy, these users pick their device and OS from a personal preference. These people like their square coloured, high-on-typography tiles and their swirling screen transitions. What is the feeling you’re going to give them as an app developer if your app is an Android app and looks and behaves just like it?

Sure, this is a great way to segue into the Windows ecosystem and get your popular app in the hands of Windows users, but it will make their coloured rectangles OS look like FrankenWindows when they have mixed Windows, Android and iOS apps on them. This is what it’s going to look like to them:

As I see it, this should be an intermediate step. You’ll want to give your Windows users a first class experience just as your iOS and Android users, so you’ll want to drink that Windows Universal App Kool-Aid, and develop for them natively. And this is where the Universal Apps approach make a lot of sense, because you’re not only hitting that 5% market share Phone OS, but tablets, desktops and laptops as well if you’re doing it right. Those 1 billion devices that Microsoft is talking about.

So, I think this FrankenWindows trick is a good way for Microsoft to make Windows Phone more relevant in the market, and I hope it will make developers push their iOS and Android apps to the Windows Store as well. But as Windows Phone gains traction, I also expect that cross platform development will remain relevant.

I’ll leave it up to you whether this will be HTML/CSS/JavaScript or native via Xamarin.

In any case, Microsoft made some bold moves yesterday, and it makes developing in their ecosystem all the more exciting.

UPDATE: Alan Mendelevich has a great blog post on this topic as well, with some inside info on how these Android and iOS bridges should be interpreted

Share this: