Por qué las tiendas te obligan a actualizar tu app cada año
Si te han dicho que tu app necesita una actualización «técnica» que no añade ninguna función nueva, no te están vendiendo humo: Google Play y App Store exigen cada año que las apps se compilen contra una versión reciente del sistema operativo, y la que no cumple deja de poder actualizarse o desaparece de las búsquedas para los móviles nuevos. Es una obligación de las tiendas, no un capricho de tu proveedor. Entenderla te ahorra discusiones y, sobre todo, te permite presupuestarla antes de que se convierta en una urgencia.
Qué es eso del SDK y por qué le importa a tu negocio
Cuando alguien programa tu app, la construye apoyándose en un kit de desarrollo (el SDK) de una versión concreta de Android o de iOS. Ese kit define con qué reglas juega la aplicación: cómo pide permisos, cómo accede a la cámara o a la ubicación, cómo gestiona las notificaciones y qué protecciones de privacidad aplica.
Las tiendas quieren que todas las apps de su catálogo jueguen con reglas modernas, porque las antiguas permiten comportamientos que hoy se consideran inseguros o invasivos. Por eso, cada año, suben el listón: para publicar algo nuevo tienes que haberte construido con un kit reciente. No es que tu app deje de funcionar en los móviles de tus clientes de un día para otro; es que deja de poder evolucionar.
Qué exige Google Play exactamente
Google publica estos requisitos con bastante antelación en su documentación para desarrolladores. La mecánica tiene dos capas que conviene no confundir:
- Para publicar: las apps nuevas y las actualizaciones deben apuntar a una versión reciente de Android. Según los requisitos de nivel de API objetivo de Google, desde el 31 de agosto de 2026 las publicaciones deben apuntar a Android 16 (nivel de API 36).
- Para seguir siendo visible: las apps ya publicadas deben apuntar como mínimo a Android 15 (nivel de API 35) para seguir estando disponibles para usuarios nuevos en dispositivos con una versión de Android superior a la que apunta la app.
Es decir, si tu app se quedó anclada en una versión antigua, tu ficha no se borra y quien ya la tiene instalada la conserva, pero pierdes dos cosas importantes: la capacidad de publicar cualquier cambio (un arreglo urgente incluido) y la posibilidad de que la instale alguien que acaba de comprarse un móvil nuevo. Google contempla además solicitar una prórroga limitada para quien necesita más margen, pero es un parche temporal, no una solución.
Qué exige App Store
Apple aplica la misma lógica con otro calendario, ligado a la salida de cada versión de iOS. Según sus requisitos para próximas entregas, las apps que se suben a App Store Connect deben estar construidas con una versión reciente de Xcode y del SDK correspondiente: a partir del 28 de abril de 2026, con Xcode 26 o posterior y el SDK de iOS 26.
Ojo a un matiz que suele generar confusión: cambiar el SDK con el que se compila no significa que tu app deje de funcionar en móviles antiguos. Una cosa es con qué herramientas se construye y otra a partir de qué versión de iOS puede instalarse. Lo que sí puede pasar es que, al recompilar con un SDK nuevo, ciertos elementos visuales adopten por defecto el aspecto del sistema más reciente, y eso obliga a revisar el diseño antes de publicar.
Qué pasa de verdad si no actualizas
Los efectos aparecen en cascada y casi siempre en el peor momento:
| Situación | Consecuencia para tu negocio |
|---|---|
| No puedes publicar actualizaciones | Un fallo o un precio mal puesto se queda ahí hasta que pongas la app al día |
| La app no llega a los móviles más nuevos | Pierdes instalaciones justo del cliente que acaba de renovar terminal |
| Las bibliotecas de terceros se quedan atrás | La pasarela de pago o el servicio de notificaciones dejan de dar soporte a tu versión |
| La deuda técnica se acumula | Saltar tres versiones de golpe cuesta mucho más que ir año a año |
| Riesgo de seguridad | Te quedas sin parches del sistema y de las librerías que usa tu app |
El último punto es el más caro a medio plazo. Una app que lleva dos o tres años sin tocarse no se actualiza «en una tarde»: hay que subir versiones de librerías que han cambiado de forma de funcionar, adaptar permisos, revisar pantallas y volver a pasar la revisión de las tiendas. Lo que podían haber sido tres revisiones pequeñas se convierte en un proyecto.
Cómo se planifica esto sin que te pille por sorpresa
La buena noticia es que las fechas se conocen con meses de antelación. Con eso basta para convertir una urgencia en una tarea de calendario:
- Apunta las dos fechas del año: la de Google, ligada al final del verano, y la de Apple, ligada a la primavera siguiente a cada versión de iOS.
- Revisa el estado real de tu app: qué versión de SDK usa hoy y qué librerías de terceros lleva. Tu proveedor puede decírtelo en un correo.
- Reserva una ventana de trabajo dos o tres meses antes de cada fecha límite, no la semana anterior.
- Prueba antes de publicar: una actualización de SDK puede romper cosas que funcionaban, así que conviene pasar una batería de pruebas de regresión sobre los flujos críticos (registro, pago, notificaciones).
- Publica con margen, porque la revisión de las tiendas puede pedirte cambios y ese ida y vuelta consume días.
Si tienes contrato de mantenimiento, esto debería estar dentro. Si no lo tienes, es justo el tipo de trabajo que conviene acordar por adelantado, porque llega sí o sí todos los años.
Qué preguntarle a tu proveedor este mes
Tanto si la app te la lleva una empresa como si la hizo alguien que ya no está, hay cinco preguntas que te dan la foto completa en diez minutos:
- ¿A qué nivel de API de Android y a qué SDK de iOS apunta hoy la app?
- ¿Tenemos avisos pendientes en Google Play Console o en App Store Connect?
- ¿Quién es el titular de las cuentas de desarrollador y quién tiene los accesos?
- ¿Están actualizadas las bibliotecas de terceros y los certificados de firma?
- ¿Qué trabajo implica la próxima actualización obligatoria y cuándo hay que hacerlo?
Si nadie sabe responder a la primera pregunta, ya tienes el primer problema localizado. Y si la titularidad de las cuentas no está a nombre de tu empresa, resuélvelo antes que nada: sin esas cuentas no hay actualización posible.
En resumen: es mantenimiento, no un extra
Una app no es un producto que se compra una vez. Vive en dos tiendas que cambian sus reglas todos los años y sobre dos sistemas operativos que se renuevan cada otoño. Asumir una actualización técnica anual, con sus pruebas y su publicación, es el precio de seguir estando disponible; ignorarla no ahorra dinero, solo lo aplaza y lo multiplica.
En Tangram Consulting nos encontramos a menudo con apps bloqueadas por no haber pasado alguna de estas fechas, y también acompañamos a empresas que quieren dejar de ir a remolque. Si no sabes en qué estado está la tuya, escríbenos y la revisamos contigo antes de que llegue el siguiente plazo.