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.
Artículos relacionados
Te puede interesar
Preguntas frecuentes sobre
Cómo mejorar mi negocio con la metodología Anticompetencia
En Tangram no queremos que la información pase por una cadena interminable de intermediarios donde se pierden los detalles importantes.
Contarás con un interlocutor que coordinará la comunicación y trasladará las decisiones al equipo responsable de tu proyecto.
Cuando sea necesario profundizar en cuestiones de estrategia, diseño o tecnología, podremos involucrar a los especialistas correspondientes.
Así tendrás una comunicación organizada, sin necesidad de gestionar personalmente a todos los profesionales que intervienen.
Queremos que tengas acceso al conocimiento de un equipo especializado, sin sufrir la complejidad de coordinarlo.
No tendrás que averiguar a quién escribir cada vez que tengas una duda.
En Tangram contemplamos la figura del Account Manager como interlocutor principal, encargado de acompañarte durante el proyecto, coordinar la comunicación y facilitar el seguimiento de las decisiones.
Nuestra metodología incluye reuniones de revisión, canales de comunicación y herramientas para que puedas participar en el trabajo.
La organización concreta, la frecuencia de las reuniones y los canales disponibles se establecerán según el proyecto contratado.
Lo importante es que sepas con quién hablar, en qué punto está tu proyecto y qué decisiones necesitan tu participación.
Sí, podemos valorar una colaboración con los profesionales que ya trabajan en tu empresa.
No siempre tiene sentido sustituir un equipo que conoce bien tu negocio. En muchas situaciones, lo más útil es complementar sus conocimientos con especialistas en determinadas áreas.
Podemos estudiar qué responsabilidades asumiría Tangram, cuáles mantendría tu equipo y cómo coordinar las decisiones para evitar duplicidades.
La forma concreta de colaboración dependerá de la organización, las herramientas y las necesidades del proyecto.
No se trata de reemplazar lo que ya funciona, sino de aportar el conocimiento que necesitas para llegar más lejos.
No tienes por qué cambiar de proveedor para explorar una colaboración con Tangram.
Durante nuestra trayectoria hemos trabajado con agencias y consultoras, participando en proyectos en los que cada empresa asumía una parte diferente del trabajo.
Esa experiencia nos permite comprender la importancia de definir responsabilidades y coordinar a los profesionales implicados.
Podemos valorar una colaboración para cubrir necesidades concretas que tu proveedor actual no ofrece o para reforzar determinadas áreas.
Si tienes una relación profesional que funciona, no queremos que la rompas sin motivo. Queremos encontrar dónde podemos aportar valor.
La confidencialidad es especialmente importante cuando hablamos de nuevas ideas de negocio, información económica, estrategias comerciales o desarrollos tecnológicos.
En Tangram tenemos experiencia trabajando en proyectos sujetos a acuerdos de confidencialidad, motivo por el que no podemos mostrar públicamente muchos de los trabajos en los que hemos participado.
Si tu proyecto requiere un acuerdo de confidencialidad (NDA) antes de compartir información sensible, podemos revisar sus condiciones y acordar cómo proteger esa información antes de entrar en los detalles.
Entendemos que la confianza empieza por respetar lo que todavía no quieres hacer público.