Libgdx and RoboVM on a device

Niklas, the man behind RoboVM, a JVM for iOS, just fixed up a few things that make RoboVM work with libgdx properly. This includes being able to run things on a device!

I managed to run all our demo games for which there’s a RoboVM project (Super Jumper, Vector Pinball, Pax Britannica, Gdx Invaders), and am happy to report that they all run very well on both an IPad 2 and IPad 3. Except for Pax Britannica, which has a couple of issues and seems to be too much. I haven’t done formal benchmarks yet, but things look really promising.

If you feel like testing things out (realizing that this is still super early days with lots of work to be done), here’s a quick rundown on how to get things going.

  1. Make sure you have all prerequisits for libgdx development for iOS, except Xamarin.iOS/Monotouch!
  2. Open Eclipse, and install the RoboVM plugin from This will install everything you need
  3. Get the libgdx source and import all projects into Eclipse
  4. Right click any of the xxx-robovm projects in Eclipse, select Run As, then iOS Device App, or iOS Simulator App
  5. See things running on your iOS simulator or device! (Note that you need to provision your device to be able to run anything on it, which costs you 90$/year. Thanks Apple!)

Currently lacking/broken:

  • Touch doesn’t work on the simulator, but works fine on the device. Investigating.
  • Audio is missing completely, we’ll use ObjectAL most likely
  • Many things in the Input class (proper orientation handling, keyboard input, etc.) are missing
  • Benchmarking and optimizations
  • Proof of concept on the iOS App Store
  • Debugging support (unlikely to come soon, but hey, it’s free and super easy to use)

Benefits over the Xamarin backend:

  • Free, apart from the mandatory 90$ Apple developer cert
  • Open-Source
  • Full JRE class library support, same as Android 4
  • Extremely fast compilation and deploy times (seconds, not minutes) to both the simulator and device

I’ll try to put some work into it over the next few weeks, maybe we can finish this puppy up. Please refrain from filing RoboVM issues on our tracker for the time being.

Happy coding!

23 thoughts on “Libgdx and RoboVM on a device

  1. This is a really great news! Thank you very much for spending time on this free iOS alternative. Good luck.

  2. That’s what I want to know too :p
    I’d say he’s come up with a device to slow down normal time flow, so he is able to do more in less time. Or he’s somehow super efficient and needs to write a quick post on time management 😉

  3. Just a random thought… from the RoboVM site: “The RoboVM compiler translates Java bytecode into native ARM or x86 code.”. Does that open the possibility of converting libgdx games to native executables for windows too?

  4. Awesome! 🙂
    Any info on how this fares in terms of performance in comparison to the Xamarin route? In particular, how’s the performance concerning JNI? Box2D was/is pretty slow with Xamarin…

  5. Just a short question, before I investigate further. Will it be possible to integrate the AdMob iOS SDK in apps running through libgdx+RoboVM?

  6. Are you referring to not having to use the JVM for running the game on Windows? If so, from what the website says on this page ( is that it looks like currently it would only compile to an executable that could only be used on Unix-based OSes such as Mac OS X or Linux distros (such as Ubuntu or ArchLinux, etc.). Now, I don’t know if this would apply to compiles using Cygwin or MingW on Windows. Maybe try that?

  7. You are correct. As for Windows solution, I understand some LibGDX users had success with using Avian ( for creating self-contained applications. I guess it depends on being very picky about third party libraries because every dependency can introduce new problems for Avian and RoboVM.

  8. Now, there is one possible issue I do see with using RoboVM or Avian. Quite often, mostly for Linux-based distros, isn’t it much better to compile separate builds for both the x86 and x86_64 processors since certain programs only work on one but not the other? Examples would be older versions of Wine or the game recording software GLC, both of which can have difficulties working on x86_64 (although, Wine has gotten better in the last couple years). Would this be a problem at all?

  9. just read that it compiles and does not run in a vm.. so 3d performance is likely fantastic!

  10. Its Amazing!
    Guys, what about
    libgdx game+RoboVM -> LLVM bytecode -> Emscripten+asm.js (supported by ff now) -> fast non-plugin browser game?

  11. Browser backend is very slow, especially in scene 2d. (100 actors with one texture gave me 7 fps)

    Browser backend support only an subset of only java language, not java bytecode/ You need to compile only java sources.
    Compilation is SLOW. I have 70 000 lines of my code and ~140 000 library code. I’m afraid that hl3 will be finished before I can translate it to javascript.
    GWT-compiled code is slower than hand-made javascript. If you use asm.js, code is faster, and in ff it is only 2x slower than native.
    Games need to be fast to work.

Leave a Reply

Your email address will not be published.