React-Native-Upgrades werden Architekturarbeit
React Native 0.87 wurde am 11. August 2026 veröffentlicht und aktiviert die Strict TypeScript API standardmäßig, bringt Metro 0.87, experimentellen Swift-Package-Manager-Support für iOS und erste Unterstützung für Android Gradle Plugin 9. Gleichzeitig steigen die Mindestanforderungen an Node.js, Kotlin und Android-Build-Konfiguration.
Für Produktteams ist die Botschaft klar: Ein Mobile-App-Upgrade ist nicht mehr nur ein Paketversionswechsel. Es berührt 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 ältere 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 würden. 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 berühren.
- Festlegen, welche Geräte, OS-Versionen und authentifizierten Workflows vor Release bestehen müssen.
- Upgrade-Blocker von Cleanup-Aufgaben trennen, die warten können.
Die Strict TypeScript API als Qualitätssignal nutzen
Die Strict TypeScript API macht die öffentliche JavaScript-API von React Native zur standardmäßigen Wahrheit. Dadurch werden alte Annahmen sichtbar: private Imports, ungenaue Ref-Typen, veraltete Aliasse oder Hilfspfade, die nur funktioniert haben, weil Legacy-Typdefinitionen großzügig waren.
Diese Reibung ist nützlich. Wenn das Typsystem anschlägt, zeigt es oft Code, der in einem späteren Release ohnehin brechen könnte. Teams sollten auf Root Exports und unterstützte Typen migrieren, statt jeden Fehler dauerhaft mit einem Opt-out zu verdecken. Ein Opt-out kann für gestaffelte Lieferung helfen, braucht aber Owner und Entfernungsdatum.
Metro-Änderungen an der Developer Experience messen
Metro 0.87 verspricht schnellere Source-Map-Erzeugung und geringeren Speicherverbrauch. Beides zählt in größeren 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 auslösen, React Native DevTools öffnen, Source Maps prüfen und lokales Start- sowie Reload-Verhalten vergleichen. Wenn Entwickler weniger warten und mehr echten App-Zustand debuggen, zahlt das Upgrade bereits zurück.
Swift Package Manager experimentell halten
React Native 0.87 fügt einen opt-in Swift-Package-Manager-Pfad für iOS hinzu. Das ist attraktiv, weil es Ruby, Bundler und CocoaPods in manchen Workflows reduzieren kann. React Native beschreibt CocoaPods aber weiterhin als standardmäßig unterstützten Weg und weist darauf hin, dass sich Befehle und generiertes Layout noch ändern können.
Damit ist SwiftPM ein kontrolliertes Experiment, keine automatische Produktionsmigration. Teste es auf einem Branch, miss CI-Setup, prüfe 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 größere Android-Build-Änderung mit neuen öffentlichen DSL-Interfaces und Kompatibilitätsanforderungen. React Native 0.87 bringt erste Unterstützung dafür, während die Android-Dokumentation den Upgrade Assistant und sorgfältige Prüfung der Verhaltensänderungen empfiehlt.
Für ein Mobile-Produkt sollte Android-Build-Arbeit nicht im JavaScript-Upgrade versteckt werden. CI-Images, JDK, Gradle Wrapper, Kotlin-Version, Compile SDK, Library-Kompatibilität und Release Signing brauchen eigene Verifikation. Ein grünes 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 über den Expo-SDK-Fahrplan lesen, statt blind zu aktualisieren. Expo SDK 55 wurde mit React Native 0.83 ausgeliefert und entfernt Legacy-Architecture-Support für SDK-55-Projekte und später, während React Native 0.87 zunächst für Expo Canary eingeordnet wurde.
Damit brauchen Expo-Apps zwei Pläne: einen für den SDK-Migrationspfad und einen für Produkt-QA. Development Builds, EAS-Update-Verhalten, native Modulkompatibilität, Over-the-Air-Update-Strategie und Store-Submission-Timing bestimmen gemeinsam das sicherste Release-Fenster.
Ein praktischer Upgrade-Plan für produktive Apps
Für EDS-Labs-Mobile-Projekte ist der stärkste 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 Geräten oder repräsentativen 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.