Desarrollo de apps móviles: nativas y multiplataforma que sí se publican
La mayoría de las apps móviles mueren entre TestFlight y la App Store. Nosotros publicamos apps que superan la revisión de las tiendas, las redes reales y la larga cola de dispositivos que tus usuarios tienen de verdad.
| Dimensión | Nativo (iOS + Android) Swift / Kotlin | Multiplataforma React Native o Flutter |
|---|---|---|
| Tiempo hasta la primera publicación | Más lento (dos códigos base) | Más rápido |
| Coste a largo plazo | Más alto | Un 30–50 % más bajo |
| API específicas de cada plataforma | Acceso desde el primer día | La mayoría, mediante puentes nativos |
| UI donde los fps son críticos | La mejor opción | Excelente si se hace bien |
| Equipo necesario para mantenerla | Especialistas en iOS + Android | Un solo equipo |
| Recomendado para | Uso intensivo de hardware, realidad aumentada, juegos | La mayoría de las apps de producto |
Qué obtienes
Cuándo encaja
- El móvil es el canal principal, no un añadido de última hora a un producto web
- Necesitas capacidades reales del dispositivo (procesamiento de cámara, BLE, realidad aumentada, tareas en segundo plano)
- Puedes nombrar tres cosas que la app debe hacer mejor que la web para merecer que la instalen
- Tienes (o vas a financiar) un ritmo continuo de releases: las apps se deterioran si se quedan paradas
Cuándo no
- La «app» es en realidad una web empaquetada: una PWA suele ganar en coste y alcance
- Nadie se va a hacer cargo del producto tras el lanzamiento: las apps sin responsable se degradan en menos de un trimestre
- Esperas un desarrollo puntual, sin mantenimiento continuo frente a las nuevas versiones de iOS y Android
Proceso
Dos semanas de discovery: matriz de dispositivos, auditoría de riesgos de la revisión de las tiendas y un Hello World publicado en TestFlight y en el canal de pruebas internas de Google Play. Después, 8–14 semanas hasta el MVP. Desde el primer sprint instrumentamos las sesiones sin crashes, los fps y el tiempo hasta que la app es interactiva: una «app rápida» es una métrica, no una sensación.
Proceso de entrega completoPrecios
Precio cerrado por hitos para desarrollos bien definidos (normalmente $80–250k para un MVP). Equipo dedicado para hojas de ruta más largas. Los contratos de mantenimiento cubren las actualizaciones de versión del sistema operativo, los cambios en las políticas de las tiendas y las releases continuas.
Ver modelos de colaboraciónCasos de éxito
Control de accesos residencial
Una puerta de acceso sencilla y elegante a entornos seguros e interconectados, que aporta facilidad de uso y tranquilidad a las comunidades residenciales.
Plataforma de banca móvil FinTech
Plataforma de banca móvil segura y con IA que da servicio a más de 500.000 usuarios, con transferencias instantáneas y autenticación biométrica.
Cómo lo construiríamos
Blueprints: proyectos de ejemplo con el plan, la arquitectura y los objetivos de los que partiríamos.
App de socios para gimnasios 24/7 con acceso móvil
App de socios para gimnasios 24/7 sin personal: acceso móvil, antipassback, reserva de clases, congelación de membresías, aforo en vivo y alertas.
App para instaladores de aerotermia y fotovoltaica
Visitas técnicas offline, presupuestos, puesta en marcha y trámites de ayudas para cuadrillas de aerotermia y fotovoltaica, con portal para clientes.
App de última milla para repartidores y tráfico
App offline-first para repartidores con prueba de entrega, ETA en vivo para destinatarios y panel de tráfico para cambios de ruta y devoluciones.
Preguntas frecuentes
- ¿Nativo o React Native? ¿Cómo elegimos?
- Empieza por la carga de trabajo, no por el framework. Las apps con uso intensivo de hardware (realidad aumentada, flujos BLE, procesamiento de vídeo) suelen justificar el desarrollo nativo. La mayoría de las apps de producto (banca, marketplaces, productividad) salen antes y más baratas con React Native o Flutter sin que los usuarios lo noten. En el discovery te mostraremos los pros y contras frente a tu lista concreta de funcionalidades.
- ¿Os encargáis de la revisión de App Store y Play Store?
- Sí. Durante el discovery hacemos una auditoría de riesgos de la revisión y diseñamos teniendo en cuenta las categorías que de verdad se rechazan (flujo de las compras dentro de la app, uso de API privadas, permisos, contenido infantil). En la mayoría de las apps conseguimos la aprobación a la primera; en las categorías de riesgo planificamos un rechazo y una corrección rápida.
- ¿Cuánto tardáis en tener algo en TestFlight?
- La semana 2. Una build Hello World funcional en TestFlight y en el canal de pruebas internas de Google Play es el entregable del primer sprint. La idea es resolver la firma, el aprovisionamiento y la CI antes de cualquier trabajo de producto: son justo las cosas que retrasan a los equipos que las dejan para el final.
- ¿Dais soporte tras el lanzamiento y con las nuevas versiones del sistema operativo?
- Sí, con una cuota mensual. Las apps móviles necesitan como mínimo unas 4 horas por plataforma en cada versión principal del sistema operativo solo para seguir en las tiendas; sin eso, se degradan. Lo incluimos en un modelo de mantenimiento para que el coste sea predecible.
Quién lo construye
Nuestro propio equipo, que trabaja desde nuestra oficina en Istočno Sarajevo, Bosnia y Herzegovina. Los ingenieros de tu llamada para definir el alcance son quienes lo construyen.
Conoce al equipo