App nativa, híbrida o Flutter: cuál elegir para tu negocio

Si estás pensando en una app para el celular, tarde o temprano vas a escuchar tres palabras: nativa, híbrida y Flutter. Suenan a decisión técnica, pero te tocan de cerca: cambian el costo, el plazo, lo que la app puede hacer y cuánto trabajo da mantenerla. Aquí te explicamos qué significa cada una sin jerga, cuándo conviene cada una (incluso cuándo conviene una app nativa pura) y cómo decidir con unas pocas preguntas.

La respuesta corta

• App nativa: se construye por separado para cada plataforma, Android por un lado e iOS por el otro. Es la opción más completa y también la que más trabajo pide.
• App híbrida: una sola base de código hecha con tecnología web, que corre dentro de una app contenedora. Es la más simple de armar, con menos acceso a las funciones del teléfono.
• Flutter: una sola base de código que dibuja su propia interfaz y se publica en Android y en iOS. Para apps de negocio como pedidos, reservas, seguimiento o formularios con fotos, suele ser un buen punto medio entre costo y resultado.

No hay una opción mejor para todos los casos. Hay una que encaja con lo que necesitas hoy. Más abajo te decimos cuándo la mejor respuesta es una app nativa y cuándo es otra cosa.

Qué es una app nativa

Una app nativa se programa con las herramientas y los lenguajes propios de cada plataforma: Kotlin o Java en Android, Swift u Objective-C en iOS. Cada plataforma tiene su propia versión de la app, con su propio código.

Lo bueno:

• Accede a las funciones del teléfono directamente, sin intermediarios.
• Se ve y se comporta como el resto del sistema, porque usa sus mismos componentes.
• Es la opción natural cuando el proyecto exige algo muy específico de una plataforma.

Lo que cuesta:

• Si la quieres en Android e iOS, son dos aplicaciones. Cada pantalla y cada cambio se hacen dos veces.
• Suele requerir un especialista por plataforma.
• Las dos versiones pueden quedar desiguales si no se coordinan bien.

Qué es una app híbrida y qué es Flutter

La palabra "híbrida" se usa con varios sentidos, y eso causa confusión. En su sentido más clásico, una app híbrida es una página web empaquetada dentro de una app: se programa con HTML, CSS y JavaScript, y la app contenedora la muestra y le da acceso a algunas funciones del teléfono. Con un solo código tienes una app para las dos tiendas. Su límite es que, al ser una web por dentro, depende de qué tan bien se comunique con el teléfono.

Flutter es otra cosa. Es un framework de Google, es decir, un conjunto de herramientas para construir apps, que se programa en el lenguaje Dart. Su documentación explica que Flutter no usa los controles del sistema, sino los suyos (se abre en una pestaña nueva): botones, listas y menús los dibuja él mismo. Y que la versión final de la app se compila a código de máquina, en lugar de ser una web dentro de un contenedor.

Dicho simple: la app híbrida clásica es una web con un envoltorio. Flutter es una sola base de código que dibuja su propia pantalla. Por eso hay quien lo llama "multiplataforma" y no "híbrida". Cuando necesita una función propia de cada teléfono, Flutter se comunica con el código de la plataforma mediante canales de plataforma (se abre en una pestaña nueva): ese código se escribe en Kotlin o Java para Android y en Swift u Objective-C para iOS.

Comparación en una tabla

Sobre el rendimiento no te vamos a dar cifras ni comparaciones. Cambian con cada proyecto y cada teléfono. Si tu app tiene un requisito exigente, lo correcto es probarlo con un prototipo antes de comprometerte.

Cuándo conviene cada una

Estos casos son hipotéticos, pero te ayudan a ubicarte.

Conviene una app nativa pura cuando…

• Tu app depende de funciones muy específicas del teléfono: un uso especial de la cámara o de los sensores, o una función que la plataforma acaba de estrenar.
• Es un juego o una herramienta con gráficos o audio muy exigentes.
• Solo la necesitas en una plataforma y quieres que se vea exactamente como las demás apps del sistema.
• Ya tienes un equipo de Kotlin o de Swift que la mantendrá.

Si tu caso es este, te lo vamos a decir con claridad, porque en móviles no hacemos apps nativas separadas por plataforma. Es mejor que lo sepas desde el principio.

Conviene una app híbrida con tecnología web cuando…

• Ya tienes una web que funciona bien y solo quieres que esté también dentro de una tienda.
• Tu contenido es simple y casi no usas funciones del teléfono.

Antes de elegir esta opción, pregúntate si una web bien hecha para celulares ya te basta. Si tus clientes solo entran a informarse, a veces es la respuesta correcta y sale más barata.

Conviene Flutter cuando…

• Una cadena de cafeterías quiere que sus clientes repitan pedidos y reciban avisos, en Android y en iOS, con las dos versiones iguales.
• Un equipo de técnicos que trabaja en la calle necesita registrar visitas, fotos y firmas desde el teléfono.
• Un negocio quiere empezar con una plataforma y sumar la otra más adelante, reutilizando lo que ya está construido.
• Quieres una interfaz con diseño propio, que se vea igual de bien en las dos plataformas.

Los límites de Flutter y de compartir código

Una sola base de código ahorra trabajo, pero no lo elimina. Estos son los límites que conviene conocer:

• Cada tienda tiene sus reglas. Apple revisa todas las apps con sus guías de revisión (se abre en una pestaña nueva), y su propia lista de comprobación aclara que cumplirla no asegura la aprobación. Google Play tiene su propio proceso. Una app puede ser rechazada, y hay que corregirla y enviarla de nuevo.
• Cada plataforma pide su propia preparación. Para publicar en iOS, la documentación de Flutter (se abre en una pestaña nueva) indica que se necesita una computadora con macOS y Xcode, y una cuenta del programa de desarrolladores de Apple. Para Android, la guía de publicación (se abre en una pestaña nueva) explica que la app debe firmarse con un certificado digital y que Google Play prefiere el formato app bundle.
• Hay que probar en cada plataforma. Que la app funcione en un Android no significa que funcione igual en un iPhone. Por eso probamos en celulares reales de cada sistema.
• Algunas funciones piden código nativo. Si necesitas algo muy específico, puede hacer falta escribir una parte en Kotlin o Swift, lo que suma trabajo.
• El sistema cambia. Android, iOS y las tiendas se actualizan con los años, y la app necesita ajustes de vez en cuando, sea nativa, híbrida o Flutter.

Por eso en CodeJ2 el precio de entrada cubre una plataforma. Sumar la segunda suele salir más barato que hacer una app nueva, pero no sale gratis.

Qué usa CodeJ2 y por qué

Para apps móviles usamos Flutter. La razón es práctica: una sola base de código para Android e iOS ahorra trabajo, y cuando hay que cambiar algo, las dos versiones se mantienen iguales. Para una app de negocio, con pantallas claras, avisos, cámara o ubicación, es un camino directo y con costo razonable.

Si además quieres saber cuánto cuesta, lee cuánto cuesta una app para tu negocio. Nuestra app móvil incluye hasta 5 pantallas, diseño de interfaz, pruebas en celulares reales y publicación en la tienda bajo tu cuenta de desarrollador. El precio es desde US$ 840 para una plataforma, y el plazo va de 4 a 8 semanas. Si necesitas un servidor propio, se cotiza aparte. Los detalles están en la página de precios.

Las aplicaciones de escritorio son distintas, y ahí sí trabajamos de forma nativa: C# para Windows y Swift para macOS, una versión por sistema. Un programa de escritorio vive en la computadora, funciona sin internet y se conecta con impresoras, lectores y archivos locales, y para eso conviene hablar el idioma de cada sistema. Si es lo que buscas, mira las aplicaciones de escritorio.

Cómo decidir con cinco preguntas

1. ¿Qué hace la app que una web no puede hacer? Si la respuesta es "nada", empieza por una web.
2. ¿La necesitas en Android, en iOS o en los dos? Con Flutter, empezar por una y sumar la otra más adelante es un camino válido.
3. ¿Usa funciones muy específicas del teléfono o gráficos exigentes? Si sí, pregunta si una app nativa pura es lo correcto.
4. ¿Quién la va a mantener dentro de uno o dos años? Una base de código única es más fácil de entregar y de cuidar.
5. ¿Qué presupuesto y plazo tienes? Una sola base de código suele ayudar a los dos.

Si respondes estas cinco, ya tienes casi decidida la opción. Si quedan dudas, esa es justo la conversación que conviene tener antes de pagar nada.

Siguiente paso

Cuéntanos qué quieres que haga tu app, para quién es y en qué plataforma la necesitas. Con eso te decimos con honestidad si te conviene Flutter, una web o algo distinto, aunque sea más simple de lo que imaginabas.

Puedes empezar por la página de Aplicaciones móviles, completar el brief de cotización o escribirnos por WhatsApp. La primera reunión es gratis.