@Elias, GluonVM is not a thing at all now. You are victim of some kind of old marketing here. Article/doc you linked is 3 years old and mentions still even ODLEST approach using javafxports and jfxmobile plugin (peek there again and see that some links are dead and github repo of jfxmobile is 3 years old). On my way to understand current state of Gluon Mobile, I found this very old article (2014) which nicely described OLDEST approach, where javafx was used on top of DalvikVM on android devices and using RoboVM on iOS. But then came Apple and prohibited use of JIT compilation and any kind of external VMs on his devices. So that way was gone. Then came Oracle with GraalVM which is JDK more in java itself and part of such GraalVM is minimal VM for natively compiled java code, they call it SubstrateVM (Oracle). Although GraalVM compiles code into pure native processor code, in some cases when apps use reflection, there must be way to reflect on metadata at least on some classes. This must be explicitly provided to GraalVM compilation phase. And there are tools for scanning such access in your code, although it may require also manual tweaks in case your app is too dynamic (some kind of dependency injection and such magic), not a problem in most simper mobile apps though. This all is hard to do manually. And then came Gluon with his name Gluon VM term (as of your linked doc from 2018), probably, starting using GraalVM to build native images. And gluon ALSO used term SUBSTRATE in his products. Its Gluon-Substrate on github. This is NEW, CURRENT approach. Understand Gluon Substrate as "advanced-build-engine" using GraalVM, rather than any kind of new "VM". As there is not in fact any VM in GluonMobile native apps (apart from the GraalVM SubstrateVM left here because of reflection) - are you still following? Yes, its unfortunate mess in terms mostly :-). But thats OK, it simply just works now. Gluon Substrate build-engine hides everything magic inside new gluon "client-maven-plugin" (primary) and "client-gradle-plugin" (community). This provides goal "mvn client:build" which uses Gluon Substrate to assemble everything together for mobile and even embedded on Raspberry Pi. Uses ARM-based openJDK, ARM-based openJFX and allows you to run even almost pure JavaFX app on android/ios DEVICES, but this result will have NO access to such OS PLATFORM. For this, there is Gluon-Attach which defines abstract APIs and implements them on specific platform to provide access to things which ARE NOT part of JavaFX and tries to do it uniform way. When you develop app, you make it as DESKTOP and can run it even without native image built. In fact, its recommended, because you have all tools. Only if final app works as expected, you can do "mvn client:build" and other steps to pass it to your device or emulator to test there. You have also Glisten UI enhancements which provide some unified "Material Design" based UI on both android and iOS. Its not platform native though. Its not for ALL kinds of applications, but from my point of view, its enough for me to do something which can be distributed to Apple and Google stores. Yes, there are still quirks, most depends on Attach implementations. Consider this as kind of HAL/PAL - hardware or platform abstraction layer, but do it carefully. Its not so well defined here and some hardware access has no desktop implementations in Attach yet. Some makes no sense on desktop, ya. But I can imagine for development at least SIMULATED desktop implementations, with some kind of companion development app helping to test EVERYTHING on desktop before final deployment on the devices. Attach is quite flat set of abstractions for platforms, just some things are still missing. Anybody with AndroidSDK+NDK and iOS expertice can try to extend there what is missing for HIS app.
OLD (2014) article, well written but for OLD approach (STRONG WARNINGS!):
https://www.infoq.com/articles/Building-JavaFX-Android-Apps/
NEW video, describing even OLD approach (46:42) and NEW Substrate-build-engine (50:52)
https://drive.google.com/file/d/1Td9rZLh-1sY-GylBcPIrpM9028GJ43T7/view
For the "substrate" term, compare this about GraalVM JDK and Gluon-Substrate github:
https://en.wikipedia.org/wiki/GraalVM
https://github.com/gluonhq/substrate
