Was ist React Native?

Was ist React Native?

React Native ist ein Cross-Platform-Mobile-Framework, mit dem Entwickler iOS- und Android-Apps mit JavaScript und React bauen. Der Output ist eine echte native Binary — keine Web-Views in einem Wrapper. UI-Komponenten mappen auf plattformspezifische native Widgets (UIKit auf iOS, Android-Views auf Android), und dein JavaScript läuft auf einem separaten Thread, der mit der nativen UI über eine Bridge oder in neueren Versionen das effizientere JSI (JavaScript Interface) kommuniziert.

2015 von Facebook (jetzt Meta) aus einem Hackathon-Projekt erstellt, löste React Native einen echten Schmerzpunkt: dasselbe Produkt-Team musste zwei komplett separate Codebases für iOS (Swift/Objective-C) und Android (Kotlin/Java) shippen und pflegen. Mit React Native werden ~85-95% des Codes geteilt. Große Production-User: Metas eigene Apps, Microsoft Office Mobile, Discord (ursprünglich), Shopify, Coinbase und Walmarts App — neben tausenden kleineren Apps.

Wie React Native funktioniert (die Architektur)

Das mentale Modell:

• JavaScript-Thread. Dein React-Native-Code läuft hier. Standard-React-Rendering-Regeln gelten — Component-Tree, State, Effects.
• Native UI-Thread. Rendert die tatsächlichen Plattform-Widgets (UIView auf iOS, View auf Android). Der JS-Thread berührt das nicht direkt; er sendet Anweisungen.
• Bridge / JSI. Die Kommunikationsschicht zwischen den beiden Threads. Die ursprüngliche "Bridge" (bis ~2022) serialisierte Nachrichten als JSON — langsam für Animationen und interaktive Elemente. Die neue JSI-Architektur (Standard in modernem React Native) gibt JavaScript direkten synchronen Zugriff auf native Module, dramatisch schneller.
• Native Module. Plattformspezifischer Code (Swift, Kotlin), zugänglich aus JavaScript. Nutze diese für Dinge, die React Native standardmäßig nicht exposed — Bluetooth, native Kamera-APIs, Biometric-Auth.

Das Ergebnis: UI sieht und fühlt sich nativ an (weil sie es IST), Animationen können auf moderner Hardware 60fps treffen und die meiste Anwendungslogik bleibt in der geteilten JavaScript-Codebase.

Wofür React Native gut ist

• Cross-Platform-UI-Entwicklung. Eine JavaScript-Codebase, echte native UIs auf beiden Plattformen. Der Shared-Code-Anteil ist genuin hoch (typischerweise 85-95%).
• Hot-Reload und schnelle Iteration. Code-Änderungen erscheinen in der laufenden App innerhalb von Sekunden. Native-Entwicklung mit vollen Xcode-/Android-Studio-Rebuilds dauert Minuten pro Iteration.
• Bestehende React-Expertise. Web-Teams, die React nutzen, können Mobile shippen, ohne Swift oder Kotlin von Grund auf zu lernen. Das React-Mentalmodell überträgt sich direkt.
• Over-the-Air-Updates. Tools wie Expos EAS Update (oder CodePush, 2024 deprecated aber noch genutzt) lassen dich JS-only-Updates pushen ohne den App Store / Play Store-Review zu durchlaufen. Kritische Bug-Fixes in Stunden, nicht Wochen.
• Die meisten App-Kategorien. CRUD-Apps, Social-Apps, E-Commerce, Content-Apps, Produktivitäts-Tools — alle gute Fits.

Wo React Native kämpft

• Performance-intensive Apps. AR/VR, fortgeschrittene Grafik, komplexe Echtzeit-Datenvisualisierung, heavy Game-Logik — diese brauchen oft Native-Code. Die JS-Bridge (oder selbst JSI) fügt Overhead hinzu, der am Rand zählt.
• Native UI-Features, die der Plattform hinterherhinken. Wenn iOS oder Android neue APIs shippen (z.B. Vision Pro, neue Material-3-Komponenten), braucht React Native oft Monate, sie zu exposen. Native-Entwickler shippen sie am Tag eins.
• Größere App-Größe. Das Bundling der JavaScript-Runtime addiert 5-15 MB zu deiner Binary. Wichtig für Emerging-Market-Nutzer mit strikten Storage-/Datenplänen.
• Debugging über die Bridge. Wenn etwas crashed, kann der Stack-Trace JS, native Bridge-Code und Plattform-Code spannen. Tooling hat sich verbessert (Flipper, React DevTools), aber es ist schwerer als reines Native.
• Library-Ökosystem-Verfall. Viele React-Native-Libraries sind abandoned oder unmaintained. Alles, was nicht offiziell von Expo oder dem Meta-Core-Team unterstützt wird, hat erhöhtes Risiko.

React Native vs. Flutter vs. Native

Die drei Haupt-Mobile-Entwicklungspfade 2026:

• React Native: JavaScript + React, echte native Widgets. Am besten für Teams mit bestehender React-Expertise. Reif, aber die Architektur hat sich durch Schmerz weiterentwickelt.
• Flutter: Dart-Sprache + Custom-Rendering-Engine (keine nativen Widgets, zeichnet alles selbst). Pixel-perfekt über Plattformen, aber etwas weniger "natives Gefühl". Wächst schnell durch Googles starke Investition.
• Native (Swift/Kotlin): Zwei Codebases. Höchste Performance, neueste Plattform-Features am Tag eins. Am besten für ressourcenreiche Teams, die plattformspezifische UX oder performance-kritische Apps shippen.

Die 80/20-Regel: Die meisten Produkt-Apps brauchen keine native Performance. React Native oder Flutter spart genug Engineering-Zeit, um die (kleinen) Kompromisse zu rechtfertigen.

React Native und Expo

Expo ist ein Managed-Framework auf React Native, das die schmerzhaftesten Teile handhabt: Build-Infrastruktur, OTA-Updates, native Module, Push-Benachrichtigungen, Splash-Screens. Moderne Best Practice ist "starte mit Expo, außer du hast einen spezifischen Grund nicht" — selbst Meta-geführte Projekte nutzen zunehmend Expos Tooling. Der Trade-off: Expo bündelt einen fixen Set nativer Module, also wenn du etwas brauchst, das sie nicht shippen, ejectest du zu Bare React Native.

Häufige React-Native-Gotchas

• Subtile iOS- und Android-UI-Unterschiede. Die gleiche React-Komponente rendert leicht unterschiedlich auf jeder Plattform — Text-Rendering, Scroll-Verhalten, Default-Farben. Teste auf beiden; nimm keine Parität an.
• Permission-Handling unterscheidet sich. iOS fragt nach Permissions bei erster Nutzung; Android pre-requested oft im Manifest. Die React-Native-API glättet das, aber unifiziert das Verhalten nicht vollständig.
• Navigation ist eine separate Library. React Native shippt keine Meinung. React Navigation ist der De-facto-Standard, aber die API ist groß und hat Breaking Changes zwischen Major-Versionen.
• iOS-Deployment erfordert einen Mac. Kein Weg drumrum — iOS-Bundles für den App Store zu bauen erfordert Xcode, das nur auf macOS läuft. Linux/Windows-Teams nutzen Cloud-Build-Services (EAS Build, Bitrise) für iOS.
• Crash-Logs brauchen Symbol-Upload. React-Native-Crashes können schwer zu lesen sein, ohne Source-Maps zu deinem Crash-Reporter (Sentry, Crashlytics) hochzuladen. Leicht zu vergessen; teuer zu debuggen ohne.

FAQ: React Native

Ist React Native 2026 noch relevant?

Ja. Der Architektur-Rewrite (Fabric-Renderer + JSI), der 2023-2024 ausgeliefert wurde, adressierte langjährige Performance-Probleme. Große Apps (Meta, Microsoft, Shopify) pflegen aktiv React-Native-Investitionen. Expos Tooling hat das Onboarding viel smoother gemacht. Cross-Platform-Mobile ist ein Steady-State-Markt und React Native ist einer von zwei Leadern neben Flutter.

Was ist der Unterschied zwischen React Native und React (Web)?

Gleicher React-Kern (Komponenten, State, Hooks), unterschiedliche Rendering-Ziele. React für Web rendert zu DOM-Elementen (<div>, <span>). React Native rendert zu nativen UI-Primitives (<View>, <Text>). Du teilst Komponentenlogik und State-Management; UI-Komponenten selbst werden nicht direkt zwischen Web und Mobile geteilt (nutze React Native Web, wenn du UI teilen willst, mit Caveats).

Kann ich Code zwischen Web (React) und Mobile (React Native) teilen?

Business-Logik, Hooks und State-Management: ja, einfach. UI-Komponenten: nur mit React Native Web (rendert RN-Komponenten im Web). Viele Teams nehmen einen 60-70%-Sharing-Ansatz — teile Logik, schreibe plattformspezifische UI für jedes Target.

Ist React Native gut für performance-sensitive Apps?

Zunehmend ja. Die neue Architektur (Fabric + JSI, Standard seit RN 0.74) reduzierte Bridge-Overhead signifikant. Für AR/VR, komplexe Animationen mit 120fps oder 3D-Rendering gewinnt Native immer noch. Für die meisten Produkt-Apps ist React Native schnell genug, dass Performance nicht der Limiter ist.

Wie lange dauert es, eine React-Native-App zu bauen?

Initiales Setup (Expo): 1-2 Tage zur laufenden App mit Auth und ein paar Screens. Reines natives Äquivalent: 1-2 Wochen. Die Cross-Platform-Beschleunigung kompoundet — was in reinem Native 4 Monate dauert, dauert in React Native für typische Produkt-Apps 2-3.

Kann ich eine bestehende native App zu React Native migrieren?

Inkrementelle Migration ist möglich — React Native unterstützt Embedding innerhalb einer bestehenden nativen App ("Brownfield"-Integration). Viele große Apps (Microsoft Office, Walmart) nutzten diesen Ansatz. Es ist schwer, aber machbar; budgetiere Monate, nicht Wochen.

Wie LoadFocus React-Native-Apps testet

React-Native-Apps, die mit Backends sprechen (95%+ von ihnen), brauchen API-Monitoring und Lasttest. LoadFocus-API-Monitoring validiert das Backend, das deine Mobile-Clients treffen — langsame APIs lassen selbst die beste React-Native-UI träge wirken. Lasttest validiert, dass dein Backend hält, wenn deine App launcht und viral geht. UI-Testing der React-Native-App selbst nutzt andere Tools (Detox, Maestro) — aber die Netzwerkschicht profitiert absolut von Synthetic-Monitoring.