Proceso de desarrollo de aplicaciones móviles: qué pasa de verdad

Casi ningún proyecto de app se retrasa por el código. Se retrasa porque nadie decide quién aprueba los textos legales, porque el acceso al ERP tarda tres semanas o porque el export que iba a migrarse traía cuatro mil registros con el email vacío. Por eso este artículo sobre el proceso de desarrollo de aplicaciones móviles no va de fases con nombre bonito: va de qué entregable sale de cada una, qué tienes que hacer tú y dónde se pierde el calendario.

En Docastix construimos apps móviles nativas y multiplataforma para empresas que ya tienen un negocio funcionando y quieren llevarlo al móvil sin romper lo que les da de comer. Lo que viene es el proceso que usamos, con la parte incómoda: las semanas que se van en aprobaciones internas, lo que se cae cuando el calendario aprieta y quién coge el teléfono un viernes a las 17:00.

Respuesta rápida: ¿cómo es el proceso de desarrollo de una app paso a paso?

Cuatro bloques: entender el negocio antes que el stack (1-2 semanas), decidir la tecnología mínima y diseñar un prototipo navegable (2-4 semanas), construir en iteraciones de dos semanas con la build en tu móvil (8-20 semanas) y mantener en producción desde el lanzamiento. La diferencia entre un proyecto que sale y uno que se pudre no está en el esquema: está en que cada fase termine con algo que puedas tocar y en que alguien decida en 48 horas.

Si necesitas quedarte con tres cifras: un MVP a medida arranca desde 8.000 €, un proyecto medio en España ronda los 40.000 € y el mantenimiento anual cuesta entre el 15% y el 20% del desarrollo.

Fase 1: entender el negocio antes que el stack

La primera conversación no va de React Native ni de Kotlin. Va de cuántas personas hacen hoy ese proceso a mano, cuánto tardan y qué pasa cuando se equivocan. Si una agencia te presupuesta sin preguntar eso, te vende horas: es la primera señal a mirar cuando estás eligiendo equipo para desarrollar tu app.

El entregable no es «documentación», son tres cosas concretas:

• Un mapa del proceso actual, con los puntos donde se pierde tiempo o dinero.
• Un backlog priorizado: funcionalidades ordenadas, cada una con estimación por rango y marca de imprescindible o aplazable.
• Un alcance de dos páginas que dice qué queda fuera. La lista de lo que no se hace vale más que la de lo que sí.

Cómo lo revisas: te sientas dos horas con el backlog y mueves cosas de arriba abajo. Si algo no lo entiendes, está mal escrito. Nada de aprobar un PDF de cuarenta páginas por email.

Lo que aportas tú pesa más de lo que parece: un decisor único con capacidad de decir que no, acceso a quien hace hoy el trabajo y datos reales, no una descripción de cómo deberían estar. En Saher Connect esta fase cambió el proyecto: al acompañar a un técnico a campo quedó claro que trabajaba sin cobertura media jornada, y eso convirtió el modo offline en el requisito número uno, con más de 200 referencias de boquillas ISO consultables sin conexión. Por videollamada habríamos construido una app inútil.

Fase 2: decidir la tecnología mínima que sostiene el resultado

La pregunta correcta no es cuál es la mejor tecnología, sino cuál es la más pequeña que aguanta lo que necesitas los próximos tres años. Nativo cuando la app vive del hardware o del rendimiento fino; multiplataforma cuando la lógica de negocio pesa más que la capa de dispositivo. Lo comparamos en desarrollo nativo frente a multiplataforma.

Dos ejemplos propios en direcciones opuestas. Dormus es nativa en ambas plataformas (Swift y SwiftUI, Kotlin y Jetpack Compose, con Firebase detrás) porque el audio en segundo plano, las suscripciones y el comportamiento del dispositivo durante la noche son el producto. Saher Connect es Flutter porque casi todo su valor es una base de datos técnica y un cálculo, idénticos en iOS y Android.

El entregable cabe en una página: stack elegido con el motivo, integraciones y quién da cada credencial, plan de datos y decisiones de seguridad tomadas al principio. Ese último punto no es opcional: cómo se guardan las credenciales, cómo viaja la información y qué pasa si alguien pierde el móvil son decisiones de arquitectura, y rehacerlas en la semana 14 cuesta el triple. Lee la guía de seguridad en el desarrollo de aplicaciones móviles antes de firmarla, no después.

Fase 3: diseño, y el entregable es un prototipo navegable

El diseño no termina con un PDF de pantallas bonitas, sino con un prototipo clicable que abres en tu móvil y recorres como si la app existiera: entras, te registras, haces la acción principal, ves el error cuando metes algo mal. Si no puedes hacer eso, has visto una portada, no un producto.

Cómo se revisa, en concreto:

• Recorres el flujo principal y anotas cada punto donde dudas.
• Se lo pasas a dos personas que van a usar la app de verdad, no a dos compañeros de dirección, y les dejas solos.
• Devuelves una lista de cambios numerada, no un «no me convence».

Aquí se decide también la accesibilidad: si entras en el ámbito de la normativa europea de accesibilidad, tamaños de texto, contraste y lectores de pantalla dejan de ser un extra. Rehacer una pantalla en el prototipo cuesta una tarde; ya programada, una semana.

La trampa habitual es diseñar solo las pantallas felices: un prototipo sirve si incluye los estados incómodos, que son la mitad de la experiencia real. La lista vacía el primer día, el error de conexión, la sesión caducada, el pago rechazado.

Fase 4: construir en iteraciones de dos semanas con la app en tu móvil

Cada dos semanas recibes una build instalable: en iOS por TestFlight, en Android por un canal de pruebas de Google Play. No un informe de avance, la app en tu teléfono funcionando. Es el único control de avance honesto que conocemos y la base de un MVP en producción en menos de tres meses.

Conviene saber cómo funciona el canal antes de prometer fechas. TestFlight admite hasta 100 testers internos y 10.000 externos, pero las builds para externos pasan por revisión de Apple antes de distribuirse. Y en Google Play, si la cuenta es personal y reciente, Google exige un test cerrado con un mínimo de 12 testers apuntados de forma continua durante al menos 14 días antes de solicitar acceso a producción: dos semanas de calendario que no dependen de programar nada y que hay que meter en el plan desde el día uno.

Tu trabajo aquí es el que más proyectos hunde cuando no se hace: probar cada build en menos de 48 horas y responder con decisiones, no con impresiones. «Este flujo no vale, cámbialo por este otro» es útil; «lo vemos la semana que viene en comité», por diez iteraciones, son diez semanas perdidas.

Los cuellos de botella reales y lo que cuestan en calendario

Estos cuatro explican la mayoría de los retrasos que hemos visto. Ninguno es del todo técnico, y la lectura completa de por qué una fecha se mueve está en cuánto se tarda en desarrollar una app.

Revisión de las tiendas. Apple afirma que, de media, el 90% de los envíos se revisan en menos de 24 horas, y que más del 40% de los problemas sin resolver caen en la directriz 2.1: fallos, contenido de relleno o falta de cuenta de demo para el revisor. Google es más lento y más opaco: reconoce revisiones ampliadas de hasta siete días o más en casos excepcionales. Planifica una semana por envío.

Integraciones con terceros. El código suele ser rápido; conseguir credenciales de sandbox de un departamento que no sabe que existe tu proyecto, no. Reserva dos o tres semanas solo para eso y pide los accesos la primera semana, aunque no los uses hasta la octava.

Migración de datos. Nunca están tan limpios como se cree: duplicados, campos vacíos, teléfonos con tres formatos, clientes que son la misma empresa escrita de dos maneras. Pide un export real en la semana uno y cuenta con una o dos semanas de limpieza que nadie presupuestó.

Aprobaciones internas y contenidos. Textos legales, política de privacidad, revisión de marca, fotos, textos de la ficha de tienda y el visto bueno del comité que se reúne una vez al mes. Es donde más calendario se evapora: un ciclo de comité cuesta un mes. Ponlos en el plan como tareas con fecha, igual que una pantalla.

Publicación: lo que la tienda te va a pedir

Las cuentas de desarrollador van siempre a nombre del cliente, nunca de la agencia: Apple cuesta 99 € al año y Google Play, 25 € una única vez. Si alguien propone publicar bajo su cuenta «para ir más rápido», crea una dependencia que un día te costará cara.

Además de la app, las tiendas piden ficha, capturas que se correspondan con el producto, política de privacidad accesible por URL y el detalle de qué datos recoges. Si cobras dentro, entran las comisiones: 15% por debajo del millón de euros al año y, en la Unión Europea tras el DMA, un 10% para pequeñas empresas o un 17% estándar en Apple, más un 3% si usas su sistema de pagos. Eso cambia las cuentas de una suscripción, así que calcúlalo antes de elegir modelo de negocio: lo vemos en la guía de monetización de apps.

Un detalle que casi nadie usa y ahorra sustos: el lanzamiento por fases. Apple documenta que una actualización por fases llega al 1% de los usuarios el primer día y escala hasta el 100% en siete, con opción de pausar. Si algo va mal, lo ve el 1%.

Qué se recorta cuando el proyecto va tarde y qué no se recorta nunca

Todos los proyectos llegan a una semana en la que hay que elegir, y tener la lista escrita de antemano evita que decida el cansancio.

Se recorta:

• La segunda plataforma. Salir en una y añadir la otra después es perfectamente razonable.
• El panel de administración. Una hoja de cálculo conectada aguanta meses sin que se note.
• El onboarding de cinco pantallas, las animaciones de transición y el modo oscuro.
• La configuración avanzada que usará el 2% de los usuarios.
• Todo lo que esté por debajo de la mitad del backlog. Para eso se priorizó.

No se recorta nunca:

• La seguridad y la gestión de credenciales. Un fallo aquí no es una funcionalidad menos: es una brecha.
• El registro de errores en producción. Sin eso lanzas a ciegas.
• Las pruebas en dispositivos reales de gama baja y con mala conexión. El emulador miente.
• Los textos legales y la política de privacidad. Sin eso no publicas, literalmente.
• El plan de reversión: poder volver a la versión anterior en minutos.

El criterio es simple: se recorta alcance, no rigor. Menos funcionalidades hacen el producto más pequeño; menos rigor lo hace más caro dentro de seis meses.

Después del lanzamiento: el día 1 es publicar, no terminar

Aquí desaparece buena parte del sector: se entrega, se factura y el teléfono deja de sonar. Pero una app es software vivo en dispositivos que cambian solos dos veces al año.

Adaptarse a las nuevas versiones de iOS y Android no es una mejora opcional, es un requisito de las tiendas. Google exige que desde el 31 de agosto de 2026 las apps nuevas y las actualizaciones apunten a Android 16 (API 36) o superior, y Apple, que desde el 28 de abril de 2026 lo subido a App Store Connect se compile con Xcode 26 y el SDK de iOS 26. Traducido: si nadie toca tu app durante un año, llega un punto en que ni siquiera puedes publicar una corrección urgente sin una migración técnica completa.

Por eso el mantenimiento se presupuesta desde el principio, entre el 15% y el 20% del coste de desarrollo al año, y nuestro evolutivo arranca desde 500 €/mes; qué cubre exactamente esa cuota lo detallamos en coste de mantenimiento de aplicaciones móviles. Ese dinero no compra disponibilidad: compra correcciones, adaptación a versiones nuevas del sistema, vigilancia de fallos y un lote de mejoras al mes. Es donde un producto se convierte en un buen producto: Dormus no llegó a 50.000 descargas, más de 22.500 familias registradas y un 4,5★ de media el día del lanzamiento, sino iterando después con datos de uso reales.

Y la pregunta que casi nadie hace en la fase comercial: quién responde un viernes a las 17:00 cuando los pagos dejan de procesarse. La respuesta correcta tiene tres partes: una persona con nombre, un canal que no sea un formulario y un tiempo de respuesta comprometido por escrito. En PropPilot ese compromiso es el producto: el agente de IA bajó la primera respuesta a un lead de horas a menos de 60 segundos, funciona 24/7 en cuatro regiones y responde en menos de 60 segundos a cualquier hora. Eso solo se mantiene si hay alguien mirando.

Conclusión

El proceso de desarrollo de aplicaciones móviles no se diferencia por los nombres de las fases, iguales en todas las agencias. Se diferencia por tres cosas medibles: si al final de cada fase recibes algo que puedes tocar, si sabes qué decidir tú y cuándo, y si alguien sigue ahí seis meses después del lanzamiento. Lo demás es un diagrama en una propuesta comercial.

Si estás valorando arrancar, haz dos números antes de reunirte con nadie: qué te cuesta hoy el proceso que quieres llevar al móvil y cuánto invertirías para quitártelo de encima. Con eso puedes contrastar cifras en la guía de cuánto cuesta hacer una app. Y si prefieres saltarte rodeos, cuéntanos tu caso: en media hora te decimos si tiene sentido y qué parte te conviene no construir todavía.