5 ms·
None of those forks support bitcode which is clearly where Apple is going moving forward. Since all of them are hobbyist projects they might disappear overnight
by invalidname 10y ago
None of those forks support bitcode which is clearly where Apple is going moving forward. Since all of them are hobbyist projects they might disappear overnight when things become difficult (e.g Apple requiring bitcode for submission). So they are fine if you already have a heavy investment in RoboVM but other than LibGDX not many people used it.
The problem is that LibGDX chose not to pick a "winner" and is fragmenting between all of those different forks/options guaranteeing that they will all have issues reaching critical mass.
If you are a Java developer there is one option that pre-dated RoboVM, has always enjoyed better traction and installs millions of apps every month and that's Codename One. It's taken a far more conservative approach to the VM so it is both future proof and much smaller: https://github.com/codenameone/CodenameOne/tree/master/vm https://github.com/codenameone/CodenameOne/tree/master/vm
Add to that a true write once run anywhere approach there is really no one else.
- chii 10y agoregarding bitcode, i haven't even heard of it before, but a quick google showed me: https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitcode-f35cd8fbfcc5#.ll9iorkaw https://medium.com/@FredericJacobs/why-i-m-not-enabling-bitc... I am sceptical of bitcode, and i would not want to buy into that scheme.
- invalidname 10y agoWe don't enable it by default either. It's not mature at this time and still suffers some issues. But just like anything Apple introduced and then required (e.g. v7s, 64bit etc.) this will probably become a requirement. E.g. they announced 64 bit and gave relatively little time to make it a requirement for all new projects. Apple officially supports: C/C++, Objective-C, Swift & JavaScript. If you skip a stage (like going directly to LLVM) they will not make your lives easier.
- pjmlp 10y agoThe other option would be to face reality that outside Android Java has lost all meaning regarding mobile OS portability and use C++ instead, which is a first class language in all mobile SDKs.
- invalidname 10y agoIf you are doing games then yes C/C++ can work. However, since Android widgets are written in Java then it's a second class citizen there as you need to go thru the slow JNI bridge for widget access there. Since we are talking about portability I guess most client developers abandoning Java go to JavaScript not C++.
- pjmlp 10y agoYou arw reducing it to Android, the only mobile platform where Java has a meaning. On iOS, WP, Tizen and anything else Java support is quite worse than having to deal with C++, specially since it is a first class language on those platforms.
- invalidname 10y agoFYI Codename One works on all of them natively. Notice I didn't refute or try to refute your claims. I just specifically mentioned that on the most or second most significant platform C++ is not a first class citizen.
- pjmlp 10y agoiOS has Objective-C++, WP has C++/CX, both provide a seamless interoperability with Objective-C/Swift and WinRT respectively and are fully supported by the platform owners. It is also the approach taken by Microsoft, Dropbox. My work experience is that relying on second class languages always leeds to support problems down the line. I had that with Turbo Pascal, Oberon and quite a few other languages.
- StevePerkins 10y ago> outside Android Java has lost all meaning regarding mobile OS portability Umm... I don't have hard numbers handy, but isn't the mobile OS market something like: 60% - Android 35% - iOS 5% - Everything else combined (if it's even 5%) Quite frankly, if I were going to do a professional mobile app today (a big "if", as the bubble seems to be bursting)... then I'd just bite the bullet. Use Java for the Android version, ObjC/Swift for the iOS version, forget anything else, and keep the actual business logic on the server side.