React Native Probleme & Lösungen: Erfahrungsbericht

TL;DR – Die ehrliche Version

Wir bei exponent entwickeln Apps mit React Native und Expo — und wir lieben es. Aber wir wären keine ehrlichen Entwickler, wenn wir verschweigen würden: React Native hat Pain Points. Build-Fehler, die einen halben Tag kosten. Upgrades, bei denen plötzlich nichts mehr kompiliert. Native Module, die auf iOS funktionieren und auf Android crashen.

Dieser Artikel ist kein Marketing-Blabla, sondern ein ehrlicher Erfahrungsbericht mit konkreten Lösungen. Wenn Sie React Native evaluieren oder bereits nutzen und auf Probleme stoßen — hier finden Sie Antworten.

Das Wichtigste vorab: Die meisten dieser Probleme sind lösbar, und mit dem richtigen Setup (Expo, EAS Build, guter Toolchain) lassen sich 80 % der Schmerzen vermeiden.

1. Build-Probleme — Der Pain Point Nummer Eins

Fragen Sie einen React-Native-Entwickler nach seinem größten Schmerzpunkt, und die Antwort ist fast immer: „Das Build-System." iOS und Android haben jeweils eigene, komplexe Build-Toolchains — und React Native muss mit beiden gleichzeitig funktionieren.

iOS: Xcode, CocoaPods und Signing-Chaos

Die häufigsten iOS-Build-Probleme, die uns begegnen:

Xcode-Version-Mismatches: Apple aktualisiert Xcode regelmäßig und deprecatet ältere Versionen. Wenn Ihr CI/CD eine andere Xcode-Version hat als Ihre lokale Maschine, passiert Folgendes:

// ❌ Der gefürchtete Fehler nach einem Xcode-Update
// "The following build commands failed:
//   CompileC /Users/.../RCTNetwork.o
//   error: module 'React' not found"

// ✅ Lösung: Pods komplett neu installieren
// cd ios && rm -rf Pods Podfile.lock && pod install --repo-update

CocoaPods-Konflikte: CocoaPods ist der Dependency-Manager für iOS, und er ist ... eigen. Unsere häufigsten Probleme:

pod install schlägt fehl wegen inkompatbler Versionen
Verschiedene Libraries fordern verschiedene Minimum-iOS-Versionen
Cache-Probleme nach Updates (pod cache clean --all ist Ihr Freund)

Signing-Certificate-Fehler: „No signing certificate iOS Distribution found" — dieser Fehler hat schon Tage gekostet. Apple's Provisioning-Profile-System ist selbst für erfahrene Entwickler verwirrend.

Android: Gradle, SDK und NDK

Android-Build-Probleme sind anders, aber nicht weniger frustrierend:

Gradle-Version-Hell: Android nutzt Gradle als Build-System, und die Kompatibilitätsmatrix zwischen Gradle, Android Gradle Plugin, Java-Version und React Native ist ein Minenfeld:

// ❌ Typischer Gradle-Fehler
// "Could not determine the dependencies of task ':app:compileDebugJavaWithJavac'.
//  > Could not resolve all files for configuration ':app:debugRuntimeClasspath'."

// ✅ In android/gradle.properties sicherstellen:
// org.gradle.jvmargs=-Xmx4096m -XX:MaxMetaspaceSize=1024m
// android.useAndroidX=true
// android.enableJetifier=true
// newArchEnabled=true

SDK-Version-Anforderungen: Google erhöht regelmäßig die Minimum-SDK-Version für den Play Store. Und jede Third-Party-Library hat ihre eigenen SDK-Anforderungen — Konflikte sind vorprogrammiert.

NDK-Inkompatibilität: Manche native Module brauchen spezifische NDK-Versionen. Wenn zwei Libraries verschiedene NDK-Versionen fordern, wird es hässlich.

Die Lösung: Expo EAS Build

Unser Game-Changer war der Wechsel zu Expo EAS Build. Statt lokaler Builds kompilieren wir in der Cloud:

// Build für beide Plattformen mit einem Befehl
// eas build --platform all --profile production

// EAS kümmert sich um:
// ✅ Richtige Xcode-Version
// ✅ Richtige NDK/SDK-Versionen
// ✅ Code Signing (mit Managed Credentials)
// ✅ CocoaPods-Installation
// ✅ Gradle-Konfiguration

Seit wir EAS Build nutzen, haben sich unsere Build-Probleme um geschätzte 70 % reduziert. Der Cloud-Build sorgt für eine konsistente Umgebung, und das Managed-Credentials-System von Expo nimmt uns das Signing-Chaos ab.

2. Hermes vs. JSC (JavaScript Core)

Was ist Hermes?

Hermes ist Meta's eigene JavaScript-Engine, speziell für React Native optimiert. Seit React Native 0.70 ist Hermes die Standard-Engine und ersetzt JavaScriptCore (JSC).

Vorteile von Hermes:

Schnellerer App-Start (Bytecode-Precompilation)
Geringerer Speicherverbrauch
Bessere Garbage Collection
Optimiert für mobile Geräte

Hermes-spezifische Gotchas

Hermes ist großartig — aber es gibt Eigenheiten, die uns schon gebissen haben:

Date-Handling-Unterschiede: Hermes implementiert die JavaScript-Date-API etwas anders als JSC oder V8:

// ❌ Funktioniert in Chrome/JSC, aber NICHT zuverlässig in Hermes
const date = new Date('2026-03-30');
console.log(date.toLocaleDateString('de-AT'));
// Hermes gibt manchmal unerwartete Ergebnisse

// ✅ Besser: date-fns oder dayjs verwenden
import { format } from 'date-fns';
import { de } from 'date-fns/locale';

const formatted = format(new Date(2026, 2, 30), 'dd. MMMM yyyy', {
  locale: de,
});
// "30. März 2026" — immer korrekt

Intl-Support: Hermes hatte lange keinen vollständigen Intl-Support. Seit neueren Versionen ist es besser, aber wir empfehlen trotzdem:

// In app.json / app.config.ts für vollständigen Intl-Support:
// {
//   "expo": {
//     "jsEngine": "hermes",
//     "plugins": [
//       ["expo-build-properties", {
//         "android": { "extraProguardRules": "-keep class com.facebook.hermes.** { *; }" }
//       }]
//     ]
//   }
// }

// Polyfill für ältere Hermes-Versionen
import 'intl';
import 'intl/locale-data/jsonp/de-AT';

Debugging mit Hermes

Die alte Debugging-Methode (Chrome Remote Debugging) funktioniert mit Hermes nicht mehr zuverlässig. Stattdessen:

React Native DevTools (der neue Standard seit RN 0.76): Direkte Verbindung zur Hermes-Engine
Flipper: Netzwerk-Inspektion, Layout-Debugging, Datenbankansicht
console.log + LogBox: Immer noch das schnellste Debugging-Tool (ehrlich gesagt)

// Hermes-spezifisches Debugging:
// Performance-Profiling direkt in der Engine
if (__DEV__) {
  const Systrace = require('react-native/Libraries/Performance/Systrace');
  Systrace.setEnabled(true);
}

3. Native Module Pain

Wann braucht man ein Native Module?

Expo deckt mit seinem SDK die meisten Use Cases ab: Kamera, GPS, Push-Notifications, Biometrie, Filesystem. Aber manchmal braucht man Zugriff auf native Funktionalität, die kein fertiges Modul bietet:

Spezielle Bluetooth-LE-Protokolle
Proprietäre Hardware-SDKs
Custom Video-Processing
Integration mit nativen SDKs von Drittanbietern (z. B. Banking-SDKs)

Die „expo prebuild" Escape Hatch

Expo's Managed Workflow ist großartig — bis man native Code braucht. Die Lösung heißt expo prebuild:

// Generiert die nativen iOS/Android-Projekte
// npx expo prebuild

// Danach hat man Zugriff auf:
// ├── ios/
// │   ├── Podfile
// │   ├── YourApp.xcworkspace
// │   └── YourApp/
// └── android/
//     ├── build.gradle
//     ├── app/
//     └── settings.gradle

Wichtig: Nach prebuild verlieren Sie den Managed Workflow nicht komplett. Expo's Config Plugins erlauben es, native Änderungen deklarativ zu beschreiben, sodass prebuild reproduzierbar bleibt.

Bridging zwischen JS und Native

Die neue React Native Architektur (JSI + TurboModules) macht das Bridging deutlich besser als früher — aber es bleibt komplex:

// Beispiel: Ein einfaches TurboModule (TypeScript-Seite)
import { TurboModuleRegistry } from 'react-native';
import type { TurboModule } from 'react-native';

export interface Spec extends TurboModule {
  getDeviceToken(): Promise<string>;
  isNfcSupported(): boolean;
}

export default TurboModuleRegistry.getEnforcing<Spec>(
  'CustomDeviceModule',
);

Auf der nativen Seite (Swift/Kotlin) muss das entsprechende Gegenstück existieren — und hier passieren die meisten Fehler: falsche Methodennamen, falsche Typen, fehlende Registrierung.

Häufige Native-Module-Probleme

Autolinking-Fehler: React Native's Autolinking findet installierte native Module automatisch — meistens. Wenn nicht:

// ❌ "Cannot find module 'react-native-xyz'"
// nach npm install + pod install

// ✅ Checkliste:
// 1. npx react-native clean  (Cache leeren)
// 2. cd ios && pod install --repo-update
// 3. npx expo prebuild --clean  (bei Expo)
// 4. Metro Cache leeren: npx react-native start --reset-cache

Versions-Konflikte: Library A braucht react-native-reanimated 3.x, Library B braucht 2.x. Solche Konflikte erfordern oft, dass eine der Libraries geforkt oder ersetzt wird.

4. Performance Pitfalls

React Native ist performant — aber man kann sich leicht in die Fußschießen. Hier sind die häufigsten Performance-Fallen:

Re-Render-Hölle

Das mit Abstand häufigste Performance-Problem. Eine Komponente rendert 50x pro Sekunde, weil ein Parent-State sich ändert:

// ❌ Jedes Mal, wenn `parentState` sich ändert,
// rendert ExpensiveList komplett neu
function ParentComponent() {
  const [parentState, setParentState] = useState(0);
  const [items, setItems] = useState(longList);

  return (
    <View>
      <Text>{parentState}</Text>
      <ExpensiveList items={items} />
    </View>
  );
}

// ✅ Lösung: React.memo + useCallback
const ExpensiveList = React.memo(function ExpensiveList({
  items,
}: {
  items: Item[];
}) {
  return (
    <FlatList
      data={items}
      renderItem={({ item }) => <ItemRow item={item} />}
      keyExtractor={(item) => item.id}
    />
  );
});

Unser Tipp: Installieren Sie react-native-performance-flipper-plugin oder nutzen Sie React DevTools Profiler. Damit sehen Sie sofort, welche Komponenten zu oft rendern.

FlatList-Optimierung

FlatList ist die Standard-Komponente für lange Listen — aber ohne Tuning ist sie langsam:

// ✅ Optimierte FlatList-Konfiguration
<FlatList
  data={items}
  renderItem={renderItem}
  keyExtractor={(item) => item.id}
  // Layout-Berechnung überspringen → schnelleres Scrollen
  getItemLayout={(data, index) => ({
    length: ITEM_HEIGHT,
    offset: ITEM_HEIGHT * index,
    index,
  })}
  // Weniger Items gleichzeitig rendern
  windowSize={5} // Standard ist 21!
  maxToRenderPerBatch={10}
  initialNumToRender={10}
  // Scroll-Performance
  removeClippedSubviews={true}
  // Update-Optimierung
  extraData={selectedId} // Nur bei Bedarf
/>

Der häufigste Fehler: windowSize nicht setzen. Der Standardwert von 21 bedeutet, dass React Native 21 Bildschirme voller Items im Speicher hält — bei langen Listen ein massiver Speicherfresser.

Image Loading und Caching

React Native's eingebaute Image-Komponente hat kein Disk-Caching auf Android. Die Lösung:

// ✅ expo-image — der moderne Standard
import { Image } from 'expo-image';

<Image
  source={{ uri: 'https://example.com/photo.jpg' }}
  style={{ width: 200, height: 200 }}
  contentFit="cover"
  placeholder={blurhash} // BlurHash für Ladeanimation
  transition={200}
  cachePolicy="memory-disk" // Caching auf beiden Ebenen
/>

expo-image nutzt unter der Haube SDWebImage (iOS) und Glide (Android) — beide sind battle-tested und deutlich schneller als die Standard-Lösung.

JS Thread vs. UI Thread

Das wichtigste Architektur-Konzept, das man verstehen muss:

JS Thread: Führt Ihre Geschäftslogik, React-Rendering und Event-Handling aus
UI Thread (Main Thread): Rendert die nativen Komponenten auf den Bildschirm
Bridge/JSI: Kommunikation zwischen den beiden

Wenn der JS Thread blockiert ist (z. B. durch eine aufwändige Berechnung), friert die UI ein. Die Lösung:

// ❌ Blockiert den JS Thread
function processLargeDataset(data: BigData[]) {
  // 500ms Berechnung → UI friert ein
  return data.map(expensiveTransform).filter(complexFilter);
}

// ✅ Auf den UI Thread auslagern mit Reanimated Worklets
import { runOnUI } from 'react-native-reanimated';

// Oder: InteractionManager für nicht-kritische Arbeit
import { InteractionManager } from 'react-native';

InteractionManager.runAfterInteractions(() => {
  // Wird ausgeführt, nachdem alle Animationen/Transitions fertig sind
  processLargeDataset(data);
});

5. Der gefürchtete Upgrade-Prozess

Major Version Upgrades

React Native hat eine Geschichte von schwierigen Upgrades. Besonders der Sprung auf die neue Architektur (Fabric + TurboModules) war schmerzhaft:

Das Problem:

React Native hat keine SemVer-Garantien bei Minor-Releases (bis 0.76 war alles 0.x)
Jedes Upgrade kann native Code-Änderungen erfordern
Third-Party-Libraries sind oft nicht sofort kompatibel

Unser Workflow für Major Upgrades:

Branch erstellen und alle Dependencies aktualisieren
npx react-native upgrade-helper nutzen — zeigt Diff zwischen Versionen
Native Dateien manuell aktualisieren (oder npx expo prebuild --clean bei Expo)
Libraries einzeln testen — jede einzelne
Auf beiden Plattformen testen — iOS und Android separat

Expo SDK Upgrades

Expo-Upgrades sind deutlich weniger schmerzhaft, aber nicht schmerzfrei:

// Expo SDK Upgrade (z. B. SDK 52 → SDK 53)
// npx expo install expo@latest
// npx expo install --fix  // Aktualisiert alle Expo-Packages

// Dann: CHANGELOG lesen! Expo dokumentiert Breaking Changes gut.
// https://expo.dev/changelog

Unsere Faustregel: Wir upgraden innerhalb von 2 Wochen nach einem neuen Expo SDK Release. Je länger man wartet, desto mehr Libraries divergieren, und desto schmerzhafter wird das Upgrade.

Breaking Changes in nativen Dependencies

Das tückischste Problem: Eine Library, die Ihr Projekt nutzt, hat ein Breaking Update, das eine neue Minimum-iOS-Version oder eine andere Gradle-Version braucht. Plötzlich kompiliert nichts mehr, und man muss eine Kaskade von Upgrades durchführen.

Unsere Strategie: Wir pinnen Versionen in package.json (keine ^-Ranges für native Libraries) und upgraden bewusst:

// ❌ Gefährlich bei nativen Libraries
// "react-native-reanimated": "^3.0.0"

// ✅ Exakte Version pinnen
// "react-native-reanimated": "3.16.7"

Zwei Optionen, beide mit Eigenheiten:

Expo Router (unser Standard): File-based Routing wie in Next.js. Großartig für neue Projekte, aber:

Deep Linking erfordert sorgfältige Konfiguration der app.json
Dynamische Routen ([id].tsx) können bei komplexer Navigation verwirrend werden
TypeScript-Typisierung für Navigation-Params ist aufwändig

React Navigation (für komplexe Fälle): Mehr Flexibilität, aber mehr Boilerplate:

// Expo Router: Einfach, aber Deep Linking braucht Setup
// app/(tabs)/profile/[userId].tsx

// ✅ Deep Linking in app.json konfigurieren:
// {
//   "expo": {
//     "scheme": "myapp",
//     "plugins": [
//       ["expo-router", {
//         "origin": "https://myapp.at"
//       }]
//     ]
//   }
// }

Deep Linking — Komplexer als gedacht

Deep Linking klingt einfach: Ein Link öffnet die App an der richtigen Stelle. In der Praxis braucht man:

Universal Links (iOS) + App Links (Android) für HTTPS-Links
Apple's AASA-Datei (Apple App Site Association) auf dem Webserver
Android's assetlinks.json auf dem Webserver
Handling für „App nicht installiert" (Fallback auf Website)
Deferred Deep Links (Link merken → App installieren → richtige Seite öffnen)

// Deep Link Handling mit Expo Router
import { useURL } from 'expo-linking';
import { useRouter } from 'expo-router';

export function DeepLinkHandler() {
  const url = useURL();
  const router = useRouter();

  useEffect(() => {
    if (url) {
      const { path, queryParams } = parseURL(url);
      router.push(path);
    }
  }, [url]);

  return null;
}

Bei Development Builds will man den Navigation-State beim Hot Reload beibehalten. Expo Router macht das automatisch — aber bei React Navigation muss man es manuell einrichten, und es gibt Race Conditions beim App-Start.

7. Plattform-spezifische Bugs

Android-spezifische Probleme

Keyboard-Handling: Android handhabt die Soft Keyboard komplett anders als iOS. Die Tastatur kann Content verdecken, KeyboardAvoidingView verhält sich anders, und windowSoftInputMode in AndroidManifest.xml muss richtig konfiguriert sein:

// ❌ KeyboardAvoidingView verhält sich auf Android anders
<KeyboardAvoidingView behavior="padding">
  {/* Auf iOS: funktioniert. Auf Android: springt wild herum */}
</KeyboardAvoidingView>

// ✅ Plattform-spezifisches Behavior
import { Platform } from 'react-native';

<KeyboardAvoidingView
  behavior={Platform.OS === 'ios' ? 'padding' : 'height'}
  keyboardVerticalOffset={Platform.OS === 'ios' ? 64 : 0}
>
  {/* Funktioniert auf beiden Plattformen */}
</KeyboardAvoidingView>

StatusBar-Inkonsistenzen: Android hat eine transluzente StatusBar, iOS nicht. Die Höhe variiert je nach Gerät. Ohne react-native-safe-area-context ist Layout-Chaos vorprogrammiert.

Touch-Feedback: Android nutzt Ripple-Effekte, iOS Opacity-Changes. Pressable mit android_ripple deckt das ab, aber viele Entwickler vergessen es.

iOS-spezifische Probleme

Safe Area: Die Notch, Dynamic Island, Home Indicator — iOS hat viele „sichere Bereiche", die Content nicht überdecken sollen:

// ✅ Safe Area korrekt handhaben
import {
  SafeAreaProvider,
  useSafeAreaInsets,
} from 'react-native-safe-area-context';

function Screen() {
  const insets = useSafeAreaInsets();

  return (
    <View style={{ paddingTop: insets.top, paddingBottom: insets.bottom }}>
      {/* Content ist sicher vor Notch/Home Indicator */}
    </View>
  );
}

Keyboard Avoiding View auf iOS: Funktioniert grundsätzlich besser als auf Android, aber bei verschachtelten ScrollViews + TextInputs kommt es zu Sprüngen. Unsere Lösung: react-native-keyboard-aware-scroll-view statt dem eingebauten KeyboardAvoidingView.

Modal-Präsentation: iOS-Modals haben seit iOS 13 eine Card-Präsentation (halbe Bildschirmhöhe). React Native's Modal-Komponente unterstützt presentationStyle, aber die Gestik zum Schließen (Swipe Down) erfordert zusätzliche Konfiguration.

8. Testing-Herausforderungen

Unit Tests mit Jest

Jest funktioniert grundsätzlich gut mit React Native, aber es gibt Fallstricke:

// jest.config.js — unsere bewährte Konfiguration
module.exports = {
  preset: 'jest-expo', // Expo-Preset statt react-native
  setupFilesAfterSetup: ['./jest.setup.ts'],
  transformIgnorePatterns: [
    'node_modules/(?!((jest-)?react-native' +
      '|@react-native(-community)?' +
      '|expo(nent)?' +
      '|@expo(nent)?/.*' +
      '|@expo-google-fonts/.*' +
      '|react-navigation' +
      '|@react-navigation/.*' +
      '|@sentry/react-native' +
      '|native-base' +
      '|react-native-svg)/)',
  ],
};

Die transformIgnorePatterns sind der Klassiker: React Native Module sind ESM, Jest erwartet CJS. Jede neue Library muss potenziell zur Liste hinzugefügt werden.

E2E Testing: Detox vs. Maestro

Wir haben beide ausprobiert:

Detox (von Wix): Mächtig, aber komplexes Setup. Erfordert spezielle Build-Konfigurationen, und die Tests sind fragil bei UI-Änderungen.

Maestro (unser Favorit): YAML-basierte Tests, einfacheres Setup, visuelles Debugging:

// maestro/login-flow.yaml
// appId: at.exponent.app
// ---
// - launchApp
// - tapOn: "E-Mail"
// - inputText: "test@example.com"
// - tapOn: "Passwort"
// - inputText: "securepassword"
// - tapOn: "Anmelden"
// - assertVisible: "Willkommen"

Real Device vs. Simulator

Die unbequeme Wahrheit: Manche Bugs treten nur auf echten Geräten auf:

Push Notifications funktionieren nicht im iOS Simulator
Biometrische Authentifizierung verhält sich anders
Performance-Probleme sind auf älteren echten Geräten spürbar, aber im Simulator unsichtbar
Kamera-Integration braucht ein echtes Gerät

Unser Workflow: Development im Simulator, aber Testing immer auch auf mindestens 2 echten Geräten (ein älteres Android, ein aktuelles iPhone).

9. Lessons Learned: Unser Workflow, der den Pain minimiert

Nach Jahren mit React Native haben wir einen Workflow entwickelt, der die meisten Probleme von vornherein vermeidet:

1. Expo als Basis — immer. Der Managed Workflow mit EAS Build eliminiert 70 % der Build-Probleme. Nur wenn wirklich nötig, nutzen wir expo prebuild für nativen Zugriff.

2. Exakte Versionen für native Libraries. Keine ^-Ranges für Packages mit nativem Code. Upgrades nur bewusst und getestet.

3. Upgrade early, upgrade often. Wir upgraden Expo SDK innerhalb von 2 Wochen nach Release. Kleine, häufige Upgrades sind weniger schmerzhaft als ein großer Sprung nach 6 Monaten.

4. TypeScript strict mode. Typisierung fängt viele Fehler ab, bevor sie zu Runtime-Bugs werden — besonders bei Navigation-Params und API-Responses.

5. Plattform-Tests von Anfang an. Nicht „iOS first, Android later". Beide Plattformen von Tag 1 testen. Plattform-spezifische Bugs werden umso teurer, je später man sie findet.

6. expo-image statt Image. Immer. Die eingebaute Image-Komponente hat zu viele Schwächen.

7. React Native Performance Monitor. In Development immer aktiviert. FPS-Drops sofort fixen, nicht „später".

8. EAS Update für OTA-Patches. Kritische Bugfixes ohne App Store Review ausliefern — das allein rechtfertigt Expo.

FAQ

Ist React Native für große Apps geeignet trotz dieser Probleme?

Ja. Instagram, Discord und Shopify nutzen React Native in Production mit Millionen von Nutzern. Die hier beschriebenen Probleme sind real, aber lösbar. Mit dem richtigen Workflow (Expo + EAS Build + TypeScript) ist React Native eine ausgezeichnete Wahl für die meisten Business-Apps.

Wie lange dauert ein React Native Upgrade typischerweise?

Für ein Expo SDK Upgrade (z. B. SDK 52 auf 53): 2–4 Stunden bei einem gut gewarteten Projekt. Für ein Major React Native Upgrade ohne Expo: 1–3 Tage, je nach Anzahl der nativen Dependencies. Die Investition lohnt sich — aufgeschobene Upgrades werden exponentiell teurer.

Sollte man Hermes deaktivieren, wenn es Probleme macht?

Nein. Hermes ist der empfohlene Standard und wird aktiv weiterentwickelt. Statt Hermes zu deaktivieren, sollten Sie die spezifischen Probleme lösen — meistens fehlt ein Polyfill oder eine Library nutzt eine nicht unterstützte API. JSC wird langfristig weniger Support bekommen.

Wie findet man heraus, ob ein Performance-Problem im JS oder UI Thread liegt?

Nutzen Sie den React Native Performance Monitor (Shake-Gesture → „Show Perf Monitor"). Zwei FPS-Anzeigen: links JS Thread, rechts UI Thread. Wenn der JS Thread droppt, liegt es an Ihrer Logik/Rendering. Wenn der UI Thread droppt, ist es ein natives Rendering-Problem (oft Schatten, Opacity-Animationen oder zu viele Views).

Wann sollte man doch zu Native wechseln statt React Native Probleme zu lösen?

Wenn Ihr Hauptfeature eines dieser drei ist: Echtzeit-3D-Rendering, komplexe Videobearbeitung, oder extrem low-level Hardware-Kommunikation (z. B. medizinische Geräte). Für alles andere — E-Commerce, Social, Buchung, Dashboard, Content — ist React Native die wirtschaftlich bessere Wahl. Mehr dazu in unserem Vergleich React Native vs. Native.

Fazit

React Native ist nicht perfekt. Build-Probleme, Hermes-Eigenheiten, native Module, Performance-Pitfalls und Upgrade-Schmerzen sind real. Aber mit dem richtigen Setup — Expo, EAS Build, TypeScript, bewusste Upgrade-Zyklen — lassen sich die meisten dieser Probleme kontrollieren.

Die Alternative (zwei separate native Apps in Swift und Kotlin) hat ihre eigenen Probleme: doppelte Codebasis, doppeltes Testing, doppelte Kosten. In unserer Erfahrung überwiegen die Vorteile von React Native die Nachteile deutlich — solange man weiß, worauf man sich einlässt.

Sie planen eine App und möchten die Fehler vermeiden, die wir bereits gemacht haben? Wir beraten Sie gerne — fordern Sie ein unverbindliches Angebot an.

Dieser Artikel basiert auf unseren Erfahrungen bei exponent — Ihrer Agentur für App-Entwicklung in Österreich. Wir entwickeln React Native Apps für österreichische Unternehmen seit mehreren Jahren und kennen die Tücken aus erster Hand.

React Native Probleme & Lösungen: Ein ehrlicher Erfahrungsbericht aus der Praxis