Flutter oder React Native? Nach App, Plattform und Team entscheiden

Die Kurzantwort: Erst den App-Auftrag, dann das Werkzeug wählen

Flutter ist ein UI-Toolkit mit Dart, eigenem Framework und Rendering-Engine. Die offizielle Architekturübersicht beschreibt, wie Flutter die Oberfläche selbst aufbaut und über einen Plattform-Embedder mit dem Betriebssystem verbindet. React Native verwendet JavaScript oder TypeScript, React-Komponenten und native Bausteine der Zielplattform. Beide können Code zwischen Plattformen teilen. Beide brauchen dennoch plattformspezifische Arbeit, wenn Funktionen, Bedienung oder Systemintegration voneinander abweichen.

Beginnen Sie mit vier Fragen: Welche Plattformen müssen wirklich unterstützt werden? Gibt es bereits eine native App oder ein React-Team? Welche Gerätefunktionen sind zentral? Wer pflegt Veröffentlichung, Store-Vorgaben, Zugänglichkeit und Fehlerbehebung? Ein Cross-Platform-Framework spart nur dann Arbeit, wenn Ihr Produkt und Team die gemeinsame Basis sinnvoll nutzen.

Prüfen Sie die offiziellen Plattformlisten zum Zeitpunkt Ihrer Entscheidung. Unterstützte Betriebssystemversionen ändern sich. Ein Eintrag auf einer Liste belegt außerdem nicht, dass jedes Drittanbieterpaket oder jedes Gerät Ihres Zielpublikums abgedeckt ist.

Fiktiver Fall: eine Außendienst-App mit Kamera und Offline-Aufträgen

Fiktives Beispiel, keine Division5-Kundenreferenz: Ein Wartungsunternehmen möchte eine App für Technikerinnen und Techniker. Sie zeigt Aufträge, speichert Notizen ohne Verbindung und lädt nach Wiederherstellung des Netzes Fotos hoch. Ein Teil des Teams baut bereits Weboberflächen mit React. Ein vorhandener Android-Prozess nutzt eine spezialisierte Bibliothek für Barcode-Scanner.

Die verantwortliche Product Ownerin entscheidet, dass iOS und Android zum Start nötig sind. Die Barcode-Erfassung muss auf den tatsächlich genutzten Geräten funktionieren. Offline-Speicherung und sichere Wiederholung nach Netzunterbrechung sind wichtiger als eine gemeinsame Oberfläche für Desktop oder Web. Das Team baut deshalb dieselben Kernabläufe in einer kurzen technischen Probe: Anmeldung, Auftrag laden, Flugmodus einschalten, Notiz speichern, Verbindung wiederherstellen und Foto anhängen.

Für dieses fiktive Unternehmen fällt die Entscheidung zunächst auf React Native, weil das bestehende Team React kennt und ein kleiner Prototyp die Scanner-Bibliothek auf den Geräten des Unternehmens bestätigt. Das ist keine allgemeine Empfehlung. Wenn die native Integration in der Probe instabil wäre oder das Unternehmen ein einheitliches Rendering über viele Zielplattformen benötigte, müsste Flutter erneut verglichen werden. Die Entscheidung wird ausdrücklich an Geräte- und Offline-Ergebnisse gebunden.

Beide Optionen am selben Ablauf prüfen

Die React-Native-Dokumentation rät bei neuen Apps dazu, ein Framework zu verwenden. Das betrifft den Startweg des Projekts, ist aber kein Beleg, dass React Native für jede bestehende App oder jedes Produkt besser passt. Flutter hebt eine gemeinsame Codebasis für mehrere Plattformen hervor. Auch das ersetzt keine Geräteprüfung.

Die Probe: nur mit Funktionen, die Ihre Auswahl riskant machen

Ein „Hello World“ zeigt, dass der Entwicklungsrechner eingerichtet ist. Es sagt wenig darüber aus, ob Offline-Speicherung, Push-Mitteilungen oder ein Scanner in Ihrer App funktionieren. Wählen Sie deshalb den kleinsten vertikalen Ablauf, der die wichtigsten Unsicherheiten berührt.

1. Geräte festlegen: Listen Sie die iPhone- und Android-Modelle sowie Betriebssystemstände auf, die Mitarbeitende tatsächlich nutzen.
2. Schwierige Funktion auswählen: Nehmen Sie die native Integration, die im Fehlerfall den größten Schaden oder Arbeitsausfall verursacht.
3. Netz und App-Zustände prüfen: Testen Sie Anmeldung, Unterbrechung, App-Neustart, Synchronisation, Abmeldung und doppelte Übertragung.
4. Zugänglichkeit einbeziehen: Prüfen Sie Fokusreihenfolge, Beschriftungen, Textvergrößerung, Systemtastatur und Fehlerhinweise.
5. Release-Weg durchlaufen: Bauen Sie ein signiertes internes Testpaket, prüfen Sie Protokolle und dokumentieren Sie, wer Store-Veröffentlichung und Fehlerbehebung verantwortet.
6. Wartung simulieren: Ändern Sie eine Datenstruktur, lassen Sie einen Fehler reproduzieren und dokumentieren Sie nötige native Anpassungen.

Erfassen Sie für Flutter und React Native dieselben Beobachtungen: Was funktionierte, welche Einschränkung blieb, wer konnte sie beheben, welches Wissen fehlte und was muss vor einem Produktstart noch geprüft werden? Eine kürzere Probe gewinnt nicht automatisch. Sicherheits- und Betriebsanforderungen sind Ausschlusskriterien, wenn sie nicht erfüllt sind.

Wann sich die Entscheidung ändert

Ein Team, das React für das Web nutzt, besitzt dadurch nicht automatisch Erfahrung mit mobilen Builds, nativen Modulen, Geräteberechtigungen oder App-Store-Abläufen. Ebenso beweist Flutter-Erfahrung nicht, dass eine Person mit Ihren vorhandenen iOS- oder Android-Komponenten umgehen kann. Fragen Sie nach einem ähnlichen, konkreten Ablauf und lassen Sie die Person die eigenen Verantwortungen erklären.

Bei einer bereits veröffentlichten App können Migration und Parallelbetrieb mehr kosten als eine gezielte Erweiterung. Inventarisieren Sie daher Screens, native Module, gespeicherte Daten, Release-Pipeline und Zuständigkeiten, bevor Sie einen Wechsel bewerten. Behalten Sie die bestehende Lösung, wenn die aktuelle Einschränkung nicht benannt und reproduzierbar ist.

Division5 vermittelt vorgeprüfte Fachkräfte aus dem Balkan. Sie können die geprüften Profile und aufgezeichneten Interviews schon vor dem Kennenlernen ansehen. Für eine mobile Entwicklungsrolle nennen Sie Zielplattformen, vorhandene App und nötige native Funktionen. Für alle Fachkräfte gilt eine 30-tägige Testphase. Die konkreten Bedingungen stehen vor dem Start schriftlich fest. Mobile Fachkraft besprechen.