Roadmap
What is on the roadmap, and what is not promised?
Section titled “What is on the roadmap, and what is not promised?”This page describes intent, not commitments. No item here has a date, and none will get one until its blockers are cleared. The library is production-ready today, and everything below is about removing setup friction, not about missing functionality.
| Shipped | Six ad formats, UMP consent in the init flow, mediation support, paid events, and the dev.avinya.ads.admob-cmp Gradle plugin for Kotlin/Native iOS test linking |
| Planned, gated | SwiftPM import migration — removes both the Gradle plugin and the manual Xcode package step |
| Not planned | Direct support for ad networks other than AdMob (mediation covers this), and renaming the published Maven coordinate |
What is the SwiftPM import migration?
Section titled “What is the SwiftPM import migration?”The Kotlin Gradle plugin has gained first-class Swift Package
Manager dependencies via swiftPMDependencies {}. A Kotlin
Multiplatform module declares the Swift package, and the Kotlin
Gradle plugin resolves it and generates the cinterop bindings.
The official documentation states the property that would make
the current Gradle plugin unnecessary:
“For transitive dependencies (projects that depend on those that use SwiftPM import), the Kotlin Gradle plugin automatically provides the necessary machine code from SwiftPM dependencies. For example, you don’t need to do any additional configuration when running Kotlin/Native tests or linking a framework.”
What shipping it would mean for a consumer, concretely: no
dev.avinya.ads.admob-cmp plugin, no manually-added Swift
packages in Xcode, and one added one-time integrateLinkagePackage
step. It would raise the Kotlin floor for every consumer and
would therefore ship as 2.0.0, with the 1.x line continuing
to receive fixes for as long as the ecosystem lags.
A note on the “fixes for as long as the ecosystem lags” commitment. The 1.x line is not abandoned when 2.0.0 ships; it is maintained in parallel until the migration is provably complete for every consumer. The cost of a parallel line is small relative to the cost of a forced migration, and the library has stated this as policy in the contributing guide so the maintenance window is committed, not implied.
Which four gates does it wait on?
Section titled “Which four gates does it wait on?”The gates, with the reason for each, exactly as the Track 3 plan defines them. None of them can be unblocked by work in this repository, which is the honest reason there is no date.
Gate 1 — Kotlin 2.4.20 or later is a stable release
Section titled “Gate 1 — Kotlin 2.4.20 or later is a stable release”Not Beta, not RC. A published library must not be compiled by a pre-release compiler, because consumers cannot reliably resolve klibs produced by one.
Gate 2 — SwiftPM import is no longer Alpha
Section titled “Gate 2 — SwiftPM import is no longer Alpha”A published SDK must not depend on an Alpha build-tool feature. The DSL shape itself is still subject to change while it carries that label.
Gate 3 — KSP has a release for the target Kotlin version
Section titled “Gate 3 — KSP has a release for the target Kotlin version”Consumers using Room or Koin annotation processing cannot move to a Kotlin version KSP does not support, so shipping ahead of KSP would strand them.
Gate 4 — Compose Multiplatform has a stable release for that Kotlin version
Section titled “Gate 4 — Compose Multiplatform has a stable release for that Kotlin version”The composable surface is part of the published artifact, so Compose Multiplatform must support the same Kotlin version.
What is the one question nobody has answered yet?
Section titled “What is the one question nobody has answered yet?”The direction of travel honestly:
KT-84420 concluded
that Kotlin should start emitting a Package.swift structure
describing the direct and transitive SwiftPM dependencies needed
for linkage — that is, linkage requirements travel as metadata
the consumer resolves, not as embedded binaries. Whether the
equivalent reaches a Maven consumer’s
linkDebugTestIosSimulatorArm64 is exactly what has to be
proven.
The four steps the experiment will use: build a trivial Kotlin
Multiplatform library declaring a swiftPMDependencies package
and exposing one function touching its API; publish it to Maven
Local; in a separate Gradle build with no SwiftPM declaration
of its own, depend on it from commonMain, add a trivial test,
and run iosSimulatorArm64Test; if it links, the migration is
viable, and if it fails with undefined symbols, the migration
is dead for a published SDK, because the consumer would then
have to declare the SwiftPM dependency themselves — no better
than today’s Gradle plugin and worse than the status quo, since
it would also drag every consumer onto a new Kotlin minor.
The secondary technical prerequisite settled by the same
experiment: GoogleMobileAds’ Package.swift is a
.binaryTarget, so swiftPMDependencies must handle
binary-target packages. The official documentation’s own example
is a binary distribution, which is encouraging evidence but not
proof for this package specifically.
A note on the experiment’s scope. It is intentionally a single
trivial library, not a port of admob-cmp itself. The point of
the experiment is to validate the metadata-passes-through-the-
klink hypothesis, which is the only behaviour that matters for
the migration’s viability. A negative result is conclusive; a
positive result is suggestive but not yet a commitment to ship.
Why not do what other SDKs do and embed the binary?
Section titled “Why not do what other SDKs do and embed the binary?”A factual contrast, no criticism of anyone. RevenueCat’s
purchases-kmp 3.0.0 reaches the same outcome by a different
route: a home-grown swiftPackage DSL in their own build logic
that compiles purchases-ios from source, pinned as a git
submodule, and statically links the result into the published
artifact. That works because purchases-ios is open source.
Google Mobile Ads is a closed-source prebuilt binary: there is no
source to compile, and the XCFramework ships only third-party
licences with no grant to redistribute GMA itself. Embedding
Google’s binary in a dev.avinya.ads artifact would also
reintroduce the duplicate Objective-C class problem that breaks
mediation adapters — the exact thing the bindings-only design
avoids. Same destination, different vehicle. The
architecture reference has the
full rationale.
What happens if the gates never clear?
Section titled “What happens if the gates never clear?”Plainly, because it reassures rather than worries: the Gradle
plugin is a perfectly serviceable permanent answer. It is a
small amount of code in one place, it is dogfooded by this
repository’s own modules, and it is invisible to consumers
beyond a single plugins {} line. The migration will not happen
on principle; it will happen when the official path is genuinely
stable and the ecosystem has caught up. Until then, the plugin
is the answer, and the installation guide
walks through it as the supported path.