Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RoboVM: Native iOS apps in Java

robovm.org

Post reply on HN
Print view View original

31–40 of 64 posts

Re: RoboVM: Native iOS apps in Java

#31

Post by cookerware »

jevinskie wrote: post #27
hippiehippo wrote: post #10

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/ld…

is there a tutorial on this? The biggest hurdle to making iOS app is that you need a physical hardware from them.

Re: RoboVM: Native iOS apps in Java

#32

Post by jevinskie »

cookerware wrote: post #31
jevinskie wrote: post #27

Earlier quoted context omitted.

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/ld…

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/

Re: RoboVM: Native iOS apps in Java

#34

Post by matt_heimer »

cookerware wrote: post #28

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 X…

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.

Re: RoboVM: Native iOS apps in Java

#35

Post by philbarr »

bsaul wrote: post #22
talloaktrees wrote: post #5

I have just finished porting my Android game Superior Tactics ( https://play.google.com/store/apps/details?id=org.jrenner.su... ) to iOS using RoboVM. 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 i…

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/

Re: RoboVM: Native iOS apps in Java

#36

Post by revscat »

gdubs wrote: post #33

Java experts: would this make Clojure a potentially valid development option now for iOS?

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

Re: RoboVM: Native iOS apps in Java

#39

Post by cookerware »

jevinskie wrote: post #32
cookerware wrote: post #31

Earlier quoted context omitted.

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/

is it possible to run this on windows 7?

Re: RoboVM: Native iOS apps in Java

#40

Post by ntherning »

SifJar wrote: post #3

It says right on the homepage "no virtual machine involved". So why is "VM" in the name? Surely that's just misleading?

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.
Post reply on HN