Firebase, Flutter, React Native: qué tecnologías se usan en una app y qué significan para ti

En este artículo

1. ¿De qué partes está hecha una app?
2. ¿App nativa o multiplataforma?
3. ¿Qué son Flutter y React Native?
4. ¿Qué es Firebase y cuándo conviene?
5. ¿Y el backend propio?
6. ¿Qué significa cada elección para tu bolsillo?
7. Preguntas que debes hacerle a tu proveedor
8. En resumen
9. Preguntas frecuentes

Cuando pides cotizaciones para una app, cada proveedor nombra tecnologías distintas: «la hacemos en Flutter», «nosotros usamos React Native», «el backend va en Firebase», «nativa en Kotlin y Swift». Para un dueño de empresa, suenan igual. Pero la elección afecta cuánto pagas hoy, cuánto pagarás en mantenimiento, quién puede seguir el proyecto si cambias de proveedor y si tus datos quedan bajo tu control.

Esta guía explica, sin tecnicismos, con qué se hace una app y qué significa cada opción para tu negocio. En CONIT desarrollamos sistemas y apps a medida para empresas peruanas con tecnologías web y móviles, y entregamos el código al cliente, así que vemos de cerca las consecuencias de cada elección.

¿De qué partes está hecha una app?

Una app de empresa casi nunca es solo lo que se instala en el celular. Tiene dos partes:

• La app (frontend móvil): las pantallas que el usuario ve y toca. Se descarga de Google Play o la App Store.
• El backend: lo que vive en un servidor. Guarda los datos (clientes, pedidos, citas), valida usuarios, procesa pagos, envía avisos y se conecta con otros sistemas.

Y casi siempre hay una tercera: el panel web de administración, donde tu equipo gestiona lo que pasa en la app. Cuando te cotizan, pregunta qué incluye cada parte. Muchas veces la «app barata» no incluye el backend ni el panel.

¿App nativa o multiplataforma?

La primera gran decisión es cómo se construye la app del celular:

Para apps de pedidos, reservas, citas, consultas, catálogos o cobranzas, la multiplataforma es la opción más común hoy. La nativa se justifica en apps muy exigentes: realidad aumentada, cámara avanzada, juegos, procesos pesados en segundo plano. La comparación con la web instalable está en app móvil o PWA: cuál conviene.

¿Qué son Flutter y React Native?

Son las dos herramientas multiplataforma más usadas. Las dos generan apps para Android y iPhone desde un solo código.

• Flutter es de Google. Usa el lenguaje Dart y dibuja sus propias pantallas, por lo que la app se ve igual en todos los celulares. En su vitrina oficial aparecen Google Pay, Google Earth, BMW, Toyota, eBay y Xiaomi (flutter.dev/showcase, revisada el 10 de octubre de 2026).
• React Native fue creado por Meta. Usa JavaScript o TypeScript, el mismo lenguaje de la web, y usa los componentes propios de cada sistema. En su vitrina aparecen Facebook, Microsoft Teams, Shopify, Amazon Alexa y las apps de Wix (reactnative.dev/showcase, revisada el 10 de octubre de 2026).

¿Cuál conviene? Para tu negocio, la diferencia práctica es menor que la experiencia del equipo. Pregunta al proveedor cuántas apps publicadas tiene con esa tecnología y pide verlas en la tienda. Un dato útil: si tu empresa ya tiene un sistema web en JavaScript, React Native permite compartir parte del conocimiento y del código.

¿Qué es Firebase y cuándo conviene?

Firebase es un conjunto de servicios de Google que resuelve buena parte del backend sin montar un servidor: base de datos en la nube, inicio de sesión de usuarios, almacenamiento de archivos, notificaciones push y estadísticas. Tiene un plan gratuito (Spark) con límites amplios y uno de pago por uso (Blaze), y el envío de notificaciones con Cloud Messaging figura sin costo.

Conviene cuando:

• La app es nueva, sin sistemas previos con los que conectarse.
• Necesitas lanzar rápido y validar la idea.
• El volumen de datos y usuarios es moderado.

Hay que pensarlo dos veces cuando:

• Tu negocio ya tiene un sistema (ventas, almacén, facturación) y la app debe trabajar con esos datos.
• Necesitas reportes complejos, como los que da una base de datos relacional (MySQL, MariaDB o PostgreSQL).
• Te preocupa depender de un solo proveedor: salir de Firebase después implica rehacer parte del backend.

¿Y el backend propio?

La alternativa es un backend propio: una aplicación en el servidor hecha con PHP (Laravel), Node.js o Python, con una base de datos MySQL, MariaDB o PostgreSQL. Es lo que usan la mayoría de sistemas de empresa.

Ventajas: tus datos están en tu servidor, el mismo backend sirve a la app, a la web y al panel de la oficina, y cualquier equipo con experiencia puede continuarlo. Desventaja: requiere servidor, copias de seguridad y mantenimiento, que deben estar en el costo mensual.

Lo que hacemos en CONIT

Construimos sistemas a medida y apps para empresas de todo el Perú con tecnologías abiertas (PHP/Laravel, Python, Node y React) y bases de datos MySQL, MariaDB o PostgreSQL, en servidor propio con copias diarias, y entregamos el código fuente. Puedes ver sistemas que hicimos, como el de Sisgenyca, y conocer el servicio de sistemas a medida.

¿Qué significa cada elección para tu bolsillo?

Como referencia de precios, la agencia peruana Alaz ubica las apps móviles para iOS y Android entre S/ 25,000 y S/ 80,000 (Alaz, julio de 2026). El desglose completo está en cuánto cuesta desarrollar una app móvil en Perú.

Preguntas que debes hacerle a tu proveedor

Más que elegir tú la tecnología, haz estas preguntas y compara las respuestas:

1. ¿Con qué tecnología harán la app y el backend, y por qué esa?
2. ¿Cuántas apps han publicado con esa tecnología? ¿Puedo verlas en la tienda?
3. ¿Me entregan el código fuente de la app, del backend y del panel?
4. ¿Las cuentas de Google Play, App Store y el servidor quedan a nombre de mi empresa?
5. ¿La app funcionará sin internet, si lo necesito?
6. ¿Cuánto cuesta mantenerla al mes y qué pasa cuando Google o Apple exigen actualizarla? Lo explicamos en qué pasa con tu app después de lanzarla.

En resumen

• Una app tiene dos partes: lo que se instala en el celular y el backend en un servidor; casi siempre hay además un panel web.
• La app puede ser nativa (Kotlin y Swift, dos desarrollos) o multiplataforma (Flutter o React Native, un solo código); para la mayoría de pymes conviene la multiplataforma.
• Firebase acelera el inicio y tiene plan gratuito, pero ata tus datos a un servicio; un backend propio con base de datos estándar te da más control.
• Más que la tecnología, importa la experiencia real del equipo con ella.
• Exige el código fuente y las cuentas a nombre de tu empresa.

Preguntas frecuentes

¿Qué es mejor, Flutter o React Native?

Las dos son buenas y las usan empresas grandes. Flutter, de Google, tiene la app Google Pay, Google Earth, BMW y Toyota en su vitrina oficial; React Native, creado por Meta, lista a Facebook, Microsoft Teams, Shopify y Amazon Alexa. Para ti importa más que el equipo que la hará tenga experiencia real con la que elija.

¿Una app multiplataforma es peor que una nativa?

Para la mayoría de apps de empresa (pedidos, reservas, citas, consultas, catálogos), no se nota la diferencia y cuesta menos porque es un solo código. La nativa se justifica cuando la app usa a fondo funciones del celular, como cámara avanzada, realidad aumentada, juegos o procesos en segundo plano muy exigentes.

¿Firebase es gratis?

Tiene un plan gratuito, Spark, con límites de uso amplios y sin tarjeta, y un plan de pago por uso, Blaze, para más servicios y volumen. El envío de notificaciones con Firebase Cloud Messaging figura sin costo. El riesgo no es el precio inicial, sino que tus datos y tu lógica queden atados a ese servicio si después quieres salir.

¿Qué tecnología necesito para que la app funcione sin internet?

Todas lo permiten, pero hay que diseñarlo desde el inicio: una base de datos dentro del celular (en Android, por ejemplo, Room, que es la recomendada por Google) y un proceso de sincronización con el servidor. Pregúntalo antes de que te coticen.

¿El código de mi app debe ser mío?

Sí. Pide en el contrato que te entreguen el código fuente de la app y del backend, las cuentas de Google Play y App Store a nombre de tu empresa y el acceso al servidor o a Firebase. Si cambias de proveedor, otro equipo debe poder continuar sin empezar de cero.

¿Puedo hacer mi app con una plataforma sin programar?

Para un prototipo o una app muy simple, sí. Cuando necesitas reglas propias, integraciones con pagos, facturación o tu sistema, o miles de usuarios, las plataformas sin código se quedan cortas o se encarecen. Úsalas para validar la idea, no para el producto final.