Coste de mantenimiento de aplicaciones móviles al año

Desde el 31 de agosto de 2026, ninguna app nueva ni ninguna actualización entra en Google Play si no apunta a Android 16 (API 36). Desde el 28 de abril, App Store Connect rechaza cualquier binario que no se haya compilado con Xcode 26 y el SDK de iOS 26. Y el 11 de septiembre arrancan las obligaciones de notificación del Reglamento de Ciberresiliencia europeo. El coste de mantenimiento de aplicaciones móviles ha dejado de ser una partida opcional: es la condición para que tu app siga existiendo en las tiendas.

En Docastix llevamos apps propias y de clientes en producción durante años, y la conversación incómoda siempre es la misma: alguien pagó el desarrollo, nadie presupuestó el año siguiente. Por eso, cuando presupuestamos desarrollo de apps móviles, el mantenimiento va en la propuesta desde el primer día con el detalle de qué entra y qué no.

Respuesta rápida: cuál es el coste de mantenimiento de aplicaciones móviles al año

Entre el 15% y el 20% del coste de desarrollo, cada año, sin contar funcionalidad nueva. Ese porcentaje ya está publicado con su desglose en cuánto cuesta hacer una app y llevado a un caso concreto en el presupuesto real de una app de yoga. Aquí lo abrimos por dentro: qué compras con ese dinero, qué no compras y qué pasa el día que decides no pagarlo.

Si necesitas quedarte con tres fechas: 28 de abril de 2026 (Apple ya exige el SDK de iOS 26), 31 de agosto de 2026 (Google ya exige API 36) y 11 de septiembre de 2026 (obligación de notificar vulnerabilidades explotadas en la UE).

Mantener no es opcional: las tiendas y la ley te obligan

Dejar una app «tal cual está» no existe técnicamente: existe la app que puedes actualizar y la que ya no. La diferencia la marcan tres calendarios que no controlas.

Google Play. La política de nivel de API objetivo obliga a que, desde el 31 de agosto de 2026, las apps nuevas y las actualizaciones apunten a Android 16 (API 36) o superior. Hay prórroga solicitable hasta el 1 de noviembre y excepciones para Wear OS, Automotive, TV y XR. La consecuencia menos comentada: las apps ya publicadas que no lleguen al menos a Android 15 (API 35) dejan de ser visibles para usuarios nuevos en dispositivos recientes. No te retiran la app, te la esconden.

Apple. Según la página de requisitos futuros de Apple, desde el 28 de abril de 2026 todo lo que se sube a App Store Connect tiene que compilarse con Xcode 26 o posterior y el SDK de iOS 26, iPadOS 26, tvOS 26, visionOS 26 o watchOS 26. Si tu proyecto está congelado en un Xcode de hace dos años, hoy no publicas ni un cambio de una línea.

El Reglamento de Ciberresiliencia (CRA). Aquí el mantenimiento pasa de buena práctica a obligación legal. El CRA entró en vigor el 10 de diciembre de 2024, su aplicación plena llega el 11 de diciembre de 2027 y el 11 de septiembre de 2026 arrancan las obligaciones de notificación: ante una vulnerabilidad explotada activamente o un incidente grave, el fabricante tiene 24 horas para el aviso temprano, 72 horas para la notificación completa y 14 días para el informe final ante el CSIRT correspondiente y ENISA.

El CRA cubre «productos con elementos digitales», y eso incluye el software. Además exige definir y comunicar un periodo de soporte con actualizaciones de seguridad gratuitas; INCIBE lo resume así: hay que dar soporte a las vulnerabilidades durante todo el ciclo de vida del software o durante cinco años, salvo que la vida útil del producto sea más corta.

Traducido: no notificas en 24 horas algo que nadie está mirando, ni parcheas con un equipo que se disolvió hace dieciocho meses. Esa capacidad de respuesta es exactamente lo que compras en una cuota de mantenimiento, y el detalle técnico está en cómo manejar la seguridad en el desarrollo de aplicaciones móviles. Un matiz honesto: el alcance del CRA tiene aristas y hay servicios puramente remotos que quedan fuera, pero si distribuyes una app en la UE la conversación te toca. Y no es la única obligación con calendario: la normativa europea de accesibilidad ya te aplicaba antes.

Qué hay dentro de la cuota de mantenimiento, partida a partida

Esto es lo que pagas de verdad. Sin el desglose, una cuota mensual parece un peaje arbitrario.

• Adaptación a nuevas versiones de iOS y Android. Cada otoño llega una versión mayor de ambos sistemas, con cambios de API, permisos que se endurecen y componentes que se deprecian. Recompilar contra el nuevo SDK, probar y corregir lo que se rompe es trabajo garantizado todos los años, y justifica por sí solo buena parte de la cuota.
• Corrección de errores. Los que reportan los usuarios y, sobre todo, los que no reporta nadie porque desinstalan y se van. Reproducir, diagnosticar, corregir, probar y republicar.
• Actualización de dependencias y SDK de terceros. Firebase, pasarelas de pago, analítica, notificaciones, mapas: cada uno con su calendario de deprecaciones. Una librería sin tocar durante dos años se convierte en un bloqueo, porque para actualizar una necesitas actualizar otras tres.
• Monitorización y respuesta a caídas. Crash reporting, alertas y alguien que responda cuando el backend se cae un sábado. Es la partida que más presupuestos omiten y la que más se echa de menos.
• Parches de seguridad. Vulnerabilidades en dependencias, rotación de claves y certificados, revisión de permisos. Desde el 11 de septiembre, con un reloj legal encima.
• Compatibilidad con dispositivos y pantallas nuevas. Plegables, tamaños raros, densidades nuevas, cambios en la zona segura. Nada glamuroso, y aparece cada año.
• Republicación y fichas. Revisiones rechazadas y formularios de privacidad y datos que las tiendas cambian con poca antelación.

Qué no entra en el mantenimiento

Esta frontera provoca discusiones y casi nadie la escribe en la propuesta. Nosotros sí: es más barato discutirla antes que después.

• Funcionalidad nueva. Una pantalla que no existía, un flujo nuevo, un rol nuevo. Aunque sea «pequeño».
• Rediseños. Cambiar la identidad visual, reorganizar la navegación o rehacer el onboarding.
• Integraciones nuevas. Conectar un ERP, un CRM o una pasarela distinta.
• Migraciones grandes. Cambiar de proveedor de backend, de framework o de autenticación.
• Contenido, marketing y ASO. Cargar catálogo, traducir a un idioma nuevo, redactar textos legales, hacer creatividades y experimentos de ficha.

La regla que usamos: si la app hace algo que antes no hacía, es evolutivo o proyecto nuevo; si sigue haciendo lo que ya hacía en un entorno que ha cambiado, es mantenimiento. Cualquier presupuesto que no puedas clasificar con esa frase está mal redactado.

Tramos orientativos por tipo de app

El 15-20% anual funciona como regla, pero conviene aterrizarlo.

App sencilla, sin backend propio. Consulta de contenido, formularios, quizá login delegado. Sobre un desarrollo de 8.000-20.000 €, salen 1.200-4.000 € al año. Una cuota fija mensual rara vez tiene sentido aquí: por debajo de cierto volumen es más honesto trabajar con bolsa de horas anual y concentrar el esfuerzo en las ventanas en que llegan las versiones nuevas.

App con backend propio, cuentas y pagos. El proyecto medio en España, en torno a 40.000 €. Mantenimiento de 6.000-8.000 € al año, entre 500 y 670 € al mes. Nuestro evolutivo arranca en 500 €/mes precisamente en esta franja, porque es donde ya hay servidor, datos de usuarios y obligación real de responder.

App compleja, con integraciones y volumen. De 80.000 a 300.000 € de desarrollo, de 12.000 a 60.000 € al año. Aquí el mantenimiento ya no se parece a un seguro, sino a un equipo pequeño con dedicación estable.

Dos factores mueven estos tramos más que ningún otro. El primero, cuántas bases de código mantienes: nativo iOS más nativo Android son dos ciclos de adaptación anuales en vez de uno, mientras que multiplataforma concentra el trabajo pero te ata al ritmo con el que el framework se adapta a cada versión nueva. Es un intercambio, no una ventaja limpia, y lo comparamos en desarrollo nativo frente a multiplataforma. El segundo, cuántos SDK de terceros tocas: cada uno es un calendario de deprecaciones ajeno que heredas.

Dormus es un buen ejemplo: nativa en iOS y Android, con Swift/SwiftUI, Kotlin/Jetpack Compose y Firebase, suscripción activa, 50.000 descargas y más de 22.500 usuarios activos con 4,5 estrellas de media. Una app así ha atravesado ya varios ciclos completos de sistema operativo, y esas estrellas no se sostienen sin ese trabajo detrás.

Los costes recurrentes que no son mantenimiento pero se pagan igual

Aunque no toques una línea de código, estas facturas llegan igual.

• Cuenta de desarrollador de Apple. 99 € al año, suscripción anual: si caduca, tus apps salen de la tienda.
• Cuenta de desarrollador de Google. 25 € de pago único al registrarse, sin renovación. Ojo con las verificaciones de identidad y los requisitos de pruebas para cuentas nuevas.
• Infraestructura. Servidores, base de datos, almacenamiento, copias, CDN. Escala con los usuarios, no con tu presupuesto.
• Servicios de terceros. Push, correo transaccional, analítica, monitorización de errores, mapas. Casi todos tienen capa gratuita generosa y un salto de precio brusco justo cuando la app empieza a funcionar.
• Certificados, dominios y firma de código. Pequeño, olvidado y capaz de tumbarte una publicación.

Y si cobras dentro de la app están las comisiones de tienda: no son mantenimiento, pero se comen margen cada mes. Las desglosamos, con los tramos y el efecto del DMA en Europa, en monetización de apps.

Qué pasa si no mantienes, por orden de gravedad

No es un apagón, es una degradación con etapas predecibles.

Mes 0-6: pierdes la capacidad de publicar. Con el SDK o el nivel de API por debajo del mínimo, cualquier envío se rechaza. Y el problema no es el cambio que querías publicar: es que si aparece un fallo grave, tampoco publicas el arreglo.

Mes 6-18: empiezan los fallos en sistemas nuevos. Llega la versión mayor de turno, cambian permisos y comportamientos de fondo, y aparecen cierres inesperados en los dispositivos recientes, que suelen ser los de tus usuarios de mayor valor. La nota media cae y las reseñas se llenan de «antes funcionaba».

Mes 12-24: pérdida de visibilidad y riesgo de retirada. Primero dejas de aparecer para usuarios nuevos. Después, si incumples políticas que han cambiado, llega la retirada. Recuperar una ficha retirada cuesta mucho más que haberla mantenido.

En paralelo, sin calendario: la exposición legal. El CRA exige notificar en 24 horas y sostener un periodo de soporte con parches. El RGPD no perdona una brecha causada por una dependencia con vulnerabilidad conocida y sin parchear durante meses. Es la única capa que puede costarte más que rehacer la app entera. Y el desenlace habitual acaba siendo justo ese: reescribir, que cuesta bastante más que los tres años de mantenimiento que te ahorraste.

Cómo se contrata el mantenimiento: bolsa de horas, cuota fija o por incidencia

Tres modelos, y ninguno es el mejor en abstracto.

La bolsa de horas es un saldo que consumes según necesites: encaja cuando la app es estable, el volumen es bajo y prefieres flexibilidad a garantía de respuesta. La cuota fija mensual compra disponibilidad: alguien mira la monitorización, planifica la adaptación anual y está ahí cuando algo se rompe. Encaja cuando hay usuarios de pago, datos sensibles o backend propio, y es el modelo de nuestro evolutivo desde 500 €/mes. El por incidencia solo tiene sentido en apps internas sin criticidad, porque no compra prevención: cuando llamas, ya ha pasado.

Antes de firmar, cuatro preguntas: qué tiempo de respuesta y resolución te garantizan y en qué horario; si la adaptación anual a iOS y Android va incluida o se factura aparte, que es la trampa más común; quién es el titular de las cuentas de desarrollador y del repositorio; y cómo se sale del contrato. Los criterios para juzgar al equipo que te ofrece esto están en cómo elegir el mejor equipo para desarrollar tu app.

Cómo reducir la factura de mantenimiento sin arriesgar

La mayor parte del coste se decide durante el desarrollo, no después. Hay decisiones que te condenan a pagar más, y conviene decirlo aunque sea autocrítica del sector.

• Menos dependencias. Cada librería externa es una obligación futura. Si te ahorra dos días y te obliga a una migración cada año, es un mal negocio.
• Stack aburrido. Comunidad grande, versiones con soporte largo y perfiles fáciles de encontrar. Lo llamativo envejece mal y encarece cada relevo de equipo.
• Tests en lo que duele. No hace falta cobertura total: hacen falta en pagos, autenticación y sincronización. Sin ellos, cada adaptación anual es una ronda completa de QA manual.
• No acumular deuda técnica. Un porcentaje fijo de cada ciclo dedicado a limpiar sale más barato que la reescritura que llega cuando no se puede tocar nada sin romper otra cosa.
• Automatizar la publicación. Compilación, firma y subida automatizadas convierten una republicación de urgencia en media hora en vez de una tarde.
• Documentación y accesos. Un proyecto que solo entiende una persona tiene un coste oculto enorme. Cómo se organiza desde el principio está en el proceso de desarrollo de aplicaciones móviles.

Lo que no recomendamos: recortar monitorización, saltarse las adaptaciones anuales «hasta que dé problemas» o dejar caducar la cuenta de Apple para ahorrar 99 €. Ahorran poco y cuestan mucho.

Conclusión

El mantenimiento no es un seguro que contratas por si acaso. Es la cuota que pagas por seguir teniendo acceso a las dos tiendas que distribuyen tu producto, en un entorno donde Apple y Google suben los requisitos mínimos todos los años y donde, desde este mes, la normativa europea pone un reloj de 24 horas a la respuesta ante vulnerabilidades explotadas. Una app sin mantenimiento no se queda como está: se queda sin poder actualizarse, y a partir de ahí lo demás es cuestión de tiempo.

Si vas a lanzar, mete el 15-20% anual en el plan financiero desde el principio y exige que la propuesta diga por escrito qué entra y qué no. Y si ya tienes una app parada, lo primero no es presupuestar funcionalidad nueva: es saber si todavía puedes publicar. Cuéntanos qué tienes en producción y te decimos en qué estado está y qué cuesta ponerla al día, con las dos cifras separadas.