Cross-Platform Mobile (React Native / Flutter)
Eine Codebasis, die sowohl im App Store als auch bei Google Play erscheint. Cross-Platform-Entwicklung ist ein ernstzunehmender Engineering-Ansatz -- kein Kompromiss --, wenn das richtige Framework zum richtigen Projekt passt. Die Wahl zwischen React Native und Flutter hat messbare Auswirkungen auf Personalkosten, langfristige Wartung und die Reichweite einer einzelnen Codebasis. Wir klären diese Entscheidung, bevor eine einzige Zeile Code geschrieben wird.
Die meisten Projekte liegen zwischen 15.000 und 60.000 US-Dollar, abhängig von Umfang, Integrationskomplexität und ob native Module erforderlich sind.
Eine Codebasis, zwei Stores: Wann Cross-Platform die richtige Wahl ist#
Was Cross-Platform-Entwicklung tatsächlich bedeutet#
Cross-Platform-Frameworks kompilieren oder überbrücken eine gemeinsame Codebasis in plattformspezifische Binaries, die nativ auf iOS und Android laufen. Flutter kompiliert über Dart zu nativem ARM-Code. React Native rendert echte native UI-Komponenten über eine JavaScript-to-Native-Bridge -- oder ab v0.74+ über die Bridgeless New Architecture, die diese Brücke vollständig eliminiert.
Das Ergebnis ist keine Web-App in einer Shell. Richtig umgesetzt ist eine Cross-Platform-App im Alltag nicht von einer nativen zu unterscheiden. Der technische Kompromiss zeigt sich an den Rändern: tiefer Hardware-Zugriff, komplexe Animationen und plattformspezifische UI-Patterns, bei denen nativer Code mehr direkte Kontrolle bietet.
Wann Cross-Platform sinnvoll ist -- und wann sich native Entwicklung lohnt#
Cross-Platform-Entwicklung ist die richtige Wahl, wenn:
- Sie iOS und Android gleichzeitig ausliefern müssen, nicht nacheinander
- Der Funktionsumfang aus Standard-UI und API-Aufrufen besteht, ohne intensive Hardware-Integration
- Ihr Team mit JavaScript arbeitet (React Native) oder Sie neben Mobile auch Web und Desktop benötigen (Flutter)
- Das Wartungsbudget zählt: eine Codebasis zu pflegen ist besser als zwei
Native Entwicklung lohnt die zusätzlichen Kosten, wenn:
- Die Kernfunktionalität der App auf plattformspezifischen APIs basiert, für die es kein Cross-Platform-Äquivalent gibt
- Sie durchgehend 60fps-Rendering benötigen -- Games, Videobearbeitung, AR
- Ein Fehler bei der Integration eines nativen Moduls eine knappe App-Store-Review-Deadline blockieren würde
Was Sie aufgeben und was Sie gewinnen#
Sie gewinnen Geschwindigkeit bei der Auslieferung und eine geringere Wartungsoberfläche. Der Kompromiss ist der direkte Zugriff auf Plattform-APIs ohne native Module und gelegentliche Versionskonflikte zwischen dem Framework und einem neuen OS-Release. Sowohl React Native als auch Flutter haben ihre Parität mit nativen APIs deutlich verbessert, aber keines der beiden ist ohne Overhead. Wir dokumentieren die konkreten Lücken, die für Ihren Funktionsumfang relevant sind, während des Scopings -- damit es keine Überraschungen mitten im Build gibt.
React Native vs Flutter: So treffen wir die Wahl#
React Native: JavaScript-nativ, tiefer Plattformzugriff#
React Native rendert echte native UI-Komponenten. Der Talent-Pool an JavaScript-Entwicklern für React Native übertrifft den für Dart/Flutter im Verhältnis von etwa 20:1, was sich direkt auf Personalkosten und Teamflexibilität auswirkt (BrowserStack, 2025). LinkedIn US zeigt etwa 6.400 React-Native-Stellenanzeigen im Vergleich zu circa 1.100 Flutter-Stellenanzeigen Stand 2025 -- eine Zahl, die zeigt, wie tief React Native in der Enterprise-Mobile-Entwicklung verankert ist (DEV Community, 2025).
Die Bridgeless New Architecture ab v0.74+ entfernt die JavaScript-Bridge, die historisch bei komplexen Interaktionen zu Latenz führte (React Native Dokumentation, 2025). Für Teams mit bestehenden JavaScript- oder React-Web-Codebasen ermöglicht React Native echtes Code-Sharing: Geschäftslogik, State Management und API-Client-Code wandern zwischen Web und Mobile. Die gemeinsame Schicht ist tatsächlich laufender Code, nicht nur eine gemeinsame Sprache.
React Native ist unsere Standardempfehlung, wenn das Team des Kunden JavaScript-nativ arbeitet oder wenn das Produkt eine React-Web-Anwendung hat, die von geteilter Logik profitiert.
Flutter: eigenes Rendering, echte Multi-Platform-Reichweite#
Flutter verwendet keine nativen UI-Komponenten. Es zeichnet alles über seine eigene Skia/Impeller-Rendering-Engine, was bedeutet, dass dieselbe Codebasis auf iOS, Android, Web und Desktop ohne separate Renderer läuft. Flutter erreicht über 95 % Code-Wiederverwendung über alle vier Plattformen hinweg; React Native erreicht 60-70 % Wiederverwendung in Kombination mit einer React-Web-App (DroidsOnRoids, 2025).
Flutter hält einen Marktanteil von rund 46 % bei Cross-Platform-Mobile-Frameworks gegenüber 35 % für React Native, Stand 2025 (Statista via TechAhead, 2025). Das Wachstum konzentriert sich auf Teams, die konsistentes UI-Verhalten über jede Plattform hinweg benötigen: Fintech, Enterprise-Tooling, Produkte, bei denen pixelgenaue Design-Treue nicht verhandelbar ist.
Flutter ist unsere Empfehlung, wenn der Kunde Multi-Platform-Reichweite über iOS und Android hinaus benötigt, wenn das Design-System komplex und individuell ist oder wenn Rendering-Konsistenz über Plattformen hinweg eine harte Produktanforderung darstellt.
Entscheidungsfaktoren: Team, Roadmap, Performance, Timeline#
Wir arbeiten beim Scoping vier Faktoren durch:
- Teamzusammensetzung -- JavaScript-nativ oder offen für Dart? Das beeinflusst die Build-Timeline und die langfristigen Betriebskosten. Nach unserer Erfahrung dauert die Dart-Lernkurve in der Regel eine Woche und ist kein Blocker, aber sie kostet anfangs dennoch Zeit.
- Roadmap-Umfang -- Benötigt das Produkt innerhalb von 12-18 Monaten Web- oder Desktop-Reichweite? Flutters Multi-Platform-Story ist hier stärker.
- Performance-Profil -- Durchgehend hohe Frameraten bei komplexen UIs? Flutters eigener Renderer liefert berechenbarere Ergebnisse.
- Timeline -- React Native ist anfangs schneller, wenn das Team die Sprache bereits beherrscht. Flutter zahlt sich bei langlebigen Produkten stärker aus.
Das Ergebnis dieses Prozesses ist eine schriftliche Framework-Empfehlung mit dokumentierter Begründung -- kein mündlicher Vorschlag, der nach dem Gespräch verfliegt.
Was in einem Cross-Platform-Engagement enthalten ist#
Stack-Auswahl und Architektur-Scoping#
Vor Entwicklungsbeginn erstellen wir ein schriftliches Architektur-Briefing: Framework-Empfehlung mit Begründung, vorgeschlagene App-Architektur (State Management, Navigation, Datenschicht), benötigte native Module und bekannte plattformspezifische Risiken für den Funktionsumfang. Das gibt dem Kunden einen Prüfpunkt, bevor Build-Kosten festgelegt werden.
UI-Entwicklung und Plattform-Paritätstests#
Wir entwickeln auf Basis des vereinbarten Design-Systems, wobei Plattform-Paritätstests Teil der Definition of Done für jedes Feature sind -- nicht erst ein finaler QA-Durchlauf. Tests umfassen physische Geräte der aktuellen und einer vorherigen OS-Generation für iOS und Android und decken die Fragmentierungsprobleme ab, die typischerweise erst kurz vor der Produktion auftreten.
App-Store-Einreichung und Release-Pipeline#
Die App-Store-Einreichung ist inklusive: Provisioning Profiles, Signierung, Build-Konfiguration und der Einreichungs-Workflow für Apple App Store und Google Play. Wir konfigurieren eine CI/CD-Release-Pipeline (typischerweise GitHub Actions oder Fastlane), damit der Kunde zukünftige Updates ohne externe Hilfe ausliefern kann. Unter unserer Übersicht zur Mobile-Entwicklung erfahren Sie, wie das in unsere breitere Mobile-Praxis eingebettet ist.
Übergabe, Dokumentation und optionaler Retainer#
Die Übergabe umfasst Architektur-Dokumentation, eine Komponenten- und Screen-Übersicht, Anleitungen zur Einrichtung der Entwicklungsumgebung und einen dokumentierten Release-Prozess. Kunden, die laufende Unterstützung wünschen, können mit einem monatlichen Retainer weiterarbeiten. Für Kunden mit iOS-spezifischen oder Android-spezifischen nativen Anforderungen neben einem Cross-Platform-Kern scopen wir diese als separate Arbeitspakete.
Preise und Zeitrahmen#
Der Umfang bestimmt den Zeitrahmen mehr als die Framework-Wahl. Ein Standard-Engagement -- Authentifizierung, Kern-Feature-Set, API-Integration, App-Store-Einreichung -- dauert 10-16 Wochen. Komplexe Apps mit Offline-Synchronisation, nativen Modulen oder großen Datenoberflächen dauern 16-24 Wochen.
| Umfang | Geschätzter Rahmen | Typischer Zeitrahmen |
|---|---|---|
| MVP (Auth, 3-5 Screens, API-Integration) | 15.000-25.000 USD | 10-14 Wochen |
| Standardprodukt (vollständiger Funktionsumfang, individuelles UI) | 25.000-45.000 USD | 14-20 Wochen |
| Komplexe App (native Module, Offline-Sync, mehrere Rollen) | 45.000-60.000+ USD | 20-28 Wochen |
Dies sind Scoping-Schätzungen. Das Architektur-Briefing liefert ein Festpreis-Angebot, bevor der Build beginnt. Wenn Sie Cross-Platform gegen einen Web- oder SaaS-Ansatz abwägen, lohnt sich dieses Gespräch, bevor ein Framework gewählt wird. Unter unserer Technologie-Übersicht erfahren Sie, wie wir Stack-Entscheidungen über die gesamte Produktoberfläche hinweg angehen.
FAQ#
Soll ich meine App in React Native oder Flutter entwickeln?
Das hängt von Ihrem Team und Ihrer Roadmap ab. React Native passt, wenn Ihr Team JavaScript-nativ arbeitet oder wenn Sie eine React-Web-App mit teilbarer Logik haben. Flutter passt, wenn Sie iOS, Android, Web und Desktop aus einer Codebasis benötigen oder wenn Design-Konsistenz über Plattformen hinweg wichtiger ist als alles andere. Wir dokumentieren diese Empfehlung im Scoping, sodass die Entscheidung schriftlich festgehalten wird -- nicht mündlich.
Was ist der Unterschied zwischen React Native und Flutter?
React Native rendert echte native iOS- und Android-UI-Komponenten, gesteuert durch JavaScript. Flutter nutzt seine eigene Rendering-Engine und zeichnet die UI direkt, ohne native Komponenten zu verwenden. Beide erzeugen Apps, die sich für Nutzer nativ anfühlen. Die praktischen Unterschiede liegen bei der Personalgewinnung (JavaScript-Talente sind leichter zu finden), der Plattform-Reichweite (Flutter erstreckt sich natürlicher auf Web und Desktop) und der Performance-Vorhersagbarkeit bei komplexen UIs.
Kann eine Cross-Platform-App zwei native Apps ersetzen?
Bei den meisten kommerziellen Produkten ja. Die Fälle, in denen Cross-Platform an Grenzen stößt -- anhaltendes AR-Rendering, komplexe Hardware-APIs, OS-Level-Features, die das Framework noch nicht abdeckt -- sind spezifisch und identifizierbar. Wir weisen beim Scoping darauf hin, bevor mit dem Build begonnen wird.
Was kostet Cross-Platform-Mobile-Entwicklung?
Die meisten Projekte liegen zwischen 15.000 und 60.000 US-Dollar, abhängig vom Funktionsumfang, der Integrationskomplexität und ob native Module erforderlich sind. Ein verbindliches Festpreis-Angebot wird nach dem Scoping erstellt.
Übernehmen Sie die App-Store-Einreichung?
Ja. Die Einreichung bei Apple App Store und Google Play ist in jedem Engagement enthalten. Wir konfigurieren Signierung, Provisioning, Build-Pipelines und Release-Automatisierung, damit der Kunde zukünftige Releases eigenständig verwalten kann.
Wenn Sie eine Framework-Entscheidung treffen müssen und vor dem Projektstart eine technische Einschätzung wünschen, beginnen Sie mit einem Scoping-Gespräch. Wir arbeiten Ihren Funktionsumfang, Ihr Team und Ihren Zeitrahmen durch und senden Ihnen eine schriftliche Empfehlung, bevor irgendetwas vereinbart wird.
