libGDX 1.9.3 released – New iOS backends

libGDX 1.9.3

Been a while since the last release. Here’s what’s new!

[1.9.3]
- Switched to MobiDevelop's RoboVM fork (http://robovm.mobidevelop.com)
- Addition of Intel Multi-OS Engine backend for deploying to iOS
- Updated iOS native build scripts to iOS 9.3 and TVOS 9.2
- API Addition: GestureDetector#pinchStop() called when no longer pinching
- API Addition: Gdx.graphics.setUndecorated/setResizable API added to Graphics https://github.com/libgdx/libgdx/pull/3847
- API Addition: Gdx.graphics.getGLVersion(), grab the GL version and implementation type. https://github.com/libgdx/libgdx/pull/3788
- API Change: Lwjgl3WindowListener -> filesDropped(String[] files) adds drag'n drop support for the lwjgl3 backend
- Added isComplete() to ParticleEffect to make it easier to know when all the emitters are done, behaves the same as in the 2D API.
- API Change: renamed Lwjgl3WindowListener.windowIsClosing() to closeRequested() to better communicate its intent.
- Add IndexData.updateIndices method to increase performance when used with IndexBufferObjectSubData. 
- Added FlushablePool
- Added ShapeCache see https://github.com/libgdx/libgdx/pull/3953
- API Change: moved shape builder logic out of MeshBuilder, see: https://github.com/libgdx/libgdx/pull/3996
- API Change: Table reset now calls clearChildren, not clear.
- Fixed crashes in AndroidMusic.java when isPlaying is called. Errors are now logged only rather than crashing the app.
- Added emulation of ScreenUtils for GWT
- Improved performance of glReadPixels() on GWT. New method is 20-30 times faster
- Fixed crash on Mac when using LWJGL2, custom cursors and embedding the game in an AWT window
- Fixed getDisplayModes(Monitor monitor) returning wrong data on LWJGL2 backend
- Fixed Gdx.input.getCurrentEventTime() not being set on LWJGL3, fixes GestureDetector and flick scroll not working
- Fixed not being able to select non-latin characters in TextFields
- Bullet: added CustomActionInterface, see https://github.com/libgdx/libgdx/pull/4025
- Add window size limits option to LWJGL3 app and window configurations

Please update your projects as usual.

Now for the juicy bits. New iOS backends!

Re-evaluating our iOS strategy

A few weeks ago, we announced changes to our iOS backend strategy. With RoboVM winding down, we need a new way to get to iOS in the future. After an analysis of various alternatives we decided that Intel’s Multi-OS Engine is the way forward.

The post received a ton of feedback from all over the community. Many people within the community and the libGDX core team feel uncomfortable with relying on yet another proprietary piece of technology like Intel Multi-OS Engine. BugVM was mentioned as an alternative, which is a fork of the old RoboVM OSS project.

MobiDevelop and Xoppa gave BugVM a whirl and concluded that its name is not too far from the truth. The Gradle and IDEA plugins are broken in various ways, everything has been renamed, and many fixes of dubious quality have been applied. It is also unclear who is behind BugVM, what the release schedule is, and how contributions are handled. Finally, the whole repository is a mess and hard to maintain.

As a result, MobiDevelop created his own cleaned up fork of the last OSS release for RoboVM (version 1.8) from September 2015. Since then, Xoppa, MobiDevelop and Tomski have added various improvements to the fork. The guys have performed the first release of the fork, version 2.1.0, so there’s a stable version out there already. If you plan on using RoboVM in any capacity going forward, I’d suggest using this fork over any other forks. Keep in mind that there’s still the bitcode issue which is unlikely to ever be fixed.

Going forward, we have decided to provide two iOS backend options:

  • The new Intel Multi-OS Engine backend
  • MobiDevelop’s RoboVM fork

In order to support both Intel Multi-OS Engine and the MobiDevelop’s fork, we had to make some changes to the setup UI that generates your libGDX projects. You can now select either “ios” or “ios-moe” (or both if you want to compare) in the setup UI.

Each backend comes with pros and contras that we’ll look into below.

Using OSS RoboVM

When selecting “ios” in the setup UI, the resulting iOS project will depend on MobiDevelop’s fork, with groupId “com.mobidevelop.robovm” and version “2.1.0”. If you have an existing project, change the RoboVM related groupIds in your build.gradle to com.mobidevelop.robovm and the roboVMVersion to “2.1.0”.

New projects will automatically use the MobiDevelop RoboVM fork. If you want to switch a new project to the last official RoboVM build, change the com.mobidevelop.robovm groupIds to org.robovm and the roboVMVersion to “1.14.0”.

The MobiDevelop RoboVM fork comes with an Eclipse and IntellIJ IDEA/Android Studio plugin which you can install in your favorite IDE, just like the official RoboVM. This will allow you to compile and run your iOS app without a command line. The Gradle plugin is also fully functional and used by your Gradle builds. Find out more on the MobiDevelop RoboVM fork site.

The existing RoboPods have a dependency on the last official RoboVM release. They have not been tested with the MobiDevelop’s OSS RoboVM version. MobiDevelop will eventually also fork the RoboPods. Contributions welcome!

Pro & Contra OSS RoboVM

Since the MobiDevelop’s RoboVM fork is based on the last OSS RoboVM release from September 2015, there are of course a lot of limitations:

  • No debugging support
  • No TvOS support
  • No interface builder support
  • No bindings for the latest iOS versions
  • None of the proprietary bug fixes done by the RoboVM team since September 2015 are included. Everything that got fixed in the open-source portions has been included in the fork
  • RoboPods may or may not work
  • No Maven support, as libGDX is Gradle based
  • No Junit support, not useful for libGDX anyways
  • No RoboVM Studio. IDE plugins are enough, and RoboVM Studio doesn’t add much for libGDX game development
  • Not bitcode compatible

Here are the upsides:

  • Drop in replacement for RoboVM
  • Working IDE plugins for Eclipse, IDEA and Android Studio
  • Working Gradle plugin
  • Known source, release schedule and contribution policy
  • Stable and tested

Using Intel Multi-OS Engine

When selecting “ios-moe” in the setup UI, the resulting iOS project will depend on Intel Multi-OS Engine. Before you can create a new project, you need to install Intel Multi-OS Engine.

Once your project is generated, you can follow the Intel MOE documentation to get a better understanding of how it works. The workflow will be very similar to RoboVM, i.e. you create iOS run configurations in your IDE of choice, or invoke Gradle tasks on the command line. Tomski is working closely with Intel to improve the workflow and stability of Intel MOE together with libGDX. Due to that collaboration, Intel MOE now also installs a plugin for IntelliJ IDEA instead of just Android Studio.

Pro & Contra Intel Multi-OS Engine

Let’s start with the contras:

  • The libGDX backend is not as mature
  • RoboPods won’t work, all 3rd party libraries need to be bound anew (though that may be easy with the binding generator)
  • You need to have Multi-OS Engine installed for the Gradle build to work. The MOE Gradle plugin is not available in any repository. If you haven’t installed MOE locally, your Gradle build will fail
  • No Eclipse support
  • Higher build times on code changes as everything needs to be proguarded and dexed

Here are the pros:

  • Actively maintained, with bitcode in the pipeline
  • Debugging support
  • Interface builder support
  • Automatic-binding generator
  • Bindings for latest iOS APIs
  • Can compile from Windows if you have a Mac OS X build slave

Up Next

We believe giving you the choice on what technology stack to build your games is the right thing to do. Which of the two options will ultimately pan out is hard to say at this point. There are risks associated with both of them.

For Intel MOE, we hope to receive feedback over the following weeks and months that we can communicate to Intel to improve their solution. Please report any issues you find on the Intel MOE forums or on the libGDX issue tracker if it’s a problem with the libGDX MOE backend.

For RoboVM, it’d be great if the community could look into RoboPods and see if and how they work with the OSS RoboVM version. The best course of action would be to integrate them with MobiDevelop’s fork, push them to that repository and integrate them with the build. Furthermore, Xoppa and Tomski are working on getting line numbers in exceptions working, which is the precursor for (non-JDWP) debugging.

We have updated most of the wiki with new instructions for Intel Multi-OS Engine. If you miss something, speak up on the issue tracker!

Happy coding,
The libGDX team

21 thoughts on “libGDX 1.9.3 released – New iOS backends

  1. I love how you are going with BOTH solutions. Propietary but more reliable in the mid term, and open but requiring probably more time. Brave and wise decision.

  2. Actually, the open RoboVM solution is much more reliable at this point. Mid to long term MOE should have an edge though.

  3. this is great news. Thanks LibGDX team.

    You guys are the heart of LibGDX and im very grateful for each of you 🙂

  4. Awesome jobs, guys! However “No Junit support, not useful for libGDX anyways” – how so? I find myself writing lots of unit tests during game development and I reckon we should encourage everyone to do so rather than putting them off with such a statement.

  5. I still use RoboVM 1.8 to build and release my games now and my games work perfectly so the RoboVM fork is a best solution.
    many thanks to libgdx team 🙂

  6. I thought the RoboVM one would require many months of work to be truly production-ready, so glad to be wrong. Will Bitcode be ever added? if RoboVM could support bitcode, why can’t the new fork (even if it takes a long time) do it too? thanks for all this info, it really makes a difference for us devs.

  7. Very nice!
    It was a very slow, painful process getting it to work (I think with Apple’s distribution certificates), but I was finally able to update my iOS game yesterday! Was compiling in Android Studio (eclipse was a no go) in a few hours, and almost double that getting the certificates working, but everything LibGDX side worked again!
    (no ‘invalid license’ with valid licenses)

    Thanks for working so hard on getting both backends in, but it would be great if there was a good place for us to follow progress (aside from looking at upload file times on github 😉 )

  8. it’s probably best for libGDX to delegate the complex responsibility of java-to-ios compatibility (including bitcode and all future requirements) to an entity that is solely dedicated to doing that, like RoboVM used to be. this way, libGDX can focus their efforts on advancing other parts of their framework.

  9. LibGDX code can still be unit-tested from “core” module. Lack of unit-tests in platform module is a bit limiting but it usually is only a small part of code base.

  10. No bindings for the latest iOS versions.
    which ios version does MobiDevelop RoboVM 2.1.0 not support?

Leave a Reply

Your email address will not be published.