Ich habe Production-Apps in Swift, in Kotlin, in Flutter gebaut und viel in React Native geerbt. Das ist kein Benchmark-Post. Es ist die Antwort, die ich Foundern gebe, die diese Woche entscheiden müssen und das nicht zwei Jahre lang überdenken möchten.
Die kurze Version
- Flutter, wenn Sie zwei Plattformen, ein Team und viel Custom UI brauchen. Bestes Kosten-zu-Qualität-Verhältnis für die meisten Produkte 2026.
- Native, wenn die App das Geschäft ist, oder Sie auf Plattform-Features angewiesen sind, die am Launch-Tag schiffbar sind.
- React Native, wenn Sie bereits ein starkes React-Team und eine Web-App zum Teilen von Logik haben. Sonst ist der Fall schwächer als zuvor.
Alles unten ist warum.
Native (Swift / Kotlin)
Zwei Codebasen, zwei Skill-Sets, zwei Release-Zyklen. Ungefähr 1,6–1,9× die Build-Kosten eines Cross-Platform-Equivalents — nicht die 2×, die Leute annehmen, weil die gemeinsame Arbeit (Design, Backend, Produktdenken) sich nicht verdoppelt.
Was Sie kaufen: Jede Plattform-Möglichkeit am ersten Tag. Widgets, App Clips, Live Activities, CarPlay, Wear, tiefe OS-Integrationen, die neuesten Camera- und ML-APIs. Keine Abstraktionsschicht zwischen Ihnen und der Plattform, was bedeutet kein Warten, bis jemand die Sache, die Sie brauchen, wrapped.
Wählen Sie es wenn: die App das Produkt ist und seine Qualität der Unterschied; Sie sind in einer Kategorie wo Plattform-Features Retention fahren; Sie brauchen absolut beste Performance und Memory-Verhalten; oder Sie sind groß genug, dass zwei Spezialist-Teams normal sind.
Flutter
Eine Codebase, ein Team, seine eigene Rendering-Engine. Der letzte Teil ist was Leute missverstehen: Flutter wrapped native Components nicht, es zeichnet seine eigene. Das ist genau warum Custom UI in Flutter billig ist und genau warum es sich subtil un-native anfühlen kann, wenn Sie gegen die Plattform-Konventionen kämpfen.
Was Sie kaufen: wirklich dieselbe App auf beiden Plattformen, ein Team zum Einstellen, ein Bug zum Fixieren. Exzellent für Design-geführte Produkte wo die Schnittstelle ohnehin bespoke ist.
Was es kostet: Sie sind eine Schicht entfernt von neuen OS-Features, und größere Binaries. Alles tief Plattform-Spezifische bedeutet einen Platform Channel zu schreiben — was okay ist, und auch native Code ist, den Sie jetzt warten.
Wählen Sie es wenn: zwei Plattformen sind wichtig, das Budget ist echt aber endlich, die UI ist Custom, und Sie möchten lieber ein starkes Team statt zwei dünne.
React Native
Der Fall hat sich verengt. Die neue Architektur fixte die alten Bridge-Performance-Probleme, und wenn Sie React-Ingenieure haben, sind sie vom ersten Tag produktiv — das ist ein echter, großer Vorteil.
Was es kostet: die Abhängigkeitsfläche. Eine React Native App ist Ihre plus einen langen Tail von Community-Packages, und ihre Wartung ist nicht Ihre Entscheidung. Upgrades sind die häufigste Quelle ungeplanter Arbeit, die ich in geerbten RN-Codebasen sehe.
Wählen Sie es wenn: Sie ein React-Team und ein Web-Produkt zum Teilen von Logik haben. Wenn Sie frisch für es einstellen müssen, ist Flutter üblicherweise die bessere Wette 2026.
Der Kosten-Vergleich, konkret
Für eine mittlere Consumer-App — Auth, eine Core-Loop, Payments, Push, Offline-Handling, beide Plattformen — sieht die Form ungefähr so aus:
- Flutter: ein Team, eine Codebase. Baseline. Sagt 40.000 €.
- React Native: ~1,0–1,15× Baseline wenn Sie bereits React-Leute haben; ~1,2× wenn Sie neu einstellen, weil das Ecosystem-Wissen länger zu akquirieren ist als die Syntax.
- Native beide Plattformen: ~1,6–1,9× Baseline. Nicht 2×, weil Design, Backend und Produktdenken sich nicht verdoppeln — nur die Client-Arbeit.
- Native eine Plattform erst: ~0,75× Baseline, und dann haben Sie das Zweite-Plattform-Gespräch in sechs Monaten mit weniger Geld als Sie jetzt haben. Beliebt, und üblicherweise bereut.
Wartung ist wo die Divergenz verstärkt wird. Zwei Native-Codebasen bedeuten jede Änderung ist einmal spezifiziert und zweimal gebaut, für immer. Über drei Jahre ist diese Lücke üblicherweise größer als der initiale Build-Unterschied.
Die Einstellungs-Realität, die niemand preist
In Barcelona, Madrid, Lissabon und dem meisten von Zentral-Europa braucht das Einstellen eines starken Flutter-Ingenieurs 2026 Wochen. Das Einstellen eines starken Senior iOS-Ingenieurs braucht Monate, und kostet 20–30 % mehr wenn Sie einen finden. In London, Amsterdam oder Stockholm sind beide schwerer und teurer.
Das ist ein echter Input zur Entscheidung und es erscheint fast niemals im technischen Vergleich. Die beste Architektur, die Sie nicht besetzen können, ist schlechter als die gute Architektur, die Sie können.
Wenn Sie bereits drauf sind und über Wechsel nachdenken
Kurz: üblicherweise nicht, und hier der Test. Umschreiben kostet 60–80 % eines frischen Builds und liefert null neue User-Wert am Tage es shipped. Es ist nur berechtigt wenn:
- Sie können physisch nicht für den aktuellen Stack zu irgendeinem sinnvollen Preis einstellen.
- Eine Plattform-Anforderung wird die Arbeit ohnehin innerhalb von zwölf Monaten fahren.
- Die existierende Codebase versagt die Basics — siehe die Audit-Checkliste — in welchem Fall Sie nicht umschreiben wegen des Frameworks.
- Sie warten zwei Native-Codebasen mit einem Team das zu klein für eine ist.
"Unsere Ingenieure würden X vorziehen" ist nicht auf dieser Liste, und es ist der Grund die meisten Rewrites tatsächlich starten.
Die Fragen, die es tatsächlich entscheiden
Nicht "welcher ist schnellster". Diese:
- Wer wartet das in zwei Jahren? Wählen Sie den Stack, den Sie in Ihrer Stadt oder Ihrem Budget einstellen können. Eine perfekte technische Wahl mit nicht verfügbaren Ingenieuren ist eine schlechte Wahl.
- Wie Custom ist die Schnittstelle? Sehr Custom favorisiert Flutter. Plattform-konventionell favorisiert Native.
- Brauchen Sie eine Plattform-Feature am Launch-Tag? Wenn ja, Native. Alles andere wartet auf einen Wrapper.
- Gibt es eine existierende Web-App? Wenn sie React ist und die Logik ist wirklich shareable, wird React Native's Fall viel stärker.
- Was ist das echte Budget? Native für beide Plattformen auf einem 40.000 € Budget bedeutet eine Plattform, schlecht. Seien Sie früher ehrlich statt später.
Was zählt nicht so viel wie Sie denken
- Rohe Performance. Für die überwältigende Mehrheit der Apps sind alle drei weit vorbei der Schwelle wo User das merken. Ihre Network-Layer und Ihre Image-Handling zählen mehr als Ihr Framework.
- "Es fühlt sich nicht native an." Üblicherweise wahr von schlechten Apps in jedem Framework. Es ist ein Design und Attention-Problem mehr als ein Technology-Problem.
- Framework-Longevity-Argumente. Alle drei werden Ihre aktuelle Roadmap überleben. Setzen Sie auf Ihr Team, nicht auf Stiftungs-Pressemitteilungen.
Wenn Sie eine existierende App erben statt eine zu starten, ist die Framework-Frage sekundär — starten Sie mit was ein Audit wirklich sehen sollte.