So far MOE is the 1 of the only 2 options (besides robovm) for us to 100% reusing some of our critical business libraries across server/android/iOS which is great since that saved us a lot of effort to write the same thing in different languages and properly tested/sync between each other, and this is the No1 reason that I want to keep this alive.
I did attempt to update the runtime to the latest android (it was 10 at that time) but as @kisg said in another thread the biggest issue is the ICU library. To be honest I don’t really mind the increasing of app size as long as it works, but it’s still a quite substantial amount of work to make the upgrade, consider how much android itself has changed over the years.
The other option is GraalVM but that’s even more unfamiliar to me, and frankly more complicated. I also don’t know if it could include the java strack trace in native crash logs (which IMO is the most important piece that is missing from current MOE). Also it’s unknown to me if GraalVM supports apple’s bitcode.
Other than that, I’m working on a personal experimental project that converts java bytecodes into pure C code, then use Xcode for compiling, so in theory bitcode should be supported, and could take advantage of apple’s own tools for optimization etc. The idea is somewhat similar to IL2CPP, and there is already another project called “CodeNameOne” that works with a subset of java features (with lots of std libs missing, no reflection etc). My project aims on bringing full java se support (at least to the same feature level as the latest android runtime), however this is no where near useable, and I could fairly confident that it won’t be as fast as current MOE, but I’ll (slowly) work on it unless I find a better solution