# React Native 0.87 und SwiftPM 2026: Modernes iOS-Build-System und Interviewfragen > React Native 0.87 bringt experimentelle Swift Package Manager-Unterstützung für iOS-Builds. Dieser Leitfaden behandelt SwiftPM-Einrichtung, die Strict TypeScript API, Metro 0.87-Optimierungen und Interviewfragen für Senior Mobile-Entwickler. - Published: 2026-09-03 - Updated: 2026-09-03 - Author: Anthony Fillion-Maillet - Tags: react-native, ios, swiftpm, typescript, mobile-development - Reading time: 9 min --- React Native 0.87, veröffentlicht am 11. August 2026, führt experimentelle Swift Package Manager (SwiftPM)-Unterstützung für iOS-Builds ein und markiert damit den ersten Schritt zur Eliminierung von CocoaPods aus React Native-Projekten. Diese Version macht die Strict TypeScript API zum Standard, liefert Metro 0.87 mit 2x schnellerer Source-Map-Generierung und erhöht die Mindestanforderungen an die Toolchain auf Node.js 22, Kotlin 2.0 und Android compileSdk 37. > **SwiftPM-Einrichtung mit einem Befehl** > > Nach der Deintegration von CocoaPods genügt einmalig `npx react-native spm --deintegrate`. Das Projekt verknüpft dann native Abhängigkeiten bei jedem Build automatisch neu, ohne `pod install`. ## Swift Package Manager ersetzt CocoaPods für iOS-Abhängigkeiten Die SwiftPM-Unterstützung in React Native 0.87 ist opt-in und experimentell. CocoaPods bleibt der Standard-Dependency-Manager für Produktionsanwendungen. Der SwiftPM-Pfad verwendet dieselben vorkompilierten XCFrameworks, die React Native bereits veröffentlicht, sodass keine zusätzlichen Binary-Downloads erforderlich sind. Der entscheidende Vorteil: Ein SwiftPM-basiertes Projekt benötigt nur Xcode. Ruby, Bundler und CocoaPods sind auf Entwicklermaschinen oder in CI-Pipelines nicht mehr erforderlich. ```bash # ios-swiftpm-setup.sh # Schritt 1: Zum iOS-Verzeichnis navigieren cd ios # Schritt 2: CocoaPods deintegrieren und SwiftPM-Referenzen generieren npx react-native spm --deintegrate # Schritt 3: Projekt in Xcode öffnen und bauen open MyApp.xcworkspace ``` Der Befehl `spm --deintegrate` injiziert Swift-Package-Referenzen in das bestehende `.xcodeproj`, anstatt die Projektdatei zu ersetzen. Code-Signing-Einstellungen, Build-Phasen und Capabilities bleiben unberührt. Um die Änderung rückgängig zu machen, kann `npx react-native spm deinit` ausgeführt werden. ## Funktionsweise von SwiftPM-Autolinking ohne pod install Nach der initialen Einrichtung lösen Abhängigkeitsänderungen automatisches Relinking aus. Ein natives Paket kann mit npm oder yarn installiert oder entfernt werden, dann erfolgt der Build. Das Projekt erkennt Änderungen und führt Autolinking während der Xcode-Build-Phase erneut aus. ```bash # dependency-workflow.sh # Native Abhängigkeit installieren npm install react-native-reanimated # Build löst automatisches Relinking aus npx react-native run-ios # Kein pod install erforderlich ``` Für frische Clones und CI-Umgebungen muss `npx react-native spm` einmal vor dem ersten Build ausgeführt werden. Dieser Befehl generiert die `Package.swift`-Datei und löst Swift-Package-Abhängigkeiten auf. ## SwiftPM-Einschränkungen und Produktionsreife Die SwiftPM-Unterstützung in 0.87 bringt wichtige Einschränkungen mit sich, die Adoptionsentscheidungen beeinflussen: | Einschränkung | Auswirkung | |---------------|------------| | Community-Library-Support | Jede Library muss eine `Package.swift`-Datei mitliefern | | Befehlsstabilität | Flags und generiertes Layout können sich in 0.88+ ändern | | CI-Konfiguration | Erfordert `npx react-native spm`-Schritt vor Builds | | Dokumentation | Begrenzte Troubleshooting-Ressourcen verfügbar | Für Produktionsanwendungen bleibt CocoaPods der empfohlene Weg. Teams, die SwiftPM evaluieren, sollten auf einem Branch prototypen und ihren vollständigen Abhängigkeitsbaum testen, bevor sie sich zur Migration entschließen. ## Breaking Change: Namespaced iOS-Header-Imports React Native 0.87 liefert neue XCFrameworks: `ReactNativeHeaders.xcframework` und `ReactNativeDependenciesHeaders.xcframework`. Native Module, die Bare-Form-Angle-Includes verwenden, müssen das `React/`-Namespace-Präfix hinzufügen. ```objective-c // AppDelegate.m // Vor 0.87 - Bare Include #import #import #import // Nach 0.87 - Namespaced Include #import #import #import ``` Diese Änderung gilt sowohl für CocoaPods- als auch für SwiftPM-Builds. Projekte mit benutzerdefinierten nativen Modulen müssen alle Header-Imports vor dem Upgrade aktualisieren. ## Strict TypeScript API: Die neue Standard-JavaScript-Schnittstelle Die Strict TypeScript API, die in 0.80 vorgestellt wurde, wird in 0.87 zum Standard. Typen werden jetzt direkt aus dem React Native-Quellcode generiert, wodurch Abweichungen zwischen TypeScript-Definitionen und tatsächlichem Laufzeitverhalten eliminiert werden. ```typescript // component-refs.tsx import { useRef } from 'react'; import { View, TextInput, ViewInstance, TextInputInstance } from 'react-native'; export function FormComponent() { // Neue dedizierte Ref-Typen ersetzen generische RefObject const containerRef = useRef(null); const inputRef = useRef(null); const focusInput = () => { // Typsicherer Methodenzugriff inputRef.current?.focus(); }; return ( ); } ``` Drei Breaking-Type-Änderungen erfordern während der Migration Aufmerksamkeit: 1. **Deep Imports blockiert**: `react-native/Libraries/*`-Pfade erzeugen jetzt Typfehler. Alle Exporte müssen vom Root-Paket `react-native` kommen. 2. **Ref-Typ-Updates**: `ViewInstance` und `TextInputInstance` ersetzen generische Ref-Typen. Die `*Properties`-Typ-Aliase werden zugunsten von `*Props` entfernt. 3. **useColorScheme-Änderung**: Gibt `ColorSchemeName | null` zurück anstelle des bisherigen String-Werts `'unspecified'`. ## Opt-Out aus Strict TypeScript während der Migration Teams, die mehr Zeit für die Migration benötigen, können Legacy-Deep-Imports bis React Native 0.88 wiederherstellen: ```json // tsconfig.json { "extends": "@react-native/typescript-config", "compilerOptions": { "customConditions": ["react-native", "react-native-legacy-deep-imports"] } } ``` Diese Ausweichmöglichkeit wird in React Native 0.89 entfernt. Projekte sollten die Migration vor diesem Release priorisieren. ## Metro 0.87: 2x schnellere Source Maps und 50% weniger Speicher Metro Bundler Version 0.87 bringt signifikante Performance-Verbesserungen, die den Entwicklungsworkflow und die Startzeit der React Native DevTools beeinflussen. Die Source-Map-Generierung ist durch optimierte String-Behandlung 2x schneller. DevTools laden schneller, da Source Maps während Development-Builds effizienter generiert werden. Der Speicherverbrauch sinkt um 50% durch effizientere Source-Map-Speicherung. Dies ist relevant für große Codebasen, bei denen Metro zuvor während langer Entwicklungssitzungen erheblichen RAM verbrauchte. Weitere Metro-Änderungen: - Stabile Unterstützung für TypeScript-Konfigurationsdateien (`metro.config.mts`) - ESM-Konfigurationsdatei-Unterstützung neben CommonJS - Package-Self-Resolve im Resolver - Eingestellte Unterstützung für `.es6`-Dateierweiterungen und YAML-Konfigurationsdateien ## Mindestanforderungen an die Toolchain für React Native 0.87 Dieses Release erhöht die Mindestversionsanforderungen in der gesamten Toolchain. CI-Pipelines und Entwicklerumgebungen müssen vor dem Upgrade aktualisiert werden. | Anforderung | Version | |-------------|--------| | Node.js | ≥ 22.13.0 | | Kotlin | ≥ 2.0 (mitgeliefert: 2.2.0) | | Android minCompileSdk | 34 | | Android compileSdk | 37 | | Android Gradle Plugin | 9.x | Für AGP-9-Kompatibilitätsprobleme können Opt-Outs in `android/gradle.properties` hinzugefügt werden: ```properties # android/gradle.properties # Temporäre Opt-Outs für AGP-9-Migration android.builtInKotlin=false android.newDsl=false ``` ## Entfernte APIs in React Native 0.87 Mehrere veraltete APIs werden in diesem Release entfernt. Projekte, die diese APIs verwenden, müssen vor dem Upgrade refaktoriert werden. | Entfernte API | Ersatz | |---------------|--------| | `InteractionManager` | `requestIdleCallback` | | `Modal` animated prop | Standard-Übergangsverhalten verwenden | | `NativeMethods` Typ | `HostInstance` | | `useTurboModules` Flag | Immer aktiviert, Flag entfernt | | `Touchable` Root-Export | `ViewProps` direkt erweitern | | `react-native/rn-get-polyfills` | `@react-native/js-polyfills` | Weitere Deprecations, die für zukünftige Entfernung vorgesehen sind, umfassen `ImageBackground` (`View` mit absolut positioniertem `Image` verwenden), `DrawerLayoutAndroid` ([react-native-drawer-layout](https://github.com/react-navigation/react-navigation/tree/main/packages/drawer) verwenden) und `react-native/Libraries/Core/InitializeCore` (`react-native/setup-env` verwenden). ## React Native 0.87 Interviewfragen für Senior-Entwickler Diese Fragen erscheinen in Senior-Mobile-Developer-Interviews nach großen React Native-Releases. Das Verständnis der architektonischen Entscheidungen hinter SwiftPM-Support und der Strict TypeScript API demonstriert Framework-Level-Wissen. **F: Warum führt React Native 0.87 SwiftPM als experimentell ein, anstatt CocoaPods sofort zu ersetzen?** SwiftPM-Support hängt davon ab, dass Community-Libraries `Package.swift`-Dateien mitliefern. Anders als bei CocoaPods, wo ein zentrales `Podspec`-Registry existiert, erfordert SwiftPM, dass jeder Library-Autor native Swift-Package-Konfiguration hinzufügt. Die experimentelle Phase ermöglicht dem Ökosystem, SwiftPM schrittweise zu adoptieren, während CocoaPods für Produktionsanwendungen stabil bleibt. Zusätzlich können sich CLI-Befehle und generiertes Projektlayout basierend auf Entwickler-Feedback ändern, bevor sie stabilisiert werden. **F: Welches Problem löst die Strict TypeScript API, das manuell gepflegte Typdefinitionen nicht lösen konnten?** Manuell gepflegte Typdefinitionen weichen zwischen Releases vom Laufzeitverhalten ab. Interne Refaktorierungen, die Funktionssignaturen ändern oder Parameter hinzufügen, werden möglicherweise nicht sofort in den Typen reflektiert, was zu Laufzeitabstürzen führt, die TypeScript hätte abfangen sollen. Die Strict API generiert Typen direkt aus dem Quellcode, wodurch Typen autoritativ statt aspirativ werden. Sie blockiert auch Deep Imports, die auf instabile interne APIs zugreifen, und verhindert Brüche, wenn sich diese Interna ändern. **F: Wie unterscheidet sich SwiftPM-Autolinking von CocoaPods-Autolinking in React Native?** CocoaPods-Autolinking läuft während `pod install`, was Entwickler nach Abhängigkeitsänderungen manuell ausführen müssen. SwiftPM-Autolinking läuft während der Xcode-Build-Phase automatisch. Das Build-System erkennt Abhängigkeitsänderungen und regeneriert das Package-Manifest ohne manuelles Eingreifen. Dies eliminiert eine häufige Quelle von "es funktioniert auf meinem Rechner"-Problemen, bei denen Entwickler vergessen, `pod install` nach dem Pullen von Änderungen auszuführen. Für zusätzliche React Native Interview-Vorbereitung können der [Native Modules Deep Dive](/technologies/react-native/interview-questions/rn-native-modules) und die [Testing-Strategien](/technologies/react-native/interview-questions/rn-testing) Fragenbanken konsultiert werden. ## Upgrade-Strategie für React Native 0.87-Projekte Der [React Native Upgrade Helper](https://react-native-community.github.io/upgrade-helper/) generiert einen Diff zwischen dem aktuellen Projekttemplate und 0.87. Dieser Diff zeigt genau, welche Dateien geändert werden müssen. Diese Migrationsschritte sollten priorisiert werden: 1. **Node.js auf 22.13.0+ aktualisieren** und sicherstellen, dass CI-Umgebungen übereinstimmen 2. **TypeScript-Kompilierung ausführen**, um Deep-Import-Verletzungen zu identifizieren 3. **Ref-Typen aktualisieren** von generischen zu dedizierten Instance-Typen 4. **iOS-Header-Imports aktualisieren** auf Namespaced-Format 5. **Vollständigen nativen Abhängigkeitsbaum testen** vor Aktivierung von SwiftPM Für Expo-Projekte ist React Native 0.87 in `expo@canary`-Releases verfügbar. Produktions-Expo-Projekte sollten auf das stabile SDK-Release warten. ## Was 0.87 SwiftPM-Support für iOS-Build-Zeiten bedeutet SwiftPM eliminiert `pod install` aus dem Entwicklungsworkflow, aber die initiale Projekteinrichtung erfordert mehr Zeit. Der Befehl `npx react-native spm` löst Swift-Packages aus dem Quellcode auf, was länger dauert als das Herunterladen vorkompilierter CocoaPods-Binaries. Nachfolgende Builds profitieren von Xcodes inkrementeller Package-Auflösung. Nur geänderte Packages werden erneut abgerufen. Für Teams mit häufigen Abhängigkeitsänderungen kann dieser inkrementelle Ansatz schneller sein als wiederholte `pod install`-Zyklen. Die CI-Optimierung unterscheidet sich zwischen beiden Ansätzen. CocoaPods cached `Pods/`-Verzeichnisse effektiv. SwiftPM cached über Xcodes Derived Data, was andere Cache-Key-Strategien erfordert. Teams, die CI-Pipelines migrieren, sollten beide Ansätze mit ihrem spezifischen Abhängigkeitsset benchmarken. Für verwandte iOS-Build-Optimierungstechniken kann der [React Native New Architecture Guide](/blog/react-native/react-native-new-architecture-hermes-v1-bridgeless) zu Hermes V1 und Bridgeless-Mode-Performance-Charakteristiken konsultiert werden. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/de/blog/react-native/react-native-087-swiftpm-ios-build-interview-questions