When Apple announced SwiftData at iOS 17, my first thought was “I can finally forget about CoreData”. Macros, clean syntax, native SwiftUI integration. Then I used it on a real project, and the story turned out to be more nuanced.
I’ve shipped SwiftData in two of my iOS apps, and ten of them still run CoreData. Why? Because SwiftData is still young, and in certain cases it can’t do what CoreData does. Here’s how I decide which one to reach for.
Where SwiftData wins
1. Minimum boilerplate. You declare a class with the @Model macro and Apple handles persistence underneath. No xcdatamodeld, no NSManagedObject subclasses, no NSPersistentContainer setup. A model that takes 80 lines of CoreData takes 10 in SwiftData.
2. Native SwiftUI integration. With @Query you filter, sort, and limit directly in the view. CoreData’s @FetchRequest did similar things, but the syntax was uglier. In SwiftData, predicates are type-safe through Swift macros.
3. Migrations are automatic. Add a new property, use it at runtime, done. CoreData’s versioned model migration setup (usually a 2 to 3 hour job) is often unnecessary in SwiftData.
4. CloudKit sync is built in. modelContainer(for: Item.self, isCloudKitEnabled: true), one line. CoreData needed NSPersistentCloudKitContainer and schema mirroring configuration.
Where CoreData still wins
1. Complex relationships. SwiftData supports many-to-many, but fine-grained controls like cascade rules, inverse relationships, and orphan deletion are still weak. CoreData has a decade-matured API.
2. Performance-critical cases. When I stored a 10K+ entry brushing history on Dentii, some queries in SwiftData were 2 to 3x slower than CoreData. Apple will probably fix it, but today it’s real.
3. Mature migration strategy. CoreData has versioned migration, lightweight/heavyweight migration, and manual mapping models, all tested in the field. SwiftData still hits bugs on complex schema changes.
4. Third-party integration. CoreData has 10 years of ecosystem around it. NSFetchedResultsController with custom collection views, background sync helpers, debugging tools. SwiftData is still growing that ecosystem.
5. iOS 16 and below support. SwiftData is iOS 17+. If your users are on older iOS, CoreData is mandatory.
Decision matrix
For a new iOS project, this is my matrix:
- iOS 17+ target, simple model, SwiftUI only: SwiftData
- Need iOS 16 or older: CoreData
- Data model with 10K+ entries expected: CoreData (for now)
- Complex relationships (3+ levels): CoreData
- CloudKit sync critical: SwiftData (if iOS 17+)
- Offline-first, complex sync: CoreData (mature)
- Prototype / MVP: SwiftData (fast)
- Enterprise app meant to last 5+ years: CoreData (lower risk)
Is a hybrid setup possible?
In theory yes, you can keep some models in SwiftData and others in CoreData in the same app. In practice it’s confusing: which store owns which model, which tool manages migration, how do you structure tests? Avoid it.
Keeping the same model in both stores is even worse. Sync logic complexity grows exponentially.
SwiftData’s maturity curve
iOS 17 (September 2023), first release. iOS 17.2 brought core bug fixes. iOS 18 (September 2024) added real improvements (index support, custom migrations, unique constraints). iOS 18.1 is where it’s fair to call it production-ready.
Through 2026 SwiftData should catch up to about 90% of CoreData’s feature set. At that point it becomes the default pick for new projects. For now (late 2024), stay fluent in both.
Practical starting strategy
On a new iOS 17+ project, I decide this way:
- Fewer than 10 entities, flat relationships? → Start with SwiftData.
- Do performance issues show up in real use? → Benchmark, and if so prepare a migration path to CoreData.
- If you haven’t shipped to the App Store yet, switching takes a day or two. Switching post-launch is much more expensive.
SwiftData is heading in the right direction. But “mandatory on every project” isn’t true yet. Pick based on your situation.