The relatively mature iOS support was one main reasons I chose to develop my game using libGDX (which relies on RoboVM). Luckily I've not started my iOS build yet (and am currently Android-only) but this has wrecked my plan going forward.
The BadLogic (libGDX) solution is to use the Intel Multi-OS Engine [1] but this too is a closed solution. I'm now concerned that I might spend months getting my game working in Multi-OS, marketing on iOS, building a user-base then find Intel has abandoned the project (as RoboVM have).
This has just highlighted how much risk is involved in fringe runtime environments (Java on iOS, for example), especially those relying on closed solutions.
https://www.codenameone.com/ is the only answer here. It's been around the longest (longer than RoboVM) is mature and run by ex-Sun/Oracle guys so no complexities over the licensing issues with Oracle.
It's open source and has always been, supports all IDE's etc.
> The Codename One SDK (Software Developer Kit) contains IDE plugins, our visual design tool, simulators for phones/tablets, our documentation/API and implementations for multiple platforms. Included in the SDK are simulators and build environment for iOS (java for iPhone/java for iPad), Android, Blackberry (RIM) and others (Windows Phone 7 Coming SOON!).
We've seen this story before. It's as old as cross-platform software development tools.
A platform vendor buys and kills closed source code that makes it faster and easier to make applications across platforms including those the new owner does not control, so the closed source product is killed and all the developers who used it now have to re-write all the their apps costing them significant resources and money.
Can anyone really wonder why developers do not like to buy closed code that acts as glue between platforms and their applications?
The only time it's smart to do is if it lets you reach the market faster than others, and then only if that buys you time to get off the cross-platform tool before it lags and degrades in the face of platform updates the tool vendor does not control or dies.
Rather surprised LibGDX didn't do this sooner. One of the niceties of LibGDX was that it was 102% free for all platforms. But then RoboVM closed source and suddenly making an iOS game stopped being free.
(although LibGDX was able to finagle a free license for small developers).
And I wish I could say I'm surprised that Oracle's not jumping in to buy this tech, as it seems like it would be a terrific addition to the Java toolset. But adding innovation to Java is, to say the least, not Oracle's strong suit.
I spent about 3 minutes trying to figure out what RoboVM and BugVM are. The RoboVM website has removed all explanations of the product and just says it's winding down, their Github page links to their website, BugVM links to RoboVM and has no information on their website, BugVM's Github links to their website.
Do they not WANT anyone to know what these things are?
I'm not entirely sure how many people are actively contributing to BugVM. Perhaps it's gone a little under-loved in the last six months since forking. That might explain the lack of solid marketing and documentation. I imagine there's a chance that might change now.
RoboVM is a Java VM on iOS. It's used by some third party libraries such as libGDX - a cross platform Java game development framework which targets Android, iOS (via RoboVM) and others.
BugVM is a fork of RoboVM. In October 2015, RoboVM (a formerly open source project) announced they were making their project closed source proprietary, and as a result someone forked under BugVM.
Why did they stay silent for this long? They could have at least given a hint that this was in talks. People make important decisions on what to use. The only answer we got on what the acquisition meant for RoboVM was 'Stay tuned'. Same thing was when they decided to remove it from open source. They just stayed silent for 3 months and then BAM... Kinda looks irresponsible
It would be a travesty if RoboVM, a formerly open source project, did not re-open source their code before shutting down. I can't imagine there is any value to their code sitting in some closed Microsoft repository until the end of time.
Absolutely. I'd love to see the "new Microsoft" step up and say "Under our stewardship, one of our acquisitions has abandoned a vital and heavily relied upon product. We're going to give it back to the community to ensure that it'll live on past Xamarin's ownership".
I doubt this is just RoboVM unilaterally making this decision. They're offering a full refund to all license holders - some decision maker somewhere is paying for this (be in Xamarin or Microsoft).
> I doubt this is just RoboVM unilaterally making this decision.
While they likely didn't make the decision to close up shop, RoboVM did unilaterally make the decision to close source the code 7 months ago. Additionally, they did make the decision to sell to Xamarin. They indicated that very few people contributed to the open source project, and with it being open source it was difficult, if not impossible, for them to make money as a business.
I understand that people want to make Microsoft the bad guy, but in this case RoboVM sealed this fate themselves a while back, and from their point of view they didn't really have a choice if they wanted to make any money.
As another comment pointed out, the old open source repository is still available on github as of now.
Yes, the fact being that there are a few commercial native AOT compilers for Java and all FOSS alternatives for AOT compilation fail to get any community support.
I think this is because the gulf between the user and one with the ability to do the hacking is so far apart. Those with a pressing need to get Java compiled into a native exe also has ability to pay for an off the shelf solution.
I agree, a little healthy competition is a good thing. Xamarin being the only player (afaik) in town is an odd thing, maybe a result of Xamarin open sourcing a decision they couldn't afford to compete against possibly?
Edit: Forgot Xamarin technically owns RoboVM, maybe Microsoft wants to avoid any legal issues with Oracle.
Xamarin is not the only game in town, if one is doing game apps.
Assuming one is ok with a little dosis of JNI pain on Android, given that C++ is a first class language in iOS (via Objective-C++) and Windows (C++/CX and or via WRL).
That's JNI pain + C++ pain (this is coming from a guy who just did a C++ project full time for >year - C# and C++ aren't in the same league when it comes to productivity) - and C++ has no access to android java api - xamarin is just a whole different kind of solution to this - you can literally have all code in one language across all platforms - C++ can't do this without a custom UI like QT
C++ is a straight-up awesome language, on that you and I fully agree. And I have been there with regards to the teeth-pulling pain of Xamarin projects when you want to do something nontrivial. So it kind of pains me to disagree with you, but I do. C++ is awesome. I love it. But I also recognize that I barely trust myself to write it, after ten years or so of exposure and a few years of steady writing it. I don't trust off-the-rack mobile developers to write it safely and correctly. To that end, something like Xamarin or the RIP'd RoboVM provide a significant benefit: by offering the kind of guardrails that C++ can't, they do significantly improve the ability of people who don't eat and breathe this stuff to get something out the door. (Whether or not that's a desirable trait...reasonable people can differ. But it is in demand.)
Sure, Xamarin has done a lot of that work--but that's also kind of the point in the first place.
Don't get me wrong, I would like that more type safe languages were available for native cross platform development and I am getting myself deeper in Xamarin.
However one thing that my likeness for Turbo Pascal and Oberon teached me was that making applications with languages which aren't first class on the platform SDKs opens the door to situations like these.
So I rather be more pragmatic, even if it goes a bit against to my preferences and keep my code free of company politics, which may lead to porting the application to other languages.
I can't blame Microsoft much, when they've open-sourced Xamarin and are doing good things with .NET Core, plus they aren't the ones to blame.
The writing was on the wall ever since RoboVM was closed sourced, right before Xamarin bought them. I was one of the pessimists here. Basically any project that goes from open-source to close source is as good as dead, unless forked. And whenever you see such projects, you should run. Because the most interesting aspect of any open source project is its open source nature. And a bait and switch doesn't work so well.
That said, RoboVM was open-source before October 2015 and the most interesting aspect of open source is the ability to fork the project. A fork of RoboVM can still happen, the code from before October 2015 should still be there somewhere, I just hope the license is permissive enough. And if a fork doesn't happen, it only means that the project doesn't have enough interest and so it probably should wither away.
You're gonna have to explain how they're not the ones to blame when they're the ones that own the project. As in, they're literally the ones who make the decision to do this.
If RoboVM isn't revenue-positive, what's Microsoft to do? Xamarin bought RoboVM, presumably hoping that there were synergies there. Then Microsoft bought Xamarin, and Xamarin's business-model changed, and those synergies may not be there anymore. At that point, you can make a case for RoboVM to operate independently if RoboVM pays for itself. But the decision to take RoboVM closed-source and increase what they charge indicates that maybe RoboVM couldn't and can't self-sustain.
While not really a replacement, there's always j2objc. On the downside, it doesn't provide APIs, it just translates Java to Objective-C source. On the upside, it's straightforward, fast, and can be integrated with Objective-C/Swift code easily via a GWT-like JSNI mechanism. Some people have wired it up to libGDX and PlayN to provide a layer for writing games.
I will say that as soon as Xamarin bought RoboVM my heart sank. I had a feeling Microsoft was going to buy Xamarin, it made perfect sense to do so, the only other choice would have been to buy Unity (which they could still do) And of course, if MS bought Xamarin, there would be no point in maintaining both a C# and Java product.
Killing a well functioning piece of technology instead of open sourcing it is not just downsizing. MS is applying their "Embrace, extend, and exterminate" strategy to cross platform mobile development.
That's ridiculous, what % of software companies open source the software they kill? 0.1% maybe? Did Google open source Reader or Dodgeball when it killed those?
Criticize them all you want but "Feels like the MS of the 90's is back." isn't criticism it's FUD meant to invoke fears of how closed down software was back then.
It happens all the time, companies unload unwanted or unaligned assets to focus on their roadmap and strategies. RoboVM should pick a page from Xamarin and buy out IP and support from mothership.
Exactly. I think we should wait until they shut down Xamarin before we get out the pitchforks. The simplest explanation is that they want to focus all of their cross-platform development resources on the core product that they acquired, and it sounds like Microsoft is very invested in Xamarin's future.
On the other hand, after what happened the last time they used Java (back in the "embrace, extend, extinguish" days), I think they wouldn't touch it with a 10-foot pole.
Though I do hope that they'll make the sources available. It's not like just a code dump will suddenly transform into viable competition for Xamarin.
I think it's a mixture of: what Microsoft went through with J++ (which is totally not what inspired C# cough) where they got sued for basically turning Java into Windows only, and what Google has gone through, which still makes me wonder with all their talents why they either don't invest in an entirely new language or find an alternative to Java that would be friendlier to be on their platform. I understand legacy apps and what not, but Oracle doesn't even want to help them out which could of been for their own benefit. Anyway, yeah... corporation owned programming languages...
I've seen a couple of mentions of Oracle in this thread, implying Oracle would sue over copying of APIs I imagine. Is there any basis to the FUD here? What APIs did robovm copy?
I agree. The timing of events is no coincidence. This is nothing more than trying to eliminate a competing technology from the cross platform development choices. I hope Google is serious about making Swift a first class language on Android. That would pretty much derail any ambitions MS might have had to make C# the language from cross platform mobile development.
This is incredibly sad, libGDX + RoboVM was the most painless way I ever found of making a cross-platform game. Throw in some Kotlin for cleaner code and you had the most serious code-only contender for making absolutely cross-platform games on a single codebase that's ever been... and even quite a lot of simple business apps too. And to think most of the tools were Open Source for a brief moment. If people can rally somehow and bring back bugVM to the state RoboVM was before its death (a long and harsh 7 months of work lost), we could get back to that point and even further. Or MS could just open source RoboVM back, is that even possible?
I've built and deployed a game using libGDX + RoboVM once, and it was super easy to get my app running on both Android and iOS. I was more intrigued by the bureaucracy around compiling and distributing an iOS app than by RoboVM itself.
That said, I was just this week thinking about my next game, a Tower Defense, and now RoboVM dies... :/
I deployed a turn-based board game to Android, iOS, and HTML5 -- libGDX was fine, and RoboVM was pretty rock-solid. The worst part was the surgery required to the Gradle files to get everything working, and hacking up the Google Web Toolkit (another nearly-orphaned project): http://blog.puzzlingplans.com/post/100992521086/building-a-c...
I also archived a desktop .jar file, because I doubt I'll be able to rebuild this thing in five years.
I wish someone would do a site with a summary / wizzard of what the mature options are for deploying several types of software applications and what platforms they can target.
Something where you select the type of app (DB Driven Web App, Static Web Site, CMS BAsed Website, Game, Desktop App, Enterprise Server Application)
And it starts giving you a decision tree showing the options with pros/cons.
Sorry for the vagueness, but I cant put it into better words at the momment =)
You ask for something very complex and subjective. For instance, I have a set of libraries written in Python, and I use them in a web app, on a desktop app and in Android (using python 3.5 provided by crystaxNDK - https://www.crystax.net/).
The python libraries are my "backend" where I have most of the interesting code, and only the frontends change: html/css/js over flask for web, PyQt for desktop and Java/JNI for Android.
The only reason Xamarin bought RoboVM was to get a better deal from MS, it was used to flag to Oracle we are into Java and probably cause to MS to sign the deal before Oracle gets into the Picture.
It is just a shame the community is the biggest loser in this scenario. The RoboVM guys should have probably see this coming but who can blame them for earning some dollars on this deal.
https://www.myappconverter.com/ is a solution converting your native Objective-C apps to Android or Swift. The generated code is native which makes developers free to maintain their generated code.
Conversion is free and is done instantly after uploading iOS project source code
What is the future of libGDX on iOS?
Tomski has already written a new libGDX backend for Multi-OS engine. Here’s the roadmap for libGDX:
Clean-up the Multi-OS backend, integrate it with the libGDX Setup UI, and update the documentation. We are at a 95% status with this, i hope to have the code drop sometime this weekend
Release a new libGDX version next week, that will make Multi-OS engine the default iOS backend for newly created libGDX projects
Begin creating bindings for popular 3rd party iOS libraries. This is where we hope the community can jump in
Keep the RoboVM backend around until the licenses expire (April 17 2017). We’ll try our best to fix any bugs in the backend, however we won’t be able to fix bugs in RoboVM itself
The roadmap of your existing apps should look something like this:
Keep publishing updates using RoboVM 1.14.0 and the corresponding backend
Immediately start adding a Multi-OS engine based version of your app for iOS
Test it and report bugs on our issue tracker
Switch over to Multi-OS Engine as soon as possible
In Closing
There will be some rough edges with the new Multi-OS Engine backend. We are in contact with Intel, who have been very reactive in fixing issues we identified while creating the new iOS backend. Please help test the new backend and report issues, so Intel is able to fix problems on their end.
Multi-OS Engine is free to use, but not OSS. Before you guys start screaming for my head again, I’d like you to read the above analysis carefully one more time. None of the OSS options are even close to production ready. I will however happily merge any and all backend based on those OSS options.
I’d be grateful if everyone funnels their emotional energy created by this announcement into helping out with the new backend, e.g. testing, bindings, reporting bugs etc. I believe this is a much better use of everyone’s time. If you feel the need to vent, I understand. But please don’t expect me to vent with you. The winding down of RoboVM is already emotionally taxing enough for me. My goal is it to keep things running smoothly for everyone, I have no intention to waste time on a screaming contest.
Intel Multi-OS Engine:
Formerly known as Migeran, Multi-OS Engine is a pretty nice piece of tech that let’s you run Java bytecode on iOS. Under the hood, Multi-OS Engine is powered by ART, Android’s virtual machine, which has an AOT compilation mode Multi-OS Engine exploits.
Tooling: Integrates with Android Studio, IntelliJ IDEA and Gradle. Used to have support for Eclipse, but it seems that’s no longer available. Also let’s you build and deploy from a Windows machine (using a Mac as the build slave).
Bindings: Provides a custom bridge called Nat/J, which is quite similar to RoboVM’s Bro, albeit quite a bit more cumbersome. It appears that all native APIs are accessible from Java via Nat/J, and 3rd party libraries can be bound (semi-)automatically.
Binary size: OK but not great. Bigger than comparable RoboVM binaries.
Performance: Good, faster than RoboVM in some workloads, slower in others.
Bitcode: Currently unsupported, but apparently Intel is working on it.
Multi-OS Engine comes closest to RoboVM along all these axes.
The BadLogic (libGDX) solution is to use the Intel Multi-OS Engine [1] but this too is a closed solution. I'm now concerned that I might spend months getting my game working in Multi-OS, marketing on iOS, building a user-base then find Intel has abandoned the project (as RoboVM have).
This has just highlighted how much risk is involved in fringe runtime environments (Java on iOS, for example), especially those relying on closed solutions.
[1] https://software.intel.com/en-us/multi-os-engine