First RoboVM/libgdx app in iOS App Store

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 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!

22 thoughts on “First RoboVM/libgdx app in iOS App Store

  1. Congrats Mario, you and Niklas should be really proud of what you’ve accomplished. I can’t wait until I get Critter Rollers on the app store (assuming I can get it ported over of course).

  2. I want to emphasize that i mostly just played the part of a mere bystander in this. Niklas wrote all of RoboVM and ported the Xamarin libgdx backend to it, so all thanks should be directed at him!

  3. Great job, its incredible how fast RoboVM is coming up. Just tested one of our games and the performance is awesome.

    Don’t want to be a bummer, but have to ask. We’ve been working on pushing one of our games to the App Store for some months now, working with the Xamarin.iOS build. I tried upgrading the IKVM folder that Michael uploaded for PlayN, but get a “System.TypeInitializationException” coming from Gdx2DPixmap If anyone has an idea of how to fix, would be of great help.

  4. I’m afraid we have to wait for Michael on this one. It seems to be a bug in the Xamarin compiler, for which there’s an issue on the tracker. Michael is currently busy with many RL things, so i don’t expect a solution to this issue soon. I’ll update our IKVM version once this is resolved. Sorry for the inconvenience.

  5. That’s great news! Going to make it a lot easier to publish games on iOS.

    re-question: yes, the porting was straight-forward. I didn’t have to make any code changes/etc. to my project when going from Xamarin to RoboVM. A lot lot easier and quicker using RoboVM 😀

  6. Yes… kind of… There are some services on the internet which will rent you a virtual mac environment to develop on, they usually charge per hour or you can buy blocks. Never used one myself though so can’t vouch for performance and I’m guessing you can plug your iOS device in to test on device either.

  7. This is awesome. I am in ecstasy.

    BTW is it possible to create reusable Java-based libraries with RoboVM for other iOS apps?

  8. Sounds really good. We have been trying to find a way to do this for a while at my dayjob since some non-game application code tends to get very fragmentated across platforms. Reusing libraries with RoboVM on iOS would save us a lot of time and effort 😮

  9. That’s really awesome!

    I’ll have to find some idevices off craigslist to test… Which devices do you guys test on iOS?

    On Android I typically have one 3yr old device (Galaxy S1), newer device (Nexus 7), and a 4yr old (Droid eris), that I at least try to have run to some degree.

    I’d guess probably a tablet and an iphone 3, or equivalent itouch would cover most of the range?

  10. I feel like GWT/HTML backend is like the unloved stepchild, because it only transforms java source, as opposed to Java Bytecodes. This prevents non-java (but still JVM) languages from being recognized on the GWT/HTML Libgdx backend.

    It should be noted that there is not a better option, so its still great that we have it!

  11. Its an interesting thought, but actually a lot more difficult than from what ive seen and heard from. asm.js is (from my memory) basically just byte arrays. like nothing else. thats why its so optimizable, because its all byte arrays!

    but nonetheless, ive started looking into VMKIT ( as a way to AOT compile java bytecodes (! polyglot !) into llvm bitcodes. This can then be (possibly!) translated into asm.js.

    This is all preliminary research, and ive just started compiling VMKIT, then sleep, then life….so it may be some time, and im not sure it would be even very fruitful. but hey! if they can compile unreal engine to asm.js, why cant we compile some java framework!?!

Leave a Reply

Your email address will not be published.