The Future of libgdx on iOS

The latest Xamarin update, which brought us Mono 3.0, breaks our libgdx iOS backend. More precisely, it breaks the IVKM Monotouch port by Michael Bayne, on which we rely to run our JVM bytecode on iOS. Michaels already working fixed up most things, but there are still some bumps on the way to a fully working version, which requires the assistance of Xamarin.

Seeing how every update of Xamarin breaks our iOS backend, i can no longer promote this solution with good conscience. My skills and time budget are insufficient to support Michael, and not being able to fix things myself makes me really uncomfortable. The code i contributed to IKVM Monotouch was trivial compared to what Michael pulled off.

For this reason i’m announcing the deprecation of the Xamarin based iOS backend. Here’s how that will go down:

  • We’ll push out the 0.9.9 release in the coming weeks, containing the stable IKVM monotouch port that is compatible with the previous release of Xamarin iOS (
  • We’ll tag the release as always, the remove any signs of the Xamarin backend from the repository as well as our build system. This will simplify our build considerably
  • We’ll create a replacement for the setup-ui, which is long overdue, and update the documentation were necessary.
  • If you are currently working on a game, you should avoid updating to the latest Xamarin iOS version. Stick to libgdx 0.9.8, or the upcoming 0.9.9, or any nightly release in between those two versions.. If you already updated Xamarin iOS, you can downgrade to a working version ( pkg) as discussed in this issue.
  • We will start packaging the RoboVM backend starting with 0.9.9, which should now have feature parity with the Xamarin backend, thanks to a metric ton of hard work by Niklas Therning, creator of RoboVM. You should be able to “port” your game to that backend without huge problems (ymmv).

Here are the pros and cons of this change:


  • Performance of RoboVM is not yet on par with Xamarin. It should be sufficient for many games. I’m in the process of setting up a benchmark suite to quantify this
  • Debugging is currently not supported in RoboVM. You will have to resort to printf.
  • No RoboVM apps on the app store yet, at least to my knowledge. However, RoboVM compiles to native code, like Xamarin (and by proxy Unity), or Flash, and it’s unlikely that Apple will reject apps compiled through RoboVM.


  • Less layers of abstractions, RoboVM is a dedicated VM running (native, ahead-of-time compiled) bytecode.
  • Full class library support, it supports the same Java classes Android supports (minus the Android specific APIs of course).
  • IDE & Maven integration, the former being currently limited to Eclipse. You work just like with desktop, Android or GWT projects.
  • Incremental builds, no more multi-minute waits to deploy to a real device
  • Entirely Free and open-source, you still need a Mac and an Apple developer’s license though. Direct complaints towards Apple HQ.

This is not a choice made lightly. I believe our deprecation measures are adequate, please speak out if you disagree. Overall i believe this change to be positive and i hope you share this thought with me.

I’d also like to state that this is in no way the fault of Xamarin. IKVM Monotouch is a (brilliant) hack, that just happened to work really well. It does not make financial sense for Xamarin to support this “use case”. We’ve received support from Xamarin in form of free licenses for 3 developers, for which we are greatful. They’ve also actively participated with comments and suggestions in the early phases of our iOS backend effort.

45 thoughts on “The Future of libgdx on iOS

  1. Thanks for the info. RoboVM seems like a much better option in the long run. Was the issue with touches not being registered correctly in the simulator fixed already?

  2. Being new to libgdx, this question may not make sense, but does this change to RoboVM affect existing projects (i.e. ones set up with gdx-startup-ui.jar)?

  3. Tried to delete this comment after I actually read things and it seems it’s only dissociated it with my account. A better question would be, when do you anticipate releasing the update to the setup-ui?

  4. That sounds great! I hope performance won’t be that much of a difference. Looking forward to the benchmarks.

    I assume with RoboVM it is now possible to use the networking library from the Java API?

  5. Solid iOS support remains a big blocker for adoption of LibGDX. I hope to see this new focus produce positive results.

  6. This means that using RoboVM I can use Android third party SDKs (facebook sdk, flurry, chartboost…) on iOS or I would need to create platform dependant interfaces and bridge things on iOS side to iOS SDKs?

  7. Its a shame for me, especially since downgrading to Xamarin does not seem to solve the problem for me. I am running into other Xamarin issues in this version.

    However, My first attempts with your robovm support have been quite succesful. I do have 2 requests though:

    1) could you please provide clear instructions how to build really for the appstore. (So the route to get the archive that can be deployed to the store using Xcode). I could not figure out how to do this.
    2) could you include some examples that show how to use some ios platform specific features? How to use it in combination with Admob for iOS for example.

    If you do this I will be very happy to give my app a go in the appstore at very short term. I have something that seems 99% ready for publication based on my robovm tests from the nightly.

  8. Niklas has added quite a few performance optimizations in the last release (method dispatch is not way smarter, LLVM optimizations turned on, etc.). I have not benchmarked it myself yet, ymmv.

    And yes, you can now use the networking library from the Java API (and all other things supported on Android minus UI libs)

  9. Can you maybe mail Xamarin support and ask for a downgrade to a version < Since you are a paying customer, i'd assume they'd give you that option.

    Concerning your other questions:

    1) this is something some folks over at the RoboVM group have been looking it. I'll have to relay you to those guys. See!forum/robovm
    2) RoboVM has something called Bro, which allows you to call ObjC APIs. I have not yet tried this myself, as my focus is currently on fixing up the build and RoboVM backend, as well as writting a new setup tool. You can find docs on Bro on the RoboVM wiki When in doubt, folks on the RoboVM group should be able to help.

    As stated above, the Xamarin issues are out of my hands, and i'm sorry if this caused you financial loss. IIRC Xamarin has a 90-day refund period, maybe you can use that?

  10. Dont worry about my Xamarin nvestment. I use it for other non-libgdx things, so it is definately not a lost investment. Thanks for the other references, I am going to have a look at it.

  11. Thank you for this annoucement! Two more days and I would have thrown $300 away for something I wouldn’t use.

  12. Thank you for the update Mario. We are fully supporting you on this decision as well as Niklas on his journey with RoboVM. Thumbs up!

  13. Not really thrilled. RoboVM may become good in time, but this early with alpha software that hasn’t yet produced a iOS app. I have more confidence in the Xamarin solution, because fixes and workarounds could be made, c# solutions plugged in and it is a professional development tool with debugging, and it is proven to make iOS apps. Well I understand it would be a pain to keep fixing stuff and in a year when RoboVM has proved itself I would have much more confidence. The reason I use libgdx besides that it gives me full control and all the nice stuff Eclipse gives, is cross-platform and I was really hoping for some more reliable solutions for iOS that will give me confidence I should keep using libgdx. I need to release a game soon, and I guess I will have to do it with Xamarin downgrade, but shortly after I can throw away my C# code ? and start over with new problems and objective c code with RoboVM. Just bad timing I guess.. trying to think of some positive side to this but I can’t heh, let me sleep on it.

  14. I am currently working with Xamarin, and I runs just with enough performance on iPhone 3GS. As you state the performance is worse with roboVM, will that greatly affect the game? I can’t really afford any more performance drops. Even though the xamarin solution brought terrible bugs as well to my game, like ugly graphics because the stencil buffer doesn’t work and reloading after popping an UIViewController. I might consider moving to roboVM if these issues are fixed over there, and then lack the support of iPhone 3GS and similar devices.

  15. Now if we could get something similar to RoboVM that would allow a game to be easily ported to WM8 you’d have all the mobile platforms covered.

  16. Question, when Michael from PlayN updates the IKVM Monotouch to use the latest Xamarin, will Libgdx be able to use it?

  17. Awesome! I’d rather have an open source solution as well, even if I never end up touching their code.
    I’d be interested in news about WP8 ports as well- if they ever have significant market share.

    I still think Apple is greedy for asking $100/yr for developers + 30% of profits. I guess it’s their way of trying to guarantee someone makes at least $142 to just pay the license cost 😉

  18. I agree with this. I tried things and it is a bit too soon to drop Xamarin. In its current state RoboVM is just not there yet (the simple fact that you cannot create an app for publication without hacks is an example).

    Also, even if RoboVM would be production-ready, the nice thing about Xamarin is that you can also combine your Libgdx project with iOS platform-specific libraries using nice and clean C# because Xamarin did all the nasty work for us already. If I want to do Facebook integration, use Admob, use iCloud, Game Center or whatever, this is very simple now using C# from Xamarin. With RoboVM it would still require me to do a lot in Objective-C directly and mess with combining all this with RoboVM.

    The Xamarin solution was just so smooth, elegant and nice for rapid development. Only disadvantage was (or is?) the initial investment but it shouldnt be too difficult to earn this and more with the release of your game(s).

  19. Are all the LIBGDX features available through RoboVM? If not, is there an estimated time when they will be?

  20. Yes, we just need to repackage the latest IKVM. But we’ll only do that for the 0.9.9 release, after that any Xamarin folks are on their own for the most part.

  21. RoboVM has a similar ObjC -> Java bridge that Xamarin has. There’s a project that translates the ObjC headers of all iOS APIs to that bridge automatically. That way you can work with the APIs from within Java, without having to write ObjC code yourself.

    I agree that RoboVM has a way to go, but we can push Niklas by helping out with testing and feedback to get there faster.

    Xamarin is not an option in the long run, it will break forever at some point.

  22. Almost. We still lack text input via on-screen keyboard, modifying already playing sounds, and OpenGL ES 1.0 (gonna fix that one this weekend).

  23. WP8 will most likely never be a target for libgdx i’m afraid. Mostly because their OS level APIs are asynch and can’t be used to implement the JRE classes.

  24. I’ll try to get that in over the next 2-3 days. If you chose “generate iOS project”, both a Xamarin and a RoboVM project will be generated.

  25. Alright cool, just wondering. I’m about to show off libgdx to some people at my university for a project we are starting and I just want to show them the direction the iOS side will be taking.

  26. I am not professional but I need to ask when you sum all the time that spent on hacks to push VM on iOS Is not it easier to port whole LibGDX on C++ or Objective-C and then to build it? I think that Cocos2D choose that way.

  27. The way things are going, it will not take long for the RoboVM becomes part of LibGDX. Even with my injury have purchased a license from Xamarin, I believe the path is RoboVM do serve the purpose.

  28. It would in no way be easier (or appealing) to maintain two codebases in different languages, neither for libGDX developers nor for libGDX users.

  29. 4 hours after starting up a new Mac, we had my game running with roboVM in the emulator, tomorrow testing on a real device. The other day I was ready to drown myself or switch to Unity or Xamarin, but now I could see our games go through with roboVM, also because they are relatively simple and performance is not a huge issue. Not having a debugger will be a royal pain still 😛 and I also fear running into a problem I cannot fix myself, possible showstoppers make me sleep poorly.
    I had this week planned to test a iOS shop solution with Xamarin, and suddenly everything changed and I panicked, but now I just want to save those 300$ and go with roboVM. I am looking forward to a post that says a libgdx game has been released through RoboVM.

  30. Did you consider as an option? It is very similar to Xamarin, but it is based on Java, has Eclipse plugin and large developed infrastructure. And what’s the best, they have GUI designer and wrappers around iOS/Android/WP API, all pure Java. Seems like a better option instead of the alpha-quality RoboVM, isn’t it?

  31. Update: I tried it out and it actually runs much faster! 🙂 I just need to make sure that you use power of two textures. The only issues left are splash screens, set my icon as prerendered and a guide of how to implement iAd, game center, google game cervices etc.

Leave a Reply

Your email address will not be published.