Busca en todas las páginas de la documentación
Cuándo escribir código nativo versus usar un paquete Expo SDK. Estas reglas mantienen a los equipos en el camino soportado para Expo SDK 57 y React Native 0.86, minimizan sorpresas de CNG/prebuild y garantizan que las dependencias nativas se envíen con dev-client y binarios de tienda coincidentes.
ios/ y android/ en cada prebuild.npx expo-doctor después de cada cambio de dependencia nativa.Busca paquetes de Expo SDK primero: expo-camera, expo-location, expo-notifications y más de 100 módulos se envían con binarios nativos de SDK 57 - prefierelos sobre envolturas nativas random de npm.
npx expo install expo-camera - no npm install expo-camera@latest.Segunda opción: módulo comunitario con plugin de configuración de Expo: Muchas librerías incluyen un plugin de configuración en el array plugins de app.config - lee su matriz de compatibilidad con SDK 57 antes de instalar.
Tercera opción: Expo Modules API para puentes nativos personalizados delgados: Cuando no existe un paquete, escribe un módulo Expo en modules/my-feature/ - autolinking e integración de tipos TypeScript se conectan limpiamente con CNG.
npx create-expo-module@latest para la estructura del módulo.Último recurso: parches Swift/Kotlin desnudos vía plugin de configuración: Las carpetas ios/ y android/ mantenidas manualmente son solo para brownfield - las aplicaciones de CNG estándar expresan cambios como plugins.
Podfile que no están codificadas en un plugin.Expo Go no es un objetivo de prueba nativa para módulos personalizados: Los paquetes no incluidos en Expo Go requieren expo-dev-client - no reclames aprobación de QA solo desde Expo Go.
development de EAS compila clientes dev instalables.Un cambio nativo por PR cuando sea posible: Mezclar un nuevo SDK de pago, plugin de cámara y módulo personalizado en una fusión hace que bisect sea imposible cuando prebuild falla.
Siempre npx expo install para deps nativos: Resuelve versiones compatibles con binarios nativos de SDK 57 - el éxito de compilación no garantiza estabilidad en tiempo de ejecución.
npx expo install --fix luego expo-doctor.package.json se desvían de las versiones incluidas de Expo sin ADR.Registra plugins de configuración en app.config.ts: Los permisos nativos, entitlements y entradas de manifest pertenecen en plugins - no en ediciones manuales posteriores a prebuild.
npx expo prebuild --clean localmente antes de fusionar cambios de plugin.Escribe plugins de configuración idempotentes: Ejecutar prebuild dos veces no debe duplicar entradas en Info.plist o AndroidManifest.xml.
git diff la salida nativa - debería estar vacía la segunda vez.Declara permisos con strings visibles para el usuario: iOS NSCameraUsageDescription y rationale de permiso de Android - strings faltantes causan crash o rechazo de revisión de tienda.
app.config ios.infoPlist - nunca solo en archivos generados.locales/ para strings de permisos en idiomas enviados.Usa expo-build-properties para compilar SDK y objetivos de despliegue: Centraliza minSdkVersion, compileSdkVersion y objetivo de despliegue de iOS - ediciones de Gradle dispersas se pierden en prebuild.
Autolinking maneja la mayoría de enlaces - no edites manualmente settings.gradle: Expo autolinking registra módulos nativos - hacks de pod install manual pertenecen en plugins si es realmente necesario.
npx expo-modules-autolinking resolve cuando un módulo no se encuentra.react-native - copias duplicadas rompen autolinking silenciosamente.Gitignore generado ios/ y android/ bajo CNG: Las carpetas nativas comprometidas bloquean actualizaciones de plantilla de SDK 57 - EAS Build ejecuta prebuild remotamente.
npx expo prebuild --clean reproduce proyectos nativos de CI.Reconstruye dev client después de cada cambio de dependencia nativa: OTA (eas update) actualiza solo JavaScript - nuevos módulos nativos requieren eas build --profile development.
expo-dev-client con actualizaciones de SDK.Las compilaciones de tienda y cambios nativos nunca son solo OTA: Si una característica de JS requiere un nuevo módulo nativo, envía una compilación de tienda primero - controla JS con comprobaciones de versión en tiempo de ejecución hasta que se alcance el umbral de adopción.
expo-updates + feature flag para nueva API nativa.Prueba en dispositivos físicos para módulos de hardware: Cámara, BLE, NFC y push se comportan diferentemente en simuladores - QA solo en sim pierde fallas de permiso y background.
La compatibilidad de New Architecture es explícita: RN 0.86 favorece New Architecture - verifica que módulos nativos de terceros declaren soporte de Fabric/TurboModule o documenta fallback.
expo-doctor.Libera handles y listeners nativos: Instancias de SharedObject de larga vida desde módulos Expo (players, sensors) necesitan release() en unmount - las fugas crashean apps en background.
useEffect llama al módulo remove() o suscripción remove().Los módulos Expo personalizados viven en modules/ con API de JS tipada: Exporta una superficie TypeScript estrecha - las features importan @/modules/my-feature, no strings raw de NativeModules.
Sin lógica de negocio en código nativo: La capa nativa maneja APIs de plataforma y marshaling - reglas de precios y validación permanecen en TypeScript.
if user.isPremium duplicado desde JS.Semantic versioning para módulos internos: Los cambios de API nativa que rompen requieren una compilación de tienda y changelog - trata modules/ como un paquete publicado.
Revisión de seguridad para módulos nativos que tocan secretos: Wrappers de Keychain, SDKs de pago y librerías de attestation necesitan aprobación de seguridad - no solo revisión de mobile lead.
UserDefaults nativo sin encriptación.Prebuild en CI en PRs nativos: Ejecuta npx expo prebuild --clean --no-install (o compilación EAS completa) para atrapar fallos de plugin antes de fusión.
ADR para todo módulo nativo personalizado y dependencia nativa no-Expo: Status, propietario, alternativas consideradas, posición de New Architecture y trigger de jubilación.
Prefiere Expo Modules API para nuevos puentes personalizados - autolinking, TypeScript e integración de plugins de configuración con CNG. Los módulos nativos RN heredados funcionan pero necesitan más mantenimiento de enlace manual en SDK 57.
Aplicaciones Brownfield con directorios nativos comprometidos y una estrategia de fusión documentada. Las aplicaciones Expo greenfield estándar nunca deben editar manualmente archivos generados - usa plugins de configuración.
Sí - los plugins mutan proyectos nativos en tiempo de prebuild. Ejecuta un nuevo dev-client y compilación de tienda; OTA solo es insuficiente.
Verifica docs de Expo - si el paquete no está en el bundle de Expo Go, necesitas un dev build. expo-doctor también puede advertir sobre dependencias incompatibles.
No - el código nativo se envía en el binario. Puedes enviar JS que llame a un módulo nativo existente OTA, pero añadir el módulo en sí requiere una compilación de tienda.
Crea un módulo con npx create-expo-module@latest, regístralo en el package.json workspaces o carpeta modules/ de la app, y autolinking lo detecta en prebuild.
Coloca módulos compartidos en packages/native-feature/ con react-native peer deps apropiados. Una app ejecuta prebuild; el módulo autolinks desde la ruta del workspace que Metro resuelve.
Algunos módulos comunitarios atrasan soporte de Fabric/TurboModule en RN 0.86. Verifica antes de adoptar; documenta fallback de Old Architecture en un ADR si es requerido temporalmente.
Casi nunca - upstream una corrección o envuelve con un plugin de configuración. Forks cuando el mantenedor se fue requieren un ADR con propiedad de parche de seguridad.
Mock en el límite de TypeScript (jest.mock('@/modules/my-feature')) con formas de retorno realistas. Ejecuta pruebas de integración en dispositivo vía Maestro o QA manual para caminos de hardware.
Actualizaciones de SDK, cambios de plugin, fallos de autolinking y errores de compilación nativa inexplicables. --clean es la ruta de recuperación por defecto en SDK 57 - no un último recurso.
Los plugins se ejecutan en cualquier prebuild - local y remoto. Mantén prebuild local reproducible para que CI y laptops generen proyectos nativos idénticos.
El ADR nombra un propietario primario (iOS/Android o mobile full-stack). El código nativo sin propietario es un bloqueador de fusión en equipos maduros.
Versiones de stack: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (
expo~57.0.4).
Revisado por Chris St. John·Última actualización: 9 jul 2026