When I started rebuilding Drop's data layer, Core Data was the obvious choice. It has been Apple's persistence framework for over a decade. It works. A huge amount of documentation exists for it. Plenty of apps I had shipped before used it without issue.

I chose SwiftData anyway, and I want to explain why, because it was not a trivial decision.

Drop stores a lot of data. Every injection is a record: a timestamp, a dose amount, a medication, a region label, a 3D coordinate in body space, an optional discomfort tag, and eventually a set of ML-derived signals. That record needs to survive app restarts, sync to iCloud, and be queryable in ways that support real-time rendering, not just list views.

Core Data handles all of that. But Core Data also requires you to work around it constantly. You manage object contexts manually. You thread-marshal with care. You think about faults and fire and merge policies in ways that have nothing to do with the problem you are actually solving. Every time I have built something with Core Data I have shipped the feature and then spent time afterwards cleaning up the accidental complexity the framework introduced.

SwiftData is different. It was designed from the ground up for Swift concurrency, for @Observable, for the way modern SwiftUI apps are actually structured. Your models are plain Swift classes decorated with @Model. Your queries are @Query properties that just work in views. The CloudKit sync comes for free from the ModelContainer configuration. There is no separate mapping layer, no NSManagedObjectContext to pass around, no NSFetchRequest boilerplate.

The practical difference showed up immediately in Drop's injection logging flow. The screen that lets a user tap a site on the 3D body model and confirm a dose needs to write to the store and update the heatmap in a single coherent action. In Core Data that would have been two or three lines of explicit context management. In SwiftData it was one: modelContext.insert(injection).

The risk I accepted was maturity. SwiftData launched at WWDC 2023. When I adopted it for Drop it was new enough that the documentation had gaps and some edge cases were not well understood. I hit a few of them. There are still rough edges around complex queries and certain CloudKit sync behaviours that required workarounds.

But the tradeoff was right. The velocity gain across the whole project has been real. And as the framework matures, the rough edges will smooth. Core Data is not going anywhere, but for a new app built on modern Swift, SwiftData is the right foundation.

If you are starting a new iOS project today and you are not carrying a Core Data migration requirement, use SwiftData. The future is clearly there.