KMP und Dynamic Delivery strategisch einsetzen

Kotlin Multiplatform und Dynamic Delivery sind keine Startpunkte für eine neue Lern-App. Sie sind Strategien für Produkte, die wachsen: mehr Plattformen, mehr Features, größere Teams, längere Release-Zyklen. Du solltest sie bewerten, wenn gemeinsame Logik, modulare Auslieferung und Wartbarkeit wichtiger werden als schnelle lokale Änderungen.

Was ist das?

Kotlin Multiplatform, kurz KMP, bedeutet: Du schreibst bestimmte Teile deiner App-Logik einmal in Kotlin und verwendest sie auf mehreren Plattformen, zum Beispiel Android und iOS. Typische Kandidaten sind fachliche Regeln, Validierung, Datenmodelle, Netzwerk- und Repository-Logik. Android-spezifische UI, Compose-Code, Permissions oder Plattform-APIs bleiben dagegen meist im Android-Teil.

Dynamic Delivery beschreibt, wie Android App Bundles App-Inhalte gezielter ausliefern. Mit Dynamic Feature Modules kann eine App Funktionen modular bereitstellen, statt alles immer im Basis-APK zu installieren. Das ist interessant, wenn eine App groß ist oder bestimmte Funktionen nur von wenigen Nutzern gebraucht werden.

Das gemeinsame Thema ist Strategie: Du entscheidest, welche Logik geteilt wird und welche Features wann installiert werden. Das hilft bei Skalierung, kann aber Architektur, Build, Testing und Release-Prozesse deutlich anspruchsvoller machen.

Wie funktioniert es?

Bei KMP denkst du in drei Schichten. Im gemeinsamen Modul liegt Code, der ohne Android-SDK funktioniert. Dort verwendest du Kotlin, Coroutines, Flow und plattformneutrale Modelle. Wenn eine Funktion Plattformwissen braucht, definierst du eine gemeinsame Schnittstelle und implementierst sie in der jeweiligen Plattform. Das mentale Modell ist: gemeinsame Fachlogik ja, gemeinsame Plattformillusion nein.

Im Android-Alltag landet KMP oft unter einer bestehenden Architektur. Dein Android-Modul ruft Use Cases oder Repositories aus dem Shared-Modul auf. ViewModels, Compose-Screens und Navigation bleiben Android-nah. So kann die UI die gewohnten Jetpack-Bausteine nutzen, während Geschäftsregeln nicht doppelt geschrieben werden.

Dynamic Delivery funktioniert anders. Hier zerlegst du die Android-App in ein Basismodul und optionale Feature-Module. Das Basismodul enthält alles, was beim Start sicher vorhanden sein muss: App-Entry, grundlegende Navigation, zentrale Abhängigkeiten und stabile Verträge. Ein dynamisches Feature enthält eine abgeschlossene Funktion, etwa einen selten genutzten Scanner, eine große Medienfunktion oder einen Bereich für bestimmte Nutzergruppen.

Wichtig ist die Abhängungsrichtung. Das Basismodul darf nicht tief in konkrete Implementierungen optionaler Features greifen. Besser sind klare Routen, Interfaces oder registrierte Einstiegspunkte. Sonst wird das Modul zwar technisch dynamisch, bleibt aber fachlich eng gekoppelt.

In der Praxis

Eine sinnvolle Regel lautet: Teile nur stabile Logik mit KMP und liefere nur wirklich optionale Funktionen dynamisch aus. Wenn sich ein Feature täglich ändert, stark von Android-APIs abhängt oder noch fachlich unklar ist, erzeugt KMP oft mehr Abstimmung als Nutzen. Wenn ein Feature für fast alle Nutzer direkt beim Start gebraucht wird, bringt Dynamic Delivery wenig.

Ein kleines KMP-Modul kann zum Beispiel eine Preisregel enthalten:

data class CartItem(val priceCents: Int, val quantity: Int)

class CartCalculator {
    fun totalCents(items: List<CartItem>): Int {
        return items.sumOf { it.priceCents * it.quantity }
    }

    fun qualifiesForFreeShipping(totalCents: Int): Boolean {
        return totalCents >= 5_000
    }
}

Dieser Code braucht kein Android-SDK. Du kannst ihn in JVM-Tests prüfen und später auch auf einer anderen Plattform verwenden. In Android würdest du ihn aus einem ViewModel aufrufen und das Ergebnis in Compose anzeigen. Die UI bleibt austauschbar, die Regel bleibt eindeutig testbar.

Bei Dynamic Delivery kann die Entscheidung so aussehen: Eine App hat einen großen AR-Produktviewer, der viele Ressourcen mitbringt. Nur wenige Nutzer öffnen ihn. Dann kann ein dynamisches Feature sinnvoll sein. Die Basis-App zeigt den Einstiegspunkt, prüft die Verfügbarkeit und startet die Installation, bevor der Feature-Screen geöffnet wird.

Eine typische Stolperfalle ist zu frühe Modularisierung. Wenn du Dynamic Features einführst, bevor die fachlichen Grenzen klar sind, verteilst du instabile Logik auf mehrere Gradle-Module. Danach werden Refactorings langsamer, Builds komplexer und Fehler in der Auslieferung schwerer zu debuggen. Bei KMP ist die häufige Falle, Android-Code in das Shared-Modul drücken zu wollen. Sobald du überall Plattform-Ausnahmen baust, ist der gemeinsame Code nicht mehr wirklich sauber.

Prüfe solche Strategien deshalb im Code-Review mit konkreten Fragen: Ist die geteilte Logik stabil und gut getestet? Gibt es klare Modulgrenzen? Kann ein Entwickler das Feature lokal bauen, testen und debuggen? Ist der Release-Prozess für App Bundles und optionale Module dokumentiert? Wenn eine dieser Fragen offen bleibt, ist die Strategie noch nicht reif.

Fazit

KMP und Dynamic Delivery sind Werkzeuge für skalierende Produkte, nicht für jede kleine App. Du gewinnst gemeinsame Logik, kleinere Auslieferungseinheiten und klarere Verantwortlichkeiten, bezahlst aber mit mehr Architektur- und Release-Aufwand. Übe das Thema, indem du eine kleine fachliche Regel in ein plattformneutrales Kotlin-Modul verschiebst, Tests dafür schreibst und danach im Review erklärst, warum ein Feature in die Basis-App oder in ein dynamisches Modul gehört.