libGDX 1.9.3
Been a while since the last release. Here’s what’s new!
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