
RoboVM is winding down - codeulike
https://robovm.com/robovm-winding-down/
======
davb
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.

[1] [https://software.intel.com/en-us/multi-os-
engine](https://software.intel.com/en-us/multi-os-engine)

~~~
invalidname
[https://www.codenameone.com/](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.

~~~
cwyers
> 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!).

Uh, huh.

~~~
invalidname
Damn we need to update the about page. Thanks for the headsup.

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

~~~
sitkack
To the now dead trollingengineer, IntelliJ is open source and Apache Licensed.

[https://github.com/JetBrains/intellij-
community](https://github.com/JetBrains/intellij-community)

------
codeulike
LibGDX has a plan however - move to Intel Multi-OS Engine

[http://www.badlogicgames.com/wordpress/?p=3925](http://www.badlogicgames.com/wordpress/?p=3925)

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

~~~
aganders3
LibGDX is made mostly by Mario Zechner, who also happens to work on/for
RoboVM.

~~~
badlogic
libGDX is definitely not mostly made by me. Truck factor and all :)
[https://github.com/libgdx/libgdx/graphs/contributors](https://github.com/libgdx/libgdx/graphs/contributors)

~~~
eropple
Man, having a 2:1 deleted:added ratio is pretty amazing, though.

Good luck with whatever you end up doing next though, seriously, whether it's
libgdx-related or not. Y'all are good people, you do good stuff.

------
davb
I've just been directed to [http://bugvm.com](http://bugvm.com) \- an open
source fork of RoboVM from before they closed their source in October 2015.

~~~
tazjin
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?

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

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

~~~
ludamad
Sadly once a project is closing there's not much incentive to support
customers

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

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

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

~~~
sitkack
And libgdx single handily gave them a market. RoboVM would have withered long
ago without it.

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

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

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

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

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

~~~
st3v3r
None of that makes it not Microsoft's fault, and therefore makes them the ones
to blame when it happens.

~~~
emmelaich
But blame is the wrong word if anyone else would do the same given the same
circumstances.

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

------
Yrlec
So Xamarin buys RoboVM, then a couple of months later MS buys Xamarin and
kills RoboVM. Feels like the MS of the 90's is back.

~~~
Touche
Sounds like any company that buys another company for X and doesn't need/want
Y or Z.

Downsizing isn't a "Microsoft in the 90s" thing.

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

~~~
Touche
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?

~~~
Yrlec
Google was heavily criticized for killing Reader. Why should we not criticize
Microsoft?

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

~~~
st3v3r
It's not FUD if it's true.

------
phreack
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?

------
lohengramm
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... :/

Will try the libGDX response as soon as possible.

~~~
sehugg
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...](http://blog.puzzlingplans.com/post/100992521086/building-a-cross-
platform-game-with-libgdx-part)

I also archived a desktop .jar file, because I doubt I'll be able to rebuild
this thing in five years.

EDIT: Playable link (requires WebGL)
[http://feldspargame.com/](http://feldspargame.com/)

------
JayOtter
Disappointing. I've been very glad to see how quickly the LibGDX team has
responded to this, though.

~~~
Cyph0n
Absolutely. I'm now certain what my first choice when making a game will be.

~~~
pjmlp
Cocos-2D, SDL, SFML,...

~~~
democracy
sdl - which is a great library btw - is a much lower level than libgdx
framework...

~~~
pjmlp
There are other options.

------
Cyph0n
Terrible news. RoboVM was a truly interesting piece of tech.

~~~
pjmlp
That the majority didn't want to support with money, hence why they accepted
Xamarin's offer back then.

------
glaberficken
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 =)

Does anyone know such a thing?

~~~
jventura
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/](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.

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

------
democracy
heh, i kind of felt that when they closed-source it, reminded me of ext-js
thingie

------
systems
what was robovm

~~~
Cyph0n
Create both Android and iOS apps using Java. It's similar to Xamarin, which
uses C# instead.

~~~
iso-8859-1
Technically, it is just a Java compiler that emits native code. I used to to
compile plain Java code to native console Linux binaries.
[https://github.com/ysangkok/console-transit-trip-
planner](https://github.com/ysangkok/console-transit-trip-planner)

------
Ernestovitch
[https://www.myappconverter.com/](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

------
bitmapbrother
Here's an update from Mario of libGDX:

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.

