React Native tiene fama de dos cosas contradictorias: de ser la forma más rápida de sacar una app a producción en iOS y Android a la vez, y de producir apps con arranque lento y consumo de memoria alto. Las dos famas son ciertas, y la diferencia entre un caso y el otro casi nunca es "React Native", sino cómo se ha arquitecturado la app por encima.

Cuándo tiene sentido y cuándo es una trampa

Funciona bien cuando el objetivo es llegar rápido a mercado con un equipo pequeño, la UI no necesita ser espectacular, y no hace falta acceso muy específico a APIs nativas. Se convierte en un problema cuando la app necesita rendimiento gráfico serio (juegos, trading en tiempo real), cuando el equipo es una sola persona sin experiencia nativa para depurar los problemas específicos de plataforma que aparecen tarde o temprano, o cuando ya existe una app nativa estable y reescribirla no aporta nada.

La regla práctica: si la app no necesita 60 FPS constantes ni renderizado GPU a medida, React Native es viable. Si necesita cualquiera de esas dos cosas, un enfoque híbrido —la mayor parte en RN, las piezas críticas en nativo— suele ser mejor que ir a por todo o nada.

Por qué el arranque es lento (y qué hacer)

Una app React Native típica tarda bastante más en arrancar que su equivalente nativa, por tres razones concretas: el puente entre JavaScript y código nativo añade latencia en cada cruce, el bundle de JavaScript pesa varias decenas de MB que hay que cargar en memoria, y el motor Hermes tiene que compilar bytecode al arrancar.

Hermes (ya viene por defecto en Expo) precompila ese bytecode y reduce sensiblemente el tiempo de arranque.

Code splitting por feature evita cargar todo de golpe:

// Mal: todo en un único bundle inicial
import PaymentScreen from './payments';
import AnalyticsScreen from './analytics';

// Mejor: carga bajo demanda
const PaymentScreen = lazy(() => import('./payments'));
const AnalyticsScreen = lazy(() => import('./analytics'));

Delegar tareas pesadas a un módulo nativo cuando el cuello de botella es cómputo puro:

// Procesar un array grande en JS puede ser notablemente más lento
const users = await processHeavyData(largeArray);

// que delegarlo a un módulo nativo
const users = await NativeModule.processHeavyData(largeArray);

El patrón que mejor funciona a escala es el híbrido: la parte genérica de la UI en React Native, y las piezas donde el rendimiento es crítico —listas que se actualizan constantemente, renderizado en tiempo real— resueltas en nativo.

Gestión de estado a medida que la app crece

El Context API de React funciona bien al principio, pero tiene un problema conocido: cualquier cambio en el contexto redibuja a todos los componentes que lo consumen, aunque solo les interese una parte pequeña de ese estado.

Redux resuelve esto pero es verboso para features simples. Zustand es una alternativa más ligera, cada vez más habitual en proyectos React Native:

import { create } from 'zustand';

const useUserStore = create((set) => ({
  user: null,
  setUser: (user) => set({ user }),
  logout: () => set({ user: null }),
}));

// El componente solo se redibuja si "user" cambia
function UserProfile() {
  const user = useUserStore((state) => state.user);
  return {user.name};
}

New Architecture: ¿migrar ya o esperar?

La arquitectura antigua de React Native sigue funcionando pero ya no recibe mejoras, y arrastra lentitud conocida en listas largas (FlatList con miles de elementos). La New Architecture (Fabric + TurboModules) elimina buena parte del overhead del puente y mejora notablemente el rendimiento en operaciones pesadas.

Si el proyecto es nuevo, tiene sentido empezar directamente con la New Architecture. Si el proyecto ya existe y es pequeño, migrar suele llevar un par de semanas; el ROI depende de si la app sufre lag visible hoy.

Distribuir cambios sin pasar por la tienda

La aprobación de App Store o Play Store puede tardar días. Para cambios de solo JavaScript (no código nativo nuevo), Expo Updates permite desplegar en minutos sin pasar por ese proceso:

import * as Updates from 'expo-updates';

useEffect(() => {
  (async () => {
    const update = await Updates.checkForUpdateAsync();
    if (update.isAvailable) {
      await Updates.fetchUpdateAsync();
      await Updates.reloadAsync();
    }
  })();
}, []);

Ideal para arreglar bugs rápido. Si el cambio incluye módulos nativos nuevos, sigue haciendo falta pasar por la tienda.

Herramientas del día a día

Expo CLI evita tener que tocar Xcode o Android Studio directamente en la mayoría de los casos.

Expo EAS permite compilar para iOS en la nube, sin necesitar un Mac.

Flipper, de Meta, es un depurador con visor de red, logs y base de datos en un mismo panel.

Cuándo adoptarlo

Tiene sentido si el equipo es pequeño, la app es sobre todo formularios, listas y autenticación, y el time-to-market importa más que exprimir cada milisegundo. No tiene tanto sentido si necesitas rendimiento de nivel gaming, funcionalidades muy específicas de una plataforma, o ya tienes un equipo nativo consolidado. En apps con features complejas, el enfoque híbrido suele ganar frente a ir 100% React Native.

Fuentes:

• React Native — Documentación oficial
• Expo — Documentación