It's amazing to me that I can write my game completely in Java and get a performant AOT compiled version that runs on iOS.
RoboVM really is amazing for indie game devs, and it's open source. I've already donated around $300 to the project.
I've also done tests to see if other JVM languages work with RoboVM. So far, I have been able to get games written in Kotlin running. Can you imagine writing a game in a nice modern JVM language like Kotlin or Scala, and then being able to publish it to PC, Android , HTML5 and iOS? That's what is possible now, and all with open source.
Obviously, for those who develop non-game apps, native UI concerns mean you can't just publish the same thing to both Android and iOS, but for games that isn't an issue.
> native UI concerns mean you can just publish the same thing to both Android and iOS
That's a myth often seen in "deploy everywhere" mobile dev tools, in reality the design habits/guidelines between the two platforms have a lot of difference and you need a separate UI layer for each more often than not.
Doesn't change the awesomeness of RoboVM, but it had to be said.
> the design habits/guidelines between the two platforms have a lot of difference and you need a separate UI layer for each more often than not
Phonegap is a great tool for writing code once (html5 & javascript) & deploying to many platforms with native capabilities.
I suspect it's not quite there for games, however it has great performance for most CRUD apps.
---
Re: RoboVM, I suspect there will be libraries that will properly use iOS-like UI. Some logic branches will be required, however the main flow is centralized and DRY.
---
There's also cross platform, openGL based tools. If you are making an openGL game, you minimize your need to use the native UI.
I'm curious : what parts of your game code were you able to reuse on the ios version ( apart from obvious things such as the game logic itself) ? Network ? Opengl libs ? Sound libs ?
RoboVM create bindings for most of the iOS API, and there are also bindings being created for 3rd party libs [0]. LibGDX [1] have done their own too.
I created a game [2] in LibGDX for Android, set it up on the Mac, right clicked and it just worked. Not deployed to the app store yet but I will be doing.
I just released my latest Augmented Reality "game" [3] on Google Play which uses Vuforia [4] for the AR, and am in the process of writing the RoboVM bindings for it. Once I've finished that I'll submit it back to robovm-ios-bindings so you should be able to write AR apps for iOS and Android at the same time.
I've successfully used RoboVM to ship native linux binaries from jvm bytecode, in addition to the headlining cross-platform-mobile features. It's fantastic. It worked pretty much out-of-box with a few commands from the Getting Started page.
And as for performance: startup time is impressive: an order of magnitude faster than launching a jar in the jvm, such that you can actually use it in the middle of other shell scripts without blinking. Once it's been running for a while, it's hard to beat the kind of optimizations a JIT compiler can do, but RoboVM is still approximately as fast as java (I think the mailing list handwaves this to about 2x slower; still a couple hundred times faster than most interpreted languages, so I'm pretty okay with this).
RoboVM uses the Boehm GC, which is mature, effective, and (of critical note to me) a heap-compacting garbage collector... which means you can confidently use it even for applications with days or months of contiguous uptime.
I've thrown wicked strange bytecode at RoboVM. It copes fine; I was impressed. (After some time working in golang gave me a great appreciation for the semantic style of goroutines, I've been trying to bring them everywhere. I made some custom bytecode with code derived from the Apache JavaFlow library to try to break RoboVM, and it didn't even blink; I'm now using it with http://paralleluniverse.co/quasar/ very happily.)
And did I mention how pleasant it is to ship statically linked native executables?
I'm pretty sure the Boehm GC isn't heap compacting.
It at least didn't used to be, and if it is it works in some way I cannot fathom, as I'm not sure how you can compact the heap without changing the value of pointers, which the Boehm GC cannot do safely.
That said it's still a very good GC and you should be fine. (It does try to minimize fragmentation in other ways, but nothing is as effective as heap compacting.)
If I understand correctly, when used in "precise" mode, the Boehm GC is capable of compacting. Mono north of version 2.8 also claims to be heap compacting by virtue of Boehm in precise mode.
I'm afraid that you are mistaken about the capabilities of the Boehm GC when it comes to compacting. It doesn't compact so heap fragmentation is a possibility with RoboVM. Mono 2.8 introduced SGen [0] which is a totally separate GC developed by the Mono project. It is a compacting GC and is now the default IIUC.
(I had drawn my impression of Mono from https://en.wikipedia.org/wiki/Boehm_garbage_collector#Uses_a... 's current statement: "The Boehm GC is used by many projects that are implemented in C or C++, as well as by runtime environments for a number of other languages, including [...], the Mono implementation of the Microsoft .NET platform (also using precise compacting GC since version 2.8)"... which evidentially is referring to "also" a different GC entirely, rather than a mode as I had thought.)
Do you know of any good resources that explain more about the precise vs conservative scanning modes of Boehm?
I thought I recalled some references to a precise mode available via a "GC_MALLOC_ATOMIC" function in Boehm which would understand all of the contained data to be not-pointers and thus enable smarter handling, but perhaps that's a necessary-but-not-sufficient thing on the road to heap compacting. I'm hitting a lot of dead links looking for more information sadly; hpl.hp.com seems to have suffered a reorganization lately :(
It's actually what you get when building on linux with no special args: the default behavior is to produce a binary for the current operating system and architecture.
Thereafter, if you want to get fancier and target other specific systems, there are options for "-os", "-arch", and "-cpu"; you can find some description of them in the default usage help message from running `robovm` with no commands.
We used to have instructions for installing and compiling under Linux. Since our main focus is currently iOS and some users were confused by mentioning Linux and thought that they could cross-compile for iOS on Linux we removed those instructions from the web site. Only Linux x86 can be targeted when compiling under Linux. Here's what you need to install if you are running Ubuntu 12.04:
[edit: are you saying only 32-bit Linux can be targeted, and not 64bit/multiarch?]
Thank you both, after looking harder at the documentation I figured out as much (except for the icu-part, I don't think that's mentioned anywhere).
Unfortunately I had to give up building under Debian 7.0 (wheezy/stable) -- even after trying with both open jdk7, oracle jdk 7 and 8, standard llvm as well as llvm 3.5 and a newer cmake (in each case the jni/llvm-bindings doesn't build, as maven fails the second test-case).
And the binary distribution is linked against a newer libc than I have.
I guess it'll be possible to get it to run in an Ubuntu VM/chroot -- but I haven't tried that yet.
But you are right, this VM <=> memory safe languages, has done more harm than good, making a whole generation think you require a VM for memory safe compilers.
Thanks for pointing this out. I have now changed this to just "No interpreter involved". Except for not interpreting or JITing bytecode it's indeed very much a VM. E.g. it presents the same memory model and threading model to the running app as a desktop JVM would.
Can anyone compare this to Xamarin in terms of features/stability/workflow ? Xamarin is .NET/C# which is arguably nicer than Java but its also not too cheap if you just want to play around with stuff.
are there any other JavaScript to native compiler projects in the works? last time I heard there was llvm.js or something like that was doing the same thing as hyperloop.
He is using LibGDX and pretty much everything in most games developed with LibGDX run on all platforms (iOS, Android, Desktop Java). Most LibGDX games will work in a web browser too (converts to GWT + WebGL). A couple native extensions like some of the freetype stuff won't work in the web environment.
You can write the game on Windows if you want but to compile and test the iOS build you need a Mac with Xcode.
Almost all your game development is done is a project that is shared by all the platforms. During development you typically test the Java desktop version so you don't have to deal with deploying to devices or slow emulators.
Honestly the biggest pain is when you start doing ads or game center type stuff that is platform specific but there are ways to work around that.
You may be able to get it to work on other systems if you copy / port some of the necessary Apple bits. You'd have to copy the iOS SDKs from Xcode and get ld64 [0] / codesign [1] (both open source) to build on non-Mac machines. Perhaps some resource file prep tools as well. Then you could use libimobiledevice [2] and friends to push apps to the phone and debug them.
Theos [0] has been used with Linux before but I have never personally done so. I don't think anybody has yet ported ld64/codesign to run natively on Linux but it has been possible for some time to run the Mac CLI dev tools under Linux using runtime shims like maloader [1] or its descendant Darling [2].
maloader and Darling won't, they require Linux. LLVM works fine on Windows. I'm guessing the RoboVM front-end is also fairly portable. The effort to port ld64/codesign to Windows would probably be similar to the effort to port them to Linux.
For now you'll need Xcode to use RoboVM which implies Mac OS X running on Mac hardware or in a VM (it can be done although Apple doesn't allow it unless you run the VM on Mac hardware).
Just in case anyone is wondering, it is possible to compile Java to native code without a VM. I had to write a Java to MIPS compiler in uni, once in C++ and again in Java. Painful and hard without the luxury of LLVM but doable.
Did anyone have any experience with this? How mature/stable the project is? Can you expect to successfully port a 10KLoC Objective-C application to it?
Libgdx works with RoboVM now and the results are very nice. For non-game projects I'm curious as well. I'm sticking with Xamarin but I hope there will be more alternatives in non-Objective-C languages.
It says that it takes Java byte code and translates it to native ARM or x86 code. Since Closure is a JVM language, then yes, it would be possible to do so.
I'm worried Scala would get implemented first, though. :)
They prohibit on-device dynamic native code generation (ie. no JIT and no interpreters that attempt to mark memory as executable).
They also (generally) prohibit interpreters that download code from the network and execute it.
If you're doing a workflow like: non-ObjC language -> llvm -> native code, Apple has no problem with that generally (currently).
They just want to make sure that the executable code that ships in your iOS app is all they have to worry about, that it can't generate access to system libraries/routines that were not present when submitted to them.
This is why things like Pythonista and LuaBox are in the store currently, in addition to many apps written in other languages with other IDEs (Xamarin, etc.)
No, a lot of games are C# (Unity) or Lua (Corona).
The thing they are understandably hissy about is downloading new scripts off the net and executing those, and they want to be sure that when they test something it's 100% representative of what the consumer experiences. (This gets really damn fuzzy when people want to do A-B testing in iOS apps). Not sure of the state of the fine print these days, but it's like many of these things where if you understand why they do it (not necessarily agree with it) it's not too hard to work within that framework. As a consequence if you even look like you might be executing arbitrary code they might reject you.
Print the CLA, sign it and scan it (or use a camera to photograph it) and e-mail it to hello(at)robovm.com. Include your GitHub user name in the e-mail.
A bit wacky indeed. For what it's worth when dealing with this stuff I use Apple's Preview App's signature feature. It's pretty neat. You take a photo of your signature with your webcam and place/resize it as necessary. I create a new signature each time (paranoia) but if you have to do this a lot you can have Preview save it for later.
It's amazing to me that I can write my game completely in Java and get a performant AOT compiled version that runs on iOS.
RoboVM really is amazing for indie game devs, and it's open source. I've already donated around $300 to the project.
I've also done tests to see if other JVM languages work with RoboVM. So far, I have been able to get games written in Kotlin running. Can you imagine writing a game in a nice modern JVM language like Kotlin or Scala, and then being able to publish it to PC, Android , HTML5 and iOS? That's what is possible now, and all with open source.
Obviously, for those who develop non-game apps, native UI concerns mean you can't just publish the same thing to both Android and iOS, but for games that isn't an issue.