Prácticas Recomendadas de Expo Rules

Un resumen condensado de las 25 prácticas recomendadas más importantes extraídas de cada página en esta sección.

1. Fija el SDK en el momento del scaffolding: Usa npx create-expo-app@latest --template default@sdk-57 para que expo comience en ~57.0.4 - actualizar tres SDKs en un PR compone cambios disruptivos.

2. app.config.ts es la fuente de verdad: La configuración dinámica admite entornos, complementos y ayudantes con tipos - ejecuta npx expo config --type public antes de cada envío a la tienda.

3. Nunca confirmes secretos en extra o EXPO_PUBLIC_*: Los bundles de cliente exponen estos valores - los secretos del servidor pertenecen solo en Secretos de EAS y código backend.

4. Confirma archivos de bloqueo y usa npx expo install: CI y EAS deben resolver el mismo árbol de dependencias - npm install manual en paquetes de Expo sesga los binarios nativos.

5. Mantén app/ delgado; las características poseen lógica: Los archivos de ruta reexportan pantallas desde features/<name>/ - sin llamadas de obtención, hooks o reglas de negocio junto a _layout.tsx.

6. Gitignore ios/ y android/ bajo CNG: Las carpetas nativas confirmadas bloquean plantillas prebuild de RN 0.86 - regenera en EAS Build o expo prebuild --clean.

7. Ejecuta expo-doctor en CI en cada PR: Detecta sesgo de versión, configuración inválida y errores de dependencia antes de que lleguen a TestFlight.

8. Prefiere objetos href y rutas con tipos: Habilita experiments.typedRoutes - router.push({ pathname: '/orders/[id]', params: { id } }) supera rutas de cadena que tipografían silenciosamente.

9. Valida parámetros de ruta en el límite de características: Analiza useLocalSearchParams() con Zod antes de renderizar - los enlaces profundos mal formados muestran UI recuperable, no redboxes.

10. Las puertas de autenticación viven en layouts; reinicia la pila al cerrar sesión: Una redirección (app)/_layout.tsx - router.replace después de cerrar sesión para que el gesto de retroceso nunca regrese a información personal identificable con un token borrado.

11. Declara scheme y dominios asociados en app.config: Los enlaces universales y esquemas personalizados son territorio de complementos de configuración - no archivos nativos generados editados manualmente.

12. Busca paquetes SDK de Expo antes de escribir código nativo: npx expo install expo-* primero - Swift/Kotlin personalizado requiere reconstrucciones de cliente de desarrollo, ADRs y propiedad continua.

13. Expresa cambios nativos como complementos de configuración idempotentes: Editar manualmente Info.plist o AndroidManifest.xml se pierde en prebuild --clean - los complementos deben ser seguros en ejecuciones repetidas.

14. Reconstruye clientes de desarrollo después de cada cambio de dependencia nativa: Las actualizaciones OTA son solo JavaScript - nuevos módulos nativos necesitan eas build --profile development antes de la aprobación de QA.

15. Expo Go no es un objetivo de QA nativo: Los módulos personalizados y los IDs de bundle reales requieren cliente de desarrollo o compilaciones preview de EAS - Expo Go oculta comportamiento de enlace y permiso en producción.

16. Almacena tokens en expo-secure-store: Los tokens de refresco y acceso nunca van en AsyncStorage ni en MMKV sin cifrar - borra el almacenamiento seguro al cerrar sesión.

17. Audita la configuración pública antes del lanzamiento: npx expo config --type public con entorno de producción - busca en CI sk_live, claves privadas y nombres de host internos.

18. Prefiere TLS del sistema; fija solo con un ADR: El fijado de certificados necesita runbooks de rotación y módulos nativos - la mayoría de las aplicaciones no deben fijar el primer día.

19. Establece una política explícita de runtimeVersion: appVersion, sdkVersion o fingerprint debe coincidir entre eas build y eas update - las discrepancias dejan a los usuarios en bundles obsoletos.

20. Los canales se asignan a entornos, no a personas: development → preview → production con reposo de vista previa - usa eas update --environment production en ejecutores SDK 55+.

21. Los cambios nativos requieren compilaciones de tienda: Nuevos módulos, complementos, permisos y esquemas nunca son solo OTA - cierra la llamada de JS a nuevas APIs nativas hasta el umbral de adopción binaria.

22. Define disparadores de reversión antes del lanzamiento: La tasa de bloqueo, fallos de autenticación y caídas de pago cada uno tienen un propietario, umbral de métrica y último ID de bundle conocido como bueno.

23. Publica presupuestos de rendimiento con propietarios nombrados: MB de bundle, TTI de inicio en frío y pisos de FPS de desplazamiento son compuertas de fusión - los presupuestos anónimos se ignoran en la semana de crisis.

24. Mide en dispositivos de referencia Android de gama media: iPhone Pro oculta tartamudeo y presión de memoria - si pasa en hardware de clase Pixel, iOS generalmente sigue.

25. ADR para cada opción arquitectónica no predeterminada: Los módulos nativos personalizados, fijación, ios/ confirmado, exenciones de presupuesto y patrones modales obtienen registros docs/adr/ con fechas de revisión obligatorias.

Preguntas Frecuentes

Relacionado

• Lista de Verificación de Reglas de Proyecto Expo - 25 elementos no negociables de scaffolding de proyecto
• Reglas de Navegación y Enrutamiento - Higiene de Expo Router y enlace profundo
• Reglas de Módulos Nativos - SDK versus nativo personalizado y CNG
• Reglas de Seguridad para Móvil - secretos, almacenamiento y fijación
• Reglas de Lanzamiento y OTA - canales, versiones de tiempo de ejecución, reversión
• Reglas de Presupuesto de Rendimiento - bundle, TTI y propietarios de FPS
• Registros de Decisiones de Arquitectura - plantilla de ADR móvil

Versiones de pila: Esta página fue escrita para React 19.2.3, React Native 0.86.0 y Expo SDK 57 (expo ~57.0.4).