RoboVM: Native iOS apps in Java(robovm.org)
robovm.org
RoboVM: Native iOS apps in Java
http://www.robovm.org/?
14 comments
> 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.
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.
Sorry, that was actually I a typo on my part, I meant to write "can't"
> 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.
http://coronalabs.com/products/corona-sdk/
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.
http://coronalabs.com/products/corona-sdk/
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.
[0] https://github.com/BlueRiverInteractive/robovm-ios-bindings
[1] http://libgdx.badlogicgames.com/
[2] https://play.google.com/store/apps/details?id=com.simplyappe...
[3] https://play.google.com/store/apps/details?id=com.simplyappe...
[4] https://developer.vuforia.com/
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.
[0] https://github.com/BlueRiverInteractive/robovm-ios-bindings
[1] http://libgdx.badlogicgames.com/
[2] https://play.google.com/store/apps/details?id=com.simplyappe...
[3] https://play.google.com/store/apps/details?id=com.simplyappe...
[4] https://developer.vuforia.com/
What are you using for a game framework? libgdx?
what tools did you use to create your game assets?
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?
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.)
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.)
Niklas (the RoboVM lead dev) talked briefly about how the GC is used on the list here: https://groups.google.com/d/msg/robovm/etAxWMYvRTU/huXKmPA-J...
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.
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.
/Niklas
[0] http://www.mono-project.com/Working_With_SGen
/Niklas
[0] http://www.mono-project.com/Working_With_SGen
Ah, I stand corrected.
(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 :(
EDIT: http://hboehm.info/gc/ appears to be the living mirror of http://www.hpl.hp.com/personal/Hans_Boehm/gc/ and contains useful documentation and FAQs.
(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 :(
EDIT: http://hboehm.info/gc/ appears to be the living mirror of http://www.hpl.hp.com/personal/Hans_Boehm/gc/ and contains useful documentation and FAQs.
Hm, seems documentation for for targeting Linux as a build target is missing? Or am I just looking in the wrong place?
Perhaps the docs don't highlight it enough, but I think you should find what you're looking for under http://www.robovm.com/docs#using-the-command-line-tool
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.
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.
Just to add some more info:
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:
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:
sudo apt-get install build-essential g++-multilib openjdk-7-jdk
sudo mkdir -p /usr/share/icu
sudo sh -c 'curl "http://download.robovm.org/icudt48l.dat" > /usr/share/icu/icudt48l.dat'
[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.
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.
I was wondering the same thing.
lein-fruit facilitates usage of Clojure with RoboVM:
https://github.com/oakes/lein-fruit
https://github.com/oakes/lein-fruit
It says right on the homepage "no virtual machine involved". So why is "VM" in the name? Surely that's just misleading?
Maybe because they use LLVM for code generation?
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.
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.
Maybe VM stands for Very Magical?
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.
Also, I want to understand how its creator monetarize this? Or it is just a no-profit project?
Anyway I'm happy to see competion against xamarin. Now I only want also a javascript to native (and not just webview-running) for any platform
Anyway I'm happy to see competion against xamarin. Now I only want also a javascript to native (and not just webview-running) for any platform
If you browse the RoboVM website, you'll find that you can (or will soon be able to) buy a support subscription.
As for a JavaScript to native compiler, check out Appcelerator Hyperloop [1]. It's currently experimental.
[1] https://github.com/appcelerator/hyperloop
As for a JavaScript to native compiler, check out Appcelerator Hyperloop [1]. It's currently experimental.
[1] https://github.com/appcelerator/hyperloop
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.
It's unsure what is going to happen after the MS takeover though. I keep hoping for MS being nice for a bit :) What would we be without hope...
> Xamarin is ... not too cheap if you just want to play around with stuff.
If you just want to play around then take note that the starter plans are free [1].
[1] https://store.xamarin.com/
If you just want to play around then take note that the starter plans are free [1].
[1] https://store.xamarin.com/
holy crap!
I've avoided iOS because Objective-C scared me and I stuck to Android. I have some pending questions before I use this however.
1) How much code share can there be between Android and iOS? Is it just limited to business logic like Xamarin?
2) Can you use an Android game engine, create the game in Android and build for iOS?
3) In order to create and run iOS simulator, do you need to be on the mac and have Xcode? Any way to do it on a non-Mac machine?
4) Can you use RoboVM to create Android and iOS at the same time?
Amazing stuff!
I've avoided iOS because Objective-C scared me and I stuck to Android. I have some pending questions before I use this however.
1) How much code share can there be between Android and iOS? Is it just limited to business logic like Xamarin?
2) Can you use an Android game engine, create the game in Android and build for iOS?
3) In order to create and run iOS simulator, do you need to be on the mac and have Xcode? Any way to do it on a non-Mac machine?
4) Can you use RoboVM to create Android and iOS at the same time?
Amazing stuff!
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 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.
Is a Mac needed in order to compile?
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.
[0]: http://www.opensource.apple.com/source/ld64/ld64-136/ (unfortunately the last source release is from Xcode 4.6, 2 releases behind current)
[1]: http://www.opensource.apple.com/source/security_systemkeycha...
[2]: http://www.libimobiledevice.org/
[0]: http://www.opensource.apple.com/source/ld64/ld64-136/ (unfortunately the last source release is from Xcode 4.6, 2 releases behind current)
[1]: http://www.opensource.apple.com/source/security_systemkeycha...
[2]: http://www.libimobiledevice.org/
is there a tutorial on this? The biggest hurdle to making iOS app is that you need a physical hardware from 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].
[0]: https://github.com/DHowett/theos
[1]: https://github.com/shinh/maloader
[2]: http://www.darlinghq.org/
[0]: https://github.com/DHowett/theos
[1]: https://github.com/shinh/maloader
[2]: http://www.darlinghq.org/
is it possible to run this on windows 7?
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.
Yes. It's stated in the "Get Started" section.
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.
FYI ActionScript works fine.
Java experts: would this make Clojure a potentially valid development option now for iOS?
Yes. This link was already posted in the thread but here it is again.
https://github.com/oakes/lein-fruit
https://github.com/oakes/lein-fruit
Any JVM language.
Has anyone used RubyMotion and RoboVM?
Doesn't Apple's ToS prohibit writing apps in any language other than Objective-C? Or using other than Apple's tools?
No.
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.)
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.)
Yep. These are the relevant lines from the policy:
2.7 Apps that download code in any way or form will be rejected 2.8 Apps that install or launch other executable code will be rejected
And I suppose this covers use of W^X / mprotect:
2.5 Apps that use non-public APIs will be rejected
2.7 Apps that download code in any way or form will be rejected 2.8 Apps that install or launch other executable code will be rejected
And I suppose this covers use of W^X / mprotect:
2.5 Apps that use non-public APIs will be rejected
mprotect() simply returns EPERM. The kernel enforces W^X; once a page has gone writable, it can never be executable, and vis versa.
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.
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.
The app store agreement did at one point. It hasn't for a while now.
No they do not
[deleted]
It used to. They changed it, fortunately.
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.
There goes the neighborhood.
Kidding.. anyone know how this compares to Titanium? E.g. performance, energy efficiency, debuggability, etc.? http://www.appcelerator.com/titanium/
Kidding.. anyone know how this compares to Titanium? E.g. performance, energy efficiency, debuggability, etc.? http://www.appcelerator.com/titanium/
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.