Middle React Native Developer — Preguntas de entrevista React Native

Explica paso a paso qué pasa realmente cuando JS llama a un método nativo — arquitectura vieja vs. nueva.

En el bridge viejo, la llamada se serializa a JSON, se encola, se agrupa en lotes, se envía de forma asíncrona al lado nativo, se ejecuta, y el resultado se serializa de vuelta — cada salto cuesta tiempo, y nada es síncrono. Con JSI, un TurboModule es un objeto C++ real al que JS mantiene una referencia directa; llamar a un método invoca a través de un binding en C++ sin serialización JSON y sin cola, y puede ser síncrono cuando eso es lo que se necesita. La contrapartida es la complejidad — escribir un TurboModule correctamente implica lidiar con codegen y C++, mientras que un módulo al estilo bridge viejo estaba más cerca de código pegamento cercano a JS común.

Un `FlatList` con unos cientos de filas pierde frames al hacer scroll — ¿cómo lo abordas?

Primero perfila — el profiler de Flipper/React DevTools o el perf monitor te dice si el costo está en JS (re-renders, renderItem pesado) o en el hilo nativo (layout, imágenes). Después revisa lo básico: keyExtractor estable, React.memo en la fila para que un cambio de state del padre no cascada a cada fila, y sin funciones flecha ni literales de objeto inline pasados como props a la fila. Si el thrashing de layout es el problema, getItemLayout evita un pase de medición por item, y si la lista en sí es el cuello de botella a escala, cambiar a FlashList suele ser el arreglo pragmático en vez de seguir ajustando FlatList a mano.

Una feature necesita una capacidad que React Native no expone — ¿cómo llegas a código nativo, y qué hay que duplicar?

Escribes un módulo nativo — una implementación en Swift/Objective-C para iOS y otra en Kotlin/Java para Android — exponiendo la misma firma de método en ambos lados, porque JS llama a una sola API de cara a JS que debe resolverse en una implementación real según la plataforma en la que corra. Saltarte una plataforma significa que la app se cae o no hace nada silenciosamente ahí, así que las dos implementaciones deben hacer genuinamente lo mismo, no solo compartir nombre. Probar significa correr en un dispositivo real o simulador por cada plataforma, no solo confiar en que "compiló".

¿Cómo manejas los deep links de forma confiable, incluyendo desde un cold start?

Registra el esquema de URL o el universal link/app link en la config nativa (Info.plist / AndroidManifest.xml) y en la config linking del navegador, mapeando patrones de URL a pantallas y parámetros. La parte complicada es el cold start — si la app no estaba corriendo, hay que revisar Linking.getInitialURL() al arrancar y usarlo para fijar el estado inicial de navegación, porque el listener de eventos de Linking por sí solo solo captura enlaces que llegan mientras la app ya está abierta. Los universal links además necesitan los archivos associated-domains / assetlinks.json alojados en tu dominio, para que el SO confíe en que la app maneje esa URL en vez de abrir un navegador.

¿Cuál es la diferencia entre una actualización OTA y un release de store, y cuándo usar cada una?

Una actualización OTA (CodePush, Expo Updates) envía un nuevo bundle JS directamente a las apps instaladas, sin revisión de la store, y los usuarios la reciben en el siguiente inicio de la app o en una comprobación en segundo plano — buena para bugfixes de solo JS y cambios de contenido. Cualquier cosa que toque código nativo — un módulo nativo nuevo, una adición de permiso, un bump de dependencia nativa — ni siquiera está en el bundle JS, así que OTA no puede entregarlo; necesita un build real y un envío a la store. Las guías de Apple restringen explícitamente que OTA no "cambie significativamente el propósito principal de la app", así que un equipo que se apoya en OTA más allá de fixes rápidos arriesga la cuenta de la store, no solo la actualización.