Apps Móviles

Aplicaciones móviles que la gente mantiene en el teléfono

Multiplataforma por defecto, nativo cuando de verdad compensa — y antes de eso, una respuesta honesta sobre si necesitas una app.

Empieza por saber si necesitas una app

Lo más útil que podemos hacer al inicio de un proyecto móvil es cuestionarlo. Una app es un segundo producto que diseñar, publicar, someter a revisión, actualizar y mantener, en dos plataformas, para siempre. Ese coste compensa cuando la app lo justifica, y se desperdicia cuando un buen sitio móvil habría hecho el mismo trabajo.

Una app se justifica cuando la gente vuelve a menudo, cuando hace falta el propio teléfono — notificaciones, cámara, ubicación, lectura de códigos, uso real sin conexión — o cuando la app es el producto y no el escaparate. Si el objetivo es que te encuentren, explicar qué haces y recibir solicitudes, un sitio web es mejor inversión y te lo diremos.

Cuando la app tiene sentido, la siguiente pregunta es cómo construirla. Para la mayoría de apps de empresa la respuesta es multiplataforma: un código para iOS y Android, normalmente entre un tercio y la mitad más barato que construirlo dos veces. Lo nativo compensa en casos concretos, y te diremos si el tuyo es uno.

Cómo lo construimos

Apps multiplataforma (React Native y Flutter)

Un código, ambas plataformas. Para la inmensa mayoría de apps de empresa la diferencia de rendimiento frente a lo nativo es tan pequeña que los usuarios nunca la perciben, mientras que el ahorro en construcción y mantenimiento es sustancial y permanente.

Usamos React Native por defecto, porque comparte competencias y a menudo código con una pila React en web, algo que pesa más a cinco años que cualquier prueba de rendimiento. Flutter es mejor opción cuando la interfaz es el producto: mucha animación, un sistema de diseño idéntico al píxel en ambas plataformas.

  • Un código para iOS y Android
  • React Native por defecto, Flutter cuando la interfaz es el producto
  • Competencias compartidas con la pila web
  • Una actualización llega a las dos plataformas

Nativo iOS y Android

Swift y Kotlin, construido por plataforma. Cuesta más de hacer y cerca del doble de mantener, así que necesita una razón que no sea la preferencia.

Razones hay: interfaces con gráficos pesados o 3D, realidad aumentada o visión por computador en el dispositivo, necesitar una API de la plataforma el día que sale, o productos donde la latencia es el punto — herramientas profesionales de cámara y audio. Si estás en uno de esos casos, te lo diremos.

  • Swift para iOS, Kotlin para Android
  • Acceso completo a las APIs de la plataforma desde el primer día
  • La opción correcta para gráficos, RA y latencia crítica
  • Asumimos con claridad el mayor coste de construir y mantener

Cuando una aplicación web es la mejor respuesta

Lo nativo ya no es el punto de partida. Una aplicación web progresiva se encuentra en buscadores, se abre desde un enlace, no exige instalación, evita la comisión de las tiendas y se actualiza en el momento en que publicas.

Cede algo de terreno: acceso profundo al hardware, trabajo en segundo plano, y las notificaciones en iOS siguen siendo más limitadas que en Android. Una buena respuesta frecuente es tener ambos: una aplicación web para alcance y una app nativa ligera para quien la usa a diario.

  • Localizable en buscadores, sin instalación
  • Sin comisión de tienda ni espera de revisión
  • Se actualiza en el momento de publicar
  • Combina bien con una app nativa enfocada

Funcionamiento sin conexión y tiempo real

Los móviles pierden cobertura. Una app que da por hecha la conexión falla justo donde trabajan los equipos de campo: sótanos, almacenes, zonas rurales, en desplazamiento. Offline-first significa que la app sigue siendo utilizable y reconcilia cuando vuelve la conexión.

La parte difícil es la reconciliación, no guardar los datos: decidir qué ocurre cuando dos personas modificaron el mismo registro sin conexión. Definimos esa regla contigo, en lugar de dejar que la última escritura gane en silencio.

  • Utilizable sin conexión
  • Reglas de sincronización y conflicto acordadas de antemano
  • Actualizaciones en tiempo real donde importan
  • Notificaciones que respetan la atención de la gente

Publicación en las tiendas y lo que viene después

Entrar en la App Store y en Google Play es un proceso con reglas propias: directrices de revisión, declaraciones de privacidad, formularios de seguridad de datos, clasificación por edades, versiones de prueba para tu equipo.

Y luego continúa. Apple y Google publican versiones del sistema cada año y suben periódicamente los requisitos mínimos, así que una app que se deja quieta acaba por dejar de aceptarse. El mantenimiento no es opcional, y decimos lo que cuesta antes de empezar.

  • Envío a App Store y Google Play
  • Declaraciones de privacidad y seguridad de datos
  • Versiones de prueba para el equipo antes de publicar
  • Actualizaciones de sistema y SDK tras el lanzamiento

¿Tu negocio necesita una app?

La versión honesta. Muchas empresas que nos piden una app quedan mejor servidas con otra cosa, y sale más barato descubrirlo ahora.

Una app se justifica cuando

  • La gente la usa a menudo, cada semana o cada día
  • Hace falta el teléfono: notificaciones, cámara, ubicación, escaneo, sensores
  • Tiene que funcionar sin conexión y sincronizar después
  • La app es el producto, no un escaparate
  • Necesitas estar en la pantalla de inicio para sostener el hábito

Un sitio web es mejor inversión cuando

  • El objetivo es que te encuentren, explicar y recibir solicitudes
  • La gente la usaría una o dos veces al año
  • El contenido cambia constantemente y los buscadores importan
  • No hay presupuesto para mantenimiento tras el lanzamiento
  • La razón principal es que la competencia tiene una

Cómo trabajamos

Ciclos más cortos que en web, porque la revisión de las tiendas se interpone entre tú y tus usuarios.

  1. 01

    Alcance

    Acordamos para qué sirve la app, quién la usa y qué debe hacer la primera versión. Lo que puede esperar, espera: una primera versión menor llega antes a usuarios reales.

  2. 02

    Diseño

    Pantallas y flujos validados en prototipo navegable, respetando las convenciones de cada plataforma en lugar de forzar un mismo diseño en ambas.

  3. 03

    Construcción y pruebas

    Versiones de prueba periódicas en vuestros propios dispositivos, no solo en simulador, para usar la app en el teléfono que lleváis encima.

  4. 04

    Lanzamiento y mantenimiento

    Nos encargamos del envío y la revisión, y mantenemos la app al día conforme iOS y Android evolucionan por debajo.

Tecnología

Elegimos la tecnología en función de la app y no al revés, manteniéndonos en herramientas ampliamente adoptadas para que la app siga siendo mantenible por cualquier equipo competente.

Multiplataforma

React NativeFlutterTypeScript

Nativo

SwiftKotlin

Backend

FirebaseAWS AmplifyAPIs RESTNotificaciones push

Dónde suele justificarse una app

Situaciones en las que el teléfono aporta algo que un sitio web no puede. Son ejemplos ilustrativos del tipo de trabajo que hacemos.

Equipos de campo

Técnicos que registran intervenciones, fotos y firmas in situ, trabajando sin conexión y sincronizando al recuperar cobertura.

App de seguimiento para clientes

Una app para clientes existentes que siguen pedidos, citas o entregas, donde la notificación sustituye a una cadena de correos.

Citas y fidelización

Negocios a los que se vuelve a menudo, donde un icono en la pantalla de inicio y un recordatorio valen más que otra pestaña del navegador.

Escaneo e inventario

Stock, activos o entradas verificados con la cámara del teléfono, cuando la alternativa es hardware dedicado o papel.

Preguntas frecuentes

¿Cuánto cuesta una aplicación móvil?

Lo determina el alcance, no la plataforma: cuántas pantallas, cuánto backend, cuántas integraciones. Lo multiplataforma queda normalmente bastante por debajo de construir la misma app dos veces en nativo, y esa es la razón principal de que sea nuestro punto de partida. Definimos el alcance y damos una cifra real en lugar de estimar antes de entender la app.

¿Multiplataforma o nativo?

Multiplataforma para la mayoría de apps de empresa: los usuarios no perciben la diferencia y reduces a la mitad el mantenimiento a largo plazo. Nativo cuando la app tiene gráficos pesados, se apoya en realidad aumentada o visión en el dispositivo, necesita APIs recién publicadas, o cuando la latencia es el producto. Te diremos con franqueza de qué lado cae tu caso.

¿Necesitamos una app o basta un sitio web?

A menudo basta un sitio web. Si la gente entrase una o dos veces al año, o el objetivo es que te encuentren y explicar qué haces, un buen sitio móvil es mejor inversión. Una app se justifica por uso repetido, necesidad del hardware del teléfono, uso real sin conexión, o porque la app es el producto.

¿Cuánto tiempo lleva?

Una primera versión enfocada suele llevar unos meses, más la revisión de las tiendas. Mantenemos deliberadamente pequeña la primera versión, porque usuarios reales en teléfonos reales dicen más sobre qué construir después que otro mes de planificación.

¿De quién es la app y el código?

Vuestros. El código, los datos y las fichas de las tiendas pertenecen a vuestra empresa. Publicamos bajo vuestras cuentas de desarrollador y no bajo las nuestras, para que nunca quedéis sin acceso a vuestra propia app.

¿Cuánto cuesta mantenerla tras el lanzamiento?

Lo móvil tiene un coste base que la web no tiene: iOS y Android salen cada año y suben periódicamente los requisitos mínimos, así que una app que se deja quieta acaba por dejar de aceptarse. Acordamos el modelo de mantenimiento antes del lanzamiento para que sea un coste conocido y no una sorpresa.

Áreas relacionadas

Servicios que suelen formar parte del mismo proyecto.

¿Estás pensando en una app?

Cuéntanos qué haría y quién la usaría. Te daremos una respuesta clara sobre si una app es el paso adecuado y qué haría falta para construirla.