UNDERCOVERLABEs la primera pelea que aparece en cualquier proyecto de desarrollo de apps. Nativa o multiplataforma. Y casi siempre es la pregunta equivocada, porque llega antes de la única que importa: qué tiene que hacer tu app. Te explicamos la diferencia sin tecnicismos y, sobre todo, cuándo esa decisión cambia algo para tu negocio y cuándo no.
Qué significa cada cosa, en cristiano
Una app nativa se programa dos veces: una para iOS con su lenguaje, otra para Android con el suyo. Dos bases de código, dos equipos o el doble de trabajo del mismo equipo. A cambio, control total sobre el dispositivo.
Una app multiplataforma se escribe una sola vez sobre una base común, y de ahí salen las dos apps para las dos tiendas. Nosotros trabajamos con React Native para esto. Un código, dos plataformas, la mitad de mantenimiento.
Dicho así parece que multiplataforma gana siempre. No es tan simple, pero está más cerca de la verdad de lo que te contará quien vive de venderte lo caro.
Por qué casi siempre te da igual
Piensa en las apps que abre tu empresa cada día: gestión, reservas, fidelización, contenido, una herramienta interna para el equipo. Ninguna de esas necesita exprimir el procesador del móvil ni acceder a rincones raros del sistema. Hacen su trabajo, y multiplataforma las hace igual de bien por bastante menos dinero.
Para el 80% de las apps de empresa, elegir nativa por defecto es pagar el doble por una diferencia que tus usuarios no van a notar.
El coste no es solo el desarrollo inicial. Es el mantenimiento. Cada versión de iOS y de Android que sale hay que seguirla. Con un solo código, ese trabajo se hace una vez. Con dos, se hace dos veces, para siempre. Esa factura recurrente es la parte que nadie te enseña en la primera reunión.
Cuándo sí importa de verdad
Hay casos en los que la respuesta honesta es nativo, y te lo diremos aunque nos dé más trabajo:
- La app depende de rendimiento gráfico intenso: juegos, edición de vídeo en el móvil, realidad aumentada pesada.
- Necesita funciones muy específicas y recientes del dispositivo, en cuanto salen, sin esperar.
- Es un producto donde la fluidez extrema es la propuesta de valor, no un detalle.
Y hay una vía intermedia que usamos a menudo: empezar multiplataforma para validar la idea rápido y barato, y si un módulo concreto acaba pidiendo rendimiento nativo, reescribir solo ese módulo. No hay que casarse con una decisión el día uno.
La pregunta que sí deberías hacer
No es "nativa o multiplataforma". Es "qué tiene que resolver esta app, y para quién". Cuando esa respuesta está clara, la tecnología se elige sola, y casi nunca es la conversación cara que alguien intentaba venderte.
Por eso, antes de hablar de código, miramos qué necesita tu app de verdad. A veces la respuesta ni siquiera es una app: es una web bien hecha que resuelve lo mismo por mucho menos. Si es tu caso, te lo decimos antes de empezar, no a mitad de proyecto.
Cómo lo hacemos nosotros
Multiplataforma con React Native como base, y módulos nativos cuando un caso concreto lo pide. No por moda: porque la mayoría de proyectos rinde mejor así, en coste y en tiempo, sin que lo pague la calidad.
Lo hemos aplicado en apps que están en producción y se usan cada día: la app del BC MoraBanc Andorra (partidos, resultados, carnet de socio), Impuls Jove (búsqueda de empleo temporal con matching, avalada por la CCIS) o Snowplus, en producción desde 2019. Producto real, no demos. Ese es el mejor argumento de que la tecnología elegida aguanta el día a día.
