Build modernization: Gradle 9.5, AGP 9.2, Kotlin 2.3, and tooling updates

[solcott]

Overview

This PR modernizes the build infrastructure across the board — toolchain upgrades,
configuration cache adoption, CI improvements, and migration to current plugin APIs.

Changes

Gradle & Toolchain

• Gradle 8.6 → 9.6.1
• Added gradle/gradle-daemon-jvm.properties pinning the daemon to Azul JDK 17
• Enabled Gradle configuration cache (org.gradle.configuration-cache=true)
• Disabled configureondemand (incompatible with configuration cache)
• Added updateDaemonJvm task configured for JDK 17 / Azul

Dependency & Plugin Updates

• AGP 8.0 → 9.3.0(migrates to com.android.kotlin.multiplatform.library plugin)
• Kotlin 2.0.20 → 2.3.21
• kotlinx.coroutines 1.8.1 → 1.11.0
• kotlinx.serialization 1.6.3 → 1.11.0
• atomicfu 0.24.0 → 0.33.0
• Dokka 1.9.20 → 2.2.0 (new DokkaExtension API)
• KMMBridge 0.3.2 → 1.2.1 (migrates to co.touchlab.kmmbridge.github plugin)
• ktlint Gradle plugin 12.1 → 14.2, ktlint 0.39 → 1.8
• Kover 0.9.0-RC → 0.9.9
• Binary compatibility validator 0.15.0-Beta.2 → 0.18.1
• vanniktech maven publish 0.34 → 0.37
• Removed unused dependencies: molecule, androidx-paging, jacoco

Build Script Modernization

• Removed buildscript {} block — all plugins now declared via alias(libs.plugins.*) in the root build.gradle.kts
• All plugin versions centralized in libs.versions.toml
• Added VersionCatalogExt.kt with typed accessors for version catalog values (JVM toolchain, compat version, SDK levels, store version), replacing the hardcoded Versions object
• JVM target/toolchain versions now driven from the version catalog (jvmToolchain = 17, jvmCompat = 11)
• configureAndroid() updated for the new multiplatform Android library plugin API (namespace, withHostTest/withDeviceTest, compiler options)
• Removed per-module android { namespace = ... } and AndroidManifest.xml from cache, core, and multicast — namespace now set centrally in the convention plugin
• Migrated sourceSets { val x by getting { } } to sourceSets { x { } } idiom across submodules
• Extracted ktlint/spotless formatting into a FormattingConventionPlugin (org.mobilenativefoundation.store.formatting) applied per-module, replacing the deprecated cross-project subprojects {} plugin application in the root build.gradle.kts

CI / GitHub Actions

• actions/checkout v4 → v6
• actions/setup-java v4 → v5
• gradle/gradle-build-action → gradle/actions/setup-gradle@v6
• codecov/codecov-action v4 → v6
• Added explicit permissions block to CI job (least-privilege: contents: read, checks: write, pull-requests: write)
• Added --continue flag to build step so all module failures are reported in one run
• Overhauled create_swift_package.yml / KMMBridge workflow based on current KMMBridgeSPMQuickStart template; added KMMBridge-Release.yml dispatch workflow

API Validation

After migrating to the AGP 9 KMP Android library plugin, binary-compatibility-validator no longer registers any API tasks for the Android target (upstream limitation — Kotlin/binary-compatibility-validator#315). BCV neither generates nor checks api/android/*.api, so the previously committed dumps for store, cache, core, and multicast are stale, orphaned files. They have been removed.

Coverage note: the Android target is not independently ABI-validated. The JVM and klib (ios/js/linux/wasm) dumps are still generated and checked, and the JVM dump is a faithful proxy for the Android ABI since both compile the same common source. Android validation can be restored once BCV supports the AGP 9 KMP Android target.

Lint / Style

• Added .editorconfig disabling ktlint_standard_import-ordering for Kotlin files
• Expanded ktlint additionalEditorconfig rules to suppress several noisy checks project-wide

Other

• rx2: migrated deprecated TestCoroutineScope → TestScope
• cache API: getAllPresent() now compiles to a default interface method on the JVM (Kotlin 2.2+ jvm-default default change), reflected in the updated JVM .api dump
• gradle.properties: removed deprecated kotlin.js.compiler=ir
• Consolidated the project version into gradle/libs.versions.toml (store); removed VERSION_NAME from gradle.properties and pointed the CI version lookups at the catalog

[solcott]

Looks like the following github actions are not on your orgs allow list:

softprops/action-gh-release@v2 — used in create_swift_package.yml. Used for KMMBridge publishing.
touchlab/ga-update-release-tag@v1 — used in create_swift_package.yml. Used for KMMBridge publishing.

It looks like the Create Swift Package action has never been run. If you don't think it will be run in the future I can remove the KMMBridge support as well as create_swift_package.yml where these actions are used.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 80.17%. Comparing base (213e574) to head (0ce44bb).
⚠️ Report is 4 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #736   +/-   ##
=======================================
  Coverage   80.17%   80.17%           
=======================================
  Files          42       42           
  Lines         928      928           
  Branches      177      177           
=======================================
  Hits          744      744           
  Misses        110      110           
  Partials       74       74           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[solcott]

Hi @matt-ramotar, friendly nudge on this one. I know it landed out of the blue as one big PR, and a 30-file toolchain/CI/publishing change is a lot to take on in one review, so I'm happy to make it easier to digest.

I rebased onto current main today. It's mergeable and CI is running clean, so there's nothing broken or behind to untangle here, it just needs a look.

If the size is the sticking point, I can split it into small, independently-reviewable PRs, each green on its own, in a low-risk-first order:

1. Gradle wrapper bump (+ foojay-resolver)
2. CI actions refresh (checkout/setup-java/setup-gradle/codecov, least-privilege permissions block)
3. Dependency bumps (Kotlin 2.3, coroutines, serialization, atomicfu; drop unused molecule/paging/jacoco)
4. Lint/style (.editorconfig + ktlint rules)
5. Build-script modernization (remove buildscript {}, move plugins to version catalog, VersionCatalogExt)
6. AGP 9.2 / Android KMP library plugin migration
7. KMMBridge / Swift Package publishing overhaul — fully optional; I can drop this entirely if you don't publish SPM artifacts

Would that split be easier to review, or would you rather take it as one PR? Just tell me the format you prefer and I'll deliver it that way. (Also still flagging the two Actions not on the org allow-list — softprops/action-gh-release@v2 and touchlab/ga-update-release-tag@v1 — both only used by the KMMBridge workflow in #7, so they go away if you skip that piece.)

[matt-ramotar]

Can you re-run apiDump - I would have expected the Android dumps to regenerate too

[solcott]

The jvm() and android targets use different compilation backends with different -jvm-default modes.

Kotlin 2.2 changed the default -jvm-default from disable to enable. Under enable, an interface method with a default body (getAllPresent()) is emitted as a real JVM default method — non-abstract in the dump, with DefaultImpls kept for compat. The jvm() target picked this up on the Kotlin bump; the android target (compiled by AGP) pins its own mode and stayed on the old abstract + DefaultImpls shape.

Three ways to reconcile, your call:

• disable on JVM → both revert to abstract + DefaultImpls.
• enable on Android → both match the new JVM shape (real default method + DefaultImpls).
• no-compatibility on both → both drop DefaultImpls, real default method only.

The last two emit real interface default methods, which Android supports at API 24+ — safe since minSdk = 24.

[matt-ramotar]

Let's revert this if it's not being used

[solcott]

Looks like I removed the action that required these. I'll remove.

[matt-ramotar]

Why is there not a KMMBridge-Debug.yml / KMMBridge-Release.yml?

[solcott]

Good call on the naming — I've renamed KMMBridge-Publish.yml → KMMBridge-Release.yml to make the intent explicit. It's now based on KMMBridge's new recommended flow ([Base-Publish.yml](https://github.com/touchlab/KMMBridgeSPMQuickStart/blob/main/.github/workflows/Base-Publish.yml)), since a lot changed since the version we previously used.

There's no KMMBridge-Debug.yml because only release is something we distribute:

• The SPM Package.swift binary target can point at one XCFramework URL per tag, so a separate debug variant isn't independently consumable — a second publish would just overwrite the manifest.
• Debug XCFrameworks are a local dev concern. When you need to step through Kotlin from Xcode, KMMBridge builds one on demand via ./gradlew store:spmDevBuild, which rewrites Package.swift to a local path — no CI or Release upload. So a debug workflow would have nothing to publish.

I've also fixed the stale line-1 comment that claimed it published "both debug and release."

[matt-ramotar]

Why is this needed? All consumers of core would gain a transitive dependency. If this is needed for klib linking in cache/multicast, let's scope it to those modules (or their own build files)

[solcott]

Looks like this isn't needed anymore with newer versions of the atomicfu gradle plugin. I can see them being added as dependencies to jsApiElements-published and jsRuntimeElements-published in the published gradle .module file. I'll remove this.

[matt-ramotar]

Hey @solcott - thanks for doing this. Sorry to be slow. On board with general direction. Left a few questions/comments. 1 more - can you update the PR description? I see a few things are stale

• mikepenz/action-junit-report@v5
• KMMBridge-Debug.yml / KMMBridge-Release.yml
• Codecov fork guard
• Gradle should be 9.6.1
• maven-publish should be 0.37.0

[matt-ramotar]

Updated the version - #742

[solcott]

I believe I have updated everything base on your comments.

Should I update to the latest Kotlin: 2.4.10. Or keep it at 2.3.21? I don't want to force others to update to latest version, although anyone using alpha versions of libraries is probably using the latest Kotlin release.

After updating Kotlin from 2.0.20 to 2.3.21 I did notice a number of deprecation warnings. Would you like me to fix them in this PR or create a new one once this is merged?

[solcott]

I consolidated the project version to libs.versions.toml in 6b18ec7. Let me know if this works for you.

[matt-ramotar]

Works for me 👍

[matt-ramotar]

@solcott Thanks again for this contribution, Scott. I did some digging and it looks like this is an issue with BCV. I reported it here and flagged to Kotlin team - Kotlin/binary-compatibility-validator#315. There's no clean fix on Kotlin 2.3.21, so let's delete api/android/*.api in store, cache, core, and multicast, and note the coverage change in the PR body. The jvm dumps are a faithful interim proxy since both targets compile the same source with the same compiler and mode. Really appreciate the modernization help

[matt-ramotar]

Should I update to the latest Kotlin: 2.4.10. Or keep it at 2.3.21? I don't want to force others to update to latest version, although anyone using alpha versions of libraries is probably using the latest Kotlin release.

Let's keep it at 2.3.21

After updating Kotlin from 2.0.20 to 2.3.21 I did notice a number of deprecation warnings. Would you like me to fix them in this PR or create a new one once this is merged?

We can do it in a separate PR

[solcott]

I removed the android .api files in core, cache. multicast, and store modules and updated the PR body. I also made one last change in 9805deb to migrate away from applying plugins in subprojects{} as that has been deprecate.