Microsoft Ends Effort To Bring Android Apps To Windows 10 Mobile
by Brandon Chester on February 25, 2016 4:50 PM EST- Posted in
- Smartphones
- Microsoft
- Windows 10 Mobile
At the 2015 BUILD developer Conference Microsoft demoed four application bridges that they hoped would improve the number of applications available for Windows 10 Mobile, which would benefit the Windows platform as a whole. The two most interesting showcases were Project Islandwood, which helps developers to port their Objective-C applications to Windows, and Project Astoria, a subsystem for running existing Android applications right on a Windows smartphone. Today it looks like the latter of those projects has officially met its end.
The death of Project Astoria won't come as a big surprise to those who have been keeping track of Windows 10 Mobile's development process since BUILD. Back in October of last year, preview builds of Windows 10 Mobile stopped including the Android runtime and there wasn't really any explanation as to why. Since that time, Project Islandwood has continued to be promoted by Microsoft while there hasn't been much news about Astoria. This led many in the development community to suspect that Microsoft had decided to kill the project, although there was no official confirmation until today.
In my view, the death of Project Astoria has both good and bad elements. Since it was essentially packaging Android applications to run on Windows 10 Mobile, the applications never fit in with the rest of the platform and so the question then became why you wouldn't just go buy an actual Android device. On the other hand, it did provide an easy way for developers and users to bundle up applications that didn't exist at all on Windows 10 Mobile, which would help fill the app gap in a less than optimal but usable manner.
According to Microsoft, the official reason for the death of Astoria is that developers felt that having two bridges from mobile operating systems was mostly redundant when their applications likely existed on both Android and iOS. With Microsoft's recent purchase of Xamarin, they may also be betting on developers creating applications in C# that can be deployed across Android, Windows, and iOS. In any case, Microsoft's bridges for Objective-C, JavaScript, and Win32 apps are still very much alive, but the prospect of easily bringing over Android applications to Windows 10 Mobile is gone.
Source: Microsoft Windows Blog
Facebook
Twitter
RSS
45 Comments
View All Comments
atirado - Thursday, February 25, 2016 - link
I think it is better to focus on being able to write apps in VS.NET that are targeted to the different platforms as native apps (rather than webviews).ddriver - Thursday, February 25, 2016 - link
That's a big no for two good reasons:1 - C# is not native code, it is slow, even slower than Java
2 - targeting platform native libraries and APIs will result in applications which are not portable - you will have to write the application for every different platform, as they all come with different application APIs
Currently, when portability of applications and development efforts are concerned, Qt is the best, or if you wish - the least sucky solution - it is C++ at its core, so it is as fast and efficient as it gets, and you code against the Qt libraries, so the same application code will work out of the box on every supported platform with no or at most very little modification. And it has QML which is very easy and fast to work with, way better than XML based markup and integrates JS directly.
atirado - Thursday, February 25, 2016 - link
We are saying the same thing. We want portable apps so the comparison is about whether the QT APIs are 'better' than the MS APIs for what you want to do, i.e.: If you need to squeeze every single bit of performance out of a device which API simplifies coding of the app while giving you as much performance as possible?What makes QML better?
ddriver - Thursday, February 25, 2016 - link
"What makes QML better?"Mostly the choice of syntax. It is a lot like JSON, so instead of the XML-like <tag> content <endtag> you simply tag { content }. The there is the property binding, which is an extremely flexible and powerful feature. Also, JS is directly integrated, integrating with C++ code is very easy, as is the ability to define your own types in C++ and use those in QML. Lastly - the runtime performance is rather good and efficient - compared to webview based applications.
Modern hardware certainly has the power to spare, allowing more and more widespread use of inefficient scripting languages for application development. But even then, aside from performance never hurting anyone, in the case of mobile devices, battery life will surely appreciate the reduced CPU cycles. Memory usage is an important factor too, again - especially on mobile devices, where RAM is still fairly small in volume - it is not uncommon to see C/C++ workloads using 3-4+ less memory than the same workloads implemented in Java/JS/C#
Finally - MS has the habit of designing some fugly APIs, even the latest and "greatest". People who haven't seen better cannot really appreciate that though.
atirado - Saturday, February 27, 2016 - link
Sounds enticing, but the languages features you mention are also found in other languages like C#, Java, JS, Ruby, etc tosome extent to help you build different types of workloads while still caring about managing your resources like memory, battery, etc.
APIs is a different aspect which I agree to some extent and look to QT, Xamarin, and similar to address.
Brett Howse - Thursday, February 25, 2016 - link
C# can be compiled as native code for UWP apps:http://www.anandtech.com/show/9661/windows-10-feat...
The Xamarin purchase yesterday also outputs native code targeting the different platforms.
C# is a programming language, not a runtime. .NET has traditionally used a runtime on older versions of Windows but it's not always the case now.
ddriver - Thursday, February 25, 2016 - link
Every language has a runtime, including C and C++, which are as hardware native as it gets. This applies even more so to C#, as it is also a managed language.Dunno what code Xamarin outputs, but from the looks of it, it is on average 3-4 times slower than C++: http://benchmarksgame.alioth.debian.org/u64q/compa...
extide - Thursday, February 25, 2016 - link
Having a run time is not the same as being native/not native. With the Xamarin stuff you can apparently compile c# to actual native code, with and not just MSIL.ddriver - Thursday, February 25, 2016 - link
Not to belabor the point, but every JIT-ed language compiles to native code - i.e. machine code, be that Java, JavaScript, C# or whatever.However, from the performance figures of those it is quite obvious that there is more to the story than whether it is native or interpreted code - even if C# is compiled to native code, it is nowhere as fast and efficient as native code, produced by a C/C++ compiler from C/C++ code.
There are many reasons for it, but the most prominent being that managed languages are simply not cache friendly, and that JIT compilation, aside from the hype from its proponents, is nowhere nearly as good at optimizing as the ahead of time compilation of code that is close to the hardware. Managed languages are abstracted away from the hardware, so there is not that much room for code analysis and optimization.
Alexvrb - Saturday, February 27, 2016 - link
.NET was already JIT. What they're talking about is stuff like .NET Native (there have been other solutions around for some time too). It's not JIT. Yes it has a minimal runtime, and no that doesn't mean it's "not native". Far from it. The developers don't even need to compile it themselves, it's done in the cloud. This allows for faster app installs vs compiling locally, but since it's done in the cloud the code can be recompiled easily for new targets, when the compiler sees improvements, etc.https://msdn.microsoft.com/en-us/library/dn584397(...
As far as libraries and APIs go, they already have the iOS bridge written, they could build on top of their work there to go the other direction, or they could port their APIs and libraries. Similar to Qt. So it's not impossible for them to go multiplatform/portable. But it's hard to say what their goal is, so I'm not certain how they will proceed.