React Native 0.87 i SwiftPM w 2026: Nowoczesny Build iOS i Pytania Rekrutacyjne

React Native 0.87, wydany 11 sierpnia 2026, wprowadza eksperymentalne wsparcie dla Swift Package Manager (SwiftPM) w buildach iOS, stanowiąc pierwszy krok w kierunku wyeliminowania CocoaPods z projektów React Native. Ta wersja ustawia również Strict TypeScript API jako domyślne, dostarcza Metro 0.87 z dwukrotnie szybszym generowaniem source map oraz podnosi minimalne wymagania narzędziowe do Node.js 22, Kotlin 2.0 i Android compileSdk 37.

Swift Package Manager zastępuje CocoaPods dla zależności iOS

Wsparcie SwiftPM w React Native 0.87 jest opcjonalne i eksperymentalne. CocoaPods pozostaje domyślnym menedżerem zależności dla aplikacji produkcyjnych. Ścieżka SwiftPM wykorzystuje te same prekompilowane XCFrameworks, które React Native już publikuje, więc nie są wymagane żadne dodatkowe pobierania binariów.

Kluczowa korzyść: projekt oparty na SwiftPM wymaga tylko Xcode. Ruby, Bundler i CocoaPods nie są już potrzebne na maszynach deweloperów ani w pipeline'ach CI.

# ios-swiftpm-setup.sh
# Krok 1: Przejdź do katalogu iOS
cd ios

# Krok 2: Dezintegruj CocoaPods i wygeneruj referencje SwiftPM
npx react-native spm --deintegrate

# Krok 3: Otwórz projekt w Xcode i zbuduj
open MyApp.xcworkspace

Polecenie spm --deintegrate wstrzykuje referencje pakietów Swift do istniejącego .xcodeproj zamiast zastępować plik projektu. Ustawienia podpisywania kodu, fazy buildu i capabilities pozostają nienaruszone. Aby cofnąć zmianę, należy uruchomić npx react-native spm deinit.

Jak działa autolinkowanie SwiftPM bez pod install

Po początkowej konfiguracji zmiany zależności uruchamiają automatyczne relinkowanie. Instalacja lub usunięcie natywnego pakietu za pomocą npm lub yarn, a następnie build - projekt wykrywa zmiany i ponownie uruchamia autolinkowanie podczas fazy buildu Xcode.

# dependency-workflow.sh
# Zainstaluj natywną zależność
npm install react-native-reanimated

# Build uruchamia automatyczne relinkowanie
npx react-native run-ios
# Nie wymaga pod install

Dla świeżych klonów i środowisk CI należy raz uruchomić npx react-native spm przed pierwszym buildem. To generuje plik Package.swift i rozwiązuje zależności pakietów Swift.

Ograniczenia SwiftPM i gotowość produkcyjna

Wsparcie SwiftPM w wersji 0.87 niesie ze sobą istotne ograniczenia wpływające na decyzje o adopcji:

Dla aplikacji produkcyjnych CocoaPods pozostaje rekomendowaną ścieżką. Zespoły oceniające SwiftPM powinny stworzyć prototyp na osobnej gałęzi i przetestować pełne drzewo zależności przed podjęciem decyzji o migracji.

Breaking Change: Przestrzenie nazw w Native Modules

React Native 0.87 wprowadza namespacing dla natywnych modułów. Moduły muszą teraz deklarować unikalną przestrzeń nazw, aby uniknąć kolizji między bibliotekami. Ta zmiana wymaga aktualizacji kodu natywnego w istniejących modułach.

import { TurboModuleRegistry } from 'react-native';
import type { TurboModule } from 'react-native';

export interface Spec extends TurboModule {
  multiply(a: number, b: number): number;
}

// Nowa składnia z namespace w 0.87
export default TurboModuleRegistry.getEnforcing<Spec>(
  'com.myapp.MathModule'
);

Format namespace podąża za konwencją odwrotnej domeny (com.company.ModuleName). Istniejące moduły bez namespace'a nadal działają, ale generują ostrzeżenia o deprecjacji.

Strict TypeScript API jako domyślny standard

Strict TypeScript API, wprowadzone jako opt-in w 0.86, staje się domyślne w 0.87. Ta zmiana wymusza poprawne typowanie natywnych modułów i komponentów, eliminując częste błędy runtime.

// Przed: luźne typowanie akceptowało nieprawidłowe propsy
<View style={{ backgroundColor: 123 }} />

// Po: Strict API wymaga prawidłowych typów
<View style={{ backgroundColor: '#fff' }} />

Projekty migrujące z wcześniejszych wersji mogą napotkać błędy TypeScript. Większość można naprawić aktualizując propsy do prawidłowych typów lub dodając explicit type assertions.

Metro 0.87: Dwukrotnie szybsze Source Maps

Metro bundler w wersji 0.87 przynosi znaczące ulepszenia wydajności. Generowanie source map jest teraz dwukrotnie szybsze dzięki równoległemu przetwarzaniu i optymalizacjom pamięci.

module.exports = {
  transformer: {
    // Nowe opcje w Metro 0.87
    experimentalImportSupport: true,
    inlineRequires: true,
  },
  resolver: {
    // Szybsze rozwiązywanie modułów
    unstable_enableSymlinks: true,
    unstable_enablePackageExports: true,
  },
};

Dla dużych projektów te optymalizacje mogą skrócić czas buildu o kilka minut w trybie release.

Podniesione wymagania toolchain

React Native 0.87 wymaga nowszych wersji narzędzi:

Przed aktualizacją należy zweryfikować kompatybilność środowiska CI i maszyn deweloperskich.

Pytania rekrutacyjne: React Native 0.87 i SwiftPM

Poniższe pytania pomagają w przygotowaniu do rozmów rekrutacyjnych dotyczących najnowszych funkcji React Native.

Pytanie 1: Jakie są główne korzyści z przejścia na SwiftPM w React Native?

Wzorcowa odpowiedź: Główne korzyści to eliminacja zależności od Ruby i CocoaPods w środowisku deweloperskim oraz pipeline'ach CI. Projekt oparty na SwiftPM wymaga tylko Xcode do budowania. Dodatkowo SwiftPM jest wbudowanym menedżerem pakietów Apple, co oznacza lepszą integrację z ekosystemem iOS i potencjalnie szybsze czasy rozwiązywania zależności.

Pytanie 2: Dlaczego SwiftPM jest nadal eksperymentalny w 0.87?

Wzorcowa odpowiedź: Status eksperymentalny wynika z trzech głównych ograniczeń: nie wszystkie biblioteki społeczności dostarczają jeszcze pliki Package.swift, API poleceń może się zmienić w przyszłych wersjach, oraz dokumentacja i zasoby do rozwiązywania problemów są ograniczone. React Native Team zaleca CocoaPods dla aplikacji produkcyjnych do czasu stabilizacji wsparcia SwiftPM.

Pytanie 3: Jak działa autolinkowanie w SwiftPM w porównaniu do CocoaPods?

Wzorcowa odpowiedź: W modelu CocoaPods autolinkowanie wymaga uruchomienia pod install po każdej zmianie zależności. W modelu SwiftPM autolinkowanie jest zintegrowane z fazą buildu Xcode - zmiana zależności npm/yarn automatycznie uruchamia relinkowanie podczas następnego buildu bez dodatkowych poleceń. Wyjątkiem są świeże klony i CI, gdzie należy raz uruchomić npx react-native spm.

Pytanie 4: Co oznacza Strict TypeScript API dla istniejących projektów?

Wzorcowa odpowiedź: Strict TypeScript API wymusza poprawne typowanie propsów komponentów i parametrów natywnych modułów. Dla istniejących projektów oznacza to potencjalne błędy kompilacji TypeScript, które ujawniają wcześniej ukryte problemy typowania. Większość błędów można naprawić aktualizując nieprawidłowe typy lub dodając explicit assertions. To zmiana przełomowa, ale poprawia jakość kodu i zmniejsza błędy runtime.

Pytanie 5: Jak namespace'ing wpływa na tworzenie natywnych modułów?

Wzorcowa odpowiedź: Od wersji 0.87 natywne moduły muszą deklarować unikalną przestrzeń nazw w formacie odwrotnej domeny, np. com.myapp.ModuleName. Ta zmiana zapobiega kolizjom nazw między różnymi bibliotekami, które mogłyby definiować moduły o tej samej nazwie. Istniejące moduły bez namespace'a nadal działają, ale generują ostrzeżenia o deprecjacji i powinny zostać zaktualizowane przed następną wersją major.

Migracja z 0.86 do 0.87

Proces migracji wymaga uwzględnienia kilku zmian:

# Aktualizacja zależności
npm install react-native@0.87.0

# Aktualizacja natywnych projektów
npx react-native upgrade

# Weryfikacja kompatybilności TypeScript
npm run type-check

Najczęstsze problemy migracyjne dotyczą błędów TypeScript związanych ze Strict API oraz konieczności aktualizacji bibliotek natywnych do wersji wspierających nowy namespace'ing.

Podsumowanie

React Native 0.87 stanowi istotny krok naprzód w modernizacji ekosystemu iOS. Eksperymentalne wsparcie SwiftPM otwiera drogę do uproszczenia toolchaina, eliminując zależności od Ruby i CocoaPods. Strict TypeScript API poprawia jakość kodu i bezpieczeństwo typów. Ulepszenia Metro przyspieszają proces budowania.

Dla zespołów planujących adopcję zaleca się pozostanie przy CocoaPods w projektach produkcyjnych, jednocześnie testując SwiftPM na osobnych gałęziach. Przygotowanie do rozmów rekrutacyjnych powinno obejmować zrozumienie różnic między modelami zarządzania zależnościami oraz praktyczne doświadczenie z nowymi funkcjami TypeScript.