React-Native-Upgrades werden Architekturarbeit
React Native 0.87 wurde am 11. August 2026 veroeffentlicht und aktiviert die Strict TypeScript API standardmaessig, bringt Metro 0.87, experimentellen Swift-Package-Manager-Support fuer iOS und erste Unterstuetzung fuer Android Gradle Plugin 9. Gleichzeitig steigen die Mindestanforderungen an Node.js, Kotlin und Android-Build-Konfiguration.
Fuer Produktteams ist die Botschaft klar: Ein Mobile-App-Upgrade ist nicht mehr nur ein Paketversionswechsel. Es beruehrt Typsicherheit, Imports, native Dependencies, CI-Images, Android-Gradle-Verhalten, iOS-Paketstrategie und Release-Vertrauen. Genau deshalb ist das Upgrade wertvoll, braucht aber einen kleinen Projektplan.
Die App vor dem Versionswechsel auditieren
Ein sicheres Upgrade beginnt mit einem Inventar der fragilen Stellen. Suche nach Deep Imports aus React-Native-Interna, eigener Metro-Konfiguration, nativen Modulen mit alten Headern, Android-Build-Logik auf Basis veralteter APIs und Release-Skripten, die aeltere Node- oder Gradle-Versionen voraussetzen.
Das Ziel ist nicht, jeden Fehler vorherzusagen. Es geht darum zu wissen, welche Teile der App technisch wahrscheinlich brechen und welche Teile Nutzer wirklich treffen wuerden. Ein Kundenportal, eine Field-App oder ein operatives Dashboard braucht eine andere Upgrade-Checkliste als eine einfache Content-App.
- Aktuelle Versionen von React Native, React, Expo, Node, Xcode, Gradle, AGP und Kotlin erfassen.
- Nach Imports aus `react-native/Libraries/*` und anderen privaten Pfaden suchen.
- Native Module markieren, die AppDelegate, Header, Build Phases, Berechtigungen oder Background Tasks beruehren.
- Festlegen, welche Geraete, OS-Versionen und authentifizierten Workflows vor Release bestehen muessen.
- Upgrade-Blocker von Cleanup-Aufgaben trennen, die warten koennen.
Die Strict TypeScript API als Qualitaetssignal nutzen
Die Strict TypeScript API macht die oeffentliche JavaScript-API von React Native zur standardmaessigen Wahrheit. Dadurch werden alte Annahmen sichtbar: private Imports, ungenaue Ref-Typen, veraltete Aliasse oder Hilfspfade, die nur funktioniert haben, weil Legacy-Typdefinitionen grosszuegig waren.
Diese Reibung ist nuetzlich. Wenn das Typsystem anschlaegt, zeigt es oft Code, der in einem spaeteren Release ohnehin brechen koennte. Teams sollten auf Root Exports und unterstuetzte Typen migrieren, statt jeden Fehler dauerhaft mit einem Opt-out zu verdecken. Ein Opt-out kann fuer gestaffelte Lieferung helfen, braucht aber Owner und Entfernungsdatum.
Metro-Aenderungen an der Developer Experience messen
Metro 0.87 verspricht schnellere Source-Map-Erzeugung und geringeren Speicherverbrauch. Beides zaehlt in groesseren Apps, in denen Debugging-Zeit leise zu Lieferkosten wird. Gleichzeitig entfernt das Upgrade alte Config-Formate und erwartet moderne TypeScript- und ESM-Konfiguration.
Ein guter Engineering-Check ist praktisch: App starten, die schwersten Screens ausloesen, React Native DevTools oeffnen, Source Maps pruefen und lokales Start- sowie Reload-Verhalten vergleichen. Wenn Entwickler weniger warten und mehr echten App-Zustand debuggen, zahlt das Upgrade bereits zurueck.
Swift Package Manager experimentell halten
React Native 0.87 fuegt einen opt-in Swift-Package-Manager-Pfad fuer iOS hinzu. Das ist attraktiv, weil es Ruby, Bundler und CocoaPods in manchen Workflows reduzieren kann. React Native beschreibt CocoaPods aber weiterhin als standardmaessig unterstuetzten Weg und weist darauf hin, dass sich Befehle und generiertes Layout noch aendern koennen.
Damit ist SwiftPM ein kontrolliertes Experiment, keine automatische Produktionsmigration. Teste es auf einem Branch, miss CI-Setup, pruefe native Dependencies, verifiziere Fresh-Clone-Verhalten und halte einen Rollback-Pfad bereit. Bei Apps mit vielen nativen Drittanbieterpaketen entscheidet die Reife des gesamten Dependency Graph.
Android Gradle Plugin 9 als eigenen Workstream planen
AGP 9 ist eine groessere Android-Build-Aenderung mit neuen oeffentlichen DSL-Interfaces und Kompatibilitaetsanforderungen. React Native 0.87 bringt erste Unterstuetzung dafuer, waehrend die Android-Dokumentation den Upgrade Assistant und sorgfaeltige Pruefung der Verhaltensaenderungen empfiehlt.
Fuer ein Mobile-Produkt sollte Android-Build-Arbeit nicht im JavaScript-Upgrade versteckt werden. CI-Images, JDK, Gradle Wrapper, Kotlin-Version, Compile SDK, Library-Kompatibilitaet und Release Signing brauchen eigene Verifikation. Ein gruenes lokales Debug-Build reicht nicht, wenn die Release-Pipeline noch alte Annahmen nutzt.
Expo-Projekte nach SDK-Takt koordinieren
Expo-Teams sollten das React-Native-Release ueber den Expo-SDK-Fahrplan lesen, statt blind zu aktualisieren. Expo SDK 55 wurde mit React Native 0.83 ausgeliefert und entfernt Legacy-Architecture-Support fuer SDK-55-Projekte und spaeter, waehrend React Native 0.87 zunaechst fuer Expo Canary eingeordnet wurde.
Damit brauchen Expo-Apps zwei Plaene: einen fuer den SDK-Migrationspfad und einen fuer Produkt-QA. Development Builds, EAS-Update-Verhalten, native Modulkompatibilitaet, Over-the-Air-Update-Strategie und Store-Submission-Timing bestimmen gemeinsam das sicherste Release-Fenster.
Ein praktischer Upgrade-Plan fuer produktive Apps
Fuer EDS-Labs-Mobile-Projekte ist der staerkste React-Native-0.87-Pfad gestaffelt und evidenzbasiert. Starte mit Dependency- und Import-Audits, aktualisiere Tooling in CI, nutze den Upgrade Helper, behebe Strict-API-Fehler, verifiziere native Builds und teste die wichtigsten Nutzerflows auf echten Geraeten oder repraesentativen Simulatoren.
Das Business-Ergebnis ist eine Mobile App, die aktuell bleibt, ohne die Release-Woche in einen Notfall zu verwandeln. Das Upgrade wird zu einer Gelegenheit, versteckte technische Schulden zu reduzieren, Typvertrauen zu verbessern, Debugging zu beschleunigen und native Plattformanforderungen kontrolliert zu halten.