Cuánto cuesta mantener una app (y qué pasa si no lo haces)

Una app publicada no está terminada. Puede funcionar perfectamente el día del lanzamiento y, un año después, no admitir ni una actualización porque Apple o Google han subido el listón. No lo decimos para vender mantenimiento: son fechas que publican ellos con meses de antelación, y se cumplen.

Aquí repasamos qué cambia cada año, qué pasa si nadie se ocupa de la app y qué debería incluir un mantenimiento para que sepas lo que pagas.

Lo que cambió solo en 2026

Solo este año:

• Desde el 28 de abril, Apple solo acepta apps compiladas con Xcode 26 y el SDK de iOS 26. Si tu app se hizo con herramientas anteriores, la próxima actualización, aunque sea para corregir una errata, obliga primero a pasar el proyecto a las nuevas.
• Desde el 31 de agosto, Google Play exige que las apps nuevas y las actualizaciones apunten a Android 16 (nivel de API 36). Y las que se quedan por debajo de Android 15 dejan de aparecer para los usuarios nuevos con móviles más recientes.
• En la misma fecha, Google empezó a exigir la versión 8 de su librería de pagos. Si tu app vende suscripciones o compras dentro de la app, sin ella no puedes publicar ninguna actualización.

Ninguno de estos cambios rompe la app que tus usuarios ya tienen instalada. Lo que rompe es tu capacidad de actualizarla. Y eso se suele descubrir el día que hay que corregir algo con prisa.

Qué pasa si nadie la mantiene

Apple retira del App Store las apps que llevan tres años sin actualizarse y apenas tienen descargas. Avisa por correo y da 90 días para publicar una versión nueva o recurrir. Si además dejas de pagar la cuota anual del Apple Developer Program (99 dólares), la app deja de estar disponible hasta que renuevas: quien ya la tenía la sigue usando, pero nadie más puede descargarla.

Aun así, lo más habitual no es la retirada. Es la app que sigue en la tienda pero va un poco peor con cada versión del sistema: un permiso que ahora se pide de otra manera, una pantalla que se descuadra en los móviles nuevos, una librería que ya no recibe parches de seguridad. Nada grave por separado. Sumado, acaba en esas reseñas de una estrella que nadie sabe explicar.

Qué incluye un mantenimiento de verdad

Cuando te pasen un presupuesto de mantenimiento, comprueba que cubre esto:

• La adaptación anual a las versiones nuevas de iOS y Android y a los requisitos de publicación de cada tienda.
• La actualización de dependencias: pagos, mapas, analítica, notificaciones. Cada librería tiene su propio calendario de versiones que dejan de aceptarse.
• La corrección de los errores que aparecen con el uso real, que siempre son distintos de los que se encuentran probando.
• El servidor: copias de seguridad, parches de seguridad y alguien pendiente de que todo responde.
• Las credenciales que caducan. Los certificados .p12 de notificaciones push de Apple duran un año, y si la app los usa y nadie los renueva, las notificaciones dejan de llegar sin que la app muestre ningún error. Con una clave .p8 ese problema no existe, y es lo que conviene usar hoy.
• La renovación de la cuenta de Apple Developer cada año.

Lo que no entra son las funciones nuevas. Añadir pagos, un módulo de reservas o una pantalla más es desarrollo y se presupuesta aparte. Mezclar las dos cosas en una cuota mensual sin detalle es la forma más rápida de que nadie sepa qué se está pagando.

De qué depende lo que cuesta

De tres cosas, y de poco más. De cuántas bases de código hay que mantener: una app nativa para iPhone y otra para Android son dos proyectos; una multiplataforma, uno (lo explicamos en apps nativas o multiplataforma). De cuánto backend hay detrás. Y de cuántos servicios de terceros usa la app, porque cada uno cambia a su ritmo.

Una app de catálogo sin cuentas de usuario necesita muy poco. Una con pagos, reservas, notificaciones y un panel de gestión necesita bastante más, sobre todo los años en que coinciden cambios de Apple, de Google y de un par de proveedores a la vez.

En el sector se suele hablar de un 15-20 % anual de lo que costó desarrollarla. Como orientación sirve, pero no la apliques a ciegas: una app sencilla puede quedarse muy por debajo, y una con muchas integraciones puede pasarse justo el año en que todo cambia.

Aparte van los costes fijos, que no dependen de quién te mantenga la app: los 99 dólares anuales de Apple, el servidor (con poco tráfico es poco dinero, pero crece con el uso) y los servicios que cobran por volumen, como los SMS o los mapas.

Antes de firmar: de quién es la app

Hay una pregunta que conviene hacer antes de pagar el primer euro de desarrollo, no después: ¿a nombre de quién están las cuentas de las tiendas, el servidor y el código?

Si la cuenta de Apple o la de Google Play está a nombre de la agencia, la app es, en la práctica, de la agencia. Cambiar de proveedor obliga a transferirla entre cuentas, que se puede pero es un trámite, o a publicarla de nuevo y empezar sin valoraciones. Lo sensato es que las cuentas estén a nombre de tu empresa y que quien te mantenga la app trabaje dentro de ellas con acceso de equipo.

Con el código pasa lo mismo. Pide acceso al repositorio desde el principio. Si solo tu proveedor tiene el código, el mantenimiento deja de ser algo que contratas y pasa a ser algo de lo que dependes.

Nosotros creamos las cuentas de desarrollador a nombre de la empresa del cliente; cómo trabajamos el resto lo tienes en desarrollo de aplicaciones en Vigo. Y si todavía estás en la fase de presupuestar el desarrollo, empieza por cuánto cuesta desarrollar una app.