Why I Chose CoreData Instead of SwiftData

SwiftData is very neat. Concise, simple and fast. I quickly hit show stoppers, though.

The first major disappointment were the persistent identifiers. They cannot be represented as strings. Yes, PersistentIdentifier is Codable. No, I did not want to go through the ordeal of implementing a custom Encoder and Decoder which produce a monstrous String based on internal implementation details with unwarranted stability in the long term. Ok, at least I started doing so and quickly realized it is unreasonable. Anyway, I am mostly working on a file provider and not some SwiftUI example code which pokes a bit in a simple data schema. I need to pass unique identifiers to the system in form of NSFileProviderItemIdentifier which uses String as its raw value. Also I need to be abled to find my data objects based on such an identifier once I am asked for it by the system.

That could lead to the simple workaround of using an additional property and identifier, a UUID. It would serve as an additional unique key for the entity. The problem here: SwiftData does not support custom indices (yet).

That will not be a problem with containers which are expected to contain a few dozen of objects. In my use case it has to scale well with hundreds of thousands, though. By experience I can say that this can become quite slow without a fetch index. With these two disappointments I have had it and fall back to CoreData, for now. I guess SwiftData needs a few years to mature, just like SwiftUI.