Today Microsoft made an announcement that Windows 10 will allow Android applications to run in an Android AOSP subsystem. Additionally, Objective-C applications can be compiled and run on Windows 10 as well as universal applications. These announcements, particularly the later, surprised and excited many of us. I've been speaking with a lot of people both inside and outside of Magenic on what all of this means, or could possibly mean, given our limited understanding. (For details See Kevin McLaughlin's article and Mary Jo Foley's article)
First there are some pretty important technical questions raised by this:
- What will the applications look like in Windows 10? If the Android applications are just running in a ASOP subsystem then presumably you would have a bunch of applications looking and navigating like native Android applications on your Windows 10 device. That may be OK for some applications but probably not others.
- How about access to system services and 3D rendering? If I need access to the hardware GPS can one application running in the Android subsystem do that while a Windows 10 application tries to get at it at the same time. This could be handled but I'm curious as to the level to which it is handled or if there be dragons.
- For Objective-C what if my application is accessing HealthKit? I assume HealthKit is not available in Windows 10 when I port my code. When running an Android application how about Google services, can I install them in the subsystem?
- It seems Apple is putting a huge effort behind Swift but MS only mentioned Objective-C; will there be Swift support some time in the future? I just finished writing a white paper on when to use Objective-C vs. Swift. Until and unless MS also supports doing this with Swift, this could change the equation for applications that ever may be expected to run on Windows 10. For that concern, Objective-C would be the one that could work.
- I've heard that Objective-C apps may support porting over Xibs but not Storyboards. If true that could limit the applications that can be ported over without refactoring.
I look forward to learning more and getting some answers to some of these questions. Early days! :)
Even with all those questions, there are a few conclusions that we can come to with what we currently know today.
- One question I've seen floating around is do we still need solutions like Xamarin or NativeScript. The answer is absolutely yes. These new capabilities allow us to more easily run Android applications written in Java to our Windows 10 devices and compile Objective-C code into unified applications for Windows 10. What they don't do is allow you to run your applications written in Objective-C on an Android device or in Java on iOS. For this type of cross platform work you need a different cross platform tool. Then there is the question of will it look right on the platform? Technologies like Xamarin and NativeScript solve that problem, this will not.
- I've heard a comparison with when OS/2 was designed to run Windows applications to help capture the market from Windows and it did it poorly with the conclusion that Microsoft should expect the same result with Android and iOS apps running on Windows 10. Does this argument have any legs? Maybe in some ways, but not too much of a worry. OS/2 failed for many reasons, many of which had nothing to do with having Windows compatibility. But there is one area in particular where the analogy partially seems to hold true, handheld mobile devices. Like OS/2, Windows is not the dominant player in this space and is fighting entrenched leaders. But even then I don't give the argument too many legs. Like OS/2, Windows 10 will will likely stand or fall based on its strengths in the tablet space and will have an uphill battle in the mobile space just because there is so much momentum behind the leaders. If there is any detrimental impact of Android or Objective-C code on Windows 10 will be small next to that. Given the potential upside of additional applications, certainly a viable and likely small risk.
- Applications that rely on platform specific services like HealthKit or Google Play Services are unlikely to just work. The upshot of the deal, if you are writing an Objective-C or Android Java applications that accesses those services then all of the cross platform concerns come into play, just like they do writing a Xamarin application. Suddenly you have to think clearly about things like inversion of control patterns around platform specific services and writing a different implementation for the Windows platform that may change or even disable functionality.
- Microsoft has made a big deal of giving away Windows 10 and trying to get people to move. Now we see part of the reason as these capabilities are unlikely to be back ported to Windows 8.1 or Windows Phone. So the quicker users move the better. However, the enterprise is notoriously slow to move. How much this lag will carry over to the tablet space remains to be seen but it has been a much faster cycle for mobile phones.
- This move has obviously been made because it is very difficult to attract developers to a platform when there are few users and users to a platform when there are few applications. By lowering the bar to run many existing applications on Windows 10 they have made moves to help solve that equation and completely changed the price point to entry. However, this does have its limits. If I'm currently writing a native Android or iOS app, getting it to work on Windows is still not free. If I'm very lucky all I'm looking at is increased platform testing and perhaps compilation costs in terms of Objective-C. If I'm not lucky I'm re-architecting portions of my application to abstract out capabilities and services I can't access or otherwise don't work on Windows 10. For public facing apps on smart phone devices, software companies will still have to determine if that reduced cost is worth the 3% of US smart phone marketshare. Such investment may be much easier to justify in places like Europe where Windows Phone holds a 10% share.
Final thoughts
If this works well it will undoubtedly increase the attractiveness of the Windows 10 platform, particularly in the tablet space. No matter how you cut it, it is just another example in a long line of examples of how Microsoft has changed and become a very different company than it was a few short years ago. Microsoft continues to show us that it is a fighter and willing to make fundamental changes to stay relevant.
I feel great knowing that I can find enhanced utility in my ability to write Java and Objective-C. However, for my clients that need cross platform applications they almost always are looking at the two big smart phone players; Android and iOS. For that, I will continue to use tools like Xamarin and .Net.
I do wonder if this portends some future movement of MS into Xamarin's space. There were talks of acquisition last year that never materialized. Xamarin is a small player and that can work if they can hide in a niche. I see MS and Xamarin working more an more together so Microsoft is definitely getting interested in that niche. I know a lot of guys at Xamarin and they are a nice and passionate bunch that deserve credit and reward for what they have done to advance the cause and capabilities of X-Platform mobile development. No matter how this turns out I hope they receive the recognition and reward they deserve for their pioneering work.
This move by Microsoft makes a large shift in how I think about the different platforms and their capabilities and I look forward to continuing to evaluate the impact of this as we know more.
