RoboVM: Native iOS apps in Java

> 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.

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 ?

What are you using for a game framework? libgdx?

what tools did you use to create your game assets?

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.)

Hm, seems documentation for for targeting Linux as a build target is missing? Or am I just looking in the wrong place?

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.

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?

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

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/

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.

[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/

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).

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.

Yes. This link was already posted in the thread but here it is again.

https://github.com/oakes/lein-fruit

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. :)

Any JVM language.

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.)

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 app store agreement did at one point. It hasn't for a while now.

No they do not

It used to. They changed it, fortunately.

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.