RoboVM is no more, what now?

For the better part of 2 years, RoboVM has been my life. Today, RoboVM announced its discontinuation, abruptly ending that chapter. The amount of things I learned during that short period has easily overshadowed anything I learned during previous jobs, both on the technical and non-technical side. I’ll deeply miss this daily experience.

So, what does this mean for libGDX? There’s good and bad news. Let’s get the bad news out of the way.

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.

Mobile OpenJDK 9

Oracle recently announced OpenJDK 9 availability for both iOS and Android. While this seems like the most sensible option, it has a metric ton of down-sides as of this writing.

  • Tooling: No integration with IDEs, Maven or Gradle
  • Bindings: No bindings for Objective-C/Swift APIs. No easy consumption of Objective-C/Swift APIs, everything goes through JNI
  • Binary size: The generated binaries include all of OpenJDK, both native code and the class libraries. Apps are huge
  • Performance: It uses Zero VM on iOS, which is essentially an interpreter. Say goodbye to performance
  • Bitcode: Uncertainty about Bitcode compatibility, the interpreter relies on some assembler and signals, both of which don’t work in Bitcode land

None of this is likely to change in the short- to midterm future, so OpenJDK 9 is out.

CodenameOne

No. Next.

J2ObjC

A while ago, Google open-sourced J2Objc. It falls under the category of “transpiler” meaning it translates one high-level source (Java) to another one (Objective-C). Google is successfully using it for a few of their apps, like Google Inbox. Conceptually, it’s very close to GWT, which we employ to get your libGDX games running on the web.

  • Tooling: Essentially a command line tool. There exists a Gradle plugin that takes away some of the pain, but no other tooling is provided
  • Bindings: J2ObjC is mean to allow you to share business logic while you write your UI in ObjC/Swift. As such, there are no bindings. Also notable is the lack of support for most of the Java SE APIs. This makes including 3rd party Java libraries a no-go.
  • Binary size: very good, mostly due to the fact that it doesn’t have to ship a proper managed environment or Java SE APIs.
  • Performance: very good, it’s essentially Objective-C
  • Bitcode: Out-of-the-box, as things are compiled to Objective-C

With a lack of support for Java SE level APIs, the use of reference counting instead of GC, and the fact it only works for Java source code, J2ObjC is not fit for use with libGDX. One GWT based backend is enough 🙂

Avian

Avian is a great piece of OSS tech. JMonkeyEngine chose Avian as their driver on iOS a while ago, so there is some precedent. Avian let’s you chose whether you want to use the Android class library or OpenJDK’s class library, definitely a plus. However, Avian suffers from a few minor and one major shortcomingy.

  • Tooling: No integration with IDEs, Maven or Gradle, save for the integration JMonkeyEngine did with NetBeans
  • Bindings: No bindings for platform APIs, no easy consumption of Platform APIs, JNI hell it is
  • Binary size: Not terrible when using Proguard
  • Performance: The AOT mode essentially takes the JIT mode output and bakes it into an executable. The JIT is rather primitive, and performance isn’t where it should be
  • Bitcode: No path forward to be compatible with Bitcode, as the AOT directly generates machine code. This is the big one

Avian has always been a favorite of mine, as the engineering behind it is top notch. However, using it in production is just a major pita, and the missing path to Bitcode rules it out completely.

Xamarin + IKVM

Back in the olden days, Michael Bayne of PlayN fame took it upon himself to create a somewhat functional path for Java bytecode to live on iOS. The solution consisted of compiling Java bytecode to .NET CIL via IKVM and shipping a heavily cut down version of the OpenJDK class library. I added support for JNI so we could also use it with libGDX. Suffice it to say, it was a Frankensteinian monster of epic proportions. But it worked. Until Xamarin released a new version, in which case non-trivial bug fixes had to be made. Let’s give this a fair shake:

  • Tooling: No integration with IDEs, Maven or Gradle. Integrates with Xamarin Studio and Visual Studio though, including debugging. Otherwise it’s a bunch of shell scripts.
  • Bindings: Excellent, you are able to call into pretty much all native APIs through the IKVM C#/Java bridge
  • Binary size: Good, were it not for the fact that you also need to ship a huge Java class library next to the Xamarin runtime.
  • Performance: Pretty good, although IKVM introduces some suboptimal paths, which makes this solution slower than RoboVM
  • Bitcode: clear path forward, as Xamarin is based on LLVM

Note that the IKVM fork Michael and I worked on is mostly defunct. The cut down class library is also a huge problem, with things like java.net completely missing. Were it not for the last alternative in this list, this solution would probably win.

Intel Multi-OS Engine

Formerly known as Migeran, Multi-OS Engine is a pretty nice piece of tech that let’s you run Java bytecode on iOS. Under the hood, Multi-OS Engine is powered by ART, Android’s virtual machine, which has an AOT compilation mode Multi-OS Engine exploits.

  • Tooling: Integrates with Android Studio, IntelliJ IDEA and Gradle. Used to have support for Eclipse, but it seems that’s no longer available. Also let’s you build and deploy from a Windows machine (using a Mac as the build slave).
  • Bindings: Provides a custom bridge called Nat/J, which is quite similar to RoboVM’s Bro, albeit quite a bit more cumbersome. It appears that all native APIs are accessible from Java via Nat/J, and 3rd party libraries can be bound (semi-)automatically.
  • Binary size: OK but not great. Bigger than comparable RoboVM binaries.
  • Performance: Good, faster than RoboVM in some workloads, slower in others.
  • Bitcode: Currently unsupported, but apparently Intel is working on it.

Multi-OS Engine comes closest to RoboVM along all these axes.

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:

  1. 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
  2. Release a new libGDX version next week, that will make Multi-OS engine the default iOS backend for newly created libGDX projects
  3. Begin creating bindings for popular 3rd party iOS libraries. This is where we hope the community can jump in
  4. 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:

  1. Keep publishing updates using RoboVM 1.14.0 and the corresponding backend
  2. Immediately start adding a Multi-OS engine based version of your app for iOS
  3. Test it and report bugs on our issue tracker
  4. Switch over to Multi-OS Engine as soon as possible

In Closing

There will be some rough edges with the new Multi-OS Engine backend. We are in contact with Intel, who have been very reactive in fixing issues we identified while creating the new iOS backend. Please help test the new backend and report issues, so Intel is able to fix problems on their end.

Multi-OS Engine is free to use, but not OSS. Before you guys start screaming for my head again, I’d like you to read the above analysis carefully one more time. None of the OSS options are even close to production ready. I will however happily merge any and all backend based on those OSS options.

I’d be grateful if everyone funnels their emotional energy created by this announcement into helping out with the new backend, e.g. testing, bindings, reporting bugs etc. I believe this is a much better use of everyone’s time. If you feel the need to vent, I understand. But please don’t expect me to vent with you. The winding down of RoboVM is already emotionally taxing enough for me. My goal is it to keep things running smoothly for everyone, I have no intention to waste time on a screaming contest.

Happy coding,
Mario

154 thoughts on “RoboVM is no more, what now?

  1. I feel sad to read about closing down robovm. It feels like weeks ago that I read about joining Xamarin to pursue with RoboVM. I wish the best of luck to all of the developers in the team that made this awesome piece of software!

  2. That’s not good. RoboVM was an easy way to port apps to iOS. Looking at todays market share the most money is on android. At least for most small developers, big developers will continue to make big money on iOS and android anyway.

    I started app developing on iOS but I will surely never get back to native iOS programming, because it is to time consuming regarding the profit.

    If transferring code to Multi-OS is time consuming, I would rather develop a new app for android instead of port to iOS, because a new android app would make more profit anyway. So if Multi-OS turns out to be a bad alternative I would stop developing iOS games and other will probably act the same way. Perhaps that will give more space for other small developers that will stay with iOS.

    Apple should have supported RoboVM but that is only a dream, when in reality even a slight mention of a cross-play feature between iOS and android, or even the hint that an app is available on other platforms would avoid your app from being accepted in the Apple Store.

  3. While `No. Next` for CodenameOne made me laugh out loud, what are the real reasons for making it not an option out of the box?

  4. Not using LibGDX for iOS development myself, I have no stake in this as such – but I wanted to wish you the best for all your hard work and trying to be as accommodating as possible.

  5. Sorry to hear this Mario, thanks for all the work in aiming to provide an iOS solution as quickly as possible.

    Looking forward to trying out the Multi-OS Engine backend next week.

  6. It’s good for CRUD apps, it’s performance is simply not good for anything coming close to a game.

  7. This is a very sad moment.
    Was jjust fiddling around with some Libgdx stuff and bam, my inbox was got this sad announcement.
    Hope the new alternative will be as good as RoboVM was.
    R.I.P

  8. Intel will kill it’s support for Java in an upcoming update of the engine. Once Google lost to Oracle a fork of Android is a legal liability when they don’t make enough money from it.

    If you think Intel has product commitment then I have some friends from Telmap (100m USD purchase by Intel) who I can refer you to.

    You have a pre-existing bias about Codename One which is somewhat disconnected from the facts. The fact is that all of the solutions you mentioned aren’t supported seriously with the arguable exception of J2ObjC which has a radically different use case.

    I try not to hold grudges and look at things as a professional, I decided not to go with RoboVM after talking with Niklas in 2013 Java One. This wasn’t because we saw you guys as competitors, it was because I understood the exact set of events that would lead you to this point. There was no other choice with your business model.

    Anyway, when you finally look at things as an engineer and understand that we know what we are doing we will be happy to help you guys even though as I’ve always said gaming isn’t our priority.

  9. I was really looking forward to making a native iOS app with RoboVM. Are there any alternatives that offer the flexibility RoboVM offered?

    I’m really sad about this news. Hope things will sort out.

  10. But gaming is the priority of LibGDX, so what use has Codename One for this case? Better no iOS-Apps than such that perform badly in most cases.

  11. > Intel will kill it’s support for Java in an upcoming update of the engine.

    Shai, could you please elaborate on this or give some references.
    From techincal point of view, what shall they offer in MOE if it’s solely Java-based?

  12. Isn’t using MOE just stepping on the same rake? Google got sued by Oracle for using Java APIs and this might affect Intel too since it’s based on Android’s ART (if I’m not mistaking). The legal stuff was probably also a part of MS’s decision so I would not count on MOE much. At least for me BugVM seems like a better way forward, though would require a bit of help to maintain it

  13. It’s not based on any facts other than 20+ years of industry experience, working at Sun behind the scenes and being familiar with the mentality. I would however put money on this if I was a betting man 😉

    The logic is really simple, this isn’t an official “product” but rather something that’s out as a research project. That makes it easier to kill.

    Since it’s based on Android IP this puts it in a point of liability, Oracle will HAVE to sue if they succeed with Google since if they don’t Google can claim that Oracle isn’t impartial and has different rules for different companies and ask for their liability to be removed. That’s exactly why Microsoft won’t open source or sell RoboVM licenses, if they could burn every reference to it ever existing they would do that…

  14. LibGDX is a gaming engine, Codename One has many layers the lowest of which is a JavaVM and IDE integration. Effectively LibGDX could reside almost entirely outside of our API for the gaming use case.

    We didn’t design Codename One with this purpose but since we are open source this would be far easier and far more practical than all other options suggested.

  15. Now that Microsoft killed RoboVM, i was wondering why BugVM has not been listed as an alternative within the others? Is there any chance libgdx will add a BugVM backend?

  16. Whatever replacement solution you use, use an Open Source solution, or the same will happen sooner or later. For example, Intel killing Multi-OS engine, just like that. Do not repeat the same mistake (even if I understand that RoboVM was initially OSS).

  17. What about adding a Teavm + Cordova back-end? I see at http://teavm.org/ that there already exists a teavm libGDX backend … at least as an option for us non-Windows users that rely on Linux?

  18. Multi-OS engine is currently the most technically viable. As said in the blog post, we’ll be happy to merge backends for any alternatives.

  19. See the paragraph above on merging policy. We’ll happily merge alternative backends for iOS, however, Multi-OS engine is probably the most technically viable at this point.

  20. See above. Happy to merge alternative backends, MOE is probably the most technically viable at this point.

  21. The effort that needs to be put into BugVM shouldn’t be underestimated. That being said, we’ll merge alternative backends if contributed.

  22. I understand what you mean but if Intel kills it, it will not be viable at all.
    And on the other side, Open Source is not magic and not synonymous of a well maintained project..

  23. Yes but as Mario said, work on RoboVM shouldn’t be underestimated. That makes sense since a dedicated team (of 8 ?) was running RoboVM.

  24. >Since it’s based on Android IP this puts it in a point of liability,
    Oracle will HAVE to sue if they succeed with Google since if they don’t
    Google can claim that Oracle isn’t impartial and has different rules for
    different companies and ask for their liability to be removed.

    If they succeed, but will they succeed? Last news I heard (some time ago) was that Google was besting Oracle but I’d love to learn more.

  25. Unfortunately the US Supreme Court ruled in favor of Oracle and reverted the original ruling that API’s can’t be copyrighted which triggered the Android N migration to OpenJDK. Oracle then requested 9+ billion in damages…

    So the saga continues. Anyone who touches Android right now is at “risk” so MS chose wisely to avoid that risk.

  26. Well I think Google knows that they will loose after the appeals court turned down the initial victory decision for Google. There’s a new court hearing coming soon. They are now preparing their Android OS to use openODK to get away from litigation, which Oracle still argues that might not save the future versions of Android from liability. So there’s a chance Oracle will keep suing. There are also rumours about Google replacing Java with Swift from Apple as the primary programming language. Apparently Google, Facebook and Uber executives had meetings about this switch. The current efforts of Android fork of the swift’s open source compiler is lead by a Facebook employee on the official Swift Github website.

  27. Contrary to your argument about MOE, same thing happened to RoboVM can happen to Codename One as well. When your company gets super popular perhaps thanks to LibGDX community, it may get purchased by a bigger player, it might stop being open sourced and once day might just get killed off for whatever reason it is. Money talks, business as usual. I think all options have their own risks in the long run.

  28. Our community is pretty big thank you. But yes that’s a great point.

    It’s just incorrect. We are ex-Sun/Oracle guys and we know the licensing rather well. We were remarkably careful to avoid the pitfalls of licensing (one of the reasons we didn’t pick RoboVM back in the day was a discussion I had with Niklas in Java One 2013 where I got the sense that he isn’t familiar enough with the finer points of that).

    Our VM is a clean room implementation that uses the GPL+CPE license which is a huge part of the lawsuit. Obviously no one can guarantee that there will be no lawsuit in the future which is why we tried to become licensees in the past and try to keep an open channel with Oracle. When we grow enough to warrant that this is the exact path we will take. Unlike Google we won’t have liability since we used the correct license and didn’t get contaminated by the Android VM.

  29. I’m guessing those rumors are a play to cause Oracle to settle rather than keep the litigation going. Either way big companies like Microsoft and Intel would try to distance themselves from anything like this unless it’s remarkably profitable. I doubt Intel is seeing any serious revenue from this product to justify the liability risk.

    I’m not familiar with Intel internal processes but at Sun we used to have a “productization” process to turn something into a product (notice that a lot of things you would download from Sun were not officially “products”). Looking at this tool it doesn’t look like an “official” product. The difference is very important since products aren’t killed overnight but experiments do get killed. The productization process included a very heavy legal angle…

  30. It uses legacy code from Android (prior to OpenJDK integration), may be sued by Oracle. Microsoft don’t wanna fall into same trap as Google. That’s why they shut it down.

  31. https://docs.google.com/spreadsheets/d/1zALNJKvBrvfPTSe9EpsOSsSHDivmacFkIXHFwQd2MM0/pubhtml?gid=1206755131&single=true

    Shai, I did evaluate Codename One many times. I was extatic when I first saw it, way before RoboVM even was public. It’s good for WORA mobile/web apps.

    However, as you yourself said, it’s not geared towards gaming, and the numbers proof that. It being OSS is definitely a plus, but until it’s performance reaches acceptable levels, it is simply not an option for libGDX.

    I know you are a passionate guy, and I appreciate input. But please refrain to spam the entire convo here.

  32. No, it is not a far more partical solution. Codename One being OSS is definitely a plus. But it’s performance is not where we need it to be. https://docs.google.com/spreadsheets/d/1zALNJKvBrvfPTSe9EpsOSsSHDivmacFkIXHFwQd2MM0/pubhtml?gid=1206755131&single=true

    I’m more than happy to consider it if that ever changes. But there are other issues, like not supporting a wide array of Java SE APIs, no support for JNI (which we need for physics, math and other things) etc. There’s also zero debugging support, unless one likes to wade through the generated native code.

    Please stop derailing the discussion. You have always made it clear that Codename One has no interest in games. Your system design is proof of that and that is OK. It does what it’s intended to do: WORA mobile/web, not games.

Leave a Reply

Your email address will not be published.