¿Una app o dos? Lo que la IA cambió en la decisión de su canal móvil

Imagine el comité donde se aprueba la nueva app para sus clientes. Dos propuestas sobre la mesa. La primera dice: «Una sola base de código para iPhone y Android; se construye una vez y se ahorra casi la mitad». La segunda dice: «Dos apps nativas, una por plataforma; es lo serio para un banco o una aseguradora». Cada propuesta trae su caso famoso. Una cita a Shopify, que construyó sus apps con una sola base de código y le funcionó. La otra cita a Airbnb, que abandonó esa misma tecnología en 2018.

Hasta hace poco, el comité habría elegido por el caso que le sonara más. Pero en septiembre de 2026 Shopify, el ejemplo de la primera propuesta, anunció que regresa a nativo [3]. No se fue por lo mismo que Airbnb: su contexto era otro, y su razón tiene que ver con la inteligencia artificial.

Este artículo es para quien firma esa decisión: dirección general, de sistemas, comercial o digital. No es una pregunta técnica. Es una decisión de costo total, velocidad, capacidades del teléfono, equipo y riesgo, y sus supuestos caducan.

Primero, tres palabras

Antes de comparar, conviene que todos en la mesa entiendan lo mismo.

• Nativo: se construye una app para iPhone, con el lenguaje y las herramientas de Apple (Swift), y otra para Android, normalmente en Kotlin, el lenguaje que Google recomienda para Android. Son dos códigos y cierta duplicación. A cambio, cada app adopta directamente las capacidades del teléfono cuando están disponibles.
• Multiplataforma: se escribe una sola app y una capa intermedia la hace funcionar en ambos sistemas. Los ejemplos más conocidos son React Native (nacido en Facebook, se programa con JavaScript, el lenguaje de la web) y Flutter (de Google). Una base de código, un equipo, pero una capa más entre su app y el teléfono.
• Lógica compartida, pantallas nativas: el punto intermedio. Se comparte lo que no se ve (reglas de negocio, cálculos, conexión con sus sistemas) y cada plataforma dibuja sus propias pantallas. El ejemplo más visible es Kotlin Multiplatform, de JetBrains, que Google soporta oficialmente para compartir lógica entre Android e iOS [5].

Y cuatro términos que aparecerán. Framework: la plataforma de desarrollo sobre la que se construye la app. Dependencias: componentes de terceros que la app usa y que hay que actualizar y vigilar. Puente o capa: el código que traduce entre la parte compartida y las funciones del teléfono. Nueva Arquitectura: la forma rehecha en que React Native hace esa traducción.

Dos empresas, contextos distintos, resultado similar

Airbnb, 2018: no le funcionó

Airbnb integró React Native dentro de sus apps nativas, que ya eran grandes y seguían creciendo. En junio de 2018 publicó que dejaba de usarlo [1]. Sus razones, en lenguaje de negocio:

• No compartió tanto como esperaba. Solo una parte pequeña de la app estaba en React Native, y conectarla con el resto exigía mucha infraestructura de puente. Terminó, dice el artículo, manteniendo código en tres plataformas en lugar de dos [1].
• Arreglar fallas se volvió más difícil. Compilar era más rápido; depurar, mucho peor [1].
• Faltaban manos expertas, dentro y fuera de la empresa, para resolver los problemas técnicos que encontraron [1].

El matiz que casi nadie cita: el propio artículo dice que muchas de esas dificultades vinieron del modelo híbrido que eligieron, y que 63 % de sus ingenieros volvería a elegir React Native (con el sesgo, que ellos mismos señalan, de que solo encuestaron a quienes lo usaron) [1]. Y hoy lleva un aviso al inicio: refleja la tecnología de fines de 2017, y pide: «Si estos artículos se citan como única razón para no usar React Native, investigue más por su cuenta antes de decidir» [1].

Airbnb no dijo «React Native no sirve». Dijo: «en nuestra forma de usarlo, con nuestro equipo y nuestra app, no alcanzamos lo que buscábamos».

Shopify, 2020–2025: le funcionó

Shopify decidió en 2020 que sus apps móviles nuevas serían en React Native. En enero de 2025, un director de ingeniería de Shopify publicó el balance de cinco años [2]: «No tener que construir las mismas funciones dos veces nos dio un salto de productividad». Reportó pantallas que cargan en menos de medio segundo y más de 999 de cada 1,000 sesiones sin fallos, y que nativo no significa rápido automáticamente, ni React Native lento automáticamente [2].

El mismo artículo trae las advertencias que un director debe leer [2]:

• Usar React Native al 100 % debía ser un anti-objetivo: seguían necesitando código nativo para lo más nuevo del hardware (escaneo en 2D y 3D, modelos de IA que corren en el teléfono), para los widgets de la pantalla de inicio, el reloj y los atajos de voz, y para tareas largas en segundo plano, como la sincronización que permite a su punto de venta cobrar sin conexión.
• Actualizar la app a cada versión nueva del framework cuesta un trabajo considerable, y las dependencias hay que mantenerlas al día.
• Depurar seguía siendo inestable.

Es decir: le funcionó, con un equipo que además contribuyó activamente al ecosistema de React Native.

Shopify, 2026: le funcionó, y aun así regresa

El 10 de septiembre de 2026, el mismo autor publicó «Native is now the future of mobile at Shopify» [3]. La razón central cabe en una frase: «Los LLM cambiaron uno de los supuestos centrales de nuestra decisión de 2020» [3]. Un LLM es un modelo de lenguaje, la tecnología detrás de los asistentes de IA que hoy escriben código.

El supuesto era que construir cada función dos veces, en Swift y en Kotlin, era demasiado caro. Shopify dice que, con los agentes de IA (asistentes que ejecutan tareas de programación por encargo) haciendo trabajo de implementación, traducción, pruebas y revisión, ese costo dejó de ser el factor que decide [3]. Lo que sí permanece son las ventajas de nativo: estar más cerca de las capacidades de cada plataforma y de las herramientas del fabricante, con menos capas de framework y dependencias en medio [3]. Y lo aclara: no se va porque React Native sea lento; sus apps, dice, son rápidas [3].

El resultado que reporta: su app de compras (Shop) pasó de prueba de concepto a publicada en nativo en 12 semanas; la de comerciantes saldría antes de terminar 2026 [3].

La lección no es «vámonos a nativo»

Ponga los dos casos lado a lado:

Contextos distintos, resultado similar. Si su comité copia la elección de cualquiera de los dos, copia una conclusión cuyo supuesto quizá no aplica a su empresa. Lo que se copia es el método: revisar cada cierto tiempo el supuesto económico sobre el que se tomó la decisión.

Qué cambió con la IA, y qué no

Shopify declara que, para sus apps y su equipo, la IA bajó el costo de escribir la misma función dos veces, y aclara que mantener dos plataformas sigue costando [3]. En su empresa, eso se valida con una prueba acotada antes de darlo por hecho. Y aun donde baja, no baja, o baja mucho menos, todo lo demás:

• Diseñar la experiencia, decidir qué hace la app y qué no.
• Probar en decenas de modelos de teléfono y versiones de sistema operativo.
• Revisar que lo generado sea mantenible. Shopify lo dice sin rodeos: apuntar un modelo de lenguaje a todo su código para «traducirlo» producía una enorme cantidad de código imposible de mantener [3]. Para evitarlo construyó un sistema propio por etapas, con pruebas, revisión visual, dos revisores automáticos y aprobación humana [3].
• Publicar en las tiendas de Apple y Google y atender sus reglas.
• Conectar la app con los sistemas que de verdad atienden al cliente. De esto hablaremos más abajo, porque suele ser lo más caro.

En otras palabras: la IA no hizo gratis tener dos apps. Hizo que el costo de escribir dos veces dejara de ser, para Shopify, el factor que decide. Que lo sea en la suya depende de cuánto control de calidad pueda poner sobre el código generado.

Tampoco hay un ganador universal en desempeño. Un estudio publicado en septiembre de 2026 (un preprint, es decir, aún sin revisión por pares) construyó la misma app cinco veces: nativa en iOS, nativa en Android, Flutter, React Native y Kotlin Multiplatform, y midió cada variante 2,000 veces [4]. Nativo registró los menores tiempos en la parte que no es de interfaz; Kotlin Multiplatform fue la opción compartida más cercana; en esas implementaciones, las compartidas tuvieron menos código que las dos nativas sumadas, lo que no equivale al esfuerzo de cualquier producto. Su conclusión: no hay una tecnología superior en todo; la ventaja depende de qué atributo se mide, de la carga de trabajo y de la plataforma [4].

Cinco criterios para decidir

1. ¿Qué de su roadmap toca el teléfono por dentro?

Haga la lista de lo que su app hará en los próximos dos o tres años y marque lo que depende del hardware o del sistema operativo:

• Biometría: huella o rostro para entrar o autorizar una operación.
• NFC: pagar acercando el teléfono, o leer una credencial o tarjeta.
• Cámara avanzada: leer identificaciones, documentos o códigos; escanear un daño para un siniestro.
• Trabajo en segundo plano: sincronizar, cobrar sin conexión, rastrear una entrega.
• Widgets, reloj, atajos de voz, notificaciones enriquecidas.

Si la lista es corta, una app multiplataforma la resuelve bien y usa piezas nativas puntuales donde haga falta. Si la lista es larga y es el corazón de su propuesta de valor, nativo le permite adoptar cada función nueva de Apple o Google con menos capas. Shopify, aun en sus mejores años con React Native, mantenía código nativo justo para esto [2].

2. ¿Qué equipo tiene, y qué equipo puede retener?

Un equipo fuerte en desarrollo web se mueve rápido en React Native. Un equipo con especialistas de iPhone y Android aprovecha mejor nativo. Airbnb mencionó la falta de manos expertas como parte de su problema [1]; Shopify, con un equipo maduro, hizo funcionar ambas opciones. La pregunta no es qué tecnología es mejor, sino cuál puede sostener su equipo durante cinco años, incluidas las vacantes que tendrá que cubrir.

3. ¿Qué prioriza su cliente?

Llegar primero al mercado y con la misma experiencia en ambos teléfonos, o la sensación más pulida, la respuesta más inmediata y el menor tamaño de la app. Para una app de contenido o de catálogo, lo primero suele pesar más. Para una app donde el cliente mueve dinero varias veces al día, lo segundo pesa más de lo que parece.

4. ¿Cuánto cuesta mantenerla, no construirla?

El costo de construir es visible en la propuesta; el de mantener aparece después. Con multiplataforma hay que seguir el ritmo del framework y sus dependencias. Un ejemplo reciente: React Native volvió predeterminada su Nueva Arquitectura en la versión 0.76, en 2024, y desde la 0.82, en octubre de 2025, ya no se puede desactivar [6]. Una app que actualice a la 0.82 sin haberla validado puede requerir trabajo de compatibilidad y pruebas: presupuéstelo. Con nativo hay que sostener dos códigos y mantenerlos iguales. La IA cambia el peso de este segundo costo; no elimina el primero.

5. ¿Cada cuánto revisa la decisión?

Shopify tomó una buena decisión en 2020 y otra buena decisión, distinta, en 2026, porque cambió un supuesto. Ponga fecha en el acta: qué supuesto sostiene la elección (por ejemplo, «construir dos veces cuesta casi el doble»), cómo se mide, y cuándo se vuelve a revisar.

El punto intermedio: compartir lógica, no pantallas

Entre «una app» y «dos apps» hay una tercera vía que muchas veces conviene a empresas reguladas: compartir lo que no se ve y construir nativo lo que sí se ve.

Piense en lo que debe ser idéntico en iPhone y en Android: cómo se calcula una prima o una comisión, qué validaciones se aplican a una transferencia, cómo se guarda y cifra la información, cómo se habla con sus sistemas. Si esas reglas viven en dos códigos, crece el riesgo de que digan cosas distintas. Con Kotlin Multiplatform, por ejemplo, esas reglas se escriben una vez, y cada plataforma dibuja sus pantallas con sus propias herramientas. Google lo soporta oficialmente para compartir lógica de negocio entre Android e iOS, y permite elegir cuánto compartir: desde solo la lógica hasta la aplicación completa [5]. En el estudio citado, fue la opción compartida más cercana a nativo en desempeño [4].

Su costo: el equipo debe dominar las dos plataformas y, además, la capa compartida. No es la opción más barata; es la que suele dar paridad de reglas sin renunciar a la experiencia nativa.

Situación y opción que suele convenir

Guía de conversación, no receta.

Escenario (cifras ilustrativas, sin cliente). Una aseguradora planea su app para tres años: 24 funciones. Al marcarlas, 5 dependen del teléfono por dentro (cámara para siniestros, biometría, notificaciones enriquecidas, trabajo sin conexión del ajustador y un widget de póliza). Las otras 19 son pantallas de consulta y trámite que llaman a sus sistemas. El 5 de 24 es un inventario, no un veredicto: cada una de las 5 se pondera por criticidad, dependencia de un SDK (el kit de un tercero, como uno antifraude), obligación regulatoria y desempeño. Una sola función crítica puede decidir: si el trabajo sin conexión del ajustador es la apuesta del negocio, pesa más que las 19 y la balanza se inclina a nativo o a lógica compartida. En cualquier caso, las 19 pantallas dependen de que los sistemas de atrás respondan: ahí está la mayor parte del riesgo.

Los riesgos, en lenguaje de negocio

Cualquiera de las tres opciones tiene riesgos. Cinco para la mesa.

• «El framework cambió y hay que migrar». Una app multiplataforma depende del ritmo de un tercero y de muchas dependencias. Shopify describe la actualización a cada versión como un trabajo considerable [2], y la Nueva Arquitectura exige trabajo de compatibilidad a quien actualice sin haberla validado [6]. Presupueste el mantenimiento, no solo la construcción.
• «No sabemos por qué falla». Más capas entre su código y el teléfono significan fallas más difíciles de encontrar. Airbnb lo vivió [1] y Shopify lo seguía reportando en 2025 [2]. En una app que mueve dinero, el tiempo para encontrar una falla es tiempo con clientes molestos.
• «La IA lo escribió y nadie lo revisó». Generar dos apps con IA es más barato; generar dos apps imposibles de mantener también. El regreso de Shopify vino con controles en cada etapa [3]. Si su proveedor propone «dos apps nativas porque la IA las hace», pregúntele cómo controla la calidad de lo que la IA escribe.
• «En Android hace una cosa y en iPhone otra». Con dos apps nativas, la paridad no es automática: crece el riesgo de que una regla cambie en una y no en la otra. Decida qué debe ser idéntico (reglas, montos, mensajes legales), cuál es la fuente que manda, y respáldelo con contratos y pruebas de paridad entre ambas apps. Deje en el teléfono solo lo que la experiencia o la operación sin conexión exijan.
• «La app quedó lista, pero el core no». El riesgo más frecuente y el menos discutido. Lo tratamos aparte.

La app es la cara; lo difícil está atrás

En el comité, la discusión suele ser una app o dos. Pero el cliente no juzga la tecnología de la app: juzga si su pago se aplicó, si su póliza aparece, si su saldo es el correcto. Todo eso lo decide el sistema central (el core) y las integraciones que lo conectan con la app.

Una app impecable, nativa o multiplataforma, que consulta un core lento o que solo recibe un «recibido» cuando el cliente espera un «hecho», se percibe como una mala app. Por eso la decisión del canal móvil va acompañada de otras:

• Qué hace la app y qué hacen sus sistemas. Las reglas que deben ser idénticas en todos los canales (app, web, sucursal, asesor) conviene que tengan su versión que manda atrás, una sola vez; en la app, solo lo necesario.
• Cómo se integra con el core. Qué consultas van en línea y qué operaciones van con folio y seguimiento. Es el tema del artículo «¿En línea o asíncrono? Cómo elegir la forma de integrar sus sistemas».
• Qué pasa cuando el sistema de atrás no responde. Qué ve el cliente, qué se guarda en el teléfono y cómo se reintenta sin duplicar un pago.

Si la integración está bien resuelta, cambiar la tecnología de la app, como hizo Shopify, es un proyecto de canal. Si no lo está, cualquier cambio de app arrastra consigo el problema de atrás.

Cinco preguntas para su próximo comité

1. ¿Qué porcentaje de nuestro roadmap móvil depende del teléfono por dentro (biometría, NFC, cámara, segundo plano, widgets), y cuánto es pantalla que consulta nuestros sistemas?
2. ¿Qué equipo podemos sostener durante cinco años, incluidas las vacantes, para la opción que elijamos?
3. ¿Qué supuesto económico sostiene nuestra decisión actual, y cuándo fue la última vez que lo medimos?
4. Si usamos IA para construir, ¿cómo controlamos la calidad de lo que genera antes de que llegue a producción?
5. ¿Dónde vive la única versión de las reglas que deben ser idénticas en iPhone, Android y el resto de canales?

Si en dos o más la respuesta es «no sé», ahí puede estar su riesgo.

Por dónde empezar esta semana

Tome el roadmap de su app y marque cada función con una de dos etiquetas: «toca el teléfono por dentro» o «es pantalla sobre nuestros sistemas». Cuente cuántas hay de cada una y señale las críticas. Ese inventario, más el equipo que tiene, le dice más sobre la opción que conviene que cualquier caso famoso.

Qué hace Hábil

Hábil es una consultora mexicana de ingeniería, fundada en 2006, que diseña y construye canales digitales (apps web, móviles y de escritorio) conectados con los sistemas que la empresa ya tiene. No llegamos con la tecnología elegida: ayudamos a decidir entre nativo, multiplataforma o lógica compartida según su roadmap, su equipo y sus sistemas, y construimos con la opción que convenga. Vea la página Canales digitales (apps web, móviles y escritorio).

La primera conversación es sin costo: parte de su roadmap móvil y de cómo se conectará con sus sistemas actuales. Escríbanos por WhatsApp.

Las afirmaciones de empresas reflejan sus publicaciones al 13 de octubre de 2026; son declaraciones de cada empresa, no mediciones propias. Las citas están traducidas del inglés.