Having Android APKs work unmodified (minus Google APIs) is pretty neat, but has been done before (BB, Jola).
The real interesting part is the the Objective-C toolchain. Seems like they have an emulation layer for UIKit, Foundation and other frameworks. Probably hard for them to keep up with changes and I expect a lot of growing pains for early adopters.
Great news overall, I can finally add a proper Windows Phone/10 target for libGDX. Makes RoboVM more versatile as well :D
Instead of using one particular platforms' GUI framework - use only that which is common among each vendor, and fill in the missing with single-language, multi-target code, i.e. write once, truly run everywhere.
So that's why I'm putting energy into things like libGDX and MOAI as a developer - the host-build-is-the-OS ethos really seems like the way out of this big mess that Microsoft has now made. ;)
"Unlike Islandwood, which will require developers themselves to recompile their software to bring it to Windows, Astoria will in principle work with any old APK, without requiring the developer to do anything but publish the app in the store—as long as the APK sticks to the APIs that Astoria will provide."
It's nice enough in the short term, maybe -- Windows Phone users can get some subset of quickly-ported things -- but in the long-term it seems to doom Windows Phone to second-class status; why would you write a real, native Windows Phone app when you can just do a quick half-assed port of your Android/iOS version? And if Windows Phone is just a platform that has a bunch of outdated, bad versions of some Android/iOS apps, there's not a lot of reason to buy it.
Also, it appears that it is indeed about allowing compiled binaries to run unmodified.
> Specifically, Windows Mobile (and yes, that's now officially the name for Windows on phones and sub-8 inch tablets) will include an Android runtime layer that'll let them run existing Android apps (both Java and C++) unmodified.... Astoria will in principle work with any old APK, without requiring the developer to do anything but publish the app in the store—as long as the APK sticks to the APIs that Astoria will provide.
> When we spoke to Microsoft about Astoria, the company would not tell us what proportion of the AOSP and GMS APIs would be supported, but it did confirm that it wouldn't be 100 percent; there will be APIs that Astoria does not provide, and accordingly, APKs that use those APIs will not run.
> On the flip side, Astoria will offer some integration points with Windows so that Android devs can, with minor alterations, support features like Cortana in their apps.
I also wonder if this will affect Xamarin in a negative way.
IMO, Microsoft's "uncool" image is the only thing holding it back. Like everything else, it's cyclical. They'll be back on top, and I think Windows 10 is going to start getting people back on board.
I don't know if I would suggest they can get on top on phones, but they are definitely putting forth a very strong proposition for everything down through tablets.
If they can get just a big chunk of enterprise-supporting apps along with the top non-game apps over one way or another, they'll have carved out a sustainable chunk of the pie. This along with their casting of bread and butter like Office onto Android and iOS gets them into an enviable position going forward. But, it's a massive slog to get mainstream consumers to retrench when we aren't looking at something similar to the difference between a Blackberry and an iPhone.
By cyclical, I meant the "cool" factor of companies. I'm sure many people here remember when Apple was a total joke after being awesome. Microsoft is coming out of their "joke" phase, IMO.
All of the widgets "feel" better to me, too, than Android or ios.
I realize it's largely personal preference, but I hope windows phone sticks around. I'd hate to have to go back to one of the others some day.
It's not a bad platform, save for the lack of apps.
We already have BlackBerry and Amazon AppStore flavors for our apps (without google login, cast, or anything else from the play services lib). So it should be trivial to add one more for Windows.
I wonder about the UX of such a port though. Windows apps don't really look like android ones (or iOS's for that matter). Sure, it should bring more app but I can't help but worry for the general experience of the platform.
I agree; I bought a cheap-o Windows Phone to test and do development with. I'd love to use a Windows phone as my primary phone but 90% of the apps I use and need are nowhere to be found. If this can get them to bring them over, even if they don't tailer the experience it will hopefully still be good.
I can see how Microsoft wants to make the software play. They want to have all the apps available on their phone so they turn away as few people as possible. However, I think phones are still too focused on platform for this to work. The experience already varies widely across devices on the same OS (low end v.s. high end), I have difficulty seeing how it would be acceptable cross-compiled to windows phone.
Off topic: I am volunteering to help with computer classes at the library in my small town. This morning we talked about training people to view devices as not being so important, instead keeping their digital lives on one of the two cloud platforms we will probably support: Google (drive, docs, pictures) and Microsoft Office 365. I think that we are suggesting the right choice for people who are just learning to use computers and the Internet.
Me too although apparently it has some problems:
It is a good read, I am not necessarily agreed with all of this (since windows phone UX never bothered me) but he has some strong points.
Material Design by Google looks great to my eye and it seems like MS is heading that direction a bit more.
And that's a good thing IMO. WP and Win8 UI really scared away average consumers who don't want to figure out a whole new way to use a computer.
"Developers will also be able to recycle their Objective-C apps for iOS using new tools in Visual Studio."
Notice "... tools in Visual Studio".
To me this sounds more like conversion/porting tools, not so much like support for compiling ObjC and a runtime. Is there information elsewhere that sheds more light on this?
At this point, it's probably not worth writing in ObjC just to be compatible with Windows.
I wouldn't write any new code in Objective C. Swift is just a better language to work with. 12 months from now, you'll be much happier that you wrote 25k lines of Swift in 2015 instead of Objective C.
I love windows phone and don't really miss many applications on it but I know many people do. Hope this fixes it.
Also curious what the limitations are. If this works as advertised the Windows Mobile store could go from mediocre to pretty awesome as long as they get tailored for the platform.
As you need to recompile the app instead of directly running it I guess they have made wrappers that implement the native Android and IOS APIs on top of the APIs for Universal Windows apps? That would be a massive effort.
The other question is whether they recompile Java/ObjectiveC to something else (C++ or .NET) or whether they are running these languages natively and providing interop to their native SDKs.
When delivering to Windows they use an android subsystem and a container to run it. It is a quick and dirty approach, you still would need to put some Windows specific code to access to Windows only SDK such as inking API or Cortana.
If you are creating an app from scratch it seems like an universal app with c++ shared code is the way to go
I classify this announcement as: currently vaporware.
Also, developers don't avoid Windows because it lacked a code conversion tool. If all it involved was learning a new language or porting some code, developers would do it, just like they learned to go from Objective C to Swift, or all the evolution of Cocoa Touch through the years.
Developers avoid Windows for far more complex, intangible reasons that go way beyond a code converter. There are all kinds of perceptions about Windows and Windows users that simply will not change because of this tool. The iOS developers I know will shrug off this announcement, and continue shipping their apps on iOS. I admire Microsoft for overcoming the technical challenges of creating this tool, but sadly they have not overcome the perception and mindset challenges of a dieing platform.
More developers use Windows than any other platform. Your entire comment epitomises the cultish bubble that many HN developers seem to live in, completely oblivious to the rest of the world.
"A real programmer won't use a high-level language like C or Pascal. A great program is one in which the developer has written every machine code instruction to maximize performance and minimize memory use."
(Btw, Instagram has been natively on Windows Phone for at least a year.)
>"I will not accept my brand being introduced on Windows or any other platform using a glorified code generator"
Good, but there are some big companies that already are doing this and have no problem with apps running on subsystems to allow be in multiple platforms. King, Gameloft, EA and pretty much any dev using already Unity or Unreal is using a similar mechanism to be crossplatform.
This is just democratizing the mechanism so developers who didn't have access to those tools could port their apps more easily.
Frankly, your attitude comes off as elitist.
BTW, Instagram have been on Windows Store since a year ago.
You come across as an Apple fanboy snob.
Consumer myopia misses the billions related to "boring" apps that corporations use. Today's keynotes definitely balanced target markets. This wasn't a consumer-only sampling.
1 - There's a lot less completion in the windows store.
2 - You're bringing fire to cavemen, it doesn't need to be pixel perfect.
3 - The Windows 10 platform has some pretty amazing possibilities, you might want to dip your toe in the water without re-writing your app.
While I agree with your "perception" problem all that has to happen is one article in the WSJ written about an iOS dev who languished in obscurity in the App Store only to find riches in the Windows store. Then the gold rush will begin, just like Facebook apps, iOS apps, and lately Android apps the rush will be driven by outliers.
As someone who spent the better part of the last 3 years porting things, I'll share my rebuttal :)
> I will not accept my brand being introduced on Windows or any other platform using a glorified code generator.
That's a rather negative slant on a compatibility layer - one that must exist if you're doing multiplatform dev in a reasonable fashion (i.e. not rewriting the entire application for every platform.) Granted, one you write yourself will likely suit your app's needs better.
> If I want to bring an app to Windows, I would learn the platform, go "all in" and make my app as perfect on Windows as it is on iOS. This would require me to dig into all the SDK docs, understand the platform capabilities, learn the native APIs, deal with the challenges of supporting different form factors, and a lot more.
I have never seen a perfect app in my life. Regardless, even if you want to take this route, having a compatibility layer you can lean on to get things up and running, before you begin to replace the things that aren't up to snuff, can be incredibly useful. I've repeatedly used this kind of technique to good effect - relying on banned APIs for Windows 8 ModernUI apps before replacing said calls with their WinRT equivalents, using slower POSIX I/O APIs on PS4 before replacing them with their faster platform specific equivalents, etc.
The nastiest bit of porting was always the big elephant in the room which I could not (efficiently) handle in this manner - the graphics APIs. Maybe 10-20 kloc of platform specific code, written blindly in the hopes that it would be roughly along the right lines, and that my program would one day link on the new platform.
If I was lucky, I'd be able to recognize bits and pieces of what I'd rendered on my first run. I was frequently not lucky - but a program that can run can be debugged, and so I did.
> A great app is one in which the developer has written and/or analyzed every line of code to maximize the aesthetics and performance on the platform it is running on.
That might work for small mobile apps. The projects I've worked on are simply too big to afford this kind of effort. We would much rather analyze every line of code that matters, and ship within a lifetime. Chances are, a compatibility layer will handle some things which I won't need to replace. One of the things that annoyed me greatly for my windows 8 port, was that so much had to be replaced simply because the older APIs were banned. Plenty of that code would have worked just fine to ship with, otherwise - it felt like busywork. E.g. instead of CopyFile or CopyFileEx, you'd be forced to use CopyFile2 - except the latter was unavailable on Windows 7 and earlier, so we had to keep around both versions for our platform abstraction layer. This got nastier with the OVERLAPPED I/O bits of code...
> Windows' code conversion isn't going to encourage the really good apps to migrate
Simply put, I disagree. Although we agree that it's no panacea - it's quite unlikely to be as simple as Copy, Paste, Build, Profit.
> If all it involved was learning a new language or porting some code, developers would do it
I personally know and regularly have lunch with counterexamples. Developers who insist that the only reason they're not targeting e.g. Android is that they don't want to bother porting some code. Ditto for Windows. They don't think porting some code would have an acceptable return on investment, so they don't bother with it. They already know the languages and APIs involved, too.
> just like they learned to go from Objective C to Swift
They didn't learn to do this. Neither have I - why write platform specific Objective C for my logic, unless I'm actually dealing with platform specific details? The vast majority of my code does not benefit from being platform specific, being instead written in C++, which means the vast majority of my code does not benefit from replacing Objective C with Swift.
Again: There simply isn't an acceptable return on investment. A few horror stories of Swift compiler bugs encountered by early adopters overheard in my local IRC channel helped remind me of the costs of following the latest shiny thing.
> Developers avoid Windows for far more complex, intangible reasons that go way beyond a code converter. There are all kinds of perceptions about Windows and Windows users that simply will not change because of this tool. The iOS developers I know will shrug off this announcement, and continue shipping their apps on iOS. I admire Microsoft for overcoming the technical challenges of creating this tool, but sadly they have not overcome the perception and mindset challenges of a dieing platform.
At least this I can agree with :). The cross-platform developers I know won't shrug, however - and will note that one more barrier making Windows dev not worth it has been, if not eliminated, lowered.
Where did you get the idea that this is a glorified code generator?
> Developers avoid Windows for far more complex, intangible reasons...
Maybe mobile developers do, but outside of that there are whole industries that are centered around Windows. I see a lot of workers using Windows on little devices now too. Just yesterday a guy came to my house to inspect our lease return vehicle. When he was done, he whipped out this tiny little laptop with a touch screen that I had to sign with a stylus (which worked perfectly). It was running Windows 8 and that was probably the tenth time I've seen something similar in the past year.
> ...sadly they have not overcome the perception and mindset challenges of a dieing platform.
Bullshit. Windows is better than ever. More people use it than any other desktop OS. There are millions of IT departments around the world that would laugh and laugh and laugh if you suggested that they use OS X or Linux instead of Windows.
Why am I suspecting that Apple had an additional agenda with Swift?
Android laptops = all 1.5 million apps work by default (although might have some UI issues at first, depending how Google implements them - I think they should just put them in "windows") - unlike ChromeOS/Windows 10 approach which will require devs to add every single app to those stores.
As for the spying bit; I don't believe that one iota. Of course they spy as much as everyone else, they just hide/spin/sell it better.