React Native 0.87 e SwiftPM nel 2026: Build iOS Moderno e Domande per Colloqui

React Native 0.87, rilasciato l'11 agosto 2026, introduce il supporto sperimentale per Swift Package Manager (SwiftPM) nelle build iOS, segnando il primo passo verso l'eliminazione di CocoaPods dai progetti React Native. Questa versione rende la Strict TypeScript API l'impostazione predefinita, include Metro 0.87 con generazione di source map 2x più veloce e aumenta i requisiti minimi della toolchain a Node.js 22, Kotlin 2.0 e Android compileSdk 37.

Swift Package Manager Sostituisce CocoaPods per le Dipendenze iOS

Il supporto SwiftPM in React Native 0.87 è opt-in e sperimentale. CocoaPods rimane il gestore di dipendenze predefinito per le applicazioni in produzione. Il percorso SwiftPM utilizza gli stessi XCFramework precompilati che React Native già pubblica, quindi non sono richiesti download binari aggiuntivi.

Il vantaggio principale: un progetto basato su SwiftPM richiede solo Xcode. Ruby, Bundler e CocoaPods non sono più necessari sulle macchine degli sviluppatori o nelle pipeline CI.

# ios-swiftpm-setup.sh
# Passo 1: Navigare nella directory iOS
cd ios

# Passo 2: Deintegrare CocoaPods e generare riferimenti SwiftPM
npx react-native spm --deintegrate

# Passo 3: Aprire il progetto in Xcode e compilare
open MyApp.xcworkspace

Il comando spm --deintegrate inietta riferimenti ai pacchetti Swift nel .xcodeproj esistente invece di sostituire il file di progetto. Le impostazioni di code signing, le fasi di build e le capabilities rimangono intatte. Per annullare la modifica, eseguire npx react-native spm deinit.

Come Funziona l'Autolinking SwiftPM Senza pod install

Dopo la configurazione iniziale, le modifiche alle dipendenze attivano il relinking automatico. Installare o rimuovere un pacchetto nativo con npm o yarn, quindi eseguire la build. Il progetto rileva le modifiche ed esegue nuovamente l'autolinking durante la fase di build di Xcode.

# dependency-workflow.sh
# Installare una dipendenza nativa
npm install react-native-reanimated

# La build attiva il relinking automatico
npx react-native run-ios
# Nessun pod install richiesto

Per i clone freschi e gli ambienti CI, eseguire npx react-native spm una volta prima della prima build. Questo genera il file Package.swift e risolve le dipendenze dei pacchetti Swift.

Limitazioni di SwiftPM e Prontezza per la Produzione

Il supporto SwiftPM nella versione 0.87 presenta importanti limitazioni che influenzano le decisioni di adozione:

Per le applicazioni in produzione, CocoaPods rimane il percorso consigliato. I team che valutano SwiftPM dovrebbero prototipare su un branch e testare il loro intero albero delle dipendenze prima di impegnarsi nella migrazione.

Breaking Change: Import Header iOS con Namespace

React Native 0.87 include nuovi XCFramework: ReactNativeHeaders.xcframework e ReactNativeDependenciesHeaders.xcframework. I moduli nativi che usano include angle in forma base devono aggiungere il prefisso namespace React/.

// Prima di 0.87 - include base
#import <RCTAppDelegate.h>
#import <RCTBridge.h>
#import <RCTRootView.h>

// Dopo 0.87 - include con namespace
#import <React/RCTAppDelegate.h>
#import <React/RCTBridge.h>
#import <React/RCTRootView.h>

Questa modifica si applica sia alle build CocoaPods che SwiftPM. I progetti con moduli nativi personalizzati devono aggiornare tutti gli import degli header prima dell'upgrade.

Strict TypeScript API: La Nuova Interfaccia JavaScript Predefinita

La Strict TypeScript API, presentata in anteprima nella versione 0.80, diventa l'impostazione predefinita nella 0.87. I tipi vengono ora generati direttamente dal codice sorgente di React Native, eliminando la divergenza tra le definizioni TypeScript e il comportamento effettivo a runtime.

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

export function FormComponent() {
  // Nuovi tipi ref dedicati sostituiscono il generico RefObject<T>
  const containerRef = useRef<ViewInstance>(null);
  const inputRef = useRef<TextInputInstance>(null);

  const focusInput = () => {
    // Accesso ai metodi type-safe
    inputRef.current?.focus();
  };

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

Tre modifiche breaking ai tipi richiedono attenzione durante la migrazione:

1. Deep import bloccati: I percorsi react-native/Libraries/* ora producono errori di tipo. Tutte le esportazioni devono provenire dal pacchetto root react-native.

2. Aggiornamenti tipi ref: ViewInstance e TextInputInstance sostituiscono i tipi ref generici. Gli alias di tipo *Properties vengono rimossi a favore di *Props.

3. Modifica useColorScheme: Restituisce ColorSchemeName | null invece del precedente valore stringa 'unspecified'.

Opt-Out dalla Strict TypeScript Durante la Migrazione

I team che necessitano di più tempo per migrare possono ripristinare i legacy deep import fino a React Native 0.88:

{
  "extends": "@react-native/typescript-config",
  "compilerOptions": {
    "customConditions": ["react-native", "react-native-legacy-deep-imports"]
  }
}

Questa via di fuga verrà rimossa in React Native 0.89. I progetti dovrebbero dare priorità alla migrazione prima di quella release.

Metro 0.87: Source Map 2x più Veloci e 50% di Memoria in Meno

La versione 0.87 del bundler Metro include miglioramenti significativi delle prestazioni che influenzano il workflow di sviluppo e il tempo di avvio dei React Native DevTools.

La generazione delle source map è 2x più veloce grazie alla gestione ottimizzata delle stringhe. I DevTools si caricano più velocemente perché le source map vengono generate in modo più efficiente durante le build di sviluppo.

L'utilizzo della memoria diminuisce del 50% grazie a una memorizzazione più efficiente delle source map. Questo è rilevante per codebase di grandi dimensioni dove Metro precedentemente consumava RAM significativa durante lunghe sessioni di sviluppo.

Ulteriori modifiche a Metro:

• Supporto stabile per file di configurazione TypeScript (metro.config.mts)
• Supporto per file di configurazione ESM insieme a CommonJS
• Package self-resolve nel resolver
• Rimosso il supporto per le estensioni file .es6 e i file di configurazione YAML

Requisiti Minimi della Toolchain per React Native 0.87

Questa release aumenta i requisiti minimi di versione in tutta la toolchain. Le pipeline CI e gli ambienti degli sviluppatori devono essere aggiornati prima dell'upgrade.

Per problemi di compatibilità con AGP 9, aggiungere opt-out in android/gradle.properties:

# android/gradle.properties
# Opt-out temporanei per la migrazione ad AGP 9
android.builtInKotlin=false
android.newDsl=false

API Rimosse in React Native 0.87

Diverse API deprecate vengono rimosse in questa release. I progetti che usano queste API devono essere refactorizzati prima dell'upgrade.

Ulteriori deprecazioni destinate a rimozione futura includono ImageBackground (usare View con Image posizionato in modo assoluto), DrawerLayoutAndroid (usare react-native-drawer-layout) e react-native/Libraries/Core/InitializeCore (usare react-native/setup-env).

Domande per Colloqui React Native 0.87 per Sviluppatori Senior

Queste domande appaiono nei colloqui per sviluppatori mobile senior dopo le major release di React Native. Comprendere le decisioni architetturali dietro il supporto SwiftPM e la Strict TypeScript API dimostra conoscenza a livello framework.

D: Perché React Native 0.87 introduce SwiftPM come sperimentale invece di sostituire immediatamente CocoaPods?

Il supporto SwiftPM dipende dalle librerie della community che includono file Package.swift. A differenza di CocoaPods dove esiste un registro centrale Podspec, SwiftPM richiede che ogni autore di libreria aggiunga la configurazione nativa del pacchetto Swift. La fase sperimentale permette all'ecosistema di adottare SwiftPM gradualmente mentre CocoaPods rimane stabile per le app in produzione. Inoltre, i comandi CLI e il layout del progetto generato potrebbero cambiare in base al feedback degli sviluppatori prima della stabilizzazione.

D: Quale problema risolve la Strict TypeScript API che le definizioni di tipo mantenute manualmente non potevano risolvere?

Le definizioni di tipo mantenute manualmente divergono dal comportamento a runtime tra le release. I refactoring interni che cambiano le firme delle funzioni o aggiungono parametri potrebbero non riflettersi immediatamente nei tipi, causando crash a runtime che TypeScript avrebbe dovuto intercettare. La Strict API genera tipi direttamente dal codice sorgente, rendendo i tipi autorevoli invece che aspirazionali. Blocca anche i deep import che accedono ad API interne instabili, prevenendo rotture quando questi elementi interni cambiano.

D: Come differisce l'autolinking SwiftPM dall'autolinking CocoaPods in React Native?

L'autolinking CocoaPods viene eseguito durante pod install, che gli sviluppatori devono ricordarsi di eseguire dopo le modifiche alle dipendenze. L'autolinking SwiftPM viene eseguito automaticamente durante la fase di build di Xcode. Il sistema di build rileva le modifiche alle dipendenze e rigenera il manifest del pacchetto senza intervento manuale. Questo elimina una fonte comune di problemi "funziona sulla mia macchina" dove gli sviluppatori dimenticano di eseguire pod install dopo aver fatto pull delle modifiche.

Per ulteriore preparazione ai colloqui React Native, consultare le banche di domande sul deep dive dei moduli nativi e sulle strategie di testing.

Strategia di Upgrade per Progetti React Native 0.87

Il React Native Upgrade Helper genera un diff tra il template del progetto attuale e 0.87. Questo diff mostra esattamente quali file devono essere modificati.

Priorizzare questi passaggi di migrazione:

1. Aggiornare Node.js a 22.13.0+ e verificare che gli ambienti CI corrispondano
2. Eseguire la compilazione TypeScript per identificare violazioni dei deep import
3. Aggiornare i tipi ref da generici a tipi instance dedicati
4. Aggiornare gli import degli header iOS al formato con namespace
5. Testare l'intero albero delle dipendenze native prima di abilitare SwiftPM

Per i progetti Expo, React Native 0.87 è disponibile nelle release expo@canary. I progetti Expo in produzione dovrebbero attendere la release SDK stabile.

Cosa Significa il Supporto SwiftPM 0.87 per i Tempi di Build iOS

SwiftPM elimina pod install dal workflow di sviluppo, ma la configurazione iniziale del progetto richiede più tempo. Il comando npx react-native spm risolve i pacchetti Swift dal sorgente, il che richiede più tempo rispetto al download dei binari CocoaPods precompilati.

Le build successive beneficiano della risoluzione incrementale dei pacchetti di Xcode. Solo i pacchetti modificati vengono recuperati nuovamente. Per i team con frequenti modifiche alle dipendenze, questo approccio incrementale potrebbe essere più veloce dei cicli ripetuti di pod install.

L'ottimizzazione CI differisce tra i due approcci. CocoaPods fa cache delle directory Pods/ efficacemente. SwiftPM fa cache attraverso i derived data di Xcode, che richiede strategie di cache key diverse. I team che migrano le pipeline CI dovrebbero fare benchmark di entrambi gli approcci con il loro specifico set di dipendenze.

Per tecniche correlate di ottimizzazione delle build iOS, consultare la guida alla New Architecture di React Native che copre le caratteristiche prestazionali di Hermes V1 e della modalità bridgeless.