The title pretty much says it all. While it is an unfortunate announcement, it’s not an all together shocking one. For those who have never heard of it, RoboVM is a technology that allowed you to run Java applications on iOS devices. Of perhaps most importance to game developers, it was the technology that enabled LibGDX applications to work on devices like the iPad, iPhone and Apple TV.
So how did this happen? Well, it’s a bit of a story…
Back in May of 2013 LibGDX moved from (ironically enough) Xamarin to RoboVM to support iOS. At this time RoboVM was open source and simply worked better than Xamarin at the task. Everything was going well until October of 2015 when RoboVM was suddenly purchased by Xamarin. Leading up to this point, the open source project was quietly shutdown and the future of RoboVM was suddenly in doubt. Xamarin responded with free licenses for LibGDX developers, removing a great deal of the fear about the future. At this point I had this, now somewhat eerie, exchange with Nat Friedman, CEO of Xamarin:
The devil truly is in the details, eh? In all honesty, Nat is a stand up guy and I don’t imagine he even knew what was coming next. On the topic of coming next in February of 2016 Microsoft announced the acquisition of Xamarin. For most developers this was ultimately good news, as just a few months later they made Xamarin free and open source. The missing piece in this whole equation is what happens to RoboVM? Xamarin’s goal was to own the process of porting to mobile devices, but Microsoft’s are more about pushing the adoption of their .NET developer stack. Let’s just say Microsoft isn’t Java’s biggest cheerleader at this point. So then, what happens to RoboVM when the dust settles?
That brings us to this day, and this announcement from the RoboVM team:
Over the past few weeks, we’ve been working with the teams at Xamarin and Microsoft to assess the technology and business conditions of RoboVM to determine the path forward for the products. After looking at the complete landscape for mobile development with Java, the decision has been made to wind down development of RoboVM.
We have compiled an FAQ to help guide customers through the impact of this announcement. Please contact us at [email protected] for questions not covered by this FAQ.
What happens to my app developed with RoboVM?
This has no impact on the apps that our customers are currently shipping. If your app is currently working, it should continue to work unless Apple introduces a breaking change in iOS – just like any other iOS app. Android projects and apps that you have created in RoboVM Studio can be opened and compiled in Android Studio or IntelliJ IDEA, and any cross-platform RoboPods you are using on Android and iOS should continue to work in those projects, subject to breaking changes.
What should I do with the app I’m developing with RoboVM?
Depending on where you are in the development of your apps, there are several options available to move forward, including tools that will help you port to Xamarin, and alternative Java SDKs which target iOS. In particular, libGDX has just announced their support for Intel’s Multi-OS Engine, which means there is an alternative for the majority of RoboVM’s active developers. Beyond this, Microsoft and Xamarin are very interested in enabling your success in mobile and we’d like to help you move forward. If you’d like to discuss your app development plans, please email us at [email protected]
Can I continue using my license?
Yes. You will be able to continue to activate your current RoboVM paid or complimentary subscription until April 30th 2017. This should give you ample time to transition your existing apps to alternatives.
I purchased a license, can I get a refund?
Yes. We’re offering a full refund for all existing customers as of today. Please contact us at [email protected] to request a refund.
Translation, Microsoft took a look at RoboVM, decided it didn’t fit with their plans and put a bullet in it. Ouch. In this new world where Microsoft is trying to look more open source friendly and get away from their past of embrace, extend, extinguish, it’s sad to see they didn’t just re-open the source code and let the world continue merrily as it was. Perhaps if there is enough outrage they may do exactly that, as right now the optics on this move don’t look too good for Microsoft. I do however have to applaud them for giving complete refunds to every customer that requests one.
So, where does that leave LibGDX developers in the meanwhile? While the post above linked to the answer to that. Mario Zechner, founder of the LibGDX project, has made a rather extensive blog post on the subject. I suggest you go read the entire thing for insights into the various options available, but I will reproduce key bits below:
RoboVM is dead, what now?
Quite a few libGDX folks have free RoboVM license keys to deploy their libGDX app on iOS. These license keys will continue to work until the 17th of April 2017. However, there will be no further updates to RoboVM, be it new features or bug fixes. The same is true for all the RoboPods the community came to rely on. Moreover, new sign-ups for free RoboVM Indie licenses will also no longer be fulfilled.
In short, if you have a game using RoboVM already, you can continue using RoboVM until the license expiration date. If you start a new game, RoboVM is not an option. In either case, you should move to an alternative as soon as possible.
What are the alternatives?
There are many alternatives to RoboVM, however, none comes quite close to what RoboVM offered. Let’s examine all the available options. We’ll look at them from various viewpoints: tooling support (IDEs, Maven, Gradle), bindings support, binary size, performance and Bitcode compatibility.
Before we dive in, let me elaborate on the Bitcode compatibility, as it is probably the most important feature. Apple recently introduced a requirement that prohibits submission of apps in raw machine code form for watchOS and tvOS. Instead, Apple wants you to submit your apps as Bitcode. Bitcode is a (not quite) machine independent intermediate language from which Apple generates actual machine code on app submission. Any solution that has no clear path to Bitcode is hence at a big disadvantage.
The Options (See Post for Features and Flaws of Each):
- Mobile OpenJDK 9
- Codename One
- J2ObjC
- Avian
- Xamarin + IKVM
- Intel Multi-OS Engine
–Snip–
What is the future of libGDX on iOS?
Tomski has already written a new libGDX backend for Multi-OS engine. Here’s the roadmap for libGDX:
- Clean-up the Multi-OS backend, integrate it with the libGDX Setup UI, and update the documentation. We are at a 95% status with this, i hope to have the code drop sometime this weekend
- Release a new libGDX version next week, that will make Multi-OS engine the default iOS backend for newly created libGDX projects
- Begin creating bindings for popular 3rd party iOS libraries. This is where we hope the community can jump in
- Keep the RoboVM backend around until the licenses expire (April 17 2017). We’ll try our best to fix any bugs in the backend, however we won’t be able to fix bugs in RoboVM itself
The roadmap of your existing apps should look something like this:
- Keep publishing updates using RoboVM 1.14.0 and the corresponding backend
- Immediately start adding a Multi-OS engine based version of your app for iOS
- Test it and report bugs on our issue tracker
- Switch over to Multi-OS Engine as soon as possible
So, that’s where we stand today. The sky isn’t falling, the world isn’t ending, but we are certainly going to see some bumps in the road shortly. No doubt some of you are going to be upset, but be smart about how you direct your anger. Mario and the RoboVM team aren’t the villains here, in fact they just had their baby taken away from them, imagine for a moment how that feels?
It always sucks to see a good technology discarded for business reasons. I think the happy ending for everyone would be if Microsoft open sourced the RoboVM project instead of killing it completely. In the grand scheme of things it may not take off, the skills required to develop and maintain this kind of project aren’t common place. It would however give the technology a chance to live and not be the casualty of a business decision. More to the point, it would allow developers a great deal more time, options and a smoother ride in transitioning to a new solution.
At the end of the day this wasn’t a decision made by Xamarin, RoboVM or LibGDX. The decision is 100% on Microsoft. If you want to properly focus your response, that is your target. Again, Microsoft is a company that is trying to improve their image with developers on non-MS platforms and in the open source community. This action… certainly doesn’t help!