React Native 0.87 und SwiftPM 2026: Modernes iOS-Build-System und Interviewfragen

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.

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.

# 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.

# 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:

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.

// Vor 0.87 - Bare Include
#import <RCTAppDelegate.h>
#import <RCTBridge.h>
#import <RCTRootView.h>

// Nach 0.87 - Namespaced Include
#import <React/RCTAppDelegate.h>
#import <React/RCTBridge.h>
#import <React/RCTRootView.h>

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.

import { useRef } from 'react';
import { View, TextInput, ViewInstance, TextInputInstance } from 'react-native';

export function FormComponent() {
  // Neue dedizierte Ref-Typen ersetzen generische RefObject<T>
  const containerRef = useRef<ViewInstance>(null);
  const inputRef = useRef<TextInputInstance>(null);

  const focusInput = () => {
    // Typsicherer Methodenzugriff
    inputRef.current?.focus();
  };

  return (
    <View ref={containerRef}>
      <TextInput ref={inputRef} placeholder="Email" />
    </View>
  );
}

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:

{
  "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.

Für AGP-9-Kompatibilitätsprobleme können Opt-Outs in android/gradle.properties hinzugefügt werden:

# 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.

Weitere Deprecations, die für zukünftige Entfernung vorgesehen sind, umfassen ImageBackground (View mit absolut positioniertem Image verwenden), DrawerLayoutAndroid (react-native-drawer-layout 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 und die Testing-Strategien Fragenbanken konsultiert werden.

Upgrade-Strategie für React Native 0.87-Projekte

Der React Native 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 zu Hermes V1 und Bridgeless-Mode-Performance-Charakteristiken konsultiert werden.