SwiftData vs Core Data in 2026: A Production Decision Guide

The short answer

Use SwiftData if you are starting a new project targeting iOS 17+ and your data model is straightforward — no complex migrations, no Watch target, no multi-store configuration. Use Core Data for everything else.

That covers 80% of decisions. The remaining 20% is what this article is about.

What SwiftData actually is

SwiftData is not a replacement for Core Data. It is a Swift-native API layer built on top of Core Data's persistence stack. Under the hood, SwiftData uses the same NSPersistentContainer, the same SQLite store, and the same migration infrastructure. What changes is the surface area: you use @Model macros instead of .xcdatamodeld files, @Query instead of NSFetchRequest, and ModelContainer instead of NSPersistentContainer.

This matters because the common misconception — that SwiftData is a fresh rewrite — leads to wrong decisions. SwiftData inherits Core Data's behavioral guarantees, its CloudKit sync capabilities, and its migration system. It also inherits its limitations.

When Core Data is still the right choice

Use Core Data when:

• —You have a Watch target. WatchKit and SwiftData's container sharing have known reliability issues in 2026. Core Data with NSPersistentCloudKitContainer and WatchConnectivity is the stable production pattern.
• —You need complex staged migrations. SwiftData's migration API improved in iOS 18 but still does not match Core Data's NSMappingModel flexibility for non-trivial schema transformations.
• —You have an existing Core Data codebase. Do not rewrite a working Core Data stack for SwiftData syntax. The interop is available but adds complexity for zero production benefit.
• —You need multi-configuration stores. Separate persistent stores for user data vs. app data, or read-only bundled stores, are still more ergonomic in Core Data direct.
• —Your minimum deployment target is below iOS 17. SwiftData requires iOS 17.0 minimum. Core Data runs from iOS 3.

When SwiftData wins

• —Greenfield iOS 17+ apps with a Swift team. The @Model and @Query macros reduce boilerplate significantly. Fetch descriptors are typesafe. The SwiftUI binding story is clean.
• —Simple models with straightforward relationships. If your data model fits on a whiteboard without arrows crossing, SwiftData handles it without issue.
• —Rapid prototyping for demos or internal tools. The setup is faster. For projects where long-term migration stability is not a concern, SwiftData ships faster.

Migration path: ModelContainer + NSPersistentContainer interop

If you have an existing Core Data stack and want to migrate incrementally, Apple provides ModelContainer with an option to pass an existing NSPersistentStoreDescription. This allows SwiftData and Core Data to share the same SQLite file during a transition period.

The practical recommendation: migrate leaf entities first (those with no relationships to unmitigated entities). Keep Core Data for entities with complex relationships or Watch sync until the model is stable. Do not migrate all at once.

The gotchas

• —Background context handling is less explicit. Core Data's performBackgroundTask pattern is well understood. SwiftData's actor-isolated context model has edge cases in 2026 with concurrent write scenarios.
• —Preview crashes in Xcode with in-memory stores. SwiftData previews require an explicit isStoredInMemoryOnly flag or they attempt to write to disk in the preview environment. Forgetting this causes non-obvious crashes.
• —Cascade delete rules require explicit annotation. Core Data's cascade configuration is visual. In SwiftData, missing @Relationship(deleteRule: .cascade) leads to orphaned records that are silently retained.
• —NSPredicate is still required for complex queries. SwiftData's #Predicate macro handles simple conditions but falls back to NSPredicate for subqueries and compound expressions. Know where the boundary is before you hit it.

What we use at 3NSOFTS

The Company App — our most complex production system — runs Core Data with NSPersistentCloudKitContainer. The data model has inventory items, orders, dispatch jobs, and customer records with multiple relationship paths. Watch sync is a core feature. This is not a SwiftData job.

New greenfield projects we scope for iOS 17+ with simple models get SwiftData. We made this call for a recent internal tool — two entities, no Watch target, no migration requirement. SwiftData shipped it in a third of the setup time.

See the Company App case study for what a full Core Data + CloudKit architecture looks like in production.