If Substract VM allowed for writing libraries in any of the supported languages (most importantly Java) and these libraries could be called into from iOS application code (written in Swift or Objective-C) then this would be a complete game changer for the "holy grail" of mobile development: Joint code bases for truly native mobile applications.
Rich client logic could then be written purely in Java, packaged as a library and be usable from thin layers of UI code on either platform. Currently this is not properly possible.
There are a few tools promising a solution in that area (e.g. Robo VM or Multi-OS-Engine), but they all come with quite a few strings attached and severely lack the technological soundness of Graal.
It'd be absolutely awesome if Graal would finally be the tool to properly bridge this so far insurmountable chasm between the two major mobile universes.
sirthias
All 28 comments
Hi @sirthias, iOS support is on our TODO list. AFAIK the kernel design on iOS is essentially the same as macOS, which we currently support. But first we need to implement AArch64 support. The Graal team is already working on an AArch64 back-end. Once that is implemented we need to extend the AArch64 support to SubstrateVM. Then we can support JVM languages that are currently supported on other platforms, i.e, Java, Scala, Kotlin, etc. As for other languages, i.e., JS, Python, etc., they are implemented using Truffle/Graal on top of SubstrateVM and interpreted/JITed at runtime. On iOS you cannot allocate executable memory so JITing is not possible. However you can still run Truffle languages in interpreter mode.
cstancu
on 23 Apr 2018
Thank you for this additional info, @cstancu!
So, JVM languages will be supported (eventually) via SubstrateVM's AOT compiler, but everything requiring Truffle/Graal can never be supported since JITting is disallowed on iOS.
While it'd be theoretically better to also have JS, Python, Ruby, etc. supported on iOS I'd say that the by far more important target is Java (and other JVM languages) since they are what people are already using on the Android side.
So to me the prospect of having SubstrateVM-powered Java/Scala/Kotlin/Closure-libraries run nicely on iOS is absolutely fantastic!
What would you personally say, how long the AArch64 support will take to arrive in SubstrateVM?
I know that estimates like this always have to be taken with several giant boulders of salt but it's still interesting to understand what the rough magnitude of this effort is and thus whether it's likely going to take months or rather years...
sirthias
on 23 Apr 2018
The Truffle languages can be supported as long as Truffle runs in interpreter mode. You won't get the same performance as with a JIT but it would still be useful for certain scenarios.
cstancu
on 23 Apr 2018
As for estimates, it is hard to give any estimate at this time, but it is definitely months not years. And of course we accept pull requests and would provide assistance if anyone wants to work on it.
cstancu
on 23 Apr 2018
Ok, great. Thank you, @cstancu!
sirthias
on 24 Apr 2018
Hi there @cstancu Thanks a lot for elaborating on these topics. So it appears to me that the two major pieces of work are finishing the AArch64 compiler backend and then providing support for that in SVM.
Is there any kind of board outlining planned broken down work on any of these major tasks. Just asking because if there is any way to help, I would be more than glad to (although the matter can be at times intimidating).
I see @daniel-stewart-qdt is doing some work on AArch64, so maybe he can provide some info on what the next planned steps are as well. In any case, willing to help where and how I can :)
zaharidichev
on 22 May 2018
This is interesting.
ScalaWilliam
on 27 Oct 2018
@cstancu Any ETA on the iOS support? As @sirthias said, having a AOT compiler for JVM based languages will be a game changer for the Java community.
priand
on 11 Jan 2019
We have no ETA for this. We are currently working on SubstrateVM on AArch64 for Linux (See #910). Other platforms are not decided yet.
I hope this answers the original question.
sanzinger
on 14 Jan 2019
@sanzinger The description text of this ticket does not include any question.
Rather, this ticket was meant as a point of reference for other people looking for information about graal support for iOS. Judging from the number of upvotes and comments it appears to me as this ticket was actually doing this job.
Therefore I am a bit surprised to see it simply being closed, especially since the PR you've referenced doesn't mention "iOS" anywhere.
Does your closing of this ticket actually mean "Won't Fix"?
If no, i.e. there hasn't been a decision to _not_ support iOS eventually, would it maybe be better to keep this ticket open until such a decision has actually been made, iOS support is available or another ticket properly supersedes it?
sirthias
on 16 Jan 2019
At the moment we do not have a decision if we are going to support iOS. At the moment we are occupied getting AArch64/Linux running.
I think we get a clear picture how iOS goes, when we have completed AArch64/Linux in a usable state.
sanzinger
on 16 Jan 2019
Thank you for this update and re-opening the ticket, @sanzinger!
Much appreciated!
We are keeping our thumbs crossed for iOS support eventually making it onto the Graal roadmap.
We still think it would be absolutely awesome to have and would unlock a ton of opportunities on many fronts.
sirthias
on 16 Jan 2019
So, now that the AArch64/Linux is merged, any news about supporting iOS now?
teras
on 14 Apr 2019
We support deploying to iOS via a Maven plugin. You can find examples at:
https://github.com/gluonhq/client-samples
You have an example for iOS at:
https://github.com/gluonhq/client-samples/tree/master/Maven/HelloFX
At this point, I would still advise using the LLVM backend as it is more complete.
In the future, we might support generating iOS binaries directly from GraalVM, but it is not certain if/when this will happen.
vjovanov
on 9 Dec 2019
We support deploying to iOS via a Maven plugin. You can find examples at:
https://github.com/gluonhq/client-samples
You have an example for iOS at:
https://github.com/gluonhq/client-samples/tree/master/Maven/HelloFX
At this point, I would still advise using the LLVM backend as it is more complete.
In the future, we might support generating iOS binaries directly from GraalVM, but it is not certain if/when this will happen.
Hello, could you please share any guide where I can read about how exactly it could be done? I mean, I have a jar that I can compile as a native library for OS X and Linux, but how I could compile it for iOS?
highleverage
on 30 Apr 2020
@johanvos how far are we from building shared libraries for iOS?
@lazar-mitrovic needs the same feature so it might be good to join forces.
vjovanov
on 30 Apr 2020
Shared library support for iOS would be absolutely fabulous!!
If it's available - or as soon as it's available - I'd be extremely eager to try it out and promote it (e.g. with blog posts, talks, etc.).
It's the original graal "feature" that this ticket was all about.
sirthias
on 1 May 2020
@sirthias you can take a look at the issue I made here (https://github.com/gluonhq/substrate/issues/47) and the links to my forked repositories to have a starting point for building iOS static libraries.
It is however an abandoned project on my side, as the results were not convincing enough for the time being, we decided to switch to K/Native instead.
CedricGatay
on 4 May 2020
Thank you so much for the pointer, @CedricGatay, I hadn't seen your work there yet.
A largish Scala-based shared lib is my exact first use case, so you breaking the ground there is highly relevant for us.
What exactly wasn't "convincing enough" and the trigger for you to abandon your project?
sirthias
on 4 May 2020
There was the following concerns :
- hacks around loading native libraries (JNI on devices)
- final artifact size (over 200Mb)
- general stability, it would randomly crash on device without a readable backtrace
- build time / reproducibility was also present (but not the factor that made us abandon this, as we know it will be better and better).
CedricGatay
on 4 May 2020
Ok, thank you for these details!
I guess we could live with all but your 3rd point, but maybe it's related to your first.
I'll definitely play around with your forks and try to get sth off the ground.
The good thing is that, in our use case, the shared library would simply be a heap of rather complicated business logic and nothing that needs interacting with native libs.
It would be great though to have proper threading support. Do you have any perspective on that? Did you encounter any issues wrt thread scheduling/concurrency abstractions?
Without having given it a lot of thought yet I'd assume the substrate-based shared lib to behave like any other native ios library, with the ability to start and use "its own" threads or simply run on the caller thread.
Are there any gotchas wrt the memory model? I would expect graal to make sure that all the JVM guarantees are properly upheld whatever the target platform but could imagine that there are certain edges cases that one should be aware of.
sirthias
on 4 May 2020
As far I remember, I had no concurrency issues / memory leaks during my testings (the framework is using akka / scala and makes use of concurrency).
I don't know if the random crashes were due to JNI loading ,but I sincerely doubt it, as it was rather random and backtrace were not necessary involving native code. However I might have done things the wrong way (and Graal have evolved too).
One of the "difficult" things was finding the proper LLVM / Graal combination to make the build "pass", afterwards it runs "properly".
CedricGatay
on 4 May 2020
Ok, thank you, Cedric!
sirthias
on 4 May 2020
@CedricGatay we have made quite a few improvements in the last couple of months:
- The LLVM is shipped with Graal so there are no difficulties with finding the right version.
- The LLVM backend passes all our tests.
- The debug symbols are coming soon so the stack traces should become usable.
- The build-time is improved quite a bit.
We are currently working on improving testing on mobile devices.
I was wondering about the artifact size, was it 200 MB with JavaFX or just your code?
Asking because a lot of the overhead comes from JavaFX at the moment. For the shared library use case @sirthias is referring to, I don't expect the binary to be large.
vjovanov
on 4 May 2020
Glad that most of the issues are being fixed @vjovanov !
The binary size was coming from transitive dependencies I guess from the project I was building to native (https://github.com/ACINQ/eclair) without the GUI part (so without JFX parts). But it gets scala + akka as a base.
CedricGatay
on 4 May 2020
It would be great though to have proper threading support. Do you have any perspective on that? Did you encounter any issues wrt thread scheduling/concurrency abstractions?
You can both start new threads and use the OS threads that are passed through the entry points. The memory model is the same as on the JVM.
vjovanov
on 4 May 2020
The memory model is the same as on the JVM.
Thank you, @vjovanov, that's what I assumed, as otherwise lots of things would fall apart.
sirthias
on 4 May 2020
The shared library is super interesting, compelling use case for us would be no jni etc. like kotlin mpp but without having to deal with kotlin migrations 馃
nhoughto
on 4 May 2020
Related issues
koduki
路
3Comments
ilopmar
路
3Comments
guaporocco
路
3Comments
johanvos
路
3Comments
borkdude
路
3Comments
Most helpful comment
So, now that the AArch64/Linux is merged, any news about supporting iOS now?