According to our release cycle of 3 weeks, it’s time for another release! The last release brought you improvements with regards to the GC as well as link times. Let’s see what this release has in store!

Optimize All The Things – Part 2


When RoboVM compiles your app, it gathers all classes that are referenced directly or indirectly, starting with your main class. The problem with this approach is that RoboVM might pull in classes that are actually never used. E.g.

The parseFile() method has dependencies on XmlDocument and File, which themselves depend on a lot of other classes, which also get pulled in. However, when we follow the code path starting in the main() method, we see that parseFile() is never used. If we throw away parseFile(), all the classes the method depends on can also be ignored.

This process of elimination is known as shrinking or tree shaking. It’s one of the steps ProGuard also performs.

What effects does tree shaking have on your app & development?

  • Reduce the number of classes and methods that get compiled into your app
  • Reduce binary size as less code ends up in your executable
  • Decrease compile times considerably, as less classes have to be processed
  • Decrease link times considerably, as less classes have to be processed

This is a beta release of this feature, so we decided to switch it off by default. To enable it, all you need to do is add a new element to your robovm.xml called <treeShaker>. There are three values you can set:

  • <treeShaker>none</treeShaker>, no shaking is applied.
  • <treeShaker>conservative</treeShaker>, only methods marked with a @WeaklyLinked annotation will potentially be thrown away. We already started marking eligible methods in the CocoaTouch bindings.
  • <treeShaker>aggressive</treeShaker>, any method not part of the code path starting from main will be thrown away.

Let’s look at some numbers. I created a standard single-view app in Eclipse. I then compiled the app for ARM64 release mode, for all three tree shaking modes, clearing the RoboVM cache in ~/.robovm before each compilation.

Aggressive tree shaking has a huge effect on compile times and link times. If you have a warm RoboVM cache, re-running your app takes considerably less time. On my MacBook Pro early 2013, i can rerun the single-view app after a code change within less than 5 seconds:

Effects on the binary size are also considerable. A stripped release mode executable for ARM64 is now only 5.4 MB big. We will try to improve conservative tree shaking results over the coming weeks by annotating the APIs in our bindings appropriately.

With great power comes great responsibility. Here are things you need to be aware if you use tree shaking:

  • If you use reflection to instantiate classes, you might have to add them via <forceLinkClasses>.
  • If you use expression evaluation when debugging, methods that got shaken out will not be available.

Bug Fixes & Enhancements

Thanks to your feedback as well as internal testing, we were able to close over 60 issues on our various trackers. Here’s an excerpt:

  • The RoboVM license manager in IntelliJ IDEA will no longer mess with your theme of choice.
  • The RoboVM SDK libraries will now be automatically assigned to projects imported from Maven/Gradle into Eclipse/IntelliJ IDEA. This reduces chances that you are using different RoboVM versions. You should still make sure that the RoboVM version defined in your build files and the version of your IDE plugin are the same!
  • Interface Builder integration now reflects your full class hierarchy in generated ObjC stubs.
  • Interface Builder synchronization has been improved, including fixing some exceptions, opening resources in subfolders and applying IB on project import.
  • The class limit has been lifted; you can now have billions of classes in your app. We are not saying that’s a good idea though :).
  • Added support for Gradle 2.4 for faster build times.

Please keep the feedback coming! Talk to us on our mailing list, our Github issues trackers or via

Samples & Documentation


We’ve created a new Tutorial on Cross-Platform Basics. This tutorial shows you how to setup an app for both iOS and Android, sharing code via a core project. We’ll add a screencast in the coming days. You can find the source code for all tutorials in our new RoboVM Tutorials Repository.

With our Interface Builder integration coming out of beta, we also revamped all our samples. They are now fully Mavenized/Gradleized and can be easily imported into Eclipse or IntelliJ IDEA. They’ve also been update to use storyboards where possible! Check our Samples Guide for instructions on how to do that.

We’ve also received some questions regarding 3rd party library compatibility. We’ve summarized all you need to know on our new APIs & Javadoc page.

Next Up!

We are never done with polishing and improving stability! The next release should contain a few more goodies and improvements regarding performance, Interface Builder integration and so on.

Besides the polishing work, we also want to shift gears and start focusing on the cross-platform aspect of RoboVM. We’ll add dedicated project wizards that will allow you to create cross-platform iOS & Android projects straight from within your IDE of choice. We also got another trick or two up our sleeves, but more on that in the next release announcement.

Finally, the Voting for RoboPods is still open! Head over to our previous blog post to get to know what it is and cast your vote! We’ll announce the results on Monday, 1st of June.

One more thing

About RoboVM

The goal of the RoboVM open-source project is to bring Java and other JVM languages to iOS. RoboVM’s ahead-of-time compiler translates Java bytecode into native ARM or x86 machine code that runs directly on the target CPU without being interpreted. The runtime is based on Android’s runtime classes and includes a Java to Objective-C bridge which makes it easy to use the native iOS Cocoa Touch APIs from Java or your JVM language of choice.


Web site:
Google Groups: