SwiftData in production: where it shines and where it doesn't

SwiftData shipped with iOS 17 and the pitch was compelling: macros instead of the data model editor, ModelContext instead of NSManagedObjectContext, a more actor-friendly concurrency model, and @Model instead of NSManagedObject subclass generation. In practice, the production experience depends heavily on the shape of the data model, query complexity, and migration risk.

After multiple iOS 17/18 release cycles, the main tradeoffs are clearer than the WWDC launch material suggested in Meet SwiftData, Model your schema with SwiftData, and Dive deeper into SwiftData.

What SwiftData Actually Gets Right

The day-to-day developer experience is genuinely better for typical use cases. Defining a model is expressive in a way Core Data never managed:

@Model
final class Article {
    var title: String
    var body: String
    var publishedAt: Date
    var isDraft: Bool = true

    @Relationship(deleteRule: .cascade)
    var tags: [Tag] = []

    init(title: String, body: String) {
        self.title = title
        self.body = body
        self.publishedAt = .now
    }
}

That’s it. No .xcdatamodeld file. No entity editor. No NSManagedObject subclass generation. The relationship with deleteRule: .cascade is declared at the property, not buried in a data model inspector panel.

@Query in SwiftUI views is equally clean:

@Query(sort: \Article.publishedAt, order: .reverse)
var articles: [Article]

There are three concrete advantages here.

• Schema is defined in code, so model changes, delete rules, defaults, and annotations are visible in normal code review instead of hidden in a model editor. Apple’s Schema docs reflect that same code-first model.
• SwiftUI integration is first-class: @Query covers the common “live list + sort/filter” case with far less glue code than @FetchRequest plus manual mapping.
• The fetch API surface is smaller and more readable. For straightforward reads, FetchDescriptor, SortDescriptor, and #Predicate are easier to reason about than mixing NSFetchRequest, NSSortDescriptor, and NSPredicate.

For CRUD apps with modest data volume and straightforward relationships, those advantages remove real friction. For a new notes app or task manager, SwiftData is often the more sensible default.

Where It Falls Short

Migration remains the highest-risk surface

Core Data has a mature migration story. Lightweight migration handles common schema changes automatically. Mapping models handle complex migrations explicitly. It is not fun to write, but it is predictable.

SwiftData migration support (VersionedSchema + SchemaMigrationPlan) is conceptually similar, but still less battle-tested in edge cases. That matters because persistence failures are asymmetric: a broken screen can be patched quickly, but a bad migration can permanently damage local user data.

The risk is highest when a schema change alters relationships, optionality, uniqueness, or the way records are split across models. Those changes should be treated as production migration events, not ordinary refactors. In practice, that means testing against on-disk stores produced by older app builds, not just fresh simulator data.

Core Data migration tends to fail loudly or succeed correctly because its migration surface has been exercised for far longer. SwiftData can still land in an uncomfortable middle state where the app opens but the migrated data is not obviously correct. If local data cannot be recreated from a server, migration risk should outweigh API ergonomics.

Predicate expressivity still has a gap

SwiftData’s #Predicate macro is more type-safe than NSPredicate strings. It also has a narrower comfortable operating range.

For simple equality checks, ranges, booleans, dates, and many one-hop relationship filters, #Predicate is a real improvement. The trouble starts when query requirements look more like reporting logic than list filtering.

Complex predicates such as many subquery-like filters, some aggregate-style queries, and deeper relationship traversal are still where things get awkward. When a feature needs SUBQUERY-style behavior for nested relationships, the fallback is often to fetch a superset and filter in memory, which defeats database-side filtering once datasets become large.

Core Data’s NSPredicate, for all its stringly-typed awkwardness, still covers more of the advanced query surface teams need once filtering becomes relational, dynamic, or analytical. SwiftData’s #Predicate covers the common 80% well and leaves the remaining 20% either unsupported, verbose, or operationally expensive.

Performance tuning is still a thinner surface

SwiftData is not devoid of performance controls. FetchDescriptor supports options such as fetchLimit, fetchOffset, includePendingChanges, relationshipKeyPathsForPrefetching, and propertiesToFetch, and ModelContext has batched fetch and enumeration APIs.

The issue is not that performance tooling is absent. The issue is that the low-level tuning surface is still narrower and less familiar than Core Data’s. Teams that already rely on carefully tuned fetch requests, batch behavior, and faulting semantics will notice that difference quickly on large stores.

Concurrency story is better, but identity semantics need care

SwiftData’s ModelActor is the right primitive for background work:

@ModelActor
actor ArticleProcessor {
    func processNewArticles() async throws {
        let pending = try modelContext.fetch(
            FetchDescriptor<Article>(predicate: #Predicate { $0.isDraft })
        )
        for article in pending {
            article.isDraft = false
        }
        try modelContext.save()
    }
}

In practice, actor isolation solves only part of the problem. Background work still needs explicit handoff points back to the main actor, and the safest boundary is usually identifiers or derived value types rather than live model instances.

Identity confusion remains a real risk area: a record touched in different contexts can behave like separate in-memory objects until save/merge boundaries are crossed. Those bugs are hard to reproduce and even harder to diagnose from crash logs, especially when the symptom is stale UI or a missing update rather than a hard failure.

How To Ship SwiftData Safely In 2026

Teams choosing SwiftData should treat persistence as a product surface, not plumbing:

• Define VersionedSchema from v1, even if only one version exists today.
• Keep migration fixtures from real historical app builds and run upgrade tests against those stores in CI.
• Avoid putting complex business logic directly in SwiftUI @Query views; keep FetchDescriptor and predicate construction in a thin data layer so query behavior can evolve without touching UI.
• Use @ModelActor for background mutations and pass identifiers across actor boundaries instead of passing live models.
• Load test real queries early with realistic row counts and relationship density, not toy datasets.
• Add telemetry around store open failures, migration duration, migration success/failure, and post-upgrade record counts so regressions are visible immediately.

SwiftData can be production-safe, but only if you are explicit about these guardrails.

Rule Of Thumb

Use SwiftData when:

• iOS 17+ is your minimum deployment target
• Your model is relatively stable (few high-risk migrations expected)
• Your queries are straightforward (@Query, FetchDescriptor, simple predicates, simple relationship traversal)
• Data volume is moderate (tens of thousands of records, not millions)

Stick with Core Data when:

• You need advanced predicates, aggregate queries, or heavy relational filtering
• Your migration history is long and must be airtight
• You’re syncing with CloudKit beyond the basic NSPersistentCloudKitContainer happy path
• You need fine-grained low-level control over fetch behavior, faulting, and memory characteristics

If Swift-first ergonomics still matter but SwiftData’s current limits do not fit the problem, it is also worth evaluating SQLiteData, which takes a SQL-backed approach and supports CloudKit sync.

SwiftData is still not a full Core Data replacement. It is a better API for the use cases it covers, and still a source of hard-to-debug behavior for the use cases it does not. The important decision is not “new API vs old API”; it is “narrow, low-risk persistence profile vs broad, high-control persistence profile.”

The projects that still fit Core Data best tend to share the same profile: high data volume, complex queries, and migration paths that cannot afford ambiguity. When the persistence surface gets that risky, Core Data’s ergonomic cost is often easier to justify than SwiftData’s remaining uncertainty.