Cross-Platform-App-Entwicklung 2026: eine Codebasis für iOS und Android

Cross-Platform-Entwicklung für Mobile bedeutet, eine einzige Codebasis zu schreiben, die auf iOS und Android läuft, oft auch im Web, statt einer App in Swift für das iPhone und einer zweiten in Kotlin für Android. 2026 ist das kein Kompromiss mehr, der Prototypen vorbehalten wäre: Die beiden meistgenutzten Frameworks, Flutter und React Native, treiben Apps von Google, Meta, Microsoft und Shopify an, und ein dritter Ansatz, Kotlin Multiplatform, ist inzwischen stabil genug, dass Google ihn Android-Teams empfiehlt.

Die eigentliche Frage hat sich verschoben. Sie lautet nicht mehr „Cross-Platform oder nativ?“, sondern „welche Art von Cross-Platform, für welches Team?“. Die vier Familien zeichnen den Bildschirm auf vier verschiedene Arten, und allein dieser Umstand entscheidet über Aussehen, Performance, Bewerberpool und die Wartung, auf die Sie sich einlassen. Dieser Leitfaden stellt sie nebeneinander, mit Zahlen, wo es Zahlen gibt, und gibt Ihnen anschließend einen Entscheidungspfad.

Was Cross-Platform 2026 bedeutet

Die verlässlichsten Zahlen zur Verbreitung liefert der Stack Overflow Developer Survey, der rund 45.000 Entwickler fragt, welche Frameworks sie im vergangenen Jahr genutzt haben. Mobile Frameworks sind nur ein kleiner Ausschnitt aller Entwickler, aber die Rangfolge innerhalb dieses Ausschnitts ist stabil.

Kotlin Multiplatform fehlt in dieser Liste, weil die Umfrage es nicht als Antwort angeboten hat. Es zählt trotzdem: JetBrains hat im Mai 2025 Compose Multiplatform 1.8 veröffentlicht, womit die geteilte UI für iOS stabil wurde, und Google hat den Ansatz zum Teilen von Geschäftslogik zwischen Android und iOS ausdrücklich empfohlen.

Drei Dinge haben sich geändert, seit Sie vielleicht zuletzt hingesehen haben. React Native hat seine alte asynchrone Bridge mit der New Architecture abgeschafft, die mit Version 0.85 im April 2026 zum Standard für das gesamte Ökosystem wurde. Flutter hat seine Rendering-Engine durch Impeller ersetzt. Und der Ansatz „Web in der Hülle“ hat sich in zwei Zweige geteilt: Progressive Web Apps, die die Stores komplett auslassen, und Hüllen wie Capacitor, die eine Web-App in einen Store-Eintrag bringen. Wenn Ihre Shortlist bereits auf die beiden Marktführer geschrumpft ist, geht unser Direktvergleich React Native oder Flutter auf genau diese Wahl tiefer ein.

Vier Familien, vier Arten, einen Pixel zu zeichnen

Die Namen verdecken den entscheidenden Unterschied, nämlich was aus Ihrem Code auf dem Gerät wird.

React Native, mit Expo

Ihre React-Komponenten werden zu echten nativen Views: ein UIKit-Control auf iOS, eine Android-View auf Android. Die App sieht aus und verhält sich wie die Plattform, weil sie die Plattform nutzt. Der Talentpool ist der größte der vier, da jeder JavaScript- oder TypeScript-Entwickler beitragen kann, und das React-Native-Team selbst empfiehlt inzwischen den Start mit dem Framework Expo, das Navigation, eine Standardbibliothek von Geräte-APIs und Cloud-Builds ergänzt. Diese Schicht erklären wir in Was ist Expo?.

Flutter

Flutter geht die entgegengesetzte Wette ein. Es verwendet überhaupt keine nativen Widgets: Seine Impeller-Engine zeichnet jeden Pixel selbst, sodass die App auf beiden Plattformen identisch aussieht und ein eigenes Design günstig umzusetzen ist. Der Preis ist Dart, eine Sprache, die Ihr Team wahrscheinlich erst lernen muss, und eine UI, die Plattformkonventionen nur so weit folgt, wie Flutters Widget-Bibliothek sie nachbildet. Google meldete bereits 2023 mehr als eine Million mit Flutter ausgelieferte Apps.

Kotlin Multiplatform

KMP teilt die Teile, die Nutzer nie sehen: Netzwerk, Datenmodelle, Geschäftsregeln, einmal in Kotlin geschrieben und für beide Plattformen kompiliert. Die Screens bleiben nativ (SwiftUI auf iOS, Jetpack Compose auf Android) oder lassen sich mit Compose Multiplatform ebenfalls teilen, das auf iOS seit Compose Multiplatform 1.8 stabil ist. Es ist der natürliche Weg für ein Unternehmen, das bereits Android-Entwickler hat und eine iOS-App ohne zweite Logikschicht will.

Capacitor und Ionic: das Web in einer Hülle

Ihre bestehende Web-App läuft in einer WebView, und Plugins geben ihr Zugriff auf Kamera, Benachrichtigungen oder Dateisystem. Es ist der schnellste Weg von einer Website zu einem Store-Eintrag und der schwächste beim Bediengefühl: Scrollen, Gesten und Übergänge stammen vom Browser, nicht von der Plattform. Apple lehnt zudem Apps ab, die „im Wesentlichen eine verpackte Website“ ohne nativen Mehrwert sind, die Hülle muss sich ihren Platz also mit echten Gerätefunktionen verdienen.

Die Abwägungen, die wirklich entscheiden

Kosten: ein Team, aber die Plattformsteuer bleibt

Die Ersparnis ist real und vor allem organisatorisch: ein Team, ein Backlog, ein Release statt zwei, die auseinanderdriften. Was Cross-Platform nicht beseitigt, ist alles, was die Plattformen ihrerseits verlangen. Sie brauchen weiterhin eine Mitgliedschaft im Apple Developer Program, ein Google-Play-Console-Konto, irgendwo einen Mac zum Signieren der iOS-Builds (Ihren eigenen oder einen in der Cloud), und Sie durchlaufen weiterhin beide Store-Prüfungen mit denselben Regeln wie eine native App.

Performance: ausreichend für Produkte, nativ für Extreme

Für die überwältigende Mehrheit der Apps, Formulare, Listen, Karten, Chat, Zahlungen, Kamera und Benachrichtigungen, sind alle vier Familien schnell genug, dass Nutzer keinen Unterschied bemerken. Nativ gewinnt weiterhin an den Extremen: 3D und Augmented Reality, Audio- und Videoverarbeitung in Echtzeit, Home-Screen-Widgets und tiefe Integrationen ins Betriebssystem sowie Spiele. Gehört Ihr Produkt dazu, ist die Entscheidung für Sie bereits gefallen.

Wartung: das jährliche Upgrade, das niemand einplant

Jeden September veröffentlichen Apple und Google neue Betriebssysteme, und jedes Framework liefert Upgrades nach, um Schritt zu halten. Expo veröffentlicht drei SDK-Versionen pro Jahr, Flutter erscheint vierteljährlich, Kotlin Multiplatform folgt dem Kotlin-Rhythmus, und eine verpackte Web-App entwickelt sich mit dem Web weiter. Nichts davon ist schwer, wenn Sie am Ball bleiben; alles davon wird schmerzhaft, wenn Sie zwei Jahre verstreichen lassen. Setzen Sie ein Upgrade pro Quartal in die Roadmap, und die Kosten bleiben klein.

Wie Sie wählen: ein Entscheidungsleitfaden

Gehen Sie vom Team aus, das Sie haben, nicht von Benchmarks. Das Framework, das ein Team besetzen und warten kann, schlägt das Framework, das einen synthetischen Test gewinnt.

Gehen Sie dann vor der Festlegung eine kurze Checkliste durch:

• 1. Listen Sie die Gerätefunktionen auf, die Sie brauchen. Kamera, Push-Benachrichtigungen, Standort im Hintergrund, Bluetooth, Zahlungen. Prüfen Sie, dass es für jede ein gepflegtes Modul im Framework gibt, das Sie in Betracht ziehen.
• 2. Zählen Sie die Personen, die es warten werden. Eine Person kann eine Expo-App am Leben halten; ein KMP-Setup mit nativen Screens braucht mindestens eine iOS- und eine Android-Hand.
• 3. Schätzen Sie die Lebensdauer. Eine dreimonatige Kampagnen-App und ein Produkt für fünf Jahre verdienen nicht dieselbe Architektur.
• 4. Prototypen Sie in einer Woche. Bauen Sie die zwei schwierigsten Screens in Ihrem Favoriten und bringen Sie sie auf ein echtes Smartphone. Die meisten Zweifel verschwinden an diesem Punkt.
• 5. Planen Sie die Release-Pipeline. Signierung, Cloud-Builds, TestFlight und interne Test-Tracks. Entscheiden Sie das jetzt, nicht in der Launch-Woche.

Und wenn Sie gar kein Mobile-Team haben

Der häufigste Fall für Gründer oder kleine Unternehmen lautet nicht „welches Framework?“, sondern „wer soll das schreiben?“. Ein AI App Builder beantwortet diese Frage mit einem echten Cross-Platform-Stack statt einer Vorlage. Auf Cadrant ist ein natives Mobile-Projekt eine Expo- und React-Native-Anwendung: Sie beschreiben die App in einfacher Sprache, sehen sie in einem Smartphone-Rahmen in der Vorschau, testen sie mit Expo Go auf Ihrem eigenen Gerät und veröffentlichen sie dann über Ihre eigenen Expo- und Apple-Konten im App Store. Wenn kein Store-Eintrag nötig ist, liefert derselbe Builder stattdessen eine Progressive Web App oder eine WebView-App. Die Seite Mobile-App-Baukasten beschreibt die drei Optionen im Detail.

Cross-Platform ist 2026 eine Familie ausgereifter Optionen, keine Abkürzung. Wählen Sie die, die Ihr Team verantworten kann, budgetieren Sie die Plattformkosten, die kein Framework beseitigt, und tragen Sie das jährliche Upgrade in den Kalender ein. Der Rest ist Produktarbeit.