React Native 0.87 macht die Strict TypeScript API zum Standard. Hier ist Ihre Upgrade-Reihenfolge.

React Native 0.87 erschien am 11. August und ist das umfangreichste Breaking Release, das das Framework seit Längerem hatte. Die Hauptneuigkeit: Die Strict TypeScript API, die in 0.80 als optionale Vorschau eingeführt wurde, ist jetzt für jedes Projekt der Standard. Dazu kommen experimentelle Swift Package Manager-Unterstützung für iOS, erstklassige Android Gradle Plugin 9-Unterstützung und eine höhere Toolchain-Mindestanforderung. Node.js 22.13+, Kotlin 2.0+ mit gebündeltem 2.2 und compileSdk auf 37 angehoben.

Wenn Ihre App noch auf einer älteren Version läuft, ist das kein routinemäßiges Versions-Update. Das React Native-Team bezeichnet es als den größten Schritt in Richtung 1.0 seit langer Zeit – und die Liste der Entfernungen bestätigt das.

Was die Strict API tatsächlich ändert

Bisher wurden React Natives TypeScript-Typen separat vom Quellcode manuell gepflegt, sodass sie auseinanderdrifteten. Typen versprachen Dinge, die der Code nicht tat, und interne Dateipfade wurden nach außen sichtbar, als wären sie öffentlich. Die Strict API behebt das, indem sie die Typen direkt aus dem Quellcode generiert und den öffentlichen Vertrag auf das beschränkt, was react-native an seinem Root exportiert.

Die praktische Konsequenz: Deep Imports wie react-native/Libraries/... sind jetzt Typfehler. Wenn Sie jemals auf einen internen Pfad zugegriffen haben, um etwas zu holen, das nicht offiziell exportiert wurde, wird dieser Code die Typprüfung nicht mehr bestehen. Auch Ref-Typen ändern sich. Eingebaute Komponenten werden jetzt als Funktionen typisiert, nicht als Klassen, daher funktioniert useRef<View>() nicht mehr. Jede Komponente erhält stattdessen einen dedizierten Instanztyp wie ViewInstance und TextInputInstance.

Es gibt einen temporären Ausweg. Sie können mit customConditions: ["react-native-legacy-deep-imports"] in Ihrer tsconfig.json zu den alten manuellen Typen zurückwechseln. Betrachten Sie das als Atempause, nicht als Ziel. Das Team hat angekündigt, dass diese Option in einem zukünftigen Release entfernt wird – die Migration kommt also, ob Sie sie jetzt oder später angehen.

Ein Detail, das Ihnen einen schlechten Nachmittag erspart: Die Strict API betrifft nur die TypeScript-Analyse Ihres eigenen Projekts, begrenzt durch Ihre tsconfig.json, und setzt voraus, dass skipLibCheck aktiviert ist. Die React Native TypeScript-Konfiguration aktiviert es standardmäßig. Wenn Sie skipLibCheck deaktiviert haben, aktivieren Sie es wieder, bevor Sie anfangen – sonst werden Sie in Fehlern aus Drittanbieter-.d.ts-Dateien ertrinken, die Sie nicht beheben können.

Die Entfernungen, die bei ausgereiften Apps zuschlagen

Die Strict API macht die Schlagzeilen, aber die stillen Entfernungen sind das, was ältere Codebasen bricht. Einige, nach denen wir zuerst suchen würden:

• InteractionManager ist entfernt. Verschieben Sie aufgeschobene Arbeit zu requestIdleCallback.
• TurboModules sind jetzt immer aktiviert. Das useTurboModules-Feature-Flag wurde entfernt. Wenn Sie es noch umschalten, muss dieser Code weg.
• useColorScheme() gibt ColorSchemeName | null zurück und gibt nicht mehr 'unspecified' zurück. Jeder Branch, der diesen String behandelt, ist jetzt toter Code.
• Veraltete StatusBar-Props (backgroundColor, translucent) und ihre Setter wurden entfernt, ebenso der animated-Prop von Modal und die boolesche Unterstützung für keyboardShouldPersistTaps von ScrollView.

Keines davon ist für sich genommen schwierig. Das Problem ist, alle davon in einer großen App zu finden, bevor sie zur Laufzeit oder in einem fehlgeschlagenen CI-Lauf auftauchen.

SwiftPM und AGP 9: real, aber nicht dringend

Die Änderungen auf der nativen Seite interessieren uns aus unserer Mobile-Arbeit am meisten. Swift Package Manager-Unterstützung bedeutet, dass Sie ein iOS-Projekt endlich ohne Ruby, Bundler oder CocoaPods in der Pipeline bauen können. Es ist experimentell und optional; CocoaPods bleibt der Standard und der unterstützte Pfad, und es nutzt dieselben vorgefertigten XCFrameworks, die React Native bereits mitliefert. In unseren nativen iOS-Projekten war die CocoaPods-Toolchain eine zuverlässige Quelle für „funktioniert auf meiner Maschine“-CI-Fehler, daher ist ein Weg, der nur Xcode benötigt, wirklich willkommen. Wir würden noch keinen Produktions-Build darauf migrieren, aber es lohnt sich, es auf einem Branch auszuprobieren, um zu sehen, wie es mit Ihrem Abhängigkeitsgraph umgeht.

Bei Android ist 0.87 das erste Release mit AGP-9-Unterstützung. Die eigene Empfehlung des Teams ist aufschlussreich: Deaktivieren Sie vorerst AGP 9s eingebautes Kotlin und die neue DSL, indem Sie android.builtInKotlin=false und android.newDsl=false in gradle.properties setzen. Diese Deaktivierungen sollen rund um AGP 10 wegfallen. Anders gesagt: Google und das React Native-Team stabilisieren das noch, und der empfohlene Weg ist bewusst konservativ. Aus unserer Kotlin- und Jetpack Compose-Arbeit haben wir gelernt, solche Ratschläge zu respektieren. Einen großen Gradle-Plugin in der Woche seines Erscheinens zu übernehmen – mit den Standardeinstellungen, die die Maintainer selbst zum Deaktivieren empfehlen – ist der Weg, einen Sprint mit Build-Fehlern zu verlieren.

Die Upgrade-Reihenfolge, die wir verwenden würden

Hier ist die Abfolge, die wir für eine echte App durchführen würden, mit dem geringsten Risiko zuerst:

1. Aktualisieren Sie Ihre Toolchain, bevor Sie React Native anfassen. Wechseln Sie zu Node.js 22.13+, Kotlin 2.0+ und compileSdk 37 als separate, überprüfbare Schritte. Wenn hier etwas bricht, möchten Sie wissen, dass es die Toolchain war, nicht das Framework.
2. Upgraden Sie auf 0.87, während die Legacy-Typen-Deaktivierung noch aktiv ist. Das isoliert die Laufzeit-Entfernungen – die InteractionManager- und StatusBar-Änderungen – von der Typ-Migration, damit Sie jeweils nur ein Problem debuggen.
3. Aktivieren Sie die Strict API zuletzt. Entfernen Sie die Deaktivierung, führen Sie tsc aus und arbeiten Sie die Deep-Import- und Ref-Typ-Fehler in einem dedizierten Durchgang durch. Das ist die Änderung, die am ehesten gemeinsamen Code und Drittanbieter-Bibliotheken betrifft – geben Sie ihr deshalb einen eigenen PR.

Das, was Sie heute tun können, noch vor jedem Upgrade: Führen Sie eine projektweite Suche nach react-native/Libraries/ und allen Deep Imports in React Native-Interna durch. Dieser eine Grep-Befehl zeigt Ihnen, wie viel Strict-API-Arbeit tatsächlich auf Sie wartet. Wenn die Zahl null ist, ist dieses Upgrade größtenteils mechanisch. Wenn sie in den Hunderten liegt, führen Sie ein Planungsgespräch – kein Freitagsnachmittags-Update.

Es gibt hier eine umfassendere Lektion, die wir im Web und auf Mobilgeräten gleichermaßen sehen. Wenn wir Cloud-native Apps für Unternehmenskunden entwickeln, sind die Frameworks, die überleben, diejenigen, die schließlich eine klare Grenze um ihre öffentliche API ziehen und dabei bleiben. React Native driftete jahrelang, weil die Typen und der Quellcode zwei verschiedene Dinge waren, die manuell gepflegt wurden. Dieses Release ist die Korrektur. Es schmerzt einmal, und dann hören interne Refactorings auf, Ihre Breaking Changes zu sein. Das ist ein lohnenswerter Tausch, und die Schweizer Enterprise-Teams, mit denen wir zusammenarbeiten – bei denen ein ungeplanter Breaking Change die Compliance-Freigabe blockieren kann –, werden eine vorhersehbare API einer bequemen vorziehen, jedes Mal. Sie können die Art der Mobile- und Entwicklungsarbeit sehen, die wir über native und plattformübergreifende Projekte hinweg leisten.

Wenn Ihnen ein Audit „welche unserer Imports werden bald zu Typfehlern“ vertraut klingt, sprechen Sie mit uns. Wir helfen Teams dabei, Framework-Upgrades zu planen, die sich nicht in monatelange Nebenbaustellen verwandeln.