Todo lo que has construido en este curso vive dentro de un navegador. Los componentes producen elementos del DOM, los estilos son CSS, los eventos son eventos del DOM y el almacenamiento es localStorage. Esta última lección del módulo hace el salto más grande: llevar lo aprendido fuera del navegador, a una aplicación móvil que se instala desde una tienda y que dibuja vistas nativas de verdad. La buena noticia es que la mayor parte de lo que sabes se transfiere intacto —componentes, props, estado, hooks, contexto, Redux, TanStack Query, los tipos de TypeScript de la lección anterior—; lo que cambia es la capa de presentación y las APIs de plataforma. Vas a montar CicloUrbanoMovil con Expo, portar TarjetaBicicleta, EtiquetaEstado y ListaBicicletas, entender por qué FlatList no es un map, navegar con Expo Router, y saber exactamente qué código del proyecto web puedes copiar sin tocar una línea. El objetivo no es dominar React Native en una lección, sino entender el modelo, sus límites y qué se reutiliza, para que el salto sea una decisión informada.

1. Qué es React Native y en qué se diferencia de las alternativas
2. Qué se comparte con React y qué no
3. La arquitectura en una idea
4. Expo: crear CicloUrbanoMovil
5. Componentes básicos y su equivalencia con la web
6. Estilos: StyleSheet y las diferencias con CSS
7. Portar EtiquetaEstado y TarjetaBicicleta
8. ListaBicicletas con FlatList
9. Qué se reutiliza tal cual del proyecto web
10. Navegación con Expo Router
11. Capacidades del dispositivo
12. Diferencias de plataforma y accesibilidad móvil
13. Depuración y pruebas
14. Publicación en las tiendas
15. Cierre del módulo y puente al proyecto final

React Native es React con otro objetivo de renderizado. El mismo React que conoces —el mismo reconciliador, los mismos hooks, la misma reconciliación del módulo 1— pero en lugar de producir nodos del DOM produce vistas nativas: un UIView en iOS, un android.view.View en Android.

Eso significa que un <Text> de React Native no es un <p> disfrazado. Es un UILabel real, con el desplazamiento del sistema, la selección del sistema, la accesibilidad del sistema y el rendimiento del sistema.

Comparativa con las opciones que suelen ponerse sobre la mesa:

La diferencia que decide entre híbrida y React Native es la fila de la interfaz. Una aplicación híbrida simula los componentes del sistema con HTML y CSS: el desplazamiento no tiene la misma inercia, los formularios no se comportan igual y el usuario lo nota aunque no sepa decir por qué. React Native usa los componentes de verdad.

Y la honestidad sobre el porcentaje compartido: el 85-95 % es de la lógica, no de la interfaz completa. La navegación, los espaciados, los gestos y varias convenciones difieren entre iOS y Android, y una aplicación cuidada trata esas diferencias en lugar de ignorarlas.

Esta tabla es el mapa mental de la lección.

Lo importante de esta tabla es dónde está la frontera: todo lo que es React se comparte; todo lo que es web no. La distinción que en 10-03 separaba servidor de cliente aquí separa lógica de presentación, y es igual de útil para decidir dónde va cada cosa.

Cómo funciona por dentro, en el nivel de detalle que hace falta:

La idea en una frase: tus componentes describen la interfaz y el sistema pinta vistas nativas de verdad. Tú no manipulas vistas; describes cómo debe verse el estado actual y React se encarga del resto. Es exactamente el modelo declarativo del módulo 1, con otro destino.

Sobre la arquitectura nueva (activada por defecto desde React Native 0.76), basta con saber tres nombres y qué resuelven:

• JSI (JavaScript Interface): permite que JavaScript llame al código nativo directamente, sin serializar mensajes JSON a través de un puente asíncrono. Elimina el cuello de botella histórico de React Native.
• Fabric: el renderizador nuevo, que permite operaciones síncronas y hace posible que la interfaz responda en el mismo cuadro.
• TurboModules: los módulos nativos se cargan cuando se usan, no todos al arrancar, lo que reduce el tiempo de inicio.

No hace falta más para trabajar. Lo relevante en la práctica es que los problemas de rendimiento clásicos de React Native —listas que van a tirones, animaciones que se atascan— han mejorado mucho, y que los principios del módulo 8 (evitar renders innecesarios, memorizar, virtualizar) siguen siendo válidos y aquí importan todavía más, porque un móvil tiene menos margen que un portátil.

Se puede usar React Native «desnudo» con la CLI oficial, pero eso obliga a tener Xcode y Android Studio configurados desde el minuto uno, y a gestionar a mano la configuración nativa. Expo es la forma recomendada de empezar, y la que recomienda la documentación oficial de React Native.

El último comando muestra un código QR en el terminal. Instalas Expo Go en tu móvil, escaneas el código y la aplicación se abre en el dispositivo real, con recarga en caliente al guardar. Sin cables, sin firmar nada, sin Xcode.

Qué aporta Expo:

Estructura del proyecto recién creado:

Reconocerás el patrón de app/: es el mismo enrutamiento por carpetas de Next.js. Y fíjate en que las plantillas de Expo vienen con TypeScript ya configurado, así que todo lo de 10-04 aplica directamente.

Adaptaremos la estructura a las convenciones del curso:

No hay etiquetas HTML: hay componentes importados de react-native.

La regla que más se olvida al empezar, y merece destacarse:

En la web, cualquier elemento puede contener texto. En React Native, solo <Text> puede. La razón es que el texto se mide y se pinta con el motor tipográfico nativo, que es un componente distinto de una vista contenedora. A cambio, <Text> sí puede anidarse y hereda estilos, que es la única herencia de estilos que existe en React Native:

Y sobre lo pulsable, la recomendación actual es Pressable, que da control fino sobre los estados:

Fíjate en style como función que recibe { pressed }: es el sustituto de :active de CSS, y es una buena muestra de cómo se resuelven aquí los estados visuales.

No hay CSS. Los estilos son objetos de JavaScript, y se agrupan con StyleSheet.create:

Diferencias frente a CSS, que son muchas y conviene tener presentes:

Las dos diferencias que más desconciertan al principio:

flexDirection: 'column' por defecto. En CSS, un contenedor flex apila en fila; aquí apila en columna, que es lo habitual en una pantalla vertical. Si algo aparece apilado cuando lo esperabas en línea, es esto.

No hay cascada. Un estilo puesto en la View padre no lo heredan los hijos. Cada componente lleva el suyo. Puede parecer un retroceso, pero elimina de un plumazo la clase de errores más frecuente en CSS: el estilo que llega de un ancestro que nadie recuerda. Es la misma filosofía de los CSS Modules del módulo 2, llevada al extremo.

Los estilos se combinan pasando un array, y gana el último:

Y las variables de tema de CicloUrbano se trasladan a un módulo de constantes, ya que no hay :root:

El as const de 10-04 hace que cada valor sea un literal, lo que da autocompletado exacto al usarlo.

Aquí se ve lo que de verdad cambia. La estructura de props y la lógica se mantienen idénticas; solo cambia la capa de presentación.

Compara con la versión web de 10-04: el tipo Props, el objeto TEXTOS y la firma son exactamente los mismos. Lo único que cambia es <span> → <View> + <Text>, y estilos.etiqueta de CSS Modules → StyleSheet. Un Record<EstadoBicicleta, string> sigue obligando a cubrir los tres estados.

La convención de props del curso se respeta al pie de la letra: manejador interno manejarPulsacion, prop hacia fuera alSeleccionar. Lo único específico de la plataforma es Pressable en lugar de <Link>, accessibilityLabel en lugar de aria-label, y flexDirection: 'row' explícito en la cabecera.

Aquí está la diferencia conceptual más importante de la lección, y enlaza directamente con la virtualización de 08-01.

En la web escribías esto:

Con 5 bicicletas funciona. Con 500 en un móvil, la aplicación se bloquea: se crean 500 vistas nativas de golpe, se consume memoria y el hilo de interfaz se queda sin margen. Un <ScrollView> con map dentro tiene exactamente el mismo problema, porque también renderiza todos sus hijos.

FlatList es una lista virtualizada: solo mantiene en memoria los elementos visibles y unos pocos alrededor, y reutiliza las vistas al desplazarse.

Las props esenciales:

Por qué FlatList no es un map, en tabla:

Y aquí conecta el módulo 8 de forma directa: la virtualización que allí se planteaba como una técnica avanzada que había que añadir con una biblioteca, en React Native viene de serie y es el camino por defecto. La razón es el contexto: en un móvil, ese margen no es opcional.

Un consejo de rendimiento que también viene de allí: envuelve TarjetaBicicleta en memo y define renderItem con useCallback. Al desplazarse, FlatList vuelve a renderizar con frecuencia, y evitar renders innecesarios se nota en la fluidez de forma mucho más visible que en la web.

Esta es la pregunta práctica: cuánto código se copia sin tocar.

En un equipo que mantiene las dos aplicaciones, ese núcleo compartido se extrae a un paquete (@ciclourbano/nucleo) dentro de un monorepo. Y fíjate en la consecuencia práctica de 10-04: tipos/dominio.ts es lo primero que se comparte, porque los tipos no tienen dependencias y ahora los dos proyectos hablan del mismo dominio verificado.

La sustitución más habitual, useAlmacenLocal:

La diferencia clave: localStorage es síncrono y AsyncStorage no, así que aparece un tercer valor, cargado, que indica si ya se leyó la preferencia. Es el mismo problema del tema oscuro que trataste en 10-01 con la hidratación, con otra causa.

Expo Router usa enrutamiento por ficheros, exactamente como el App Router de 10-01. Si entendiste aquello, esto ya lo sabes.

Equivalencias con React Router, que es lo que ya conoces del módulo 6:

La plantilla de pestañas:

Y una pantalla de detalle con parámetro dinámico:

Dos conceptos de navegación móvil que no tienen equivalente web:

• Pila (stack): las pantallas se apilan y se vuelve atrás con el gesto o el botón físico de Android. La animación de entrada por el lateral es parte de la convención de la plataforma.
• Pestañas (tabs): la barra inferior con las secciones principales. Cada pestaña conserva su propia pila y su estado al cambiar de una a otra, algo que en la web habría requerido trabajo explícito.

Y fíjate en que useBicicleta es la misma consulta de TanStack Query del proyecto web: la capa de datos se reutiliza intacta.

Es la razón principal por la que una empresa como CicloUrbano querría una aplicación móvil y no solo una web. Tres ejemplos con sentido de producto:

Ubicación: encontrar la estación más cercana.

Cámara: leer el código QR de la bicicleta para desbloquearla.

Notificaciones: avisar de que la reserva termina en 10 minutos.

Advertencia sobre permisos y privacidad. Cada una de estas capacidades exige el permiso explícito del usuario, y se puede denegar. Tres reglas que no son opcionales: (1) pide el permiso cuando lo necesites, no al arrancar, y explica antes para qué; (2) la aplicación debe funcionar sin él —si deniegan la ubicación, muestra la lista de estaciones ordenada alfabéticamente—; (3) declara los usos en app.json con textos comprensibles: Apple y Google rechazan aplicaciones con justificaciones genéricas, y la ubicación en segundo plano es objeto de revisión especial.

iOS y Android no son iguales, y una aplicación cuidada lo reconoce en lugar de forzar un diseño único.

Diferencias que más se notan:

Accesibilidad. Los conceptos del módulo 3 se trasladan con otros nombres, y en móvil importan igual o más porque VoiceOver (iOS) y TalkBack (Android) son de uso muy extendido:

Dos reglas propias del móvil: la zona pulsable mínima es de unos 44×44 puntos (usa hitSlop si el elemento visual es más pequeño), y el contraste debe seguir cumpliendo la ratio 4,5:1 —los colores de CicloUrbano ya lo cumplen—.

En breve, porque los conceptos ya los tienes del módulo 9.

Depuración:

• Recarga rápida (Fast Refresh): activa por defecto, conserva el estado al guardar.
• Menú de desarrollo: agitando el dispositivo o con m en el terminal de Expo.
• React DevTools: funcionan igual, incluido el Profiler de 08-05.
• Depurador de Expo: inspector de red, consola y puntos de interrupción de JavaScript.
• console.log: aparece en el terminal donde corre npx expo start.

Pruebas, con las mismas herramientas del módulo 9 y equivalentes:

La API de Testing Library es casi idéntica, y el principio rector de 09-01 —probar el comportamiento, no la implementación— se mantiene sin cambios:

La diferencia visible: fireEvent.press en lugar de click, y getByText devuelve un nodo de React Native en lugar de un elemento del DOM. Las consultas por rol siguen siendo la forma preferida, igual que en 09-03, y por el mismo motivo: si el elemento no tiene rol, tampoco lo tiene para el lector de pantalla.

Un resumen de lo que implica, porque cambia la forma de planificar las entregas.

Lo que hay que saber antes de comprometer fechas:

Y la pieza que cambia el ritmo de trabajo: las actualizaciones por aire. Con eas update, un cambio que solo toque JavaScript —una corrección de texto, un ajuste de estilo, un error de lógica— se publica sin pasar por revisión:

Los usuarios lo reciben al siguiente arranque. Lo que sí requiere una versión nueva y su revisión es cualquier cambio en código nativo: una biblioteca nueva con parte nativa, un permiso nuevo, un cambio de icono o de nombre. La regla, que conviene tener escrita en el equipo: JavaScript por aire, código nativo por la tienda.

El Módulo 10 ha llevado React a cinco terrenos que no existían al empezar:

• 10-01 · SSR con Next.js: el HTML llega construido; las cuatro estrategias de renderizado; la hidratación y sus discrepancias; ciclourbano-web con App Router.
• 10-02 · SSG e ISR: generar una vez y revalidar; generateStaticParams, revalidate, revalidateTag; la arquitectura híbrida cerrada.
• 10-03 · Suspense y RSC: el mecanismo de suspensión, el streaming, la frontera 'use client' y las acciones de servidor.
• 10-04 · TypeScript: el análisis estático como capa más barata; el dominio en tipos/dominio.ts; componentes, hooks, eventos, Redux, Query y validación en el límite con Zod.
• 10-05 · React Native: la misma React fuera del navegador.

Y ahora el aviso que ya se dio en 10-02 y en 10-03, ahora en firme:

El Módulo 11 construye el proyecto final con Vite + React Router, la aplicación de gestión de CicloUrbano que llevas montando desde el primer módulo. No con Next.js ni con React Native.

No es una contradicción: es la aplicación del criterio que este módulo te ha dado. El proyecto final es una herramienta de trabajo, privada, tras identificación y con mucho estado interactivo, exactamente la casilla de la tabla de 10-02 donde CSR es la respuesta correcta.

Lo que el proyecto final pondrá en práctica, módulo por módulo:

• Poner texto fuera de un <Text>. Error clásico del primer día: <View>Hola</View> falla. Todo el texto va dentro de Text.
• Esperar que los estilos se hereden. No hay cascada. Cada componente lleva su style; la única herencia es la de Text dentro de Text.
• Olvidar flexDirection: 'row'. Por defecto se apila en columna. Si algo aparece uno debajo de otro cuando lo querías en línea, es esto.
• Usar ScrollView con .map() para listas de datos. Renderiza todo y bloquea la aplicación. FlatList desde el primer momento.
• Escribir fontWeight: 600. Debe ser la cadena '600'.
• Usar px, rem o vh. Los números van sin unidad. vh y rem no existen; el tamaño de pantalla se consulta con useWindowDimensions().
• Copiar useAlmacenLocal sin adaptarlo. AsyncStorage es asíncrono: hay que gestionar el estado «aún no cargado».
• Pedir todos los permisos al arrancar. Molesta al usuario y es motivo de rechazo en las tiendas. Se piden cuando se necesitan, con contexto.
• Suponer que la aplicación funciona sin permisos. Diseña siempre el camino alternativo cuando se deniegan.
• Probar solo en un simulador de iOS. Los tamaños, los gestos, el botón atrás y el rendimiento son distintos en Android y en dispositivos reales de gama media.
• Consejo: empieza por la lógica compartida. Copia tipos/, las utilidades puras, los slices y las consultas antes de escribir una sola pantalla. Verás inmediatamente cuánto ya está hecho.
• Consejo: piensa en gestos, no en clics. Deslizar, mantener pulsado, tirar para recargar y el botón atrás son parte del lenguaje móvil. Portar la web literalmente produce una aplicación que se siente extranjera.

Ejercicio 1. Este componente, portado apresuradamente de la web, tiene cinco errores propios de React Native. Encuéntralos, explica cada uno y reescríbelo.

Ejercicio 2. Escribe PantallaEstaciones para CicloUrbanoMovil: obtiene las estaciones con la consulta de TanStack Query reutilizada del proyecto web, las muestra en una FlatList con «tirar para recargar», trata los estados de carga, error y lista vacía, y navega al detalle al pulsar. Indica además qué ficheros del proyecto web has copiado sin modificar.

Ejercicio 3. El equipo de CicloUrbano quiere que, al abrir la aplicación, se muestre en primer lugar la estación más cercana. Diseña la solución completa: qué permiso hace falta y cuándo pedirlo, qué ocurre si el usuario lo deniega, dónde vive esa lógica para poder probarla, y qué parte se puede reutilizar en la web. Escribe el hook useEstacionMasCercana y explica sus decisiones.

Solución 1. Los cinco errores:

1. onClick no existe. En React Native es onPress, y una View no es pulsable: hay que usar Pressable o TouchableOpacity.
2. Texto suelto dentro de View. {estacion.nombre} y la línea del barrio deben ir dentro de <Text>.
3. padding: '16px'. Los valores numéricos van sin unidad ni comillas: padding: 16.
4. display: 'flex' sobra, y falta flexDirection: 'row': por defecto se apila en columna, así que la cabecera no quedaría en línea.
5. Faltan los tipos (10-04) y el accessibilityRole/accessibilityLabel para el lector de pantalla.

Solución 2.

Ficheros copiados sin modificar del proyecto web:

• tipos/dominio.ts — las entidades del dominio.
• tipos/esquemas.ts — los esquemas de Zod, incluida la validación en el límite.
• consultas/estaciones.ts — la consulta de TanStack Query; solo se ajusta la URL base, porque localhost desde un móvil real apunta al propio móvil (hay que usar la IP de la máquina de desarrollo o una variable de entorno).

Lo único que se ha escrito de nuevo es la capa de presentación: FlatList en lugar de <ul>, ActivityIndicator en lugar de IndicadorDeCarga, y RefreshControl, que no tiene equivalente en la web.

Solución 3.

Las decisiones y su justificación:

• Cuándo pedir el permiso: al entrar en la pantalla de estaciones, no al arrancar la aplicación. El usuario entiende para qué se le pide porque está mirando una lista de estaciones. En producción conviene además una pantalla previa que lo explique antes de lanzar el diálogo del sistema, porque en iOS solo se puede preguntar una vez.
• Si lo deniega: la lista se ordena alfabéticamente y usandoUbicacion queda en false, para que la interfaz pueda mostrar un aviso discreto con un enlace a los ajustes. La funcionalidad principal no depende del permiso.
• Dónde vive la lógica para poder probarla: el cálculo está en utilidades/geografia.ts, una función pura ordenarPorCercania(estaciones, lat, lon). Se prueba con Vitest sin simuladores ni permisos, exactamente como validarReserva en 09-02. El hook solo orquesta permiso, obtención y estado.
• Qué se reutiliza en la web: ordenarPorCercania tal cual, y la estructura del hook casi entera; solo se sustituye expo-location por navigator.geolocation. Merece la pena extraer un obtenerPosicion() por plataforma y dejar el resto compartido.
• La limpieza con cancelado evita actualizar el estado si el usuario sale de la pantalla mientras se resuelve la ubicación: el patrón de 05-02 aplicado igual.

Con esta lección se cierra el Módulo 10 y, con él, todo el recorrido técnico del curso antes del proyecto.

Lo esencial de React Native es que es React con otro objetivo de renderizado: el mismo reconciliador, los mismos hooks y el mismo modelo declarativo del módulo 1, pero produciendo vistas nativas de verdad en lugar de nodos del DOM. Eso lo separa de la web móvil, de la PWA y de la aplicación híbrida, que simulan los componentes del sistema dentro de un WebView y siempre se sienten como una web. De la arquitectura nueva basta con retener tres nombres —JSI, Fabric y TurboModules— y su consecuencia: menos cuello de botella, arranque más rápido, y los principios de rendimiento del módulo 8 más vigentes que nunca, porque un móvil tiene menos margen.

La frontera es clara: todo lo que es React se comparte; todo lo que es web no. Se van el DOM, las etiquetas HTML, el CSS con su cascada y sus selectores, localStorage y React Router. Se quedan los componentes, las props, la composición, todos los hooks, el contexto, memo, Suspense, los límites de error, Redux Toolkit, TanStack Query y los tipos de 10-04.

En herramientas queda montado CicloUrbanoMovil con Expo (npx create-expo-app, Expo Go, EAS Build y EAS Update), con Expo Router navegando por ficheros igual que el App Router de 10-01 —_layout.tsx, [bicicletaId].tsx, useLocalSearchParams, pilas y pestañas—. La interfaz se escribe con View, Text, Image, TextInput, Pressable, ScrollView, FlatList y SafeAreaView, con dos reglas que hay que interiorizar el primer día: todo el texto va dentro de Text y no hay cascada de estilos. Los estilos son objetos de StyleSheet.create, en camelCase, con números sin unidad, Flexbox por defecto y flexDirection: 'column', sin selectores, sin :hover y sin media queries.

Del porte de CicloUrbano, lo importante es lo poco que cambia: EtiquetaEstado y TarjetaBicicleta conservan la misma estructura de props, los mismos tipos y la misma lógica; solo se reescribe la presentación y las convenciones de la plataforma (onPress, accessibilityLabel). Y ListaBicicletas con FlatList —data, renderItem, keyExtractor— introduce la lección de fondo: FlatList no es un map, sino una lista virtualizada que mantiene en memoria una quincena de elementos en lugar de quinientos. La virtualización que en 08-01 era una técnica avanzada que había que añadir, aquí es el camino por defecto.

Y el balance del que arranca todo lo demás: se copian sin tocar tipos/dominio.ts, los esquemas de Zod, validarReserva, disponibilidad, los slices de Redux, las consultas de TanStack Query y los hooks sin DOM; se adaptan useAlmacenLocal (a AsyncStorage, que es asíncrono), useAnchoVentana y useEstadoConexion; y se reescribe solo la capa de presentación y la navegación. Encima de ese núcleo, el móvil añade lo que la web no puede dar —ubicación, cámara y notificaciones— con la regla que las gobierna a todas: pide el permiso cuando lo necesites, explica para qué, y haz que la aplicación funcione si te dicen que no. Cierran el cuadro las diferencias de plataforma con Platform.select, la accesibilidad móvil con accessibilityLabel y accessibilityRole, las pruebas con Jest y @testing-library/react-native bajo el mismo principio de 09-01, y la publicación con su regla de oro: JavaScript por aire con eas update, código nativo por la tienda.

Con esto se cierra el Módulo 10. Empezaste el módulo con una aplicación que se descargaba al navegador y se ejecutaba allí, y lo terminas sabiendo generar HTML en el servidor y en la construcción, decidir qué estrategia merece cada pantalla, entender dónde se ejecuta cada componente y qué cruza la frontera entre servidor y cliente, convertir contratos implícitos en tipos verificados, y llevar todo ese conocimiento a un móvil. No has aprendido cinco tecnologías sueltas: has aprendido a elegir.

Y ahora toca demostrarlo. El Módulo 11: Proyecto construye la aplicación completa de CicloUrbano de principio a fin, con Vite y React Router —la decisión correcta para una herramienta de gestión privada, interactiva y tras identificación, según el criterio que tú mismo has aplicado en 10-02—. Ahí se juntan los diez módulos: la configuración y la planificación, la interfaz con sus componentes y su accesibilidad, el estado con contexto, Redux Toolkit y TanStack Query, las pruebas en sus cuatro niveles y el despliegue a producción. La próxima lección es Configuración y Planificación del Proyecto.