Kmp Module Split For Packaging Agent Skill

One shared library, thin launchers

Three modules, and each has exactly one job:

| Module | Plugins applied | Owns |

|---|---|---|

| <shared-ui> | Kotlin Multiplatform + the Android multiplatform library plugin + Compose | all UI, view models, expect/actual, shared resources |

| <android-launcher> | the Android application plugin, plus whatever its own sources and packaging need | manifest, launcher icons, application class, shrinker rules, ABI splits, store config |

| <desktop-launcher> | Kotlin Multiplatform with a single jvm() target + Compose desktop + the packaging plugin | main(), packaging targets, installer metadata, shrinker wiring |

Plugin lists overlap, and that is expected. All three modules here apply the Compose compiler;

the shared module and the desktop launcher both apply Kotlin Multiplatform and Compose

Multiplatform. A launcher applies whatever its own sources and packaging block need. What the split

makes exclusive is ownership — app identity and packaging versus shared code — not which plugin

ids may appear where; dropping one from a launcher breaks that launcher's own sources.

Both launchers depend on the library and add nothing to it:

// <android-launcher>/build.gradle.kts
implementation(projects.<sharedUi>)

// <desktop-launcher>/build.gradle.kts — inside sourceSets { jvmMain { dependencies { … } } }
implementation(project(":<shared-ui>"))

Why the Android side is not optional

The Android Gradle Plugin (AGP) ships its multiplatform support as a library plugin, and only

that. Check your own version rather than trusting a version note:

AGP=$(grep -oP '^android\s*=\s*"\K[^"]+' gradle/libs.versions.toml)
unzip -l "$(find ~/.gradle/caches/modules-2 -path '*com.android.tools.build/gradle/*' \
  -name "gradle-$AGP.jar" | head -1)" | grep -o 'META-INF/gradle-plugins/[a-z.]*\.properties'

Under AGP 9.2.1 that lists com.android.application and com.android.kotlin.multiplatform.library

as separate plugin ids, with no multiplatform *application* id at all — and among the jar's

KotlinMultiplatformAndroid* types, the ones naming a module kind name the library

(…LibraryExtensionImpl, …LibraryTargetImpl) while none is named …Application…. So the

module carrying your Android multiplatform target is a library by construction, and the module that

produces the installable artifact has to be a different, plain Android application module.

The desktop handoff is one public function

The library keeps every window, tray, crash-handler and dependency-container detail. It exposes one

entry point; the launcher owns main() and therefore owns argv:

// <shared-ui>/src/jvmMain/…/DesktopApp.kt
fun runDesktopApp(args: Array<String> = emptyArray()) { /* windows, dependency-injection start-up, deep links, tray */ }

// <desktop-launcher>/src/jvmMain/…/Main.kt — adapted
fun main(args: Array<String>) {
    forcePlatformWindowClass()   // pre-UI platform tweak that must run before any window opens
    runDesktopApp(args)
}

The packaging block points at exactly this file — mainClass = "com.example.app.MainKt". Keeping the

handoff a plain function (not a class the packager instantiates) is what still lets the library be

launched directly in development.

Traps

A library and an application do not default the same way, and the difference is silent. The

build script here records that once the shared module became a library, the Compose resources plugin

stopped generating the resource accessor class under its default auto mode — its reading is that a

library is not treated as owning the public resource class. Either way, the pin is the fix:

compose.resources { generateResClass = always }

Verify against the artifact, not the setting: find <shared-ui>/build/generated -name 'Res.kt' must

find one. Audit every other "app vs library" default the same way after the split.

A task defined in the library is not wired into the launcher's packaging by proximity. Native

staging, code generation and asset preparation can stay in the library, but each packaging task in

the launcher must name the cross-project dependency itself:

tasks.register<Exec>("package<Platform>") {
    dependsOn(":<shared-ui>:stageNatives")
    …
}

Find the ones you forgot: grep -n 'tasks.register\|dependsOn' <desktop-launcher>/build.gradle.kts

and check that every packaging task listed has a dependsOn line. A missing one packages whatever

happened to be left in the staging directory from a previous run — it succeeds, and ships stale

binaries.

Plugin order in the launcher is load-bearing, not style. A packaging plugin that creates its

tasks at apply time can only do so once the task it looks for already exists, and a plugin applied

after it can replace that task under a different name. The launcher here records that ordering in a

comment above its plugins { } block — treat a reorder as a behavioural change, not a tidy-up.

A single-target launcher may still need the multiplatform plugin. The desktop launcher applies

Kotlin Multiplatform for one jvm() target and nothing else, because the packaging plugin resolves

a runtime classpath under the multiplatform naming convention — that is what the build script

records. Confirm your packager finds a classpath before dropping to a plain JVM plugin.

Every conditional in the dependency graph must be repeated per launcher. A dependency chosen by

a Gradle property is chosen in *each* module that declares it — the Android launcher and the shared

library each carry their own branch. See foss-vs-proprietary-module-pairs.

The shrinker runs in the launcher while its rules file often stays with the library. The desktop

launcher points at rootDir.resolve("<shared-ui>/proguard-desktop-rules.pro"). That is fine, but it

means neither file mentions the other — grep for the rules file by name before assuming it is unused.

See r8-proguard-desktop-survival.

Do not let the launcher grow. Anything in it is, by definition, unshared — so measure it rather

than trusting the intent: find <android-launcher>/src -name '*.kt' | wc -l. The desktop launcher

here holds a single file; the Android one holds the application class, the activity and the

platform-only pieces that genuinely cannot move. A UI file in that list belongs in the library —

*unless* the platform only accepts that UI from an application module. The home-screen widget

composables here (MainAppWidget, TurntableWidget, WidgetIconButton) are the standing exception:

their receiver is declared in the application manifest, so the UI cannot move away from it.

Verifying it

# read each module's plugin list — overlap is expected; what must not overlap is what they own
grep -n -A12 '^plugins {' <shared-ui>/build.gradle.kts \
  <android-launcher>/build.gradle.kts <desktop-launcher>/build.gradle.kts

# nothing may depend on a launcher; anchor on the dependency forms or comments drown the result
grep -rnE 'project\(":(<android-launcher>|<desktop-launcher>)"\)|projects\.(<androidLauncher>|<desktopLauncher>)' \
  --include='*.kts' . | grep -v '/build/'

The second must return nothing at all — include() lines do not match it, so there is no

expected-hit list to remember.