Para subir compilaciones a App Store Connect se requerirá Xcode 26 y el SDK de iOS 26 a partir del 28 de abril de 2026. iOS 26 se lanzó en septiembre de 2025 — una actualización importante que incluye el diseño Liquid Glass y el framework Foundation Models anunciados en la WWDC25. iOS 27 se anunciará en la WWDC26 (del 8 al 12 de junio de 2026) y se espera que se publique en septiembre de 2026. Este artículo establece el orden de migración teniendo en cuenta ambas versiones.

Calendario de requisitos del SDK de App Store

Cada año, Apple eleva la versión mínima del SDK requerida para los envíos a App Store Connect.

Fuente: <https://developer.apple.com/news/upcoming-requirements/>

Si no compilas con el SDK de iOS 26, no podrás subir actualizaciones de aplicaciones a App Store Connect. No se trata de nuevas funcionalidades — es un requisito obligatorio para seguir distribuyendo actualizaciones a los usuarios existentes.

Orden de prioridad para la migración a iOS 26

Primero, pon en orden las herramientas

Ya sea que estés trabajando en el cumplimiento de iOS 26 o en la validación temprana de iOS 27, los primeros bloqueos suelen ser problemas con las herramientas de compilación, no con las APIs del sistema operativo. Asegura las herramientas primero.

El problema más común al migrar al modo Swift 6 son los errores de concurrencia relacionados con CoreData. Acceder a NSManagedObject fuera de @MainActor ahora genera advertencias, por lo que la solución es envolver las operaciones dentro de bloques context.perform.

actor DataProcessor {
    func process(context: NSManagedObjectContext) async {
        await context.perform {
            // CoreData operations go inside context.perform
        }
    }
}

Cambios de comportamiento en iOS 26 con los que es fácil tropezar

Cambio en la versión mínima de TLS

Para las apps compiladas con el SDK de iOS 26, la versión mínima de TLS para URLSession y el framework Network se ha elevado de 1.0 a 1.2.

Si los sistemas internos o las APIs externas todavía utilizan configuraciones TLS heredadas, las apps compiladas con el SDK de iOS 26 no podrán comunicarse con ellos.

// Example allowing legacy TLS (not recommended — temporary workaround only)
let config = URLSessionConfiguration.default
config.tlsMinimumSupportedProtocolVersion = .TLSv10 // triggers a warning
let session = URLSession(configuration: config)

La solución correcta es actualizar el lado del servidor a TLS 1.2 o superior. Asegúrate de verificar también las conexiones realizadas a través de SDKs de terceros.

Eliminación de UIScreen.mainScreen

UIScreen.mainScreen, que ya estaba previamente obsoleto, ha sido marcado como obsoleto en el SDK de iOS 26. Para compatibilidad con multiventana y soporte de escenas en iPadOS, el tamaño de pantalla ahora debe obtenerse desde UIWindowScene.

// Before (deprecated)
let screenWidth = UIScreen.main.bounds.width

// After (recommended)
if let scene = UIApplication.shared.connectedScenes
    .first(where: { $0.activationState == .foregroundActive }) as? UIWindowScene {
    let screenWidth = scene.screen.bounds.width
}

Cambio en el entitlement de Push to Talk

El entitlement com.apple.developer.pushkit.unrestricted-voip.ptt ya no funciona con el SDK de iOS 26. Se requiere la migración al framework Push to Talk (iOS 16+).

Eliminación de la clave de sincronización iCloud de CoreData

Claves como NSPersistentStoreUbiquitousContentNameKey, que fueron marcadas como obsoletas hace más de 10 años para la sincronización ubicua de iCloud, ahora provocan errores de compilación con el SDK de iOS 26. Los destinos de migración son NSPersistentCloudKitContainer (iOS 13+) o SwiftData (iOS 17+).

Adaptación al diseño Liquid Glass

Los componentes estándar de UIKit / SwiftUI (barras de navegación, barras de pestañas, sheets, etc.) se adaptan automáticamente al nuevo diseño. Para UI personalizada con dibujo manual, vale la pena verificar visualmente en un dispositivo real cómo interactúa con el desenfoque de fondo y los efectos de cristal.

Adelantarse a iOS 27 (WWDC26: del 8 al 12 de junio de 2026)

La WWDC26 se celebrará del 8 al 12 de junio de 2026. Como es habitual, el nuevo sistema operativo se anunciará el primer día con la Beta 1 disponible de inmediato. Se espera que iOS 27 se publique en septiembre de 2026.

Prioridad de pruebas para soporte simultáneo de iOS 26 y 27

Problemas comunes en apps empresariales japonesas

Qué verificar antes de actualizar

El primer paso más rápido es hacer un escaneo general de APIs obsoletas.

grep -R "UIScreen.mainb|unrestricted-voip.ptt|UbiquitousContentName|UbiquitousContentURL" ./

Ejecutar una verificación similar para problemas relacionados con TLS ayuda a detectar cosas que podrías pasar por alto.

grep -R "TLSv10|TLSv11|tlsMinimumSupported|kCFStreamSSLLevel" ./

En resumen: si envías una actualización con un targetSdkVersion inferior al que Google Play exige, se rechaza en el momento de la subida. Eso significa que no podrás publicar actualizaciones en la tienda en absoluto. No se trata de nuevas funcionalidades — es un requisito obligatorio para seguir distribuyendo actualizaciones a los usuarios existentes y mantener tu ficha en la tienda.

Google Play ha estado elevando el targetSdkVersion mínimo en un nivel cada 31 de agosto. Actualmente (desde agosto de 2025 en adelante), todas las actualizaciones por debajo de API 35 (Android 15) son rechazadas.

(Fuente: Requisitos de nivel de API objetivo de Google Play)

Según este patrón, la entrada en vigor de API 36 (Android 16) es más probable alrededor de agosto de 2026. Para completar el cumplimiento antes de que entre en vigor, este artículo delimita el trabajo partiendo de una fecha límite interna de junio de 2026. Android 17 ha alcanzado la estabilidad de plataforma en la Beta 3, así que ejecutar la verificación anticipada en una línea de trabajo paralela ahora significa que no estarás corriendo cuando llegue la versión final.

Orden de prioridad

Primero, pon en orden las herramientas

Ya sea que estés trabajando en el cumplimiento de Android 16 o en la verificación temprana de Android 17, los primeros bloqueos suelen ser problemas con las herramientas de compilación, no con las APIs del sistema operativo. Asegura las herramientas primero.

plugins {
    id("com.android.application") version "9.1.0" apply false
    id("org.jetbrains.kotlin.android") version "2.3.20" apply false
}

Fijar JDK 17 en CI, actualizar AGP y absorber las diferencias de R8 sirve para ambos propósitos — sienta las bases para Android 17 mientras completa el cumplimiento de Android 16.

Nota: Distribución real de versiones de Kotlin y coste de migración

El «Kotlin 2.3.20» de la tabla anterior es la línea base recomendada. En la práctica, muchos proyectos siguen en la línea 1.9.x. Los proyectos financieros, gubernamentales y de gran escala en Japón tienden a ser especialmente conservadores — la mentalidad de «está estable, así que no lo actualices» persiste durante mucho tiempo.

El gráfico a continuación es una estimación de principios de 2026 basada en datos públicos del ecosistema de JetBrains y observaciones de la comunidad.

(Valores estimados. Para datos exactos de cuota por versión, consulta la última Encuesta del ecosistema de desarrolladores de JetBrains)

Al actualizar de 1.9.x a 2.x, rara vez es solo una actualización de Kotlin — normalmente implica una actualización conjunta de Compose, Coroutines y AGP. Cambiar al compilador K2 puede modificar cierto comportamiento de inferencia de tipos, causando errores de compilación. «No necesitamos actualizar nuestra app 1.9.x que funciona bien ahora mismo» es una decisión perfectamente pragmática.

Cambios de comportamiento en Android 17 a los que adelantarse

Los cambios de comportamiento tienen mayor impacto en las apps existentes que las nuevas funcionalidades. Concéntrate primero en los cambios que afectan a todas las apps.

Prioridad de pruebas para soporte simultáneo de Android 16 y 17

Cuando se ejecutan en paralelo el cumplimiento de Android 16 y la verificación temprana de Android 17, es fácil perder de vista qué debe probarse en cada entorno. La siguiente tabla define los elementos requeridos/prioritarios por área de prueba — úsala como punto de control de QA para confirmar cuándo cada área puede considerarse completada.

Riesgos específicos de apps empresariales japonesas

Estos puntos rara vez se cubren en artículos generales de migración de Android de fuentes internacionales, pero las apps financieras, gubernamentales y de plataformas con membresía en Japón tienen sus propios problemas específicos. Para proyectos donde la prioridad es verificar que los flujos clave existentes — inicio de sesión, pagos, notificaciones — no se rompan en lugar de adoptar nuevas funcionalidades de Android 16/17 (cambios en canales de notificación, revisiones del modelo de permisos, nuevos componentes de Compose, etc.), revisa primero los elementos a continuación como lista de verificación.

Orden de acción recomendado

1. Finalizar el plan de lanzamiento asumiendo que la actualización de targetSdkVersion 36 (Android 16) se publica para junio de 2026
2. Alinear las herramientas: Android Studio, AGP, Kotlin, JDK
3. Ejecutar primero las pruebas de flujos clave del usuario y regresión para Android 16
4. En paralelo, crear una rama dedicada para Android 17 e iniciar una línea de verificación con emuladores y dispositivos reales
5. Abordar los cambios de comportamiento en orden: seguridad, multimedia, conectividad
6. Ejecutar un pipeline de CI separado con targetSdk 37

Java 26 alcanzó disponibilidad general el 17/03/2026.

Hay muchas funcionalidades en vista previa de nuevo, pero hay algunos cambios en HTTP/3, G1 GC y hilos virtuales que podrían marcar una diferencia real de forma silenciosa.

Por otro lado, si tu entorno todavía arrastra APIs heredadas o flags antiguos de JVM, hay puntos claros donde una actualización podría causarte problemas.

Especialmente viniendo desde Java 8, la brecha es lo suficientemente grande como para que sea mejor identificar dónde te vas a atascar antes de mirar las novedades de Java 26.

Diagrama general

Java 8 in production
	|
	+-- Audit legacy APIs / libraries
	|      - javax.xml.bind
	|      - Thread.stop
	|      - sun.*
	|      - Old JVM flags
	|
	+-- Validate on an LTS first
	|      - Test on Java 17 or 21
	|
	+-- Then check Java 26 deltas
			 - HTTP/3
			 - G1 improvements
			 - Virtual thread changes
			 - Security default changes

Lo que pinta bien

java.net.http.HttpClient ahora soporta HTTP/3.

Poder usar HTTP/3 sin cambios importantes en el código del lado de la aplicación es directamente útil.

Más allá de eso, hay mejoras de rendimiento bastante sólidas: reducción de sincronización en G1 GC, mejor recuperación de objetos enormes, y AOT Object Cache ahora soporta cualquier GC.

Los hilos virtuales también se han mejorado — es menos probable que retengan el hilo portador mientras esperan la inicialización de clases, lo que debería reducir escenarios de bloqueo extraños.

Algunas adiciones menores pero bienvenidas:

• Process ahora implementa AutoCloseable
• Se añadió UUID.ofEpochMillis(), facilitando el manejo al estilo UUIDv7
• ByteOrder ahora es un enum, lo que facilita su uso en sentencias switch

Por ejemplo, el HTTP Client te permite beneficiarte con cambios mínimos en el código:

var client = HttpClient.newBuilder()
	.version(HttpClient.Version.HTTP_3)
	.build();

var request = HttpRequest.newBuilder()
	.uri(URI.create("https://example.com/api/status"))
	.GET()
	.build();

var response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.statusCode());

Y dado que Process ahora implementa AutoCloseable, la limpieza después de ejecutar comandos externos es un poco más limpia:

try (var process = new ProcessBuilder("java", "-version").start()) {
	var exitCode = process.waitFor();
	System.out.println("exit=" + exitCode);
}

Cosas a tener en cuenta

Primero, Thread.stop() ha sido eliminado.

Si todavía persiste en código de mantenimiento heredado, directamente no compilará en JDK 26.

La API de Applet también ha sido eliminada, así que los entornos que utilizan documentación o ejemplos antiguos deben tener cuidado.

La limpieza de flags de JVM también ha avanzado — flags como -Xmaxjitcodesize, MaxRAM y AggressiveHeap que has estado usando por inercia pueden necesitar revisión.

RMI sobre TLS ahora impone la identificación de endpoints por defecto, por lo que los entornos con SANs de certificados descuidados pueden encontrar fallos de conexión.

HttpRequest.Builder.timeout() ahora cubre la recepción completa del cuerpo de la respuesta, no solo la conexión inicial. Dependiendo de tu diseño de timeout existente, esto podría causar diferencias de comportamiento notables.

Para los entornos que han estado ejecutándose en Java 8 durante mucho tiempo, esto es lo que debes tener en cuenta antes de saltar directamente a Java 26:

• Java 8 se ejecutaba bajo el modelo classpath, pero a partir de Java 9, los límites de módulos y las dependencias de APIs internas se hacen visibles
• Los módulos de Java EE / CORBA fueron eliminados en Java 11, así que si javax.xml.bind todavía está en tu código, necesitarás una corrección por separado
• Los valores por defecto de reflexión y seguridad se han vuelto más estrictos — código que antes funcionaba silenciosamente ahora puede generar advertencias o fallar
• Las configuraciones antiguas de TLS, almacenes de claves y conexiones RMI son propensas a romperse justo después de una actualización

Para los sistemas empresariales japoneses, la codificación de caracteres es también un campo minado silencioso.

Los sistemas bancarios y de negocio core en particular a menudo todavía asumen codificaciones de la familia Shift_JIS para las integraciones de back-office y sistemas host.

Si consolidas todo de forma ingenua diciendo «UTF-8 es el estándar ahora», puedes terminar con bugs insidiosos donde la interfaz funciona bien pero los informes o las integraciones externas producen texto ilegible.

En la era de Java 8, había mucho código que funcionaba casualmente porque el charset por defecto en Windows era windows-31j.

Pero desde JDK 18, el charset por defecto es UTF-8, por lo que patrones como new String(bytes) o FileReader que dependen del charset implícito se comportarán de manera diferente después de la migración.

En la práctica, tampoco deberías tratar Shift_JIS y windows-31j como intercambiables.
Ambos están disponibles en la lista de charsets de Java, pero windows-31j / MS932 incluye extensiones específicas de Windows, por lo que puede haber discrepancias con números encerrados en círculos, caracteres dependientes de plataforma y extensiones IBM/NEC.

Para transferencias de archivos bancarios y conexiones con sistemas host, es más seguro confirmar de antemano si la otra parte espera «Shift_JIS pero en realidad CP932», «estrictamente dentro del rango Shift_JIS», o «incluyendo páginas de código de host IBM».

Si estás analizando específicamente problemas con el idioma japonés, estos deberían ser parte de tu lista de verificación previa a la migración:

• ¿Se especifica explícitamente el charset en las conversiones de arrays de bytes?
• ¿Estás confundiendo Shift_JIS con windows-31j?
• ¿Has verificado la corrección de ida y vuelta para números encerrados en círculos, wave dash, tilde de ancho completo, caracteres dependientes de plataforma y gaiji?
• Para CSVs de informes, archivos de longitud fija y transmisiones a host: ¿estás confundiendo longitudes basadas en caracteres con longitudes basadas en bytes?
• ¿Puedes detectar caracteres no mapeables en lugar de reemplazarlos silenciosamente?

Así que si vienes de Java 8, en lugar de saltar directamente a 26 en producción, es más realista primero conseguir que tu compilación y tests pasen en LTS 17 o 21, eliminar las dependencias antiguas allí, y después evaluar Java 26.

Java 26 en sí es interesante, pero absorber el delta desde Java 8 es donde reside la mayor parte del trabajo real en la práctica.

Qué verificar antes de actualizar

El primer paso más rápido es hacer un escaneo general de APIs y flags obsoletos.

grep -R "Thread\.stop\|Xmaxjitcodesize\|AggressiveHeap\|MaxRAM" ./

Si quieres detectar también dependencias de la era de Java 8, ejecuta esto:

grep -R "javax\.xml\.bind\|javax\.activation\|CORBA\|sun\." ./

Para hacer un escaneo general de suposiciones de charset, esto ayuda a detectar cosas que podrías pasar por alto:

grep -R "Shift_JIS\|MS932\|windows-31j\|Cp943\|Cp930\|EBCDIC\|file.encoding" ./

En el lado de Java, es más seguro especificar explícitamente los charsets y detectar caracteres no mapeables en lugar de depender del charset por defecto:

var charset = Charset.forName("windows-31j");
var encoder = charset.newEncoder()
	.onMalformedInput(CodingErrorAction.REPORT)
	.onUnmappableCharacter(CodingErrorAction.REPORT);

var bytes = encoder.encode(CharBuffer.wrap("顧客コード①"));
System.out.println(bytes.remaining());

Una comparación aproximada:

• Java 26 desde la perspectiva de Java 8: Brecha grande — esto es un proyecto de migración
• Java 26 desde la perspectiva de Java 17: Principalmente evaluar nuevas funcionalidades y verificar cambios en valores por defecto
• Java 26 desde la perspectiva de Java 21: El coste de migración es relativamente ligero

En términos más prácticos:

Para proyectos en Java 8, antes de entusiasmarse con las nuevas funcionalidades de Java 26, el tema real suele ser descubrir cómo despegar la deuda técnica de la era de Java 8.

Por el contrario, si ya estás en Java 17 o 21, Java 26 no es una «migración completa» — se trata más de evaluar cómo incorporar mejoras de rendimiento y cambios en valores por defecto.

Aquí hay algunas cosas que vale la pena verificar en CI para mayor tranquilidad:

• Comportamiento de timeout y headers de HttpClient
• Comunicación RMI / TLS que involucre validación de certificados
• Creación de runtime con jlink
• Dependencias de XML Signature y almacenes de claves heredados
• Tests de ida y vuelta para archivos de integración con Shift_JIS / windows-31j / host

Las funcionalidades en vista previa / incubadora son interesantes, pero probablemente sea mejor considerarlas como objetivos de evaluación en lugar de listas para producción en este momento.

Resumen

Java 26 no es tanto un único gran cambio revolucionario como una acumulación de mejoras sólidas en rendimiento, APIs estándar y valores por defecto operativamente más seguros.

Para los sistemas empresariales típicos, las mejoras en HTTP/3, GC e hilos virtuales son avances positivos.

Por otro lado, cuanto más código heredado y flags de runtime antiguos tenga tu entorno, más importante es auditar primero y actualizar después.

Para los entornos japoneses, la codificación de caracteres en particular no debería posponerse.

En los entornos donde las codificaciones de la familia Shift_JIS o las integraciones con sistemas host todavía están en uso, corregir las dependencias del charset por defecto y los problemas de ida y vuelta del japonés tiene prioridad sobre evaluar las nuevas funcionalidades de Java 26.

Especialmente viniendo desde Java 8, hacer una limpieza intermedia en LTS 17 o 21 primero y después ir a por los beneficios de Java 26 es el camino más sensato.