Member Avatar for terrie4

Does anyone know about robovm??? It is a platform to make ios apps in java. I need it for a new project I´m working on in a nearshore outsourcing company.

Edited by happygeek because: promotional link removed
  • 4 Contributors
  • 9 Replies
  • 387 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by rproffitt

Dani AI

Generated

A short, current summary and practical next steps for (and anyone who finds this thread later).

The short history: was right to warn about the original RoboVM — the project was acquired and then shut down; you should not base a new product on an unmaintained commercial offering. That said, community forks have kept the technology alive (look for the MobiVM / robovm fork on GitHub), but those forks are community-maintained and carry the usual maintenance and compatibility risk for production work. (theregister.com)

If the goal is “write iOS apps in Java” there are three realistic approaches today: (1) use a Java-to-native tool that is actively maintained — for example Codename One (Java -> native builds) or Gluon Substrate (Java/JavaFX + GraalVM native-image) — (2) move shared logic to Kotlin Multiplatform and write the iOS UI natively, or (3) accept Swift/Xcode for the app and share only backend or service layers. Each has tradeoffs (native look-and-feel, platform APIs, Bluetooth and low-level device access), so pick based on how much Java you must keep. (codenameone.com)

A pragmatic note for and others doing device setup: iOS is not friendly to classic Bluetooth SPP/serial profiles — Apple prefers BLE or MFi-backed accessories — so if your product depends on a serial-over-classic-Bluetooth workflow, Android is far easier. If iOS support is required, plan device/firmware changes (BLE or an MFi path) and expect native-code work and lots of hands-on testing. (stackoverflow.com)

Recommendation: don’t start a large new iOS project on an “abandoned” RoboVM build. Prototype with an actively maintained solution (Gluon or Codename One) or move shared logic into Kotlin Multiplatform and write the iOS UI in Swift for long-term support. Early hardware compatibility testing with real devices and current Xcode is essential — that will reveal whether Java-based tooling can meet your project’s device/Bluetooth constraints. (github.com)

References:

Recommended Answers

All 9 Replies

Member Avatar for JamesCherrill

RoboVM was a nice open source project that ended up being owned, then killed, by Microsoft in 2016.
In my opinion you would be mad to start a new development on a dead platform.

Moving from Java to Swift isn't that hard, and you'll love the way its designers learned from Java's problems and did it better. It also guarantees the earliest possible and fullest possible support for new IOS versions and devices. The XCode IDE is pretty good too.

commented: Since Apple issues its own issue of Java, there's this and more. Get the Xcode IDE and go native. +15
Member Avatar for JamesCherrill

rproffitt: Apple have Java for MacOS, although its a very old version and not well supported (current Javas for MacOS from Oracle/Apache are fully supported products), but neither Apple nor Oracle nor Apache have a Java for IOS.
Apple's rules for IOS apps appear to prohibit installing non-Apple runtimes...

App Store Review Guidelines ... 2.5.2 Apps ... may not ... execute code
https://developer.apple.com/app-store/review/guidelines/#software-requirements

Swift/XCode is really the only way to go.

Edited by JamesCherrill
Member Avatar for rproffitt

. I've read that before and for reasons our main products don't have any iOS or Apple version. We use the old serial port Bluetooth profile and Apple botched that long ago so we can't issue an Apple version. We also have some code that is data driven so it's almost like a runtime. So maybe a mixed blessing we don't have to put up with Apple on this as it's an industrial control setup app and no one would understand if Apple blocked our app for any reason.

Edited by rproffitt because: Spelling.
Member Avatar for JamesCherrill

We also have some code that is data driven so it's almost like a runtime.

There's an inevitable grey area between a data-driven app and code-executing app. Data-driven is OK, butf your data is so complex that it could look like a simple programming language then who knows how Apple may approve or reject, or change their minds in the future? You can't build a business under that kind of uncertainty.

(And who would chose iPad/iPhone, the ultimate consumer product, for an industrial control application anyway?)

Member Avatar for rproffitt

Who would? Some home automation (pre-smart home?) did and here we are years later with iPads that you can't replace. We've been fine with a succession from beginning days with PalmOS then WinCE and now Android. It's not industrial control on the devices but setup. The old controllers have some 3 buttons and a two digit display which if you were a masochist you could use but with close to one hundred options we all use the Android setup tools.

It's a real shame that Apple did something to the Bluetooth system. Maybe their adapter is cheaper today but with 20 buck smart phones that can run the setup apps, there's little chance we're going to ever revisit the Apple world.

Member Avatar for Reverend Jim

It's a real shame that Apple did something to the Bluetooth system.

It's not like Bluetooth was awesome to begin with. I've had several laptops and peripherals with Bluetooth for years and never had one that didn't give me daily grief. Spotty connections even at close range, randomly dropped connections, devices not found, and paired but refusal to connect.

Edited by Reverend Jim
Member Avatar for rproffitt

Thanks for writing about Bluetooth dropouts. This is actually where our little company got its foot in the door on such work. The code we wrote at the application level works hard to re-establish the link in difficult connections.

The data is packetized, CRC'd and there's a reply expected so we know it made it there and back. It's not as speedy but the app is used by thousands in the companies that use it. There was another competitor but they would just fail on a lost link and you can imagine bugging the user on every packet drop what happens.

This is why when members get into packets, UDP and such I might perk up. We don't use any Internet Protocol but like UDP we do deal with the loss and have methods to get the data across and rebuild the link WITHOUT bugging the users. In the engineering mode of the app, we show the retry, link rebuild rates because we want to see the statistics.

But back to Apple. They added some then proprietary communications security chip and didn't reveal much about it. So that was the end of that phone for our use.

Member Avatar for Reverend Jim

At the risk of derailing this thread... Bluetooth did it again. Now that I have an app for viewing/editing text files on my Android phone, I tried to send a file.md file via Bluetooth. Apparently, even though it is a text file (and I tried setting the Perceived Type to text, Bluetooth still says it doesn't know how to handle it.

As far as I am concerned Bluetooth is complete crap.

Member Avatar for rproffitt

Derailment complete: or ES File Explorer used to deal with this very well. But when I want move files about I still lean on Dropbox.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.