No es lo mismo un demo que producción
React Native es genial para demos. En 2 días tienes algo funcionando en ambas plataformas. El problema empieza cuando esa app tiene que funcionar para miles de usuarios reales con dispositivos reales.
Estas son las lecciones que aprendimos manteniendo apps en producción durante 3 años.
1. La navegación define la arquitectura
Elegir entre React Navigation y Expo Router no es una decisión menor. Define cómo organizas toda la app.
Nuestra recomendación actual: Expo Router si arrancas de cero. El routing basado en archivos simplifica mucho la estructura y el deep linking viene gratis.
2. No ignores los renders innecesarios
En web, un re-render de más es imperceptible. En mobile, puede significar la diferencia entre una app fluida y una que el usuario desinstala.
// ❌ Esto causa re-renders en cada componente hijo
<Context.Provider value={{ user, settings, theme }}>
// ✅ Separar contextos por frecuencia de cambio
<UserProvider value={user}>
<ThemeProvider value={theme}>
<SettingsProvider value={settings}>Usamos React.memo, useMemo y useCallback con criterio — no en todos lados, sino donde el profiler muestra problemas reales.
3. Las actualizaciones OTA son imprescindibles
Depender solo de App Store y Google Play para deployar fixes es inaceptable. EAS Update (antes CodePush) permite enviar actualizaciones JavaScript sin pasar por review.
Un bug crítico en producción un viernes a las 6pm se resuelve en minutos, no en días.
4. Testea en dispositivos reales, siempre
El simulador miente. Especialmente en:
- Performance — El simulador corre en tu Mac M1. Un Android de gama media es otra historia.
- Permisos — Cámara, ubicación, notificaciones. Cada OS tiene sus particularidades.
- Gestos — El scroll, los swipes, el haptic feedback. Solo se validan con el dedo.
Tenemos un pool de dispositivos físicos para testing. No es negociable.
5. El tamaño del bundle importa más de lo que crees
Cada librería que agregas suma al tamaño del bundle y al tiempo de inicio. Hemos visto apps que tardan 4 segundos en arrancar porque importan 15 librerías en el entry point.
Regla: si una librería solo se usa en una pantalla, se carga lazy. Si solo necesitas una función de lodash, la escribes a mano.
Lo que haríamos diferente
Si arrancáramos hoy desde cero:
- Expo desde el día 1 — Ya no hay razón para hacer bare workflow salvo casos muy específicos.
- TypeScript estricto — Sin
any, sin excepciones. - Monorepo con la API — Compartir tipos entre frontend y backend elimina una clase entera de bugs.