Desarrollo con React Native para móviles, tablets y embebidos

React Native gana cuando su equipo ya vive en TypeScript y React en la web (reutilización masiva de código, sistema de diseño e ingenieros), cuando las actualizaciones de JS por aire cambian de forma sustancial su cadencia de lanzamientos y cuando la mayor parte de su app son pantallas sobre API y no un renderizado a medida. Flutter gana cuando se busca paridad de interfaz multiplataforma al píxel con sistemas de diseño propios. Swift/Kotlin nativo gana para la integración profunda con el sistema operativo, AR/VR y una experiencia premium específica de plataforma. Kotlin Multiplatform gana para compartir lógica de negocio entre equipos nativos ya existentes sin comprometerse con un único framework de interfaz. Trabajamos con las cuatro opciones y recomendamos con honestidad durante el descubrimiento.

React Native 0.76+ es nuestra opción por defecto y la nueva arquitectura (Fabric + TurboModules + modo Bridgeless) está activada por defecto desde la 0.76 (octubre de 2024) y lista para producción en 2026. Hemos publicado apps con la nueva arquitectura con más de 2 millones de MAU en iOS y Android. Hermes es obligatorio (por defecto desde la 0.70). TypeScript 5 estricto. Versión mínima admitida: iOS 15.1, Android API 24. Fijamos la versión de RN por proyecto, mantenemos en producción una versión menor por detrás de la última estable y actualizamos cada trimestre con un sprint de actualización dedicado: nunca dejamos que una versión de RN quede sin soporte.

Sí. El backend usa por defecto regiones de la UE (AWS eu-central-1, GCP europe-west3, Supabase eu-central-1) con claves KMS en la cuenta del cliente. Los Privacy Manifests de la App Store (obligatorios desde mayo de 2024) se entregan con cada API de motivo obligatorio y cada recopilación de datos de SDK declaradas: React Native y las bibliotecas de RN habituales lo necesitan todos y mantenemos una matriz interna de compatibilidad. La sección Data Safety de Play se completa según el inventario real de SDK. Consentimiento del RGPD mediante UMP o un CMP propio, y solicitud ATT de Apple cuando se necesita el IDFA. Entregamos avisos de la CCPA para productos de consumo de EE. UU.

Punto de partida por defecto: Expo prebuild (antes bare con config plugins). Ofrece la ergonomía del SDK de Expo (EAS Build, EAS Update, expo-router) y la libertad de escribir módulos nativos en Swift / Kotlin sin hacer eject. Managed puro cuando no hay ninguna necesidad de módulos nativos y se quiere la mínima infraestructura (MVP temprano, herramientas internas). Bare puro cuando hay integraciones nativas profundas desde el principio (protocolos BLE propios, SDK de hardware, una gran base de código nativa existente que integrar). El 80 % de nuestros proyectos de 2026 empiezan como prebuild.

Sí, es un proyecto habitual. Usamos el RN Upgrade Helper oficial y las guías de migración por versión como columna vertebral, pero cada app es distinta por sus módulos nativos. Paso 1: auditar cada módulo nativo para comprobar su compatibilidad con la nueva arquitectura y sustituir los que no tengan mantenimiento. Paso 2: actualización escalonada 0.68 → 0.71 → 0.73 → 0.76 con pruebas en verde en cada paso. Paso 3: activar la nueva arquitectura por plataforma tras un flag, publicar en beta interna y monitorizar la tasa de fallos de JS y los ANR durante dos semanas. Una app típica de 60k líneas de código tarda de 2 a 4 meses sin congelación de funcionalidades.

El trabajo con React Native es de alcance cerrado y todo incluido, presupuestado en USD en cuatro niveles de proyecto. Un MVP cuesta desde $3,500 (4–8 semanas): una base de código de RN, una primera app funcional con un flujo principal, iOS y Android, y publicación en tiendas. Una app de producción parte de $5,800: varias funcionalidades, integración con el backend, persistencia offline, analítica y publicación en tiendas. Un producto completo parte de $9,200: varios módulos, roles, integraciones externas, CI/CD y QA en dispositivos reales. Una app compleja parte de $11,500: módulos nativos, pagos, sincronización offline-first, escala y pruebas A/B. La cifra exacta depende de la profundidad de los módulos nativos, del número de integraciones, de los requisitos de offline y sincronización y de la superficie de cumplimiento. Usted ve el presupuesto desglosado antes de escribir una sola línea de código. Todos los proyectos incluyen jornada CET con solapamiento de 9:00–13:00 ET para clientes de EE. UU. y NDA, DPA y cesión de propiedad intelectual firmados antes del arranque.

Push mediante react-native-notifications (Wix) o @notifee/react-native para contenido multimedia enriquecido, botones de acción y manejadores en segundo plano. El certificado de APNs y la clave de servidor de FCM se gestionan mediante EAS Credentials o el propio keystore del proyecto: nunca custodiamos credenciales push de producción. Los enlaces profundos usan Universal Links (iOS, apple-app-site-association en un servidor HTTPS) y Android App Links (assetlinks.json) para una vinculación verificada y segura, con enrutado por esquema de URI de react-navigation para la navegación interna. La atribución de campañas usa AppsFlyer o Adjust, con el momento de la solicitud ATT diseñado para maximizar la tasa de aceptación antes de mostrar ATT (no en la primera pantalla que ve el usuario).

Pruebas en tres capas: Jest para la lógica de negocio en JS puro y las pruebas de hooks, con react-native-testing-library para las pruebas unitarias de componentes (rápidas, sin dispositivo); Detox para los flujos de extremo a extremo en simuladores y dispositivos reales (cubre navegación, envío de formularios, gestión de enlaces profundos y cuadros de diálogo de permisos); y compilaciones en la nube de EAS Build ejecutadas contra la matriz de dispositivos de Expo / React Native para detectar fallos en dispositivos reales. Las pruebas de Detox se ejecutan en CI en cada PR. Para sectores regulados (HealthTech, FinTech) añadimos una pasada de seguridad: comprobaciones OWASP MSTG del cifrado de datos en reposo, verificación del certificate pinning y análisis del tráfico de red con Proxyman.

Stack por defecto en 2026: Zustand para el estado global de la interfaz (ligero, sin código repetitivo), TanStack Query (React Query) para el estado del servidor con caché automática, revalidación y actualizaciones optimistas, y MMKV o SQLite (op-sqlite) para el estado offline persistido. Redux Toolkit se usa en bases de código existentes donde una migración costaría más de lo que aportaría. La Context API sirve para valores globales de baja frecuencia (tema, sesión de usuario), pero no para estado de alta frecuencia que provoca re-renderizados de todo el árbol. Evitamos el prop drilling más allá de dos niveles y usamos slices de Zustand para aislar la lógica de dominio. La arquitectura de estado se documenta y revisa en la fase de descubrimiento, no se decide durante el sprint 2.

Sí, esa es la propuesta de valor principal. Una única base de código de JavaScript y TypeScript produce un IPA de iOS y un APK/AAB de Android, ambos enviados desde el mismo repositorio. EAS Build gestiona el proceso de compilación nativa y la firma de código (Fastlane Match o EAS Credentials para iOS, Keystore para Android), y puede enviar directamente a App Store Connect y Google Play mediante EAS Submit. El trabajo principal por plataforma está en el puenteado de módulos nativos, la gestión de permisos (cadenas de finalidad de iOS frente al manifiesto de permisos de Android) y las convenciones de interfaz propias de cada tienda (Human Interface Guidelines frente a Material 3). Probamos en ambas plataformas en cada sprint para detectar pronto las divergencias entre plataformas, no en el momento del envío.

Procesamiento de pagos: SDK de Stripe para React Native, Adyen Drop-In, Apple Pay y Google Pay mediante react-native-payments. Mapas y ubicación: react-native-maps (Google Maps / Apple Maps), Mapbox GL, react-native-background-geolocation. Autenticación: react-native-app-auth (OAuth 2.0 / OIDC), Sign in with Apple, Google Sign-In, Firebase Auth. Analítica: Firebase Analytics, Amplitude, Mixpanel, AppsFlyer. Tiempo real: clientes WebSocket, Socket.io y Pusher para flujos de datos en vivo. Multimedia: react-native-video, puente de ExoPlayer (Android), puente de AVPlayer (iOS), expo-image-picker, react-native-camera. Empresarial: Salesforce Mobile SDK, SAP BTP, Microsoft Authentication Library (MSAL).

Con la nueva arquitectura (Fabric + TurboModules + Bridgeless, por defecto desde RN 0.76), el puente síncrono que era la principal fuente de tirones en el hilo de JS se sustituye por JSI: las llamadas nativas desde JS son directas y síncronas cuando hace falta. Para animaciones y gestos usamos react-native-reanimated (worklets que se ejecutan en el hilo de la interfaz y nunca cruzan el puente) y react-native-gesture-handler (reconocedores en el lado nativo). La computación pesada (procesamiento de imágenes, criptografía, grandes transformaciones de JSON) pasa a un worklet o a un módulo nativo. La virtualización de FlatList, React.memo y useMemo/useCallback se aplican a nivel de componente. Hacemos profiling con Flipper, Reactotron y el React DevTools Profiler, y condicionamos cada PR a un benchmark de rendimiento de Detox en un dispositivo Android de gama media.