For about 2-3 weeks now i’ve been actively switching our libgdx game dev framwork’s iOS efforts over from Xamarin/IKVM to RoboVM. For those of you who missed the last few weeks of libgdx updates, here’s a breakdown what RoboVM is and why we use it.
What’s RoboVM?
The promise of RoboVM is a fully workable ahead-of-time compiler for JVM bytecode for iOS (and 32-bit Linux/Mac if you fancy that). RoboVM uses Soot and LLVM to transform the bytecode to native x86 or thumbv7 ARM code. RoboVM employs Android’s latest runtime class library iteration, making it compatible with pretty much any JVM library/language out there. RoboVM also comes with a set of bindings to the ObjC APIs of iOS. These bindings are realized via a custom Java-to-native bridge called Bro, and generated automatically from header files, with minor manual intervention. JNI is of course also supported, pending some more esoteric features.
Libgdx, Xamarin & RoboVM
Previously we leveraged Xamarin iOS plus a port of IKVM by Michael Bayne of PlayN fame to get our Java based game dev framework to work on iOS. This combination worked, but had its flaws. For one, not all of the Java runtime classes were supported, most prominently the java.net package. Also, some parts we heavily rely on in libgdx, like JNI, were extremely slow with the Xamarin/IKVM hack. Note that this is not an issue with Xamarin iOS itself, but due to the nature of the IKVM port. Xamarin have been extremely helpful and gave us a few licenses at a very low discount for development. All this limitations also meant that running anything complex was always a gamble, and using other JVM languages was pretty much out of the question.
RoboVM fixes many of these issues. The JNI bridge is considerably faster, there are less layers of abstractions, all of the Android runtime classes are available, it will allow us to write games in Scala and JVM languages other than Java, and best of all, it’s entirely open-source under Apache 2. Libgdx development on iOS thus becomes essentially free, apart from the Apple tax (developer license, need for a Mac). Note that Trillian AB will eventually have to start looking into options to further fund RoboVM. If we get a chance as a community to help fund RoboVM, we should definitely do so. RoboVM is shaping up to be an excellent tool, and i think it’s worthwhile to support, just like Xamarin.
Niklas Therning from Trillian AB, creator of RoboVM, has laid the foundation for our RoboVM backend by porting our Xamarin/IKVM based libgdx backend over to RoboVM. We’ve since been fixing up many issues and missing features, and are reaching feature parity with the Android backend. You can follow the todo list on Github.
First RoboVM/libgdx App on iOS App Store, many to follow
To prove that RoboVM is a viable option, Niklas submitted the first RoboVM-based app to Apple last week. I supplied Niklas with the rights and sources for our libgdx Super Jumper demo. While it’s definitely not the fanciest game ever, it does exercise a large percentage of the few hundred thousand lines of libgdx’s managed and native code. Today, the app got approved by Apple, and is now available for your “enjoyment” on the App Store. I believe that this is an indication that our decision to go with RoboVM was the right one.
Meanwhile, others have started porting the libgdx-based games over from Xamarin iOS to RoboVM. Here’s the RoboVM version of Delver, by Chad Cuddigan, aka Interrupt. You should totally buy it either on Google Play or Steam! I did the “port”, which boiled down to converting oggs to mp3s and implementing a missing feature in our libgdx RoboVM backend.
Christoph of Noblemaster Games ported both hist latest game Demise of Nations as well as an older title called Desert Stormfront to RoboVM (you can buy Desert Stormfront and other games on the App Store, Google Play or directly from his site!). Both ran out of the box (Christoph, correct me if i’m wrong :)). Christoph also observed a considerable performance improvement going from Xamarin/IKVM to RoboVM:
Jonnus ported their libgdx game game Wings of Fury from Xamarin/IKVM to RoboVM as well, seeing pretty significant increases in performance. I’d attribute those mainly to the better JNI implementation in RoboVM.
You can find other stories on the forums.
Next Up
I plan on finishing the last bits of our RoboVM backend in the next few days to achieve feature parity with the other platform backends. Once that is complete, i’ll revamp our beloved setup-ui and replace it with something new. My goal is to make libgdx a truely polyglot game development framework, so we’ll need better integration with existing build and dependency management tools. I’m currently looking at Gradle, which seems promising, albeit a bit less ideal when it comes to IDE integration when compared with Maven.
Niklas is going to attend JavaOne in San Francisco next week. I hope he gets the time to demo some of the libgdx games we are currently preparing for this event.
Pretty cool to see how much can be done in just a few weeks. Thanks to our community for the support, and especially Pascal, Chad and Christoph for providing Niklas with real-world games he can demo at JavaOne! You guys rock!
