# React Native 0.87 e SwiftPM nel 2026: Build iOS Moderno e Domande per Colloqui > React Native 0.87 introduce il supporto sperimentale per Swift Package Manager, eliminando CocoaPods dalle build iOS. Questa guida copre la configurazione di SwiftPM, la Strict TypeScript API, le ottimizzazioni di Metro 0.87 e domande per colloqui di sviluppatori mobile senior. - 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, 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. > **Configurazione SwiftPM con un Solo Comando** > > Dopo la deintegrazione di CocoaPods, eseguire `npx react-native spm --deintegrate` una sola volta. Il progetto quindi ricollega automaticamente le dipendenze native ad ogni build senza `pod install`. ## 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. ```bash # 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. ```bash # 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: | Limitazione | Impatto | |-------------|--------| | Supporto librerie community | Ogni libreria deve includere un file `Package.swift` | | Stabilità dei comandi | Flag e layout generato potrebbero cambiare in 0.88+ | | Configurazione CI | Richiede il passo `npx react-native spm` prima delle build | | Documentazione | Risorse di troubleshooting limitate disponibili | 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/`. ```objective-c // AppDelegate.m // Prima di 0.87 - include base #import #import #import // Dopo 0.87 - include con namespace #import #import #import ``` 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. ```typescript // component-refs.tsx import { useRef } from 'react'; import { View, TextInput, ViewInstance, TextInputInstance } from 'react-native'; export function FormComponent() { // Nuovi tipi ref dedicati sostituiscono il generico RefObject const containerRef = useRef(null); const inputRef = useRef(null); const focusInput = () => { // Accesso ai metodi type-safe inputRef.current?.focus(); }; return ( ); } ``` 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: ```json // tsconfig.json { "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. | Requisito | Versione | |-----------|--------| | Node.js | ≥ 22.13.0 | | Kotlin | ≥ 2.0 (incluso: 2.2.0) | | Android minCompileSdk | 34 | | Android compileSdk | 37 | | Android Gradle Plugin | 9.x | Per problemi di compatibilità con AGP 9, aggiungere opt-out in `android/gradle.properties`: ```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. | API Rimossa | Sostituzione | |-------------|-------------| | `InteractionManager` | `requestIdleCallback` | | `Modal` prop animated | Usare il comportamento di transizione predefinito | | Tipo `NativeMethods` | `HostInstance` | | Flag `useTurboModules` | Sempre abilitato, flag rimosso | | Export root `Touchable` | Estendere `ViewProps` direttamente | | `react-native/rn-get-polyfills` | `@react-native/js-polyfills` | Ulteriori deprecazioni destinate a rimozione futura includono `ImageBackground` (usare `View` con `Image` posizionato in modo assoluto), `DrawerLayoutAndroid` (usare [react-native-drawer-layout](https://github.com/react-navigation/react-navigation/tree/main/packages/drawer)) 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](/technologies/react-native/interview-questions/rn-native-modules) e sulle [strategie di testing](/technologies/react-native/interview-questions/rn-testing). ## Strategia di Upgrade per Progetti React Native 0.87 Il [React Native Upgrade Helper](https://react-native-community.github.io/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](/blog/react-native/react-native-new-architecture-hermes-v1-bridgeless) che copre le caratteristiche prestazionali di Hermes V1 e della modalità bridgeless. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/it/blog/react-native/react-native-087-swiftpm-ios-build-interview-questions