React Native vs SwiftUI: Entscheidung in Stunden gerechnet

React Native vs SwiftUI entscheidet sich an einer Frage: Brauchen Sie in den nächsten zwei Jahren eine Android-App? Wenn nein, ist SwiftUI für eine reine iOS-App der direktere Weg – eine Sprache, eine Toolchain, neue Apple-APIs ohne Umweg über eine Bibliothek. Wenn ja, spart React Native in meinem Kalkulationsmodell rund ein Viertel der Stunden gegenüber zwei nativen Apps, solange der plattformspezifische Code klein bleibt. Performance, Syntax und Community verschieben diese Entscheidung in den meisten Projekten nur am Rand.

Ich entwickle selbst mit beiden Welten: Basaltemperatur läuft als Next.js-Web-App und als SwiftUI-App auf einer gemeinsamen Supabase-Datenbasis, PlainTrack ist bewusst SwiftUI-nativ gebaut. Die Zahlen unten stammen deshalb nicht aus Benchmarks, sondern aus einem Stundenmodell, das Sie mit Ihrem eigenen Funktionsumfang nachrechnen können.

Was die beiden Ansätze technisch unterscheidet

Der Vergleich hinkt auf den ersten Blick: React Native ist ein Cross-Platform-Framework, SwiftUI ein UI-Framework für Apple-Plattformen. Genau dieser Unterschied ist aber der Kern der Entscheidung.

React Native: eine Codebasis, native Komponenten

React Native ist ein von Meta initiiertes Framework, mit dem Sie App-Logik und Oberfläche in JavaScript oder TypeScript schreiben. Gerendert werden keine Webseiten in einem WebView, sondern native UI-Komponenten des jeweiligen Betriebssystems. Daraus folgt der zentrale Vorteil, den auch Leanware in seinem Vergleich hervorhebt: eine Codebasis, die auf iOS und Android gleichzeitig ausgeliefert wird.

Der Preis dafür ist eine zusätzliche Schicht. Zwischen Ihrem Code und iOS sitzen das Framework, häufig Expo als Werkzeugkette und eine Reihe von Community-Bibliotheken für Kamera, Bluetooth oder In-App-Käufe. Jede dieser Bibliotheken ist eine Abhängigkeit, die mit neuen iOS- und React-Native-Versionen Schritt halten muss.

SwiftUI: Apples deklaratives UI-Framework

SwiftUI ist Apples UI-Framework für iOS, iPadOS, macOS, watchOS und visionOS, geschrieben in Swift. Deklarativ heißt: Sie beschreiben, wie die Oberfläche für einen bestimmten Zustand aussieht, und das Framework kümmert sich um die Aktualisierung, wenn sich der Zustand ändert. Es gibt keine Bridge und keine Fremdbibliothek zwischen Code und System – neue APIs, die Apple vorstellt, sind in der Regel zuerst in Swift verfügbar.

Die Kehrseite: Der Code läuft ausschließlich auf Apple-Geräten. Eine Android-Version bedeutet eine zweite App, typischerweise in Kotlin mit Jetpack Compose.

Deklarative Syntax: näher beieinander als erwartet

Wer React kennt, findet sich in SwiftUI schneller zurecht, als die unterschiedlichen Sprachen vermuten lassen. Der Vergleich auf zthh.dev arbeitet die Parallelen bei Komponenten und State-Management ausführlich heraus. Ein Zähler sieht in beiden Welten fast gleich aus:

struct Counter: View {
    @State private var count = 0

    var body: some View {
        Button("Gezählt: \(count)") {
            count += 1
        }
    }
}

function Counter() {
  const [count, setCount] = useState(0);
  return (
    <Pressable onPress={() => setCount(count + 1)}>
      <Text>Gezählt: {count}</Text>
    </Pressable>
  );
}

@State entspricht useState, die View-Struktur entspricht der Funktionskomponente. Der Lernaufwand liegt deshalb weniger in der UI-Logik als in allem darum herum: Xcode, Signierung, Swift Concurrency auf der einen Seite; Metro, native Module, Build-Konfiguration für zwei Plattformen auf der anderen.

Rechenbeispiel: dieselbe App in drei Varianten

Um die Entscheidung greifbar zu machen, rechne ich eine typische Business-App durch: 14 Screens, Login, Datensynchronisation mit einem Backend wie Supabase, Push-Benachrichtigungen, In-App-Kauf und ein Home-Screen-Widget. Die Stundenwerte sind Kalkulationsannahmen für ein erfahrenes Ein-Personen-Setup, keine Messwerte. Entscheidend sind die Verhältnisse, nicht die absoluten Zahlen.

Für eine reine iOS-App ist React Native in diesem Modell also teurer, nicht günstiger. Der Grund ist simpel: Sie bezahlen die Cross-Platform-Schicht, ohne ihren Nutzen abzurufen.

Jetzt kommt Android dazu:

Die 82 Stunden für Android in der React-Native-Variante setzen sich zusammen aus 30 h plattformspezifischer QA, 24 h UI-Korrekturen für Android-Eigenheiten, 20 h für ein natives Android-Widget und 8 h Store-Release. Die 236 Stunden für die native Android-App liegen etwas unter dem iOS-Wert, weil Datenmodell und Backend-Anbindung bereits geklärt sind.

Wie ich solche Bausteinmatrizen für reine SwiftUI-Projekte aufbaue, steht ausführlicher in iOS-App-Entwicklung mit SwiftUI: Kosten in Stunden kalkulieren.

Die Native-Quote: ab wann der Cross-Platform-Vorteil kippt

Das Rechenbeispiel hat einen blinden Fleck: Es geht von einem kleinen Anteil an Code aus, der trotz React Native nativ geschrieben werden muss. Im Beispiel ist das nur das Widget. Bei manchen Apps ist es ein großer Teil.

Ich nenne diesen Anteil die Native-Quote: den Anteil der Funktionsstunden, der in einer React-Native-App trotzdem in Swift bzw. Kotlin entstehen muss. Mit zwei Annahmen lässt sich der Kipppunkt berechnen:

• Gemeinsamer Code kostet in React Native 12 % mehr als dieselbe Funktion nativ für eine Plattform (Setup, Bibliotheken, Debugging über Schichten hinweg – derselbe Aufschlag wie im Rechenbeispiel).
• Nativer Code in einer React-Native-App kostet das 2,3-Fache: zweimal geschrieben, plus 0,3 für die Anbindung an die JavaScript-Seite.

Zwei native Apps:  2,00 × H
React Native:      (1 − q) × 1,12 × H  +  q × 2,3 × H

Gleichstand:       1,12 + 1,18 × q = 2,00
                   q ≈ 0,75

Bei einer Native-Quote von etwa 75 % ist der Stundenvorteil rechnerisch aufgebraucht. In der Praxis liegt die Schwelle früher, weil ab einem gewissen Punkt ein Team zwei Plattform-Toolchains und die React-Native-Schicht beherrschen muss. Meine Arbeitsregel daraus: Liegt die geschätzte Native-Quote über einem Drittel, rechne ich beide Varianten vollständig durch, statt React Native als Standard anzunehmen.

Was die Native-Quote nach oben treibt

Einige Funktionen landen bei React Native fast zwangsläufig im nativen Teil:

• Widgets und Live Activities. WidgetKit-Widgets werden in SwiftUI geschrieben, auch wenn die Haupt-App in React Native entsteht.
• Apple Watch. Eine watchOS-App ist ein eigenes natives Projekt.
• Bluetooth-Sensoren und Echtzeit-Signalverarbeitung. Bei Respivo werden Herzfrequenzdaten eines Brustgurts direkt auf dem Gerät verarbeitet – solche Pipelines gehören in nativen Code, egal welches UI-Framework obendrauf sitzt.
• HealthKit, Kamera-Pipelines, Hintergrundaufgaben, sobald sie über das hinausgehen, was eine gepflegte Bibliothek abdeckt.

Was die Native-Quote niedrig hält

Formulare, Listen, Dashboards, Login, Zahlungsabwicklung über einen Webservice, Inhalte aus einer API: Das ist der klassische Business-App-Kern, und genau hier spielt React Native seine Stärke aus. Eine CRM-, Buchungs- oder Vereins-App liegt typischerweise deutlich unter 20 %.

Wo SwiftUI Grenzen hat

SwiftUI ist kein Selbstläufer. Drei Punkte sehe ich in Projekten regelmäßig:

Mindest-iOS-Version. Viele SwiftUI-APIs stehen erst ab bestimmten iOS-Versionen zur Verfügung. Wer ältere Geräte unterstützen muss, schreibt Fallbacks oder verzichtet auf neuere Komponenten. Klären Sie die minimale iOS-Version deshalb vor dem ersten Screen, nicht vor dem Release – sie bestimmt, welche Navigation, welche Listen- und welche Datenfluss-APIs überhaupt infrage kommen.

Keine zweite Plattform. Das ist der offensichtliche Punkt, wird aber in Angeboten gern unterschlagen. „Android machen wir später" bedeutet bei SwiftUI: eine zweite App, die in meinem Modell rund 96 % des iOS-Aufwands kostet.

Randfälle bei komplexen Oberflächen. Sehr spezielle Layouts, Textbearbeitung mit vielen Sonderfällen oder hochgradig angepasste Listen landen gelegentlich bei UIKit-Komponenten, die in SwiftUI eingebettet werden. Das ist lösbar, kostet aber Stunden, die im Angebot auftauchen sollten.

Wo React Native Grenzen hat

Abhängigkeitspflege. Eine React-Native-App lebt von Bibliotheken. Wenn eine davon nicht mehr gepflegt wird, während Apple die nächste iOS-Version veröffentlicht, steht das Update. Prüfen Sie vor Projektstart für jede kritische Bibliothek: letzter Release, offene Issues, Anzahl aktiver Maintainer.

Upgrade-Aufwand. Größere React-Native-Versionssprünge – etwa der Umstieg auf die sogenannte New Architecture mit Fabric und TurboModules – betreffen auch native Module. Planen Sie dafür jährlich ein festes Stundenbudget ein, statt es als Wartungsrauschen zu behandeln.

Neue Apple-Funktionen kommen später an. Was Apple im Juni vorstellt, ist in Swift direkt nutzbar. In React Native wartet man auf eine Bibliothek oder schreibt das Modul selbst – womit die Native-Quote steigt.

Scorecard: 8 Kriterien, 100 Punkte

Diese Scorecard nutze ich, um die Entscheidung aus dem Bauchgefühl zu holen. Vergeben Sie pro Kriterium die Punkte für die Seite, die besser passt. Liegt eine Seite über 60 Punkten, ist die Richtung klar; zwischen 40 und 60 lohnt das vollständige Durchrechnen beider Varianten.

Das Kriterium „Code-Teilung mit Web-App" wird oft überschätzt. Bei Basaltemperatur teilen sich Web und iOS eine Datenbank und Geschäftsregeln auf Datenbankebene, nicht aber Code. Das hat sich als robust erwiesen, weil keine Seite auf das Release-Tempo der anderen warten muss.

Was typischerweise schiefgeht

Der häufigste Fehler ist die Entscheidung nach Tagessatz statt nach Gesamtstunden. Ein React-Native-Angebot für „iOS und Android" sieht günstig aus, bis das Widget, die Watch-Komplikation und die Bluetooth-Anbindung als „native Erweiterung" nachberechnet werden. Das erkennen Sie früh: Fragen Sie im Angebot gezielt, welche Funktionen nativ umgesetzt werden und mit wie vielen Stunden.

Der zweithäufigste: SwiftUI wählen, weil die erste Version nur für iOS gedacht ist, und nach einem Jahr feststellen, dass der größte Kunde Android-Geräte im Außendienst einsetzt. Die Frage nach Android gehört deshalb an den Anfang – mit einer ehrlichen Antwort der Fachabteilung, nicht des Marketings.

Der dritte betrifft den Betrieb. Wer eine App ausliefert und kein Budget für die jährliche iOS-Anpassung vorsieht, hat nach zwei Releases ein Problem – bei SwiftUI kleiner, bei React Native größer, aber in beiden Fällen real. Auch die Frage, wer diese Pflege übernimmt, verändert die Kalkulation; die Unterschiede zwischen Einzelentwickler und Agentur rechne ich in Freelance Entwickler vs. Agentur: Kosten sauber vergleichen durch.

Zeitplan für eine Entscheidung im November

Wer die Technologie jetzt festlegt, plant meist für ein Budget und einen Start im neuen Jahr. Drei Schritte passen gut in die Wochen bis Jahresende:

1. Funktionsliste mit Native-Markierung. Jede Funktion bekommt ein Kennzeichen: gemeinsam umsetzbar oder plattformspezifisch. Daraus ergibt sich die Native-Quote.
2. Zwei Stundenmodelle statt einem Angebot. Lassen Sie beide Varianten kalkulieren, mit derselben Bausteinliste. Erst der direkte Vergleich zeigt, ob der Cross-Platform-Vorteil real ist.
3. Release-Fenster prüfen. Wer noch vor Jahresende eine erste Version in den App Store bringen will, sollte vorab nachsehen, ob Apple für die Feiertage Einschränkungen bei der App-Prüfung ankündigt, und Puffer einplanen.

Wenn die Scorecard keine klare Richtung zeigt, ist das auch ein Ergebnis: Dann entscheidet meist das vorhandene Team-Know-how, weil Einarbeitung der Posten ist, den beide Stundenmodelle am schlechtesten abbilden.

FAQ

Ist React Native für iOS geeignet?

Ja, React Native erzeugt echte iOS-Apps mit nativen UI-Komponenten, die regulär über den App Store vertrieben werden. Für eine App, die nur auf iOS erscheinen soll, ist es in meinem Rechenmodell allerdings rund 12 % teurer als SwiftUI. Sinnvoll wird React Native vor allem, wenn Android fest eingeplant ist.

Welche Nachteile hat SwiftUI?

SwiftUI läuft ausschließlich auf Apple-Plattformen, eine Android-Version ist also eine zweite App. Viele APIs setzen neuere iOS-Versionen voraus, was die Unterstützung älterer Geräte erschwert. Bei sehr speziellen Oberflächen greift man zudem gelegentlich auf eingebettete UIKit-Komponenten zurück.

Warum wenden sich manche Entwickler von React ab?

Belastbare Zahlen zu einer Abwanderung liegen mir nicht vor. In Diskussionen genannt werden vor allem die Komplexität des Ökosystems und der Pflegeaufwand für Abhängigkeiten. Für die App-Entscheidung zählt das nur indirekt: Prüfen Sie, wie gut die konkret benötigten Bibliotheken gepflegt sind.

Nutzt Tesla React Native?

Eine offizielle, öffentlich dokumentierte Aussage von Tesla dazu kenne ich nicht, deshalb kann ich es nicht bestätigen. Für Ihre eigene Entscheidung ist es ohnehin ein schwaches Signal: Ein Konzern mit großen Plattform-Teams hat andere Rahmenbedingungen als ein Projekt mit 300 bis 500 Stunden Budget.