Zum Inhalt springen

Fallstudie: Kotlin Multiplatform für eine Vorsorge-App mit 150'000 Nutzern

15. März 2025 von Matthias Ernst
Kotlin Multiplatform Fallstudie Mobile-Entwicklung Finanzdienstleistungen

Die Herausforderung

Eine grosse Schweizer Bank musste eine Säule-3a-App für rund 150'000 aktive Nutzer auf iOS und Android weiterentwickeln. Die besondere Herausforderung: Ein kleines Engineering-Team von nur zwei Entwicklern war für zuverlässige Releases auf beiden Plattformen verantwortlich.

Matthias Ernst und Marc Rymann von Ernst & Conte leiteten das Projekt. Das Ziel: zuverlässige Releases auf beiden Plattformen mit zwei Personen, in der Qualität, die ein reguliertes Finanzprodukt verlangt.

Warum Kotlin Multiplatform?

Zwei getrennte Codebasen mit einem Zweierteam zu pflegen führte zu den erwartbaren Problemen: doppelte Logik, unterschiedliches Verhalten auf den Plattformen und ein Testaufwand, der sich nur schlecht skalieren liess.

Zuerst teilten wir die Geschäftslogik mit Kotlin Multiplatform (KMP), während die Benutzeroberflächen plattformspezifisch blieben. Nachdem sich dieser Ansatz bewährt hatte, erweiterten wir ihn mit Compose Multiplatform auf die Präsentationsschicht. So entstand eine gemeinsame Codebasis für iOS und Android.

Schrittweise Migration

Wir haben die App nicht über Nacht neu geschrieben. Die Migration erfolgte bewusst Bildschirm für Bildschirm:

  1. Einen einzelnen Proof-of-Concept-Screen mit Compose Multiplatform entwickeln.
  2. Ihn zusammen mit den bestehenden nativen Screens im produktiven Betrieb validieren.
  3. Den nächsten Screen migrieren und den Ablauf wiederholen.

Mit jeder Iteration wurde die Codebasis einfacher und die Angriffsfläche für plattformspezifische Fehler kleiner.

Was sich geändert hat

  • Jedes Feature wird einmal gebaut. Eine Änderung kommt im selben Release auf iOS und Android, statt zweimal implementiert und zweimal eingeplant zu werden.
  • Die Plattformen driften nicht mehr auseinander. Mit einer Implementierung gibt es keine zweite, die aus dem Tritt geraten kann. Genau daher kamen die meisten plattformspezifischen Fehler.
  • Zwei Personen prüfen eine Codebasis. Niemand ist mehr «der iOS-Entwickler»: Reviews, Architekturentscheide und Wissen umfassen die ganze App.

Was wir gelernt haben

Zwei Erkenntnisse lassen sich auf jede KMP-Migration übertragen:

  1. Klein anfangen und früh validieren. Wählen Sie einen Screen mit geringem Risiko, beweisen Sie den Ansatz im produktiven Betrieb und erweitern Sie danach den Umfang. Alles auf einmal zu migrieren schafft unnötige Risiken.
  2. Kontinuierlich refaktorieren. Jeder migrierte Screen ist eine Chance, technische Schulden abzubauen. Nutzen Sie sie, denn der Gewinn für die langfristige Wartbarkeit summiert sich.

Wie es weitergeht

Die Migration läuft weiter. Das Ziel ist eine vollständig gemeinsame Codebasis: Die letzten nativen Komponenten entfallen mit der Weiterentwicklung von Compose Multiplatform, und später soll dieselbe Codebasis auch die Webanwendung tragen.


Wenn Ihr Team vor derselben Einschränkung steht, sprechen Sie mit uns.