Copy of text from discussion #879 on MobiVM/robovm repo.

This document defines the architecture, version policy, and multi-phase execution plan to transition the RoboVM project from its current monolithic release model into an independently versioned and released component ecosystem.

1. Executive Summary & Problem Statement

The RoboVM project currently operates as a monolith where all components (compiler, runtime, native VM, bindings, and IDE plugins) share a single global version (3.0.0-SNAPSHOT) and release simultaneously. This model creates critical operational bottlenecks:

• Release Coupling & Blockers: A minor fix in the IntelliJ plugin or CocoaTouch bindings forces a full release of all 20+ modules. A build failure in an unrelated component (e.g., an Eclipse Tycho repo timeout) completely blocks urgent leaf-tool updates.
• Publishing Overhead & Sonatype Quotas: Re-uploading dozens of unchanged multi-megabyte native binaries and full SDK archives on every minor fix slows down releases and risks hitting Sonatype Maven Central publishing limits.
• Code-Level Version Lock-In: Plugins hardcode calls to Version.getCompilerVersion() to locate SDK artifacts and unpack directories, making independent component evolution physically impossible in code.
• Heavy Developer Toolchain: Working on a single leaf module (such as the Gradle or IDEA plugin) requires maintaining the entire cross-compilation toolchain (CMake, multi-target Clang, Tycho, Java) and compiling the full reactor.
• Downstream Consumer Churn: iOS app developers seeking a simple IDE plugin update are forced to upgrade their compiler and runtime lockstep, re-downloading gigabytes of SDK bundles and taking on unnecessary regression risks.

Target Objective & Benefits: This migration transitions RoboVM into an independently versioned and released component ecosystem. By eliminating the monolithic build reactor and severing product-level version lock-in, publishing overhead to Maven Central is drastically reduced.

While working on compose for RoboVM, a strange NPE appeared:

java.lang.NullPointerException at androidx.compose.runtime.MonotonicFrameClock.getKey(MonotonicFrameClock.kt)

The simplified code looks like this:

  public interface MonotonicFrameClock : CoroutineContext.Element {
      override val key: CoroutineContext.Key<*>
          get() = Key
      public companion object Key : CoroutineContext.Key<MonotonicFrameClock>
  }

It was clear that the issue was related to a default method in an interface, but let’s reduce it to a simple Java sample to eliminate Kotlin overhead:

TLTR: sample project - codesnippets/compose-demo-app.

Compose Multiplatform has already been on iOS for a while. The issue is that it’s powered by Kotlin Native, which means the Java ecosystem isn’t available around it. On the other hand, RoboVM provides a JVM flavor on iOS, but it lacks the AWT/Swing support needed to run the Desktop target of Compose Multiplatform natively.

Before trying to run Compose Multiplatform on RoboVM, let’s dive into its layers:
Compose Multiplatform - UI framework for Kotlin
↓ ↓ ↓
Skiko - Kotlin Multiplatform bindings to Skia
↓ ↓ ↓
Skia - the 2D Graphics Library by Google

While playing with bulk-updater agent few frameworks received updates:

• Google Mobile Ads updated from 13.5.0 to 13.6.0
• Facebook updated from 18.0.3 to 18.1.0
• IronSource updated from 9.4.1 to 9.4.2

That was an experiment to implement agent driven alt-pods processing. The goal was to delegate all manual work to sub-agent while keep all deterministic scripts in place. Following was delegated to agent:

• check upstream for update framework, downloading and unpacking;
• handling new version with existing harvester script;
• analyze bro-gen suggestions and normalize naming of methods;
• merging of normalized suggestions with existing yaml files;
• restart handling cycle with changes;
• compiling and testing of generated modules;
• allow agent to recovery during normalization and merging.

Somehow it works. Today. But probably will not work tomorrow (check “the bad” section).

toolset

GitHub Copilot agent was used running as IntelliJ plugin with GPT-5.4-mini model. All related files located in .github/ folder of alt-pods repo.

the good

• automatic fetch of new framework version and storing them at expected location is really working and useful;
• automatic normalization of suggestions and merging with existing yaml files is useful and handles most of the cases;
• doesn’t cost too much, around 500 credits for full rebind. Or 200 for update scan with few frameworks updated.

the bad

• agent is not deterministic, might be changed with any update of the plugin, model;
• most part of agent prompt is to prohibit agent from doing random things;
• lack of proper sandboxing, agent invoke tons of shell commands, generate scripts etc. It is hard to control and verify what it does, as it breaks the idea of automation. So first thing is to do dangerous “allow everything”;
• messes with file path. considering “allow everything” it feels bad :)
• slow. rebind cycle takes around 3h, update scan takes around 1h;
• local models like Gemma4 is extremely slow in agent mode (while chat feels okay) and ever more dangerous in messing with file path (like starts looking for files in /root of drive instead of project folder). So it is not usable for this task.

bottom line

Setup will be used and probably improved in the future, most concern at moment it is slow speed.

Alt-pods update issue 1.60, new sync with recent releases.
Released to maven central.

Updated pods

• Google Mobile Ads adapters updated
• Google Mobile Ads updated from 13.3.0 to 13.5.0
• UnityAds updated from 4.17.0 to 4.18.1 (no api changes)
• Tenjin updated from 1.16.1 to 1.17.1
• Singular updated from 12.10.1 to 12.12.0
• OneSignal updated from 5.5.1 to 5.5.3
• Lottie updated from 4.6.0 to 4.6.1
• InMobiSDK updated from 11.2.0 to 11.3.0
• Firebase updated from 12.2.0 to 12.15.0
• CleverAds updated from 4.6.6 to 4.7.4
• Chars updated, no api/version changes
• AppsFlyer updated from 6.18.0 to 7.0.0
• AppLovinSDK updated from 13.6.2 to 13.6.3 (no api changes)
• AdjustSDK updated from 5.6.2 to 5.7.0

about versioning

Each pod has version of corresponding framework + .0 suffix. E.g.: Google Mobile Ads 13.0.0 are accessible as following dependency:

implementation “io.github.dkimitsa.robovm:robopods-google-mobile-ads-ios:13.0.0.0”

Also for set of pods, built from single source there are bill-of-material available, where version of bom is framework version with .0 suffix:
Facebook:

implementation platform(“io.github.dkimitsa.robovm:robopods-facebook-bom:18.0.3.0) // v18.0.3
implementation “io.github.dkimitsa.robovm:robopods-facebook-login-ios”

Firebase:

implementation platform(“io.github.dkimitsa.robovm:robopods-firebase-bom:12.9.0.0”) // v12.9.0
implementation “io.github.dkimitsa.robovm:robopods-firebase-analytics-ios”

• These pods were released to Maven central, each pod under own version. Source code @github

Updates are not fully tested, please open issue if bug found.

Idea plugin was submitted to Idea Marketplace and should be available soon.
Meanwhile it can be downloaded manually from MobiVM site.

2.3.25, June, 2026

• support for launching on ios17+ devices #830
• support for recent Intellij Idea/AndroidStudio #835, 836
• improvement: IdeaPlugin – excluding “robovm-build” from content root #839

Happy coding!
Please report any issue to tracker.

Alt-pods update issue 1.59, new sync with recent releases.
Released to maven central.

Updated pods

• Tenjin updated 1.15.1 to 1.16.1
• OneSignal updated 5.5.0 to 5.5.1
• IronSource updated 9.2.0 to 9.4.1
• Fyber updated 8.4.5 to 8.4.7
• CleverAds updated 4.6.3 to 4.6.6
• AppsFlyer updated 6.17.9 to 6.18.0
• Inmobi updated 11.1.1 to 11.2.0
• Google Mobile Ads updated 13.1.0 to 13.3.0
• Firebase updated to v12.10.0 -> v12.12.0
• new framework: Adjust SDK v5.6.2

about versioning

Each pod has version of corresponding framework + .0 suffix. E.g.: Google Mobile Ads 13.0.0 are accessible as following dependency:

implementation “io.github.dkimitsa.robovm:robopods-google-mobile-ads-ios:13.0.0.0”

Also for set of pods, built from single source there are bill-of-material available, where version of bom is framework version with .0 suffix:
Facebook:

implementation platform(“io.github.dkimitsa.robovm:robopods-facebook-bom:18.0.3.0) // v18.0.3
implementation “io.github.dkimitsa.robovm:robopods-facebook-login-ios”

Firebase:

implementation platform(“io.github.dkimitsa.robovm:robopods-firebase-bom:12.9.0.0”) // v12.9.0
implementation “io.github.dkimitsa.robovm:robopods-firebase-analytics-ios”

• These pods were released to Maven central, each pod under own version. Source code @github

Updates are not fully tested, please open issue if bug found.

Alt-pods update issue 1.58, new sync with recent releases and first update after migrating to new version numbering.

Updated pods (ones with API changed)

• Appsflyer updated 6.17.8 to 6.17.9
• CleverAds updated 4.5.4 to 4.6.2
• Firebase updated to v12.9.0 -> v12.10.0
• Google Mobile Ads updated 13.0.0 to 13.1.0
• OneSignal updated 5.4.1 to 5.5.0
• UnityAds updated: v4.16.6 -> v4.17.0

about versioning

Each pod has version of corresponding framework + .0 suffix. E.g.: Google Mobile Ads 13.0.0 are accessible as following dependency:

implementation “io.github.dkimitsa.robovm:robopods-google-mobile-ads-ios:13.0.0.0”

Also for set of pods, built from single source there are bill-of-material available, where version of bom is framework version with .0 suffix:
Facebook:

implementation platform(“io.github.dkimitsa.robovm:robopods-facebook-bom:18.0.3.0) // v18.0.3
implementation “io.github.dkimitsa.robovm:robopods-facebook-login-ios”

Firebase:

implementation platform(“io.github.dkimitsa.robovm:robopods-firebase-bom:12.9.0.0”) // v12.9.0
implementation “io.github.dkimitsa.robovm:robopods-firebase-analytics-ios”

• These pods were released to Maven central, each pod under own version. Source code @github

Updates are not fully tested, please open issue if bug found.

Eclipse plugin for RoboVM is being maintained at low priority and there are no plans for major updates in the near future. More over it is not clear if it is being used at all. Anyway meanwhile we keep it working and compatible with latest Eclipse versions. Below is the step-by-step instruction on how to set up development environment for it.

Alt-pods update issue 1.57, new sync with recent releases and first update after migrating to new version numbering.

how version builds

Each pod has version of corresponding framework + .0 suffix. E.g.: Google Mobile Ads 13.0.0 are accessible as following dependency:

implementation “io.github.dkimitsa.robovm:robopods-google-mobile-ads-ios:13.0.0.0”

Also for set of pods, built from single source there are bill-of-material available, where version of bom is framework version with .0 suffix:
Facebook:

implementation platform(“io.github.dkimitsa.robovm:robopods-facebook-bom:18.0.3.0) // v18.0.3
implementation “io.github.dkimitsa.robovm:robopods-facebook-login-ios”

Firebase:

implementation platform(“io.github.dkimitsa.robovm:robopods-firebase-bom:12.9.0.0”) // v12.9.0
implementation “io.github.dkimitsa.robovm:robopods-firebase-analytics-ios”

Updated pods (ones with API changed)

• Singular updated 12.9.0 to 12.10.0
• OneSignal updated 5.2.15 to 5.4.1
• Fyber updated 8.4.2 to 8.4.5
• CleverAds updated 4.5.4 to 4.6.2
• BranchMetrics updated 3.13.0 to 3.14.0
• Inmobi updated 11.1.0 to 11.1.1
• ApplovinSDK updated 13.5.1 to 13.6.0
• Google Mobile Ads updated 12.14.0 to 13.0.0
• Facebook updated 18.0.1 to 18.0.3
• Firebase updated to v12.7.0 -> v12.9.0

Updated pods (ones with API changed)

• UnityAds updated 4.16.5 to 4.16.6
• Tenjin updated 1.15.0 to 1.15.1

• Lottie updated 4.5.2 to 4.6.0

• These pods were were released to Maven central, each pod under own version. Source code @github

Updates are not fully tested, please open issue if bug found.