SwiftData frente a Core Data: cómo elegir una capa de persistencia en 2026

Si estás empezando una app nueva orientada a iOS 17 o superior, elige SwiftData. Si necesitas dar soporte a una versión anterior del sistema operativo, depender de consultas agregadas a nivel SQL o ampliar una configuración de Core Data y CloudKit ya existente, Core Data sigue siendo la mejor opción, muchas veces funcionando junto a SwiftData en lugar de sustituirlo. A continuación se explica qué cambia realmente SwiftData, cómo conviven ambos frameworks y las decisiones concretas que deben guiar tu elección.

Qué es SwiftData y por qué importa esta comparación

SwiftData es el framework de persistencia nativo de Swift de Apple. Está construido sobre la arquitectura de almacenamiento de Core Data, no es un reemplazo hecho desde cero. Los modelos se declaran con la macro @Model, la configuración del almacén se gestiona con ModelContainer, los cambios en memoria se rastrean con ModelContext, los resultados se obtienen y observan en vistas SwiftUI con @Query, y el filtrado usa la sintaxis segura en tipos Predicate en lugar de cadenas NSPredicate. El framework elimina una cantidad real de código repetitivo frente a una pila de Core Data construida a mano, sobre todo en la capa de modelos de una app pequeña o mediana.

La comparación empieza, y a menudo termina, con un requisito de plataforma. SwiftData requiere como mínimo iOS 17, macOS 14, tvOS 17 o watchOS 10. Si tu app da soporte a un sistema operativo más antiguo, SwiftData simplemente no es una opción todavía y Core Data sigue siendo el único camino compatible. Los equipos que lanzan apps SwiftUI con confianza suelen tomar esta decisión al inicio del proyecto, porque adaptar una capa de persistencia después de un año de funciones ya lanzadas cuesta mucho más que elegir bien desde el primer día.

La experiencia diaria de desarrollo es donde la diferencia realmente se nota. Un modelo de Core Data necesita un archivo .xcdatamodeld, subclases NSManagedObject generadas y un contenedor persistente configurado a mano antes de ejecutar la primera consulta. Un modelo de SwiftData es simplemente una clase Swift normal con la macro @Model. En una app pequeña, esa diferencia puede significar tener la primera pantalla funcionando en una tarde en lugar de un día completo. En una app grande, con cientos de entidades y años de migraciones ya registradas, esa sencillez pesa mucho menos que el historial operativo que ya tiene detrás una pila de Core Data.

Cómo funcionan juntos SwiftData y Core Data en la práctica

La propia guía de Apple para adoptar SwiftData en una app con Core Data plantea esto como una migración incremental, no como una reescritura. SwiftData puede apuntar al mismo almacén SQLite que ya usa una pila de Core Data, lo que permite a un equipo migrar los modelos uno por uno mientras el resto de la app sigue funcionando contra el almacén existente. Apple introdujo este patrón en la sesión de migración de WWDC 2023, y toda la guía posterior, incluida la documentación de coexistencia de 2026, se apoya sobre esa misma base.

WWDC 2026 añadió dos novedades importantes a SwiftData. La primera es ResultsObserver, el equivalente de @Query fuera de SwiftUI. Obtiene datos de un almacén SwiftData y observa sus cambios usando el framework Observation de Swift, con las mismas primitivas de filtrado, ordenación y seccionado que ya ofrece @Query, pero funciona desde un view model o cualquier contexto que no dependa del ciclo de vida de una vista SwiftUI. Eso importa para todo lo que se ejecuta fuera del árbol de vistas, como un controlador de actualización de WidgetKit o Live Activities que necesita leer el almacén sin esperar a un ciclo de renderizado de SwiftUI. La segunda novedad son los atributos de modelo .codable, que delegan la serialización al propio tipo y almacenan directamente la representación codificada, reduciendo la sobrecarga de inferencia de esquema para tipos anidados complejos. La contrapartida es que el contenido de un atributo .codable resulta opaco para la capa de almacenamiento de SwiftData, así que no se puede usar dentro de un Predicate para filtrar ni como clave de ordenación.

Ventajas, desventajas y casos límite

Hay dos carencias concretas que en 2026 siguen favoreciendo a Core Data. La primera es el seguimiento de historial: SwiftData lo hace automáticamente, mientras que Core Data exige configurar manualmente NSPersistentHistoryTrackingKey. Aquí SwiftData gana claramente para las apps que necesitan seguimiento de cambios sin configuración adicional. Las consultas agregadas van en sentido contrario. NSExpression de Core Data calcula sumas, promedios, conteos y valores mínimos o máximos directamente en la capa SQL sin cargar los registros en memoria, y SwiftData no tiene un equivalente directo. El mismo cálculo agregado hoy implica traer primero los registros correspondientes a memoria. Muchos equipos terminan adoptando un patrón híbrido: usar SwiftData para la capa de modelos en general y mantener una vía de escape a Core Data, contra ese mismo almacén subyacente, específicamente para las consultas agregadas basadas en NSExpression, evitando así mantener dos bases de datos separadas.

La convivencia se complica más cuando entra en juego la sincronización con CloudKit. Un ingeniero de DTS de Apple, respondiendo a la propuesta de un desarrollador de ejecutar almacenes de Core Data y SwiftData totalmente separados con contenedores de CloudKit distintos, confirmó que la separación es viable en principio, pero advirtió que la mayoría de apps reales tienen relaciones de datos que cruzan ambos almacenes, lo que obliga a escribir código puente para mover datos entre ellos. Para apps sincronizadas con CloudKit en particular, esa misma guía recomienda consolidar todo en una única base de datos privada respaldada por Core Data en lugar de mantener dos contenedores, ya que la compartición de CloudKit ya funciona a través de una base de datos privada, sin importar qué framework haya escrito el registro. Los equipos que están a mitad de una migración a la concurrencia estricta de Swift 6 deberían valorar esto con cuidado antes de apilar una segunda migración, no relacionada, encima de la primera. Secuenciar los dos proyectos suele salir más barato que ejecutarlos en paralelo.

Las pruebas y las vistas previas también merecen una mención concreta. Configurar un ModelContainer con un almacén en memoria requiere pocas líneas de código, y las vistas previas de SwiftUI pueden arrancar contra ese contenedor en memoria sin tocar un archivo de base de datos real. Ese flujo es más ágil que montar un NSPersistentContainer en memoria para el mismo propósito. Es una ventaja pequeña por sí sola, pero en un equipo que ejecuta docenas de vistas previas y pruebas unitarias al día, se traduce en tiempo real recuperado.

Preguntas frecuentes

¿Pueden funcionar SwiftData y Core Data en la misma app?

Sí. Apple documenta esto como una vía compatible: SwiftData se apoya en el formato de almacén de Core Data, así que un equipo puede adoptar SwiftData para la mayoría de sus modelos y recurrir a Core Data contra ese mismo almacén para las capacidades que SwiftData no cubre, como las consultas agregadas con NSExpression.

¿Cuál es la versión mínima de iOS para SwiftData?

SwiftData requiere iOS 17, macOS 14, tvOS 17 o watchOS 10 como mínimo. Las apps que dan soporte a versiones anteriores deben mantenerse en Core Data o conservar una vía alternativa basada en Core Data.

¿SwiftData admite las mismas consultas agregadas que Core Data?

No directamente. NSExpression, de Core Data, calcula sumas, promedios, conteos y valores mínimos o máximos en la capa SQL sin cargar los registros en memoria. SwiftData no tiene un equivalente directo en 2026, así que el cálculo agregado exige traer los datos a memoria primero, o recurrir a Core Data contra el almacén compartido para esa consulta concreta.

¿Qué novedades trae SwiftData para 2026?

WWDC 2026 añadió ResultsObserver, el equivalente de la propiedad @Query fuera de SwiftUI, pensado para view models y otro código que no forma parte de una vista, y los atributos de modelo .codable, que delegan la serialización al propio tipo, aunque esos atributos no se pueden usar en predicados ni como claves de ordenación.

Conclusión

La decisión se reduce a una lista corta de comprobaciones, no a una preferencia general. App nueva, iOS 17 o superior como requisito mínimo, sin una dependencia fuerte de consultas agregadas a nivel SQL: SwiftData por defecto. App con Core Data ya existente, soporte a versiones antiguas que mantener, o una configuración de CloudKit ya establecida que no quieres rediseñar: quédate con Core Data, o migra de forma incremental siguiendo el camino de coexistencia documentado por Apple. Es la misma decisión entre construir o ampliar que tomamos en la mayoría de nuestros proyectos de iOS en Kallos Labs, y la respuesta casi siempre depende de la app concreta que tengas delante, no de una regla que aplique siempre igual.