It's weird that this isn't the biggest news out of all the announcements today. Seems like an Electron fork is more interesting.
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
I think the idea of having new frameworks being built upon the cross-platform layers now present in all the competing vendors, is really the most viable way forward.
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. ;)
I'm confused now. I didn't think this announcement was to allow apks install on Windows 10. Simple ask: Will you be able to download the Amazon App Store apk from the handset's browser, install, and run the app?
No it seems like a developer have to integrate with Project Astoria some how to replace the Google APIs with the Microsoft ones and then submit the app to the store. I doubt end users will have access to that capability.
That's not what Arstechnica is saying (regarding the recompile - they just need to publish to the store):
"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."
This is the same strategy Blackberry tried, more or less, and I'm skeptical that it'll work out any better for Microsoft.
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.
My understanding is that this is different from Blackberry's play because windows won't be running a vm of android, instead the code itself is now easily compilable in visual studio as a windows 10 apk.
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.
Except they are building the Play Services APIs on top of the Windows APIs.
> 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.
This is a brilliant move to make Windows 10 much more relevant. I really like some of my Android apps, but I want a Windows phone. Hopefully this will encourage apps like Automatic to move to Windows phone.
I also wonder if this will affect Xamarin in a negative way.
I loooooooove my Windows Phone. Seriously. Everyone stares at me as if I'm some sort of mutant when I tell them that I am a developer and I still love WP, but it's true. I have used iOS, BB, Android, but none of them compare to WP to me. I like the mix of customizability with solid, expected behaviors. The MS apps are phenomenal (also the Nokia apps), and all the major services have some sort of app, most official by now.
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.
Second this with my WP preference. I have a device for the major platforms, but my WP experience is better than the others. It's more intuitive and has is already where the others seem to be trudging towards, in terms of content first. The consistency across apps and within the platform make for a cohesive experience that is moving closer to being seamless with the desktop experience.
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.
Oh, yeah, I didn't mean WP would take over. I do think WP will take a bigger chunk of the market and will be around for the long haul, though.
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.
If I build a native Android app using Xamarin and then take that code and compile it using Visual Studio to then run on Windows 10 will the Windows ecosystem collapse into itself like what happened to Ron Silver in TimeCop when JCVD pushed his present self into his future self?[1]
I just switched to one. The interface feels polished, in a way that I've never experienced on a smartphone before. I've used ios and android devices, and I always found them clumsy and icon-heavy; lots of looking at little pictures, when it's so much easier for me to read text.
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.
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.
It is inevitable, they are going where the apps are. Android apps will run in isolated mode on Windows 10 and you can develop Andriod apps using VS. iOS was a surprise but that would make porting more apps easier. I hope this would finally give the enough apps for Windows phone.
> I hope this would finally give the enough apps for Windows phone.
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'm disappointed to see Microsoft give up the UX control on their platform. I bought a Windows Phone because I like the WP UX better than Android or iOS. I'm also skeptical of the returns for Microsoft. How many users want the apps on Android or iOS but don't want an Android or iOS phone?
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.
It is the platform not the device. It is also about having our data securely hosted in the cloud for use on all of our devices. I think this is a brilliant strategy.
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.
I too have a WP. However, it's become wearisome to figure out what is content and what is actionable. There are other issues, but they clearly started something with flat design.
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?
I'd guess that obj-c compilation is just done with clang (as they're already using clang for Android). The fact that they've apparently reimplemented UIKit/Foundation/etc. is the more surprising part to me.
Unfortunately, many developers are going to be writing code in Swift. Xcode and Swift are baked and there's plenty of Swift information (e.g. http://www.h4labs.com/dev/ios/swift.html)
At this point, it's probably not worth writing in ObjC just to be compatible with Windows.
Swift probably still won't be used in production for some time due to the editor (Xcode) being extremely buggy. Error messages aren't great and with each new release of Xcode, there are syntax changes.
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 use Swift for small applications, but the language is clearly incomplete, and and its tools are not ready for large, complex projects. You can use it, but it's painful. Just today, I had to write dozens of lines of RawOptionSetType code to mimic a C bitmask.
I've been developing for iOS since 2008, so much this! Swift is just not ready, I constantly run into "WTF" moments when I find something that's standard in most languages "has not been implemented yet" in Swift.
I think the point of this is to port existing apps. Microsoft has a lot of different technologies (like .NET with Xamarin) to build multiplatform apps going forward. But this helps Microsoft catch up to Android and iOS in terms of app availability now.
sure, maybe today. but this lays the groundwork for Swift to eventually come to Windows as well. seems naive to think that this wouldn't be their end goal.
I'd love for Swift to be open source. Realistically, it'll take 2-3 years at best. I've been waiting for F# to mature for cross-platform development. That would be a great language to move to.
I can't wrap my head around how apps with any kind of advanced animation could work. I mean Windows Phone 8.1 has decent animations, you can do translations, scales, rotates etc but it has no kind of transition effects or bitmap effects at all. At least ios seems to rely quite heavily on that kind of stuff...
However exciting this is, I wonder how the support and future development will be accounted for. Porting an application is probably easy but the moment android adds a feature that is not supported by the Microsoft abstraction, you are either opting to choose the least common feature set or are maintaining two separate code bases. Both very unfavorable outcomes.
I love windows phone and don't really miss many applications on it but I know many people do. Hope this fixes it.
This is amazing. I'm very curious how it works under the hood with the Android and iOS platforms. It wouldn't surprise me if it gets translated into MSIL. That's how I would do it at least.
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.
I know devs for BB10 felt burned when BBRY announced the Amazon app store is coming preloaded on BB 10.3 OS for "entertainment" apps. Where the native BB World app store remained for "productivity" apps. Speaking from experience, the momentum for top tier AAA apps has all but shriveled up and died
I like how the graphic has "Web" and ".NET/Win32" in the wrong lanes, sending you to a sure death in the face of massive oncoming Android and iOS traffic as you try to cross that bridge to a cross-platform nirvana.
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.
For Android they are just using LLVM to generate the binary and deploying it to their emulator (hyperv based I believe).
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 wonder how UI accessibility for people with disabilities, e.g. blind people, is going to work for these ported apps. That is, will the UI of an ANdroid app ported to Windows Phone be as accessible as it was on Android, or as accessible as a native Windows Phone equivalent would be? Hopefully they didn't do this half-assed and ignore accessibility altogether.
In honor of "Where's the Beef", there is no info about this and you can't try it. Buried on an MSDN page is a signup form for a "limited number" or beta slots.
I classify this announcement as: currently vaporware.
I'm a full-time iOS developer and want to share my perspective on this news. The developers who create those amazing apps on iOS are not going to fall for this. I'm one of those developers, who pays very close attention to detail to make pixel perfect apps that I'm proud to put my signature on. I will not accept my brand being introduced on Windows or any other platform using a glorified code generator. 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. There is simply no shortcut to a great app, and a developer who is proud of his app would not release something that a machine generates. A great app is not one that has been thrown together using abstracted APIs and a code generator. 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. Windows' code conversion isn't going to encourage the really good apps to migrate, although it might entice some cheap knockoffs or poorly designed apps to ship an equally poorly designed experience on Windows. So bottomline, I don't expect apps like Instagram to suddenly appear on Windows because of this.
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.
> 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.
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.
This makes me feel old because I've heard this same speech when it was about assembly language:
"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.)
> "The developers who create those amazing apps on iOS are not going to fall for this. I'm one of those developers"
>"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.
As a developer working at a smaller shop where software isn't a main focus this is great news. Not everyone is an artisanal software developer, sometimes you've just got to give you users your content and services where they are.
With a tin ear no less. It seems that these types of statements focus on a small world vision devoid of a taste for, or experience, within the walls of mid and larger corporate entities whose systems are windows 10x over. Knowing that a massive client like a retailer, financial institution, etc. could put heat on an app developer to bring it to Windows because of the bigger savings that way for the client is big. This isn't about Candy Crush. This is about integrating that app which some business unit loves into the larger IT structure of bigger orgs.
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.
Apple devs love money like everyone else, so you should consider the benefits of adding support for WP.
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.
> I'm a full-time iOS developer and want to share my perspective on this news.
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.
> I will not accept my brand being introduced on Windows or any other platform using a glorified code generator...
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.
That was my first big ? as they were rolling on this set of features. But, in terms of languages, the uptake for MS with another language seems like merely a bandwidth issue at this point. Build 2016 could feasibly include Swift? What if they could bring the quality of Visual Studio on OSX to Swift and have the easy hooks to get those apps running on Windows?
I wonder if Google will realize it's now going to be forced to push "Android laptops" for "native performance" on the market instead of doing it on top of Chrome OS (like Microsoft is doing here) which is a battle it's going to lose.
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.
If this makes more people ignore Windows phone as a platform and just develop Android apps I'm all for it.
Anything that hurts MS and their platforms gets a plus in my book. This looks like a nice step in the right (non-ms) direction.
As GNU lover I cannot understand this much of hate toward Microsoft , Why ? Microsoft is the only not spying on you , Google and NSA and every other big name does too.So if you want blame someone there is more name's applicable to blame ( like NSA , Government , Google and etc ) to blame than Microsoft.
Assuming you don't use Play Services you can run an Android application under any fork of the AOSP, or anything with a compatibility layer for it (like Jolla or now Win10). You can run Windows applications under, uhh, Windows.
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