Multi-OS Engine: an iOS runtime for Java and Kotlin

What the engine actually provides

Multi-OS Engine provides a Java runtime and Java interfaces to the iOS platform API, so that you can develop native iOS applications with native look and feel, native performance, and portability of common Java logic modules from your Android apps.

That sentence contains the whole thesis, and each clause is a constraint. The apps are native, so this is not a web view wrapper and not a cross platform canvas. The performance is native, so the rendering path is the platform's own rather than an interpreter's approximation of it. And the portability is limited to common Java logic modules, which is the honest part. The point is not that everything you wrote in Java runs on iOS, but that the part that was platform independent, the domain logic, the data layer, the parsing, does not have to be rewritten.

The distribution is a complete toolchain. The project says it comes fully integrated with Android Studio hosted on macOS or Windows and contains all the development tools needed to develop an iOS app and publish to the App Store. That framing is worth noting: this is not a library you add to a Gradle build, it is an environment with its own IDE integration, its own plugin set and its own SDK publishing process.

For an Android team the appeal is obvious. The alternative to reusing Java logic on iOS is a second implementation in Swift, and that is a second codebase, a second set of bugs and a second testing effort, for anything that is not the user interface.

The getting started path is the documented one

The README is short, and the first section points outward rather than inward.

You install Multi-OS Engine from the project site, walk through the Quick Start Tutorials to configure your development environment and learn how to develop applications using it, ask questions on the Multi-OS Engine Forum, and submit issues to the issue tracker on GitHub.

There is no build-from-source quick start in that list, and that is telling. The intended path is to install the packaged environment and start writing applications, with the source build documented separately for people who need to modify the engine itself.

The documentation lives at doc.multi-os-engine.org and the project site is multi-os-engine.org. The FAQ for a new user is therefore not in the repository, which is normal for a project of this size and this age, and it is also the first thing to check if you are evaluating it: the engine's behaviour, its limitations and its current state live in that documentation and on the forum rather than in the tree.

The repository itself is the platform source, with a moe-core/ directory, natj/ for the native runtime, prebuilts/ for the toolchain binaries, build-tools/, tools/ and a Gradle build with gradlew and gradlew.bat alongside a settings.gradle and gradle.properties. The topic tags name the integration points: an IntelliJ IDEA plugin, an Eclipse plugin, a Gradle plugin, and the LLVM and macOS foundations underneath.

Building from source starts with the repo tool

The source build is a multi repository build orchestrated by Google's repo tool, and the requirements are stated plainly. You need Apple macOS 10.14 or later and a minimum of 8GB of RAM.

The repo tool itself is installed by hand or by brew. The manual route creates a directory, puts it on the path, downloads the script and makes it executable.

mkdir ~/bin
PATH=~/bin:$PATH
curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo
chmod a+x ~/bin/repo

Or you can install it with brew.

brew install repo

Then the source is fetched from the manifest repository. The mainline branch is moe-master, and the default branch of the repository matches it.

repo init -u https://github.com/multi-os-engine/manifest.git -b moe-master
repo sync

There is a second option, and the README explains when to use it. If you want the source code from the development branch with initial support of Windows and bitcode, switch to the moe-windows-bitcode branch, and the init command differs only in the branch name.

repo init -u https://github.com/multi-os-engine/manifest.git -b moe-windows-bitcode
repo sync

That branch split is a real signal about the state of the project. The mainline is what a release is cut from, and Windows support plus bitcode exist on a development branch, which means the cross-platform ambitions of the original design have not all landed on the mainline.

The Homebrew dependency list tells you the build system

Installing Homebrew from brew.sh and then the dependencies is the next documented step, and the list is long enough to explain a lot about the project.

brew install autogen autoconf automake libtool pkg-config wget isl cloog cmake gpg ant maven mpfr libmpc repo premake texinfo

The GNU autotools family, autogen, autoconf, automake and libtool, along with pkg-config and cmake, is the build system of a native C and C++ toolchain. isl and cloog are polyhedral library tools, which is what a compiler backend for integer set transformations needs. Ant and Maven are the Java build tools. mpfr and libmpc are multiple precision arithmetic libraries, and those are there for the compiler's numeric support rather than for anything you would use at runtime. premake and texinfo are build and documentation generators.

So the engine is not a Java project that happens to target iOS. It contains a native toolchain, which is why the build needs LLVM and MinGW assembled from source and why the memory floor is 8GB.

The MinGW and LLVM step is described separately, because it is the expensive one.

cd <repo>/moe
./gradlew :prebuilts:mingw :prebuilts:llvm

The README says this step only needs to be done once, or until the MinGW or LLVM components and requirements are changed. That is a large one-time cost, and it is the step most likely to make a contributor give up.

SDK and plugin publishing are separate Gradle targets

The final part of the source build is about producing the artifacts that the IDE plugins consume, and it is done through the Gradle build rather than through the repo tooling.

A developer SDK is produced by the devsdk target.

cd <repo>/moe
./gradlew :tools:moe-sdk:devsdk

Publishing an SDK to the local Maven repository is a different target, and it is the SDK Publisher project that does it.

cd <repo>/moe
./gradlew :tools:moe-sdk:publishToMavenLocal

The Gradle plugin is published the same way, from the moe-plugin-gradle project.

cd <repo>/moe
./gradlew :tools:moe-gradle:publishToMavenLocal

The IDEA plugin is built from a different directory and with a different task name.

cd <repo>/moe/tools/master
./gradlew :moe.plugin.idea:build

There is also a version override for a single component, which is useful when you are testing a change against a locally built dependency.

cd <repo>/moe/tools
sh set_version.sh <component> <version>  

Taken together, these targets show the shape of the project. The engine is not one binary. It is a runtime, a native toolchain, a developer SDK, a Gradle plugin, an IDEA plugin and an Eclipse plugin, and the build produces them separately because a developer needs the SDK and the plugin that consumes it, while a platform engineer needs the toolchain underneath.

Where Multi-OS Engine is the wrong choice

The clearest case is a team starting an iOS app with no Android codebase. Nothing here helps, and a great deal of it is in the way. You would be adopting a toolchain with an IntelliJ plugin, an Eclipse plugin, a Gradle plugin, a prebuilt LLVM and a multi repository build, in order to write an app in a language that is not the native one for the platform.

The second case is a team whose Java code is not portable in practice. The value proposition is portability of common Java logic modules, and if the shared code is entangled with Android APIs, or the team has already moved to Kotlin Multiplatform for exactly this reason, then the thing MOE saves you from is the problem you already solved.

The third case is a team that needs a maintained platform. The release list holds one entry, 1.0.853, dated 2016-08-12, while the last push to the repository was on 2026-07-05. The tree is being worked on and the tags have not moved in a decade, which means the packaged environment you would install and the source you would read are not obviously the same thing, and neither has a versioned update path. The README does not document how a running team is supposed to pick up platform changes.

The honest summary is that Multi-OS Engine is a substantial piece of infrastructure with a specific and still relevant purpose, built when Java was the pragmatic choice for cross platform Android and iOS work. The alternative for the same goal today is a rewrite of the shared layer in Swift, or a genuine cross platform framework, and the comparison to make is not technical but organisational: whether reusing your Java layer is worth a toolchain you now maintain.

Editorial conclusion

Multi-OS Engine suits a team that already has a large Java or Kotlin codebase for Android and wants to reach iOS without rewriting the shared business logic, and that is prepared to own a toolchain with an IntelliJ and Gradle plugin, an SDK publisher and a prebuilt LLVM. It does not suit a team starting an iOS app today, when Swift is the native path and this project's newest listed release tag is 1.0.853 from 2016. Verify first which branch you need, since the mainline is moe-master while Windows and bitcode support live on a separate development branch, and read the build requirements before planning around it.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. multi-os-engine/multi-os-engine on GitHub
3. Project website
4. README
5. Releases