Native vs. Cross-Platform ist die Wahl zwischen einer eigenen App für iPhone und für Android, jeweils in der Sprache der Plattform geschrieben, oder einer App, die größtenteils einmal geschrieben wird und mit einem Framework wie Flutter oder React Native auf beiden läuft. Nativ bietet die genaueste Anpassung an jedes Gerät und den frühesten Zugang zu neuen Funktionen; Cross-Platform bietet eine gemeinsame Codebasis, einen schnelleren Weg in beide Stores und meist geringere Kosten für Änderungen. Dieser Leitfaden erklärt jede Option, vergleicht fünf Ansätze nebeneinander, zeigt, wann welcher gewinnt, und endet mit einer Entscheidungsmethode und den Folgen für Kosten und Wartung.
Zuletzt aktualisiert: 26. Oktober 2026.
Was bedeuten „nativ“ und „Cross-Platform“ eigentlich?
Die Begriffe werden locker verwendet, deshalb hilft es, sie festzulegen, bevor man etwas vergleicht. Die Frage dahinter ist immer dieselbe: Wie viel der App wird einmal geschrieben und wie viel je Plattform?
Native Apps
Eine native App entsteht mit den Werkzeugen, die der jeweilige Plattformbetreiber bereitstellt: Swift und SwiftUI in Xcode für iPhone und iPad, dokumentiert auf Apples Entwickler-Website, und Kotlin mit Jetpack Compose in Android Studio für Android. Zwei Codebasen, zwei Sets an Fähigkeiten, und jede spricht direkt mit ihrem Betriebssystem, ohne Schicht dazwischen.
Cross-Platform-Apps
Eine Cross-Platform-App teilt den größten Teil ihres Codes zwischen iOS und Android. Die beiden Frameworks, von denen die meisten Auftraggeber hören, gehen unterschiedliche Wege. Flutter von Google zeichnet jedes Pixel der Oberfläche mit einer eigenen Rendering-Engine selbst und wird in Dart geschrieben. React Native von Meta wird in JavaScript oder TypeScript geschrieben und rendert echte Komponenten der Plattform, ein Button ist also der Button des Systems. Beide erlauben es, auf nativen Code zurückzugreifen, wenn eine Funktion ihn braucht.
Die zwei Optionen dazwischen
Kotlin Multiplatform teilt die Logik (Daten, Serveraufrufe, Geschäftsregeln) in Kotlin und lässt die Oberfläche auf jeder Seite nativ, oder teilt auch sie mit Compose Multiplatform. Eine Progressive Web App (PWA) ist eine Website, die sich auf dem Homescreen installieren lässt, offline funktioniert und Benachrichtigungen senden kann, ganz ohne App Store. Beide gehören in den Vergleich, weil sie für viele Projekte die bessere Antwort sind.
Kurz gesagt: Nativ bedeutet zwei Apps für zwei Plattformen. Cross-Platform bedeutet eine App, eine Hauptsprache und ein Framework, das übersetzt. Kotlin Multiplatform teilt den Motor und behält native Screens. Eine PWA umgeht die Stores ganz. Keine Option ist für jedes Projekt richtig.
Warum zählt diese Entscheidung mehr als der Framework-Streit?
Die meisten Artikel zu Flutter vs. React Native lesen sich wie ein Wettkampf. Für ein Unternehmen ist die nützlichere Frage, was die App in ihren ersten zwei Jahren leisten muss, wer sie wartet und wie oft sie sich ändern muss. Das Framework ergibt sich aus diesen Antworten.
Bei Odduel, einer Agentur für Kreation und Technologie in Barcelona und São Paulo, beginnen wir jedes Projekt der App-Entwicklung mit dieser Frage statt mit einer Lieblingstechnik. Formen Sie noch die erste Version, zeigt unser Leitfaden MVP entwickeln, wie Sie den Umfang kürzen, bevor Sie die Technik wählen; das klärt die Frage oft von selbst.
Native vs. Cross-Platform im direkten Vergleich
Die Tabelle vergleicht die fünf Ansätze in den Punkten, die ein Auftraggeber spürt, sobald die App live ist. Sie beschreibt typisches Verhalten; eine gut gebaute App in einer Spalte kann eine schlecht gebaute in einer anderen übertreffen.
| Nativ (Swift / Kotlin) | Flutter | React Native | Kotlin Multiplatform | PWA | |
|---|---|---|---|---|---|
| Performance | Am besten; direkter Zugriff auf das System | Sehr nah an nativ; eigene Rendering-Engine | Für die meisten Apps nah an nativ; aufwendige Animation braucht Sorgfalt | Native Oberfläche, geteilte Logik mit nativer Geschwindigkeit | Gut für Inhalte und Formulare; begrenzt bei aufwendiger Grafik |
| Treue der Oberfläche | Exakt Aussehen und Verhalten der Plattform | Pixelgleich auf beiden Plattformen; das Plattformgefühl muss eingebaut werden | Nutzt echte Komponenten der Plattform | Vollständig native Screens (oder geteilt mit Compose) | Web-Look; wirkt wie eine Website, wenn nicht sorgfältig gestaltet |
| Gerätefunktionen | Alle, ab dem ersten Tag einer neuen Betriebssystemversion | Die meisten über Plugins; neue Funktionen nach Plugin-Updates | Die meisten über Module; neue Funktionen nach Modul-Updates | Alle auf der nativen Seite | Eingeschränkt; je nach Browser und Plattform |
| Gemeinsamer Code | Keiner zwischen den Plattformen | Der größte Teil der App, Oberfläche eingeschlossen | Der größte Teil der App; etwas Logik lässt sich mit einer Web-App teilen | Logik geteilt, Oberfläche optional | Eine Codebasis für jedes Gerät und den Desktop |
| Fähigkeiten im Team | Zwei Spezialisierungen: iOS und Android | Dart und Flutter | JavaScript oder TypeScript, nah an Webteams | Kotlin, dazu iOS-Wissen für die Oberfläche | Webentwicklung |
| Wartung | Zwei Codebasen bei jeder Änderung aktualisieren | Eine Codebasis; Framework-Upgrades nachziehen | Eine Codebasis; Upgrades der Abhängigkeiten brauchen Disziplin | Gemeinsamer Kern, zwei schlanke Oberflächen | Eine Codebasis, keine Store-Prüfungen |
| App Stores | Ja | Ja | Ja | Ja | Nein (optionaler Eintrag in manchen Stores) |
Die Tabelle verschweigt einen Punkt, der ausgesprochen gehört: Der Abstand zwischen nativ und gutem Cross-Platform ist stark geschrumpft. Bei den meisten Business-Apps merken Nutzer nicht, welcher Ansatz verwendet wurde. Der Unterschied zeigt sich an den Rändern: neue Hardware, aufwendige Grafik, tiefe Systemintegration und die lange Phase der Wartung.
Wann lohnt sich native Entwicklung?
Nativ ist die richtige Wahl, wenn der Wert der App vom Gerät selbst abhängt. Wählen Sie es, wenn:
- die App auf neue oder ungewöhnliche Hardware angewiesen ist: Kameras mit eigener Bildverarbeitung, Sensoren, Gesundheitsdaten, Augmented Reality, Wearables oder Bluetooth-Zubehör;
- die App jede neue Funktion des Betriebssystems am Tag ihres Erscheinens übernehmen muss, etwa Widgets, Live-Aktivitäten oder neue Bildschirmformate;
- die Performance das Produkt ist: Audio oder Video in Echtzeit, Spiele, Karten mit aufwendiger Darstellung;
- die App vor allem auf einer Plattform lebt, sodass die zweite Codebasis klein ist oder noch nicht gebraucht wird.
Neue Geräteformate sind ein guter Test. Führt Apple eine neue Bildschirmform ein, können native Apps reagieren, sobald die Werkzeuge erscheinen, während Frameworks folgen, wenn ihre eigene Unterstützung kommt. Diesen Fall haben wir ausführlich betrachtet in iPhone-Duo-Apps: Was das faltbare iPhone ändert.
Wann lohnt sich Flutter?
Flutter passt zu Apps, bei denen der Markenauftritt wichtiger ist als die Konventionen der Plattform und dieselbe Oberfläche auf beiden Smartphones identisch erscheinen soll. Weil Flutter seine Oberfläche selbst zeichnet, gelangen ein eigenes Designsystem, individuelle Animation und eine starke visuelle Identität ohne Anpassung auf jeden Screen. Aus demselben Code erreicht es zudem Web und Desktop, was internen Tools und Dashboards hilft. Der Preis: Das Plattformgefühl (Scroll-Physik, Systemmenüs, Details der Barrierefreiheit) muss auf jeder Seite bewusst geprüft werden. Die offizielle Dokumentation finden Sie unter flutter.dev.
Wann lohnt sich React Native?
React Native passt zu Unternehmen, die bereits Webentwickler mit JavaScript oder TypeScript haben, oder eine React-Website, deren Logik und Menschen sich mit der App teilen lassen. Weil es die Komponenten der Plattform nutzt, fühlt es sich ohne Zusatzarbeit auf jedem Smartphone zu Hause an. Over-the-Air-Updates der JavaScript-Schicht können kleine Korrekturen im Rahmen der Store-Regeln beschleunigen. Der Preis ist eine größere Zahl an Abhängigkeiten von Drittanbietern, die aktuell gehalten werden müssen. Die Dokumentation des Projekts finden Sie unter reactnative.dev.
Wann lohnt sich Kotlin Multiplatform?
Kotlin Multiplatform passt zu Teams, die native Screens wollen, aber dieselben Geschäftsregeln nicht zweimal schreiben möchten. Es eignet sich für Apps mit komplexer Logik (Preise, Offline-Synchronisierung, Buchungen, Finanzberechnungen), bei denen ein einmal behobener Fehler überall behoben sein soll, und für eine bestehende Android-App, die iOS dazubekommt. Die Oberfläche bleibt vollständig nativ; für die Screens kostet es also mehr als Flutter oder React Native und insgesamt weniger als zwei getrennte native Apps.
Wann reicht eine Progressive Web App?
Eine PWA genügt, wenn die App vor allem aus Inhalten, Formularen, Bestellungen oder Kontoverwaltung besteht und wenn das eigentliche Hindernis ist, Menschen überhaupt zu einer Installation zu bewegen. Sie teilt sich die Codebasis mit der Website, aktualisiert sich in dem Moment, in dem Sie veröffentlichen, und braucht keine Store-Prüfung. Ihre Grenzen liegen beim Zugriff auf Gerätefunktionen, bei Hintergrundaufgaben und beim Verhalten von Push-Nachrichten, die je nach Browser und Plattform variieren. Viele Produkte starten als gut gebaute mobile Website, beweisen ihren Nutzen und rechtfertigen erst dann eine App im Store.
Wie entscheiden Sie zwischen nativ und Cross-Platform?
Die folgenden Schritte gehen wir mit unseren Kunden. Sie brauchen einen kurzen Workshop, kein Forschungsprojekt.
- Listen Sie auf, was die App in der ersten Version und im Jahr danach können muss. Markieren Sie jede Funktion, die das Gerät berührt: Kamera, Standort, Benachrichtigungen, Zahlungen, Sensoren, Offline-Nutzung.
- Markieren Sie die Funktionen, die neu oder plattformspezifisch sind. Liegen mehrere davon im Kern des Produkts, rücken nativ oder Kotlin Multiplatform nach oben.
- Entscheiden Sie, wie stark das Design jeder Plattform folgen muss. Eine starke eigene Identität spricht für Flutter; ein vertrautes Plattformgefühl für React Native oder nativ.
- Klären Sie, wer die App wartet. Ein internes Webteam spricht für React Native oder eine PWA; ein Android-Team für Kotlin Multiplatform; ein externer Partner sollte die Menschen und den Plan benennen.
- Prüfen Sie, ob Sie die Stores überhaupt brauchen. Lautet die Antwort „noch nicht“, kann eine PWA der erste Schritt sein.
- Bauen Sie einen riskanten Screen als Test. Ein kurzer technischer Spike an der schwierigsten Funktion sagt Ihnen mehr als jede Tabelle.
- Halten Sie die Entscheidung mit ihren Gründen schriftlich fest. Wer die App als Nächstes ändert, muss wissen, warum sie so gebaut wurde.
Wie Sie die Entwicklung steuern, zählt ebenso viel wie die Technik. Unser Vergleich Agil vs. Wasserfall bei App- und Website-Projekten erklärt, warum Apps meist zu einer festen Discovery-Phase mit anschließenden kurzen Entwicklungszyklen passen.
Was ändert sich bei Kosten und Wartung?
Die Kosten folgen dem Arbeitsumfang, und die Ansätze verschieben diese Arbeit, statt sie zu beseitigen. Preisspannen veröffentlichen wir nicht, weil sie vom Briefing abhängen; ein Festpreis folgt auf ein kurzes. Sagen können wir, wohin das Geld fließt.
Die Umsetzung
Zwei native Apps bedeuten zwei Umsetzungen der Oberfläche, zwei Testreihen und meist zwei Spezialisten. Cross-Platform teilt das meiste davon, die Umsetzung ist also typischerweise der kleinere Posten, auch wenn plattformspezifischer Feinschliff und native Module weiterhin Zeit brauchen. Kotlin Multiplatform liegt dazwischen. Eine PWA ist meist die kleinste Umsetzung, weil sie die Website erweitert.
Die Jahre nach dem Launch
Bei der Wartung zeigt sich die Entscheidung wirklich. Jede neue Betriebssystemversion, jede Änderung der Store-Regeln und jedes Sicherheitsupdate muss aufgefangen werden. Nativ bedeutet, das zweimal zu tun; Cross-Platform einmal, plus die Upgrades des Frameworks; eine PWA, den Browsern zu folgen. Über die Lebensdauer einer App übersteigt die Wartung oft die erste Entwicklung; fragen Sie also bei jedem Angebot, wie Updates, Upgrades und Store-Einreichungen geregelt sind.
Ein Angebot lesen
Ein gutes Angebot nennt den Ansatz und warum er gewählt wurde, trennt Design, Entwicklung, Tests und Store-Release und sagt, was der Support nach dem Launch umfasst. Liegen zwei Angebote weit auseinander, prüfen Sie, ob eines beide Plattformen, Tests der Barrierefreiheit und einen Wartungsplan enthält und das andere nicht.
Häufige Fragen zur Agenturwahl
Ist nativ immer schneller als Cross-Platform?
Nativ hat den direktesten Zugriff auf das Gerät und setzt damit die Obergrenze der Performance. In der Praxis laufen Apps mit Flutter und React Native für die meisten geschäftlichen Zwecke flüssig, etwa Listen, Formulare, Bestellungen und Konten. Der Abstand zeigt sich bei aufwendiger Grafik, Medien in Echtzeit und komplexer Animation; dort lohnt sich nativ oder sorgfältige Optimierung.
Flutter vs. React Native: Was sollte ich wählen?
Wählen Sie Flutter, wenn ein starkes eigenes Design auf beiden Plattformen identisch aussehen soll und Sie gern in Dart arbeiten. Wählen Sie React Native, wenn Sie Entwickler für JavaScript oder TypeScript haben, eine React-Website, mit der sich Logik teilen lässt, oder die Komponenten jeder Plattform nutzen wollen. Beide sind ausgereift, weit verbreitet und können nativen Code aufrufen.
Kann ich später von Cross-Platform auf nativ wechseln?
Ja, aber meist ist das eine Neuentwicklung der Oberfläche statt einer Migration. Geschäftslogik, Designs, Inhalte und Backend-Dienste bleiben erhalten; die Screens nicht. Ein häufiger Weg: mit Cross-Platform starten, lernen, was Nutzer wirklich brauchen, und nur die Teile neu bauen, die native Performance oder Gerätezugriff verlangen.
Akzeptieren Apple und Google Cross-Platform-Apps?
Ja. Beide Stores akzeptieren Apps, die mit Flutter, React Native und Kotlin Multiplatform gebaut sind, und prüfen sie nach denselben Richtlinien wie native Apps. Entscheidend ist, dass die App sich gut verhält, Datenschutzregeln einhält und echten Nutzen bietet. Eine dünne Hülle um eine Website ohne app-typische Funktionen wird eher abgelehnt.
Ist eine PWA eine echte Alternative zu einer App?
Für Inhalte, Bestellungen, Buchungen und Kontoverwaltung oft ja: Sie lässt sich auf dem Homescreen installieren, funktioniert offline und kostet eine Codebasis. Schwächer ist sie beim tiefen Gerätezugriff, bei Hintergrundarbeit und manchem Verhalten von Benachrichtigungen, das je nach Browser und Plattform variiert. Sie ist ein solider erster Schritt, wenn Sie nicht sicher sind, ob eine Präsenz im App Store nötig ist.
Wägen Sie nativ gegen Cross-Platform für ein neues Produkt oder einen Neubau ab, führt der schnellste Weg über ein kurzes Briefing: was die App können muss, wer sie wartet und wann sie bei den Menschen sein soll. Im Rahmen unserer App-Entwicklung sagen wir Ihnen, welcher Ansatz passt und warum. Sprechen Sie mit uns über Ihre App.
