React Native 0.87 e SwiftPM em 2026: Build iOS Moderno e Perguntas de Entrevista

React Native 0.87, lançado em 11 de agosto de 2026, traz suporte experimental ao Swift Package Manager (SwiftPM) para builds iOS, marcando o primeiro passo para a eliminação do CocoaPods dos projetos React Native. Esta versão também torna a API TypeScript Estrita padrão, inclui o Metro 0.87 com geração de source maps 2x mais rápida, e eleva os requisitos mínimos da cadeia de ferramentas para Node.js 22, Kotlin 2.0 e Android compileSdk 37.

Swift Package Manager Substitui CocoaPods para Dependências iOS

O suporte ao SwiftPM no React Native 0.87 é opt-in e experimental. O CocoaPods permanece como o gerenciador de dependências padrão para aplicações em produção. O caminho SwiftPM consome os mesmos XCFrameworks pré-construídos que o React Native já publica, então nenhum download binário adicional é necessário.

O benefício principal: um projeto baseado em SwiftPM precisa apenas do Xcode. Ruby, Bundler e CocoaPods não são mais necessários nas máquinas dos desenvolvedores ou nos pipelines de CI.

# ios-swiftpm-setup.sh
# Passo 1: Navegar para o diretório iOS
cd ios

# Passo 2: Desintegrar CocoaPods e gerar referências SwiftPM
npx react-native spm --deintegrate

# Passo 3: Abrir o projeto no Xcode e compilar
open MyApp.xcworkspace

O comando spm --deintegrate injeta referências de pacotes Swift no .xcodeproj existente em vez de substituir o arquivo do projeto. As configurações de assinatura de código, fases de build e capabilities permanecem intactas. Para reverter a mudança, execute npx react-native spm deinit.

Como o Autolinking do SwiftPM Funciona Sem pod install

Após a configuração inicial, mudanças nas dependências ativam o relinking automático. Instale ou remova um pacote nativo com npm ou yarn, depois compile. O projeto detecta as mudanças e re-executa o autolinking durante a fase de build do Xcode.

# dependency-workflow.sh
# Instalar uma dependência nativa
npm install react-native-reanimated

# O build ativa o relinking automático
npx react-native run-ios
# Não é necessário pod install

Para clones novos e ambientes de CI, execute npx react-native spm uma vez antes do primeiro build. Isso gera o arquivo Package.swift e resolve as dependências dos pacotes Swift.

Limitações do SwiftPM e Prontidão para Produção

O suporte ao SwiftPM no 0.87 possui limitações importantes que afetam as decisões de adoção:

Para aplicações em produção, o CocoaPods continua sendo o caminho recomendado. Equipes avaliando o SwiftPM devem criar protótipos em uma branch e testar toda a árvore de dependências antes de se comprometer com a migração.

Mudança Importante: Imports de Headers iOS com Namespace

React Native 0.87 inclui novos XCFrameworks: ReactNativeHeaders.xcframework e ReactNativeDependenciesHeaders.xcframework. Módulos nativos usando includes de ângulo na forma simples devem adicionar o prefixo de namespace React/.

// Antes do 0.87 - include simples
#import <RCTAppDelegate.h>
#import <RCTBridge.h>
#import <RCTRootView.h>

// Depois do 0.87 - include com namespace
#import <React/RCTAppDelegate.h>
#import <React/RCTBridge.h>
#import <React/RCTRootView.h>

Esta mudança se aplica tanto aos builds com CocoaPods quanto com SwiftPM. Projetos com módulos nativos personalizados precisam atualizar todos os imports de headers antes de atualizar.

API TypeScript Estrita: A Nova Interface JavaScript Padrão

A API TypeScript Estrita, previamente apresentada no 0.80, se torna padrão no 0.87. Os tipos agora são gerados diretamente do código fonte do React Native, eliminando a divergência entre as definições TypeScript e o comportamento real em tempo de execução.

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

export function FormComponent() {
  // Novos tipos de ref dedicados substituem RefObject<T> genérico
  const containerRef = useRef<ViewInstance>(null);
  const inputRef = useRef<TextInputInstance>(null);

  const focusInput = () => {
    // Acesso a métodos com type-safety
    inputRef.current?.focus();
  };

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

Três mudanças de tipos importantes requerem atenção durante a migração:

1. Imports profundos bloqueados: Caminhos react-native/Libraries/* agora produzem erros de tipo. Todas as exportações devem vir do pacote raiz react-native.

2. Atualizações de tipos ref: ViewInstance e TextInputInstance substituem os tipos ref genéricos. Os aliases de tipo *Properties são removidos em favor de *Props.

3. Mudança no useColorScheme: Retorna ColorSchemeName | null em vez do valor string anterior 'unspecified'.

Desativando TypeScript Estrito Durante a Migração

Equipes que precisam de mais tempo para migrar podem restaurar os imports profundos legacy até o React Native 0.88:

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

Esta válvula de escape será removida no React Native 0.89. Os projetos devem priorizar a migração antes desta versão.

Metro 0.87: Source Maps 2x Mais Rápidos e 50% Menos Memória

A versão 0.87 do bundler Metro inclui melhorias de performance significativas que afetam o fluxo de trabalho de desenvolvimento e o tempo de inicialização do React Native DevTools.

A geração de source maps é 2x mais rápida devido ao manuseio otimizado de strings. O DevTools agora carrega mais rápido porque os source maps são gerados mais eficientemente durante os builds de desenvolvimento.

O uso de memória diminui 50% através de armazenamento mais eficiente de source maps. Isso importa para bases de código grandes onde o Metro anteriormente consumia RAM significativa durante longas sessões de desenvolvimento.

Mudanças adicionais do Metro:

• Suporte estável para arquivos de configuração TypeScript (metro.config.mts)
• Suporte a arquivos de config ESM junto com CommonJS
• Auto-resolução de pacotes no resolver
• Remoção do suporte para extensões de arquivo .es6 e arquivos de configuração YAML

Requisitos Mínimos da Cadeia de Ferramentas para React Native 0.87

Esta versão eleva os requisitos de versão mínima em toda a cadeia de ferramentas. Pipelines de CI e ambientes de desenvolvedores precisam de atualizações antes de atualizar.

Para problemas de compatibilidade com AGP 9, adicione opt-outs em android/gradle.properties:

# android/gradle.properties
# Opt-outs temporários para a migração do AGP 9
android.builtInKotlin=false
android.newDsl=false

APIs Removidas no React Native 0.87

Várias APIs depreciadas são removidas nesta versão. Projetos usando essas APIs precisam de refatoração antes de atualizar.

Depreciações adicionais visando remoção futura incluem ImageBackground (usar View com Image posicionado absolutamente), DrawerLayoutAndroid (usar react-native-drawer-layout), e react-native/Libraries/Core/InitializeCore (usar react-native/setup-env).

Perguntas de Entrevista React Native 0.87 para Desenvolvedores Seniores

Estas perguntas aparecem em entrevistas de desenvolvedores mobile seniores após lançamentos importantes do React Native. Entender as decisões arquiteturais por trás do suporte ao SwiftPM e da API TypeScript Estrita demonstra conhecimento em nível de framework.

P: Por que o React Native 0.87 introduz o SwiftPM como experimental em vez de substituir o CocoaPods imediatamente?

O suporte ao SwiftPM depende das bibliotecas da comunidade incluírem arquivos Package.swift. Diferente do CocoaPods onde existe um registro central Podspec, o SwiftPM requer que cada autor de biblioteca adicione configuração de pacote Swift nativo. A fase experimental permite que o ecossistema adote o SwiftPM gradualmente enquanto o CocoaPods permanece estável para apps em produção. Além disso, os comandos CLI e o layout de projeto gerado podem mudar baseado no feedback dos desenvolvedores antes da estabilização.

P: Qual problema a API TypeScript Estrita resolve que definições de tipos mantidas manualmente não conseguiam?

Definições de tipos mantidas manualmente divergem do comportamento em tempo de execução entre versões. Refatorações internas que mudam assinaturas de funções ou adicionam parâmetros podem não ser refletidas nos tipos imediatamente, causando crashes em tempo de execução que o TypeScript deveria ter capturado. A API Estrita gera tipos diretamente do código fonte, tornando os tipos autoritativos em vez de aspiracionais. Ela também bloqueia imports profundos que acessam APIs internas instáveis, prevenindo quebras quando esses internos mudam.

P: Como o autolinking do SwiftPM difere do autolinking do CocoaPods no React Native?

O autolinking do CocoaPods executa durante o pod install, que os desenvolvedores devem lembrar de executar após mudanças de dependências. O autolinking do SwiftPM executa durante a fase de build do Xcode automaticamente. O sistema de build detecta mudanças de dependências e regenera o manifesto do pacote sem intervenção manual. Isso elimina uma fonte comum de problemas de "funciona na minha máquina" onde desenvolvedores esquecem de executar pod install após fazer pull de mudanças.

Para preparação adicional para entrevistas de React Native, consulte os bancos de perguntas sobre módulos nativos em profundidade e estratégias de testes.

Estratégia de Atualização para Projetos React Native 0.87

O React Native Upgrade Helper gera um diff entre o template de projeto atual e o 0.87. Este diff mostra exatamente quais arquivos precisam de mudanças.

Priorize estes passos de migração:

1. Atualizar Node.js para 22.13.0+ e verificar que os ambientes de CI correspondam
2. Executar compilação TypeScript para identificar violações de imports profundos
3. Atualizar tipos ref de genéricos para tipos de instância dedicados
4. Atualizar imports de headers iOS para o formato com namespace
5. Testar toda a árvore de dependências nativas antes de habilitar o SwiftPM

Para projetos Expo, React Native 0.87 está disponível em releases expo@canary. Projetos Expo em produção devem aguardar o lançamento do SDK estável.

O Que o Suporte SwiftPM 0.87 Significa para os Tempos de Build iOS

O SwiftPM elimina o pod install do fluxo de trabalho de desenvolvimento, mas a configuração inicial do projeto requer mais tempo. O comando npx react-native spm resolve pacotes Swift do código fonte, o que leva mais tempo do que baixar binários CocoaPods pré-construídos.

Builds subsequentes se beneficiam da resolução incremental de pacotes do Xcode. Apenas pacotes modificados são rebuscados. Para equipes com mudanças frequentes de dependências, esta abordagem incremental pode ser mais rápida do que ciclos repetidos de pod install.

A otimização de CI difere entre as duas abordagens. O CocoaPods faz cache dos diretórios Pods/ efetivamente. O SwiftPM faz cache através dos derived data do Xcode, o que requer estratégias de chave de cache diferentes. Equipes migrando pipelines de CI devem fazer benchmark de ambas as abordagens com seu conjunto específico de dependências.

Para técnicas relacionadas de otimização de build iOS, consulte o guia da Nova Arquitetura React Native cobrindo as características de performance do Hermes V1 e modo bridgeless.