← Volver al blog
iOS 27SwiftSwiftUISwiftDataXcode

iOS 27 para tu próxima app: qué vale la pena adoptar (y qué está quedando obsoleto)

S
Slekens
14 sep 2026 · 13 min de lectura

Hoy, 14 de septiembre de 2026, salieron iOS 27, iPadOS 27, macOS 27 Golden Gate, watchOS 27, tvOS 27 y visionOS 27. Cinco días después del evento Surprise and Shine, Apple pone en manos de los usuarios lo que anunció en WWDC 2026.

Para nosotros los devs eso significa dos cosas: hay APIs nuevas que vale la pena adoptar, y hay cosas obsoletas que empiezan a molestar. Este post las revisa como una lista de compras — cada sección responde una pregunta directa: ¿lo pondrías en tu próxima app? Y cuando hay algo que reemplaza a otra cosa, lo digo también, porque mantenerse al día con lo que se va es tan importante como conocer lo que llega.

El SDK de iOS 27 agrega 3,760 APIs Swift públicas y depreca 363 entre 149 frameworks (miniswift SDK diff). No voy a cubrir todas — voy a cubrir las que mueven la aguja de una app típica.

1. Foundation Models — ahora con proveedores third-party

Qué es. El framework que Apple introdujo en iOS 26 para invocar el modelo on-device (el mismo que impulsa Apple Intelligence) desde una API Swift nativa, con outputs tipados vía @Generable. En iOS 26 era “modelo de Apple o nada”. En iOS 27 se abre: dos protocolos nuevos, LanguageModel y LanguageModelExecutor, permiten que cualquier proveedor implemente una integración y la distribuya como Swift Package. Gemini de Google llega vía Firebase SDK para Apple, Anthropic (Claude) también es launch partner (WWDC26 — Foundation Models, DEV Community coverage).

Además: prompts multimodales (pasas imágenes junto al texto), tool calling (el modelo puede llamar a funciones que expones — incluido Vision para OCR o barcode readers), on-device fine-tuning, contexto expandido y un modelo más grande (byteiota — iOS 27 Foundation Models). La API es backwards-compatible: código escrito para iOS 26 sigue compilando y corriendo en 27.

¿Lo pondrías en tu próxima app? Sí, si tu app se ahorra un backend con esto. Casos concretos que sí encajan: resumir contenido dentro de la app, extraer estructura de una foto (una lista de compras a partir de una foto de recibo), semantic search local, chat de asistencia que no dependa de un servidor. Es gratis, privado y offline — la mejor combinación que puede tener una feature de LLM en móvil.

Qué reemplaza. Nada directamente — es una alternativa a llamar a una API externa (OpenAI, Anthropic, etc.). Ahora también puedes usar esos mismos proveedores a través del framework unificado, en vez de armar tu propio cliente HTTP.

2. Swift 6.4 — typed throws en Task y ergonomía de concurrencia

Qué es. Xcode 27 trae Swift 6.4 (SwiftLee — What’s New in Concurrency, Michael Tsai — Swift 6.4). Lo más útil para el día a día:

  • Typed throws en Task. Antes, Task { try algo() } producía un Task<T, Error> — cualquier error típico. Ahora puedes declarar el tipo concreto: Task<T, MyError>. Cambio pequeño, impacto grande: el catch deja de necesitar downcasts.
// Antes
Task {
    do { try await fetchOrder(id: id) }
    catch { print(error) } // ¿qué error es?
}

// iOS 27 / Swift 6.4
Task<Order, OrderError> {
    do { try await fetchOrder(id: id) }
    catch { print(error.reason) } // el tipo es OrderError
}
  • async defer. Ahora puedes usar await dentro de defer para cleanup asíncrono limpio.
  • withTaskCancellationShield. Protege código de cleanup de ver una cancelación en medio.
  • Advertencia si ignoras un Task que puede lanzar. El compilador te avisa cuando dejas huérfano un Task con un throw que nunca vas a ver.

Sobre Swift 7 y las advertencias de concurrencia. Se ha dicho que “las warnings de Swift 6 serán errores en Swift 7”. Es cierto en teoría, pero Swift 7 se proyecta hacia 2027-2028 (Medium — Road to Swift 7) — no es inminente. Aun así, atender las warnings de data race ahora vale la pena: cuando llegue, no vas a estar tapando fugas contra el reloj.

¿Lo pondrías en tu próxima app? El typed throws en Task es adopción inmediata — cero costo, más claridad de errores. Los otros cambios son opt-in cuando los necesites.

3. SwiftUI: toolbars adaptativas, reorder nativo, lazy prefetch

Qué es. iOS 27 introduce APIs específicas para que la UI de SwiftUI se acomode automáticamente a distintos tamaños de pantalla — no solo por el iPhone Duo foldable, sino en general (Adaptive SwiftUI Toolbars in iOS 27, What’s new in SwiftUI iOS 27):

  • visibilityPriority(.high | .low | .automatic) en items de toolbar — le dice al sistema cuáles items sacar primero al overflow cuando el espacio aprieta.
  • ToolbarOverflowMenu — pones ahí los comandos secundarios permanentemente y ya no compiten por espacio.
  • topBarPinnedTrailing — ancla un item al trailing edge sin importar el ancho de pantalla. Útil para el botón de compartir, típicamente.
  • toolbarMinimizationBehavior(_:for:) — controla si la nav bar se minimiza cuando el usuario scrollea.

Además: reorder nativo en List y Grid, y lazy loading con prefetch para scrolling más suave. Y en apps document-based, acceso directo a disco vía SwiftUI (antes tenías que bajar a AppKit/UIKit).

¿Lo pondrías en tu próxima app? Sí. Los toolbar APIs son cero costo y ganas UX adaptativa gratis. El reorder nativo especialmente — si tu app tiene una lista reordenable, dejas de mantener tu propio drag-and-drop.

Qué reemplaza. El reorder custom que mucha gente escribe con GestureRecognizer o .onDrag/.onDrop. Y los layouts que hacías con if horizontalSizeClass == .compact { ... } ceden espacio a que el sistema decida.

4. App Intents — obligatorio para Siri, SiriKit oficialmente en cronómetro

Qué es. Apple formalmente deprecó SiriKit en WWDC 2026 (byteiota — SiriKit Deprecation, Medium — Your App Is Invisible to Siri). A partir de iOS 27, App Intents es la única forma en que Siri puede llamar a una app third-party. Si tu app no expone App Intents, Siri no puede descubrirla, invocarla ni incluirla en workflows multi-app.

Detalle importante del timing: SiriKit compilará por un par de años más (Apple dio una ventana de dos a tres años), pero desde hoy, cualquier app basada en SiriKit queda invisible al nuevo Siri con Apple Intelligence. No recibe tráfico de voz, no indexa en Spotlight, no participa en personalización de Apple Intelligence. La deadline dura para compilar es lejana; la deadline dura para importar es hoy.

¿Lo pondrías en tu próxima app? Si haces app nueva, arrancas con App Intents desde el día uno. Si tienes SiriKit vivo, migrar es la próxima prioridad — no porque tu app se vaya a romper, sino porque desaparece de la experiencia de asistente.

Qué reemplaza. SiriKit, punto. La arquitectura cambia: en vez de mapear a un vocabulario fijo de dominios (mensajería, listas, etc.), defines acciones arbitrarias con parámetros tipados y declaraciones de privacidad.

5. NowPlaying framework — una API para todas las superficies de reproducción

Qué es. Un framework nuevo en iOS 27 que unifica cómo tu app aparece en Lock Screen, Control Center, Dynamic Island, CarPlay y StandBy — antes eran integraciones separadas (WWDC26 — Meet the Now Playing framework).

Dos protocolos clave: MediaSessionRepresentable (describe tu contenido: título, artwork, estado de reproducción; registra comandos: play, pause, skip) y RemoteMediaSessionRepresentable (para playback externo, se sincroniza vía app extensions y APNs).

Bonus en CarPlay: MiniPlayer en el template de Now Playing, y una barra de progreso que ahora sí permite saltar a un punto de la canción/podcast/audiobook desde CarPlay.

¿Lo pondrías en tu próxima app? Sí, absolutamente, si tu app reproduce audio o video. Colapsa cuatro integraciones separadas en una sola API.

Qué reemplaza. No reemplaza MPNowPlayingInfoCenter de golpe, pero el framework nuevo es lo que va a llevar la carga a futuro. Para apps nuevas, empieza aquí.

6. SwiftData — observers, sectioned queries, tipos Codable

Qué es. Cuatro adiciones concretas en iOS 27 (InfoQ — SwiftData 27, Michael Tsai — SwiftData in appleOS 27, The Swift Dev — ResultsObserver/HistoryObserver):

  • ResultsObserver — observa cambios en un fetch fuera de una vista SwiftUI. Antes tenías que envolver todo en un @Query dentro de una vista, o escribir tu propio diffing. Ahora un @Observable puede reaccionar al store directamente.
  • HistoryObserver — observa la historia persistente del store. Útil para sincronizar con servidores remotos o mantener otros sistemas al día. Expone eventCounter que incrementa con cada transacción.
  • Atributos .codable. Persiste tipos custom (incluidos los que no controlas) marcando Schema.Attribute como codable. Nota: son opacos, no puedes usarlos en predicados o sort descriptors.
  • Sectioned queries y predicados sobre enums. La macro @Query toma sectionBy y los predicados aceptan enums directamente.

¿Lo pondrías en tu próxima app? Sí, si ya usas SwiftData. Los observers son el cambio grande — si tenías un layer de “servicio” que envolvía SwiftData porque no podías observar fuera de la view, ese layer se simplifica.

Qué reemplaza. El patrón de envolver SwiftData en un servicio observable a mano. Y las sectioned queries reemplazan agrupamientos que hacías en el View con Dictionary(grouping:by:).

7. Widgets y Live Activities — canvas nuevo, landscape en Dynamic Island

Qué es. Dos cosas separadas pero relacionadas:

  • systemExtraLargePortrait — nueva family de widgets, canvas 4×6. En iPhone: solo portrait, llena una página entera del Home. En iPad: solo landscape. En Mac: ambos (9to5Mac — Extra-large widgets).
  • Live Activities en landscape del Dynamic Island. Antes las presentaciones compact y minimal se ocultaban en landscape; ahora se ven. Nuevo environment value isDynamicIslandLimitedInWidth para adaptar el layout en pruebas (WWDC26 — Live Activities essentials).

¿Lo pondrías en tu próxima app? El widget XL: sí, si tienes contenido que vale mostrar con más espacio (un dashboard, un timeline). El landscape del Dynamic Island: sí y ya, si tienes Live Activities — es adaptación de dos vistas, no una feature nueva completa.

Qué reemplaza. Nada — es capacidad adicional, no reemplazo de families existentes.

Nota importante. Apple actualizó su guideline 4.5.3 del App Store: prohibido usar Live Activities para marketing no solicitado. Si tu app las usa para anuncios o promociones no pedidas por el usuario, review las va a rechazar.

8. Swift Testing — interop con XCTest para migración incremental

Qué es. Xcode 27 / Swift 6.4 trae el modo de interoperabilidad entre Swift Testing y XCTest (WWDC26 — Migrate to Swift Testing, InfoQ — Swift 6.4 features) que hacía falta para que la migración fuera realista:

  • Limited. Los issues cross-framework de XCTest se muestran como warnings.
  • Complete. Esas warnings se vuelven errors.
  • Strict. Fatal error, apuntando a cada spot donde queda XCTest.

Bonus: los XCTAssert ahora salen como issues propios en Swift Testing, y #expect funciona dentro de XCTestCase.

Aclaración importante: XCTest no está deprecado. La migración a Swift Testing sigue siendo opcional. Lo que cambia es que ahora la migración incremental es viable — Apple recomienda dejar la mayoría de XCTests en su lugar, escribir tests nuevos en Swift Testing, y migrar los que tocas con frecuencia.

¿Lo pondrías en tu próxima app? Si arrancas app nueva: sí, Swift Testing desde el día uno. Si tienes suite XCTest: adopta Swift Testing para tests nuevos, dejando los viejos donde están.

Qué reemplaza. A largo plazo, XCTest. En el corto plazo, nada — coexisten.

9. Xcode 27 — completion on-device y agentic coding

Qué es. Xcode 27 cambia el flujo diario de escribir código en dos niveles (Xcode 27 On-Device AI, byteiota — Xcode 27 Agentic Coding):

  • Completion on-device. Autocomplete, method prediction, sugerencias multi-línea — todo corre en el Neural Engine del Mac. Cero código se manda a la nube para el autocomplete diario. Esto es el default nuevo.
  • Agentic coding. Para tareas más pesadas (planificar un feature, refactorizar, localizar, correr y depurar tests), un agente con Claude, Gemini o GPT puede operar dentro del editor. Es opt-in explícito — nada se manda a la nube sin que tú activarlo.

Cuando pides algo complejo, el agente muestra una interfaz de planning: describe pasos, tú revisas y apruebas antes de que ejecute.

¿Lo pondrías en tu próxima app? No cambia tu app, cambia tu flujo. La adopción del completion on-device es free win: mejor autocomplete sin tradeoff de privacidad. El agentic coding lo evalúas cuando tenga sentido — no es “adoptarlo por adoptarlo”.

Qué reemplaza. El completion tradicional basado en índice, para el 90% de los casos. La escritura manual repetitiva.

10. Breaking changes — lo que rompe build si no lo atiendes

Estos son los que Apple te obliga a atender antes de shipear un binary contra el iOS 27 SDK (Blake Crosley — ImageCreator deprecated, UIKit’s Scene Mandate, Stackademic — iOS 27 SDK Breaking Changes):

  • Launch screen obligatorio. Sin él, App Store rechaza el submit. Storyboard o LaunchScreen, cualquiera vale — pero uno tienes que tener.
  • UIKit scene-based lifecycle mandatorio. Si tu app sigue en el ciclo antiguo de UIApplicationDelegate-solo, no arranca en iOS 27. Hay que adoptar UIWindowScene y UISceneDelegate sí o sí.
  • Opt-out del Liquid Glass removido. El flag temporal de Info.plist que dejaba desactivar Liquid Glass en iOS 26 ya no existe. Tu app se ve con el nuevo material, punto.
  • ImageCreator removido. La API de Image Playground para generar imágenes desde código ya no compila en iOS 27. En beta compilaba con warnings pero fallaba en runtime; en la release oficial deja de compilar directamente.
  • ld64 removido. El linker viejo se fue. El flag -ld_classic ya no funciona.

Y estos otros están deprecados — no rompen ya, pero el reloj cuenta:

  • NSBundleResourceRequest / On Demand Resources → migrar a Background Assets.
  • PreviewProvider y sus preview modifiers → migrar a la macro #Preview.
  • ReferenceFileDocument de SwiftUI → migrar a ReadableDocument/WritableDocument.
  • @State ahora es un Swift macro (source-compatibility hay, pero algunas excepciones puntuales pueden aparecer).
  • Varios accesores de status bar en UIApplication deprecados.

Cómo priorizar

Si tuviera que ordenar lo anterior por urgencia, quedaría así:

  1. Hazlo ya (antes del próximo build): launch screen, UIKit scene lifecycle, quitar ImageCreator. Sin estos, no shipeas.
  2. Migración con reloj (este trimestre): SiriKit → App Intents si aplica, PreviewProvider → #Preview, On Demand Resources → Background Assets.
  3. Adopta cuando toques el código: typed throws en Task, toolbar APIs adaptativas, ResultsObserver/HistoryObserver en SwiftData.
  4. Explora cuando tenga sentido: Foundation Models con proveedor third-party, NowPlaying framework si tu app tiene playback, widget XL si tienes contenido para el canvas.
  5. Cambia tu flujo, no tu app: Completion on-device en Xcode 27 (gratis, sin riesgo), agentic coding cuando la tarea lo justifique.

El patrón es el mismo de cada release grande de Apple: hay obligaciones (rompen build), hay migraciones con calendario (Apple da tiempo, pero no infinito), y hay adopciones voluntarias (mejoran tu app pero puedes vivir sin ellas). Este año la lista de obligaciones es más corta que la de migraciones, pero SiriKit + Background Assets + #Preview merecen entrar al backlog ya. Y Foundation Models con proveedor externo cambia lo que se puede armar sin backend — vale la pena una tarde de exploración cuando puedas.

Fuentes