Drei Angebote, ein Rätsel
Ob eine App oder eine Webanwendung der richtige Weg ist, haben wir in einem früheren Artikel beschrieben. Nun haben Sie sich entschieden: Ihr Projekt braucht eine App. Nicht eine Webanwendung im Browser, sondern eine Anwendung, die auf dem Gerät installiert wird. Als nächstes holen Sie Angebote ein, doch die Zahlen verwirren.
Ein Dienstleister bietet eine App für beide Plattformen an. Ein anderer bietet zwei separate Apps, für fast den doppelten Preis. Ein dritter schlägt etwas vor, das nach einem Kompromiss klingt: geteilte Logik, aber native Oberflächen. Alle behaupten, den besten Weg zu kennen, aber die Angebote beschreiben unterschiedliche Architekturen. Und diese Architektur bestimmt, wie wartbar und erweiterbar Ihre App in drei, fünf oder sieben Jahren noch ist.
Was „nativ“ und „cross-platform“ bedeutet
Wenn Entwickler eine App nativ bauen, entsteht für jedes Betriebssystem eine eigene Anwendung. Eine für iPhones, geschrieben in Apples Programmiersprache Swift. Eine für Android-Geräte, geschrieben in Kotlin. Zwei Teams oder zumindest zwei Spezialisierungen, zwei Codebasen (der gesamte Programmcode einer App), zwei Ergebnisse. Jede App nutzt die Werkzeuge, die der jeweilige Hersteller für sein System bereitstellt, direkt und ohne Umweg.
Cross-platform bedeutet: Eine weitgehend gemeinsame Codebasis erzeugt Apps für beide Systeme gleichzeitig. Die bekanntesten Werkzeuge dafür sind Flutter von Google und React Native von Meta. Entwickler schreiben den Großteil des Codes einmal, und ein Framework (ein Baukasten, auf dem die App aufbaut) übersetzt ihn für beide Plattformen.
Und dann gibt es einen dritten Ansatz, der sich nicht sauber in eine der beiden Kategorien einordnen lässt: Kotlin Multiplatform von JetBrains. Die Idee dahinter: Die Geschäftslogik, also Berechnungen, Datenverarbeitung und Kommunikation mit Servern, wird einmal geschrieben und geteilt. Die Benutzeroberfläche bleibt für jede Plattform nativ. Das klingt nach dem Besten aus beiden Welten. Ob das stimmt, hängt jedoch vom Projekt ab.
Native Entwicklung: der Standard in beiden Stores
Native Entwicklung ist der Normalfall, nicht die Ausnahme. Laut einer Analyse von Appfigures waren 2024 rund 80 % aller Apps in beiden Stores nativ entwickelt. Der Grund liegt in der Architektur: Native Apps arbeiten ohne Umweg mit dem Betriebssystem. Jede neue Funktion, die Apple oder Google veröffentlicht, steht sofort zur Verfügung. Es gibt keine Zwischenschicht, die erst aktualisiert werden muss.
Dazu kommt die Nutzererfahrung. iOS- und Android-Nutzer erwarten unterschiedliches Verhalten: Wie Navigation funktioniert, wie Gesten interpretiert werden, wie Animationen sich anfühlen. Native Apps folgen diesen Konventionen von Haus aus. Cross-platform-Frameworks müssen sie nachbauen oder ignorieren.
Swift und Kotlin haben eine besondere Rückendeckung. Apple führte Swift 2014 ein als Sprache für die gesamte Apple-Plattform. Google erklärte Kotlin 2019 zur bevorzugten Sprache für Android. Beide Unternehmen pflegen diese Sprachen, weil ihre gesamten App-Ökosysteme darauf aufbauen. Kein Cross-platform-Framework hat diese strukturelle Absicherung.
Die langlebigsten, umsatzstärksten Apps der Welt sind nativ entwickelt. Banking, Gesundheit, Logistik. Überall dort, wo Zuverlässigkeit und Lebensdauer zählen, setzen Unternehmen auf die offiziellen Plattform-Sprachen. Dazu kommt ein praktischer Vorteil: Swift- und Kotlin-Entwickler bilden die größte Gruppe mobiler Entwickler weltweit. Wenn Sie in drei Jahren das Team wechseln müssen, finden Sie Entwickler, die den Code sofort verstehen. Bei einem spezialisierten Framework brauchen Sie Spezialisten für genau dieses Framework.
Cross-platform: eine Codebasis, zwei Plattformen
Wenn native Entwicklung so stark ist, warum gibt es Alternativen? Weil nicht jedes Projekt diese Tiefe braucht.
Eine Funktion wird einmal gebaut und erscheint auf beiden Plattformen gleichzeitig. Ein Fehler wird einmal behoben. Zwei Teams müssen nicht dieselbe Funktion unterschiedlich interpretieren und synchron halten. Das reduziert Komplexität und Fehlerquellen über die gesamte Lebensdauer der App. Solange Ihre App keine tiefe Hardware-Integration braucht, liefern Flutter oder React Native bei sorgfältiger Umsetzung Ergebnisse, die sich von nativen Apps kaum unterscheiden lassen.
Ganz ohne plattformspezifische Anpassungen kommt allerdings auch eine Cross-platform-App nicht aus. An bestimmten Stellen verhalten sich iOS und Android unterschiedlich, und dort braucht das Team Wissen über das jeweilige Betriebssystem. In der Praxis arbeitet ein Cross-platform-Team deshalb mit drei Wissensgebieten: dem Framework selbst, der iOS-Plattform und der Android-Plattform.
Die Zahlen zeigen, dass der Ansatz für viele Projekte aufgeht. Eine Analyse von Appfigures von Dezember 2025 hat die 10.000 meistgeladenen iOS-Apps untersucht: React Native steckt in rund 14 % dieser Apps, Flutter in rund 12 %. „Steckt in“ heißt hier: Das Framework ist im App-Bundle enthalten, nicht zwingend, dass die gesamte App darauf aufbaut. Eine App kann React Native für einen einzelnen Bildschirm nutzen und trotzdem gezählt werden. Das sind keine Nischenprodukte.
Cross-platform: die Grenzen der gemeinsamen Codebasis
Cross-platform-Frameworks wie Flutter und React Native setzen eine Übersetzungsschicht zwischen den App-Code und das Betriebssystem. Sie funktioniert für die meisten Anwendungsfälle hervorragend. Aber sie hat Grenzen.
Wenn Ihre App intensiv mit der Hardware arbeiten muss, stoßen Entwickler an Stellen, an denen die Übersetzungsschicht nicht ausreicht. Bluetooth-Geräte ansteuern, Augmented Reality, komplexe Animationen, Hintergrundprozesse, die zuverlässig über Stunden laufen. Für diese Teile schreiben Entwickler dann doch Code, der nur auf einer der beiden Plattformen läuft. Das ist möglich, erhöht aber die Komplexität und relativiert den Vorteil.
Der zweite Nachteil wird oft übersehen, weil er erst nach Jahren sichtbar wird. Flutter nutzt die Programmiersprache Dart, React Native nutzt JavaScript. Beides sind eigenständige Welten mit eigenen Werkzeugen und Entwicklergemeinschaften, die mit der nativen Welt von iOS und Android wenig gemeinsam haben. Solange das Framework gepflegt wird und Ihre Anforderungen sich innerhalb seiner Möglichkeiten bewegen, ist das kein Problem. Aber wenn Sie eines Tages Teile der App nativ umbauen müssen oder das Framework an Bedeutung verliert, stehen Sie möglicherweise vor einem Technologiewechsel. Das Budget, das dann in den Umbau fließt, steht nicht für neue Funktionen oder Verbesserungen zur Verfügung.
Kotlin Multiplatform: geteilte Logik, native Oberfläche
Die beiden beschriebenen Nachteile, die Übersetzungsschicht und die Abhängigkeit von einer frameworkeigenen Sprachwelt, betreffen den dritten Ansatz in geringerem Maß. Kotlin Multiplatform verfolgt eine andere Philosophie. Statt die gesamte App in einem Framework einzuschließen, entscheiden Entwickler frei, welche Teile geteilt werden und welche nativ bleiben. Dieses Verhältnis lässt sich pro Projekt und sogar pro Bildschirm anpassen. Mit Compose Multiplatform lassen sich auch Teile der Benutzeroberfläche übergreifend entwickeln. Bei Flutter oder React Native lebt die App im Wesentlichen im Framework. Wer Teile davon herauslösen will, baut gegen die Architektur.
Der entscheidende Unterschied liegt in der Sprache selbst. Kotlin ist die offizielle Programmiersprache für Android. Wer Kotlin Multiplatform einsetzt, schreibt die geteilte Logik in derselben Sprache, in der auch die native Android-App entsteht. Es gibt keinen Bruch. Wenn Ihre App wächst und ein Teil doch vollständig nativ werden muss, bleibt der Code in derselben Welt. Für die iOS-Seite entsteht die Oberfläche weiterhin in Swift.
Unternehmen wie Netflix, Philips und VMware nutzen Kotlin Multiplatform, um Geschäftslogik zwischen ihren nativen iOS- und Android-Apps zu teilen. JetBrains dokumentiert diese und weitere Praxisbeispiele auf der Kotlin-Website. Die Appfigures-Analyse von Dezember 2025 zeigt, wie sich die drei Frameworks unter den Top-10.000-iOS-Apps verteilen: Kotlin Multiplatform steckt in nur 2 % dieser Apps, aber diese 2 % vereinen 14 % der Downloads und 27 % des Umsatzes aller Apps, die eines der drei Frameworks im Bundle haben. Auch hier gilt: Diese Apps nutzen Kotlin Multiplatform, sie sind nicht zwingend vollständig damit gebaut. Dass die umsatzstärksten Apps dennoch überproportional oft KMP einsetzen, ist bemerkenswert. Zum Vergleich: React Native kommt auf 47 % der Downloads und 41 % des Umsatzes, Flutter auf 38 % der Downloads und 32 % des Umsatzes. Die wenigen Kotlin-Multiplatform-Apps werden überdurchschnittlich oft heruntergeladen und generieren überproportional viel Umsatz.
Die wichtigsten Bausteine für Netzwerk, Datenbank und Datenverarbeitung sind ausgereift und produktionserprobt. Lücken gibt es bei spezialisierten Drittanbieter-Diensten, die noch keine fertige Anbindung an Kotlin Multiplatform anbieten, und bei den Entwicklungswerkzeugen auf der iOS-Seite, die weniger komfortabel sind als auf der Android-Seite. Diese Lücken werden kleiner, aber sie existieren, und wir wollen sie nicht verschweigen.
Warum wir auf nativ und Kotlin Multiplatform setzen
Wir entwickeln seit 2008 native Apps. In dieser Zeit haben wir erlebt, wie Frameworks auftauchen und wieder verschwinden, während die nativen Plattformen Bestand haben. Aus dieser Erfahrung heraus empfehlen wir je nach Projekt einen von zwei Wegen: vollständig native Entwicklung in Swift und Kotlin, wenn die App maximale Kontrolle über beide Plattformen braucht. Oder Kotlin Multiplatform, wenn sich Geschäftslogik sinnvoll teilen lässt, ohne bei der Oberfläche Kompromisse einzugehen. Beide Wege bauen auf denselben Sprachen und Werkzeugen auf. Der Übergang zwischen ihnen ist fließend.
Flutter und React Native sind ausgereift und haben ihre Berechtigung. Für Projekte mit kurzen Lebenszyklen oder wenn ein Team bereits tief in diesen Technologien steckt, können sie der richtige Weg sein. Wir sind überzeugt, dass eine App, deren Code auf den offiziellen Sprachen der jeweiligen Plattform basiert, langfristig besser geschützt ist. Sie bleibt wartbar nach Jahren. Sie bleibt erweiterbar, ohne auf die Roadmap eines Frameworks angewiesen zu sein. Das ist jedoch nur unsere Perspektive aus 18 Jahren nativer Entwicklung, keine allgemeingültige Wahrheit.
Eine Entscheidung, die bleibt
Frameworks werden weiterentwickelt, abgekündigt oder von neuen abgelöst. Teams wechseln. Anforderungen wachsen. Die Architektur, die Sie am Anfang gewählt haben, lässt sich nur mit erheblichem Aufwand nachträglich ändern. Sie bestimmt, wie flexibel Sie auf all das reagieren können.
Die Angebote auf Ihrem Tisch bilden genau diese Unterschiede ab, auch wenn sie auf den ersten Blick nur nach unterschiedlichen Zahlen aussehen. Wenn Sie die Architektur hinter den Angeboten verstehen, treffen Sie mehr als eine Technologieentscheidung. Sie treffen eine Entscheidung über die Zukunftsfähigkeit Ihres Produkts.