As someone who has spent years building software on top of compiled android binaries, as in, adding features to apps with nothing more than the APK (no source code), I can say that what they are building is not only difficult but quite fragile. I have the benefit of customers who agree to certain OS versions and specific app versions. MS wants it to work universally with every app. It's possible to get it close enough that getting any single app to work is a few tweaks, but very hard to get it to the last mile, where every app "just works".
Why don't you have access to your customer's source code? Is this done through decompiling Java Bytecode? What kind of modifications are we talking about (cosmetic, functionality)?
Really really curious about your feedback!
My current company, Apperian, is the industry leader in a technology called "App Wrapping", for which we have several patents pending (I'm only there for another week, I'm leaving after nearly 6 years for a new adventure). Read more here: https://www.apperian.com/mobile-application-management/mobil...
iOS is different, but on Android we run the decompiled binaries through software making heavy use of finite state machines to alter the Dalvik VM code. These alterations allow us to automatically add features like SSO, analytics, security, self-updating apps, etc. to native apps without the customers making any code changes.
Because the binaries are provided to us by customers, and distributed 100% outside of the official App Stores, the risk of app-breaking updates is much reduced.
Over the years the technology has matured a great amount, and most apps "just work", but we still get apps that have some edge case we didn't think of, that requires manual intervention by engineering to update the wrapping software.
Now, the use-case that MS has is different from Apperian's, but similar enough that I can imagine what they are going through, especially trying to re-map the UI elements to native MS widgets. This is a hard problem that is difficult to nail seamlessly, and it is infeasible for them to tweak their code for every app. Even worse, the apps people want most (FB / Messenger, Google Maps, etc.) are the most complex of all, so their tech needs to be super advanced to get value out of it.
I don't think Microsoft's Astoria even tried to map Android UI elements to native Windows widgets. In my experience, the look and feel is more like a Windows-styled theme for Android. (That sounds pretty bad, but actually Windows 10 Mobile has pretty much broken the tight Windows Phone 7/8 look&feel anyway, so it's not such a big deal for the bridged Android apps.)
They do map some of the Google Play services to their MS equivalents, and that's certainly a big can of worms on its own.
From the article, quoting Microsoft's director of OSG John Justice:
“We are windowizing all the most important experiences…we recreated controls, interactions, and user experiences to match the Windows user experience (UX) to eliminate any clashes of interface concepts,”
The Astoria project at Microsoft failed because a breakthrough was needed to overcome the complexity of the software development challenge. Microsoft tried to automate mapping the Android UI into the Windows 10 UI and to map Google services within the app such as maps, payments and notifications into Microsoft equivalents. Automated conversion of a UI from one platform to another has never been successfully demonstrated.
When I first saw Microsoft's Android bridge at Build 15, I thought it was achievable. But project Astoria as it is called is much too complex. Drawing on my architectural knowledge of the underlying Microsoft/Lumia hardware that is very similar to Android phones.I concluded that in the context of partitioning the device or running a VM Microsoft would succeed. But Microsoft tried something much more ambitious.
This was impressive indeed. It was written entirely in assembly(not using the DC katana library or directX) to get the most out of the Dreamcast.
Also it was years and years before they were able to crack it to be able to copy the discs and by which time both the Dreamcast and Bleem were long dead. The author has a post on a gaming forums about a few years back.
Pretty cool stuff given the tiny size of the team that worked on this and the financial resources available to them. Sony eventually sued them into the ground.
A good reason why google play services exists is to stop things like this. Its a complex moving target that gets updated monthly. Sure, you can do this with apps that don't use play services, but a lot do, especially popular ones. MS would have a hard time keeping up with changes. Blackberry tried this and it didn't save the Blackberry product. They pretty much gave up recently and now have an excellent android phone on the market.
The real question is how many competitive app stores can we have at once? We're probably looking at some level of natural duopoly here. It took years for Android to get the attention it did and that's with it being a worldwide leader in sales. The market settled on a product that's perceived as premium (iOS) and the workhorse do-anything, install-anywhere, sell cheap, etc Android. A third app store and the developer time/cost commitments needed might not be feasible. MS should know a thing or two about how hard it is for outsiders to break natural monopolies.
Amazon does without Google Play Services, and app developers are able to publish their apps on Amazon. It's not a very high bar for app developers, and moving to a Microsoft runtime would be little different than being portable across Google and Amazon devices.
This is very disappointing to me, as a Windows Phone fan in exile (I'm on Android, for the Apps).
I'll now hope they will do something less ambitious, such as creating an Android VM on WP that would run unmodified APK's (and install the Play Store). I'm not sure if they'll strategically want to do this, but they have to do something.
I'm sure they can do it if they wanted to. This will just take users completely out of WP and into Android, though. At that point, they're better off developing their launcher, apps, and other services on Android and simply releasing another Android phone.
Jolla, Blackberry, and Tizen (did that one ever get shipped?) have Android runtime ports that can run many Android apps really well. Not surprising because the apps are touching the same bits they touch in "real" Android. But that hasn't made a lot of difference to the popularity of those OSs. App users who want Android apps are unlikely to want an OS other than Android. Windows probably had the strongest case for using Android compatibility effectively. I can think of plausible cases where a customer needs to use Windows but wants Android apps.
Here is my prediction for what comes next: Microdroid, an OS that, like Fire OS, is based on AOSP, but uses the Microsoft ecosystem. That will happen because the ecosystem and apps are more important than the OS.
Would it have been cheaper to pay the top 100 Android apps to make a Windows version? Perhaps they do it on a continual basis to keep their marketplace up to date?
On that note, I'd like to try making a windows phone app. Is there anything sorely missing from the platform?
Microsoft tried this a few years ago. Getting top 10 apps like Instagram took a lot of time -- and presumably money too, although that was of course never disclosed.
When Instagram did make a native Windows Phone app, it was feature incomplete and stuck in permanent beta. I don't think they ever released a final version.
Most other top 10 apps never did ports. At the same time, Microsoft was also spending quite extravagantly to get small indie devs making Windows apps through initiatives like "App Campus". Those didn't make a dent either.
Paying their way to a mobile ecosystem was a complete failure for Microsoft. Even with its deficiencies, I'm sad that Windows Bridge for Android ("Project Astoria") is dead. The iOS bridge is nowhere close in practical use. Windows 10 universal apps don't have developer mindshare in the mobile space. Windows 10 Mobile is pretty much dead.
The problem with apps when I left WP wasn't necessarily #1-50, it was #51-500. They had most of the top 50 (with a couple glaring holes, but those didn't impact me personally).
The problem was that "apps" have become the default mobile delivery platform for a lot of things that should be websites, and the creators of those apps always target two platforms: Android and iOS.
So you were just continually left out of the party.
Pizza chain has a mobile app for online ordering? Not on WP.
Smaller-scale sports network or league has a streaming app? Not on WP.
>Is there anything sorely missing from the platform?
without trolling : the users. It is possible to have some success on the windows mobile platform, but there just isn't a critical mass of users.
Other than that, even though it has its problems (like Android or iOS), it has most of the things you would expect.
I'm OK with low users. It's impossible to capture users on iOS and Android because the marketplace is so huge; I can't build anything which doesn't already have 10 different versions. The prospect of a "new frontier" is exciting to me, even if the frontier is very small.
You're not necessarily wrong, though it can be hard to make money on a platform with low users.
HOWEVER! I once met a guy when I was travelling in the UAE, and he built/sold a Twitter app for Palm OS smartphones (their next gen OS they launched some years ago). At the time, he was making close to $40k a month. So there's definitely money on those platforms if you can deliver a good product.
I remember a strategy similar to this earlier in the Windows Phone lifecycle - maybe they weren't outright funding the dev teams, but they were offering large incentives. I'll paste a link here if I can dig it up.
Yeah - we were working on a startup idea back in '11 or '12 and MS offered us $2500 to build on WP first.
It wasn't nothing, but it was also not even a week's salary for our team and building on WP would have taken more than a week.
No mention of Islandwood (the iOS bridge), which is probably more important, if less ambitious. The missing apps preventing Windows Phone adoption are not Android-only.
I did a deep evaluation at work of project Islandwood & my conclusion was that there's just enough framework support to make Candy Crush run, but that's about it.
That's exactly it. It's fine for a game that makes minimal use of UIKit and doesn't have high performance requirements.
Any complex non-game app will require a UI rewrite using the Windows UI framework bridge. That means many months of work, compared to the 1-day effort of bringing an Android app over using "Project Astoria".
I used to run Ubuntu for ARM on the same development phone/tablet as Android for the sole reason that I can use the Ubuntu/debian tools to debug some Android OS related issue.
It is very easy to setup with chroot.
MS can probably get linux kernel VM running inside WM ARM cpu. With that, one can probably quickly run Ubuntu or Android unmodified on WM.
Pro: probably just work. Google did most of the works already. Android VM runs in x86 Windows/Linux today.
Con: Might need more memory. 2+GB for MVP. Not a low end phone anymore
Not sure why MS doesn't start with this approach and extend from that.
Would be great to be able to run Android apps on other platforms, even if they don't replicate the native host UX or have access to all the platform APIs.
The only solutions I've seen are
-Myriad Alien Dalvik (which isn't free)
-Google's ARC Welder (which is very fast but only works inside Chrome/Chromium, doesn't work with all apps, only runs one app at a time and quite clunky to use)
And emulators like Bluestacks or Genymotion, which are generally quite slow.
But requires that you have Windows Pro as MS has "helpfully" set Windows Home and Windows basic to not allow Hyper-V to run on a core i7 unless you have the Pro version. Which I sadly discovered when I bought a new high-end desktop and didn't realize (because very few specify) which version of Windows came with it. Of course I can load Ubuntu on the same machine and use Hypervisors all day long, but then we're back to Linux aren't we :-)
As a developer, I wouldn't think this would be good. Mainly because I wouldn't have had tested the app on alternative platforms, and people would give bad reviews when it doesn't work, despite me never making the claim that it's compatible.
You can't download the apk from Google play directly to your Linux machine. You'd have to first install it on your android device and then manually copy to your Linux device - at that point I don't think many users would expect it to work 100% and probably wouldn't review it as such
I wouldn't be willing to trust that. Users can be pretty damn stupid. How many times did we see people who were running beta versions of Android and iOS, and give bad reviews to apps that weren't fully supporting it from day one?
Yes, it would have been easier, but that's not the (current) strategy.
The idea of Windows 10 is to have a converged OS that runs on PCs, phones, tablets, games consoles and everything else. "Universal" apps can run anywhere (not necessarily with the same UI).
It's an ecosystem play.
Devs creating apps now have a potential market of more than 100m Windows 10 users, and that will keep growing. (Microsoft's stated target is a billion users.) Apps are not just for Windows phones.
Otherwise, in a few places, Windows Phones are actually more popular than most people think. In France, for example, Windows Phone (12.3%) is not far behind iOS (14.6%). In Italy, Windows Phone (12.4%) actually outsells iOS (10.0%). See http://www.kantarworldpanel.com/global/smartphone-os-market-...
That is basically correct. My understanding is that Jolla phones run an Android runtime, either Dalvik VM or ART, plus the Android Framework code.
Had Microsoft taken the approach of running a separate runtime for Android apps instead of trying to map frameworks, they might have something by now.
They would still have to map the semantics of the behavior of an app being foreground or not, connect the clipboard, etc. So it's not like dropping-in a runtime that's meant to be portable, but it's a lot closer.
I understand Microsoft's business interest in entering this space, but at this point there seems to be quite little incentive for consumers to switch from Apple and Android phones.
The success of this project seemed dubious for several reasons, not the least of which is the dependence of so many apps on specific functionality of the Google Play Services API, which is subject to change. But even if Windows phones could run all Android apps perfectly, this only solves the issue of Android's entrenchment. What feature could a Windows phone offer that competing phones do not? There is the questionable justification of "integration" with Microsoft's desktop offerings, but honestly much of this functionality is already available. If there is some great boon to this that justifies the cost of the switch for users, it isn't obvious.
If I owned Microsoft stock I would question this investment of resources. How much is this costing the organization, and what is the likely return? For return on investment they not only have to pull off a techical feat that nobody else has achieved, but also the availability of 'Windowized' Android apps will have to spur a massive increase in Windows Mobile sales, another unlikely event.
Maybe this project doesn't cost much or maybe Microsoft sees it as eseential for their business' future and worth the risk.
The lack of apps for windows mobile is a killer feature it's missing.
I think they have tried other avenues, like incentivizing developers ... but they are so far behind, what other options could they pursue to solve that problem?
If you have a product that is highly unlikely to succeed, the solution isn't to invest money in highly unlikely remedies. If that's your best option (maybe Microsoft has better ones; I don't know) kill the product.
Also, they could use a VM and give up providing a 'Windowized' interface to the apps.
Buddy all three platforms mentioned here run on the same arm based Qualcomm SOC. If by vm layer you are implying that there needs to be any translation done for differing underlying processor architecture then you are mistaken.
