One of the things I like about CoreData is that all the relationships and entities are defined in one file, and its easier to browse the history of that schema to see how the models evolved. One of the things I dislike though is that it doesn't interop well with swift types and almost everything has to be marked as optional. It looks like this SwiftData solves the second problem, but since definitions are spread across all the classes individually, it's harder to get a glance at the whole schema at once.
Ditto to this suggestion. Especially when you auto generate classes it ends up creating the main class for each entity and a separate extension file for each. By default we merge the two and avoid the separate extension altogether.
There’s a number of indie devs who rely on https://github.com/ccgus/fmdb for fast persistence. The rebirth of NetNewsWire came with FMDB at its core (https://inessential.com/2020/05/18/why_netnewswire_is_fast). What’s not clear is if a project starts with, say, SwiftData, and finds it to be a bottleneck, how easy is it to remove unless one goes to great lengths to make a clean API between the 2?
I was all bought into RealmSwift, with iCloud syncing. Because I added a layer already that syncs Realm with iCloud, I expect transitioning to SwiftData (or from it to anything else) will work nearly out of box, without having to rip out the Realm code yet either. It'll receive the same iCloud data as Realm does.
When out of beta and generally available, this will be useful! Ideally the iCloud sync will work across the same app built for macOS, iOS, and iPadOS.
I used SQLite a few years ago for a Swift/SwiftUI macOS app, and this looks like what I would have used if it was available. All in all, Apple is going in a good direction with Swift, SwiftUI, SwiftData, etc.
Unfortunately it looks to be mostly papering over Core Data, after a few huge Core Data projects I don't really care to work with it anymore, especially in SwiftUI.
The more interesting addition to me looks to be CKSyncEngine, which would allow for easily adding a CloudKit sync engine to something like GRDB.
Defining models in structs and extending and conforming them to various protocols, using them in SwiftUI and passing them across threads feels much more natural to me.
I built myself something similar on top of SQLite and Combine.
Now I’m confused, should I abandon it and go with the first hand solution? I would actually prefer that but this requires the new versions of the Apple platforms. Why wouldn’t Apple make these available downstream?
Apple actively encourages everyone to adopt the latest version. If your device is from 2018 or newer it will support the latest OS, so back porting frameworks is less important than on platforms like Android where devices are only updated for a much shorter duration and often several months after that version is released by Google.
> Why wouldn’t Apple make these available downstream?
Because it probably relies on new stuff that's only in the new version of the operating system. Otherwise, you'd have to back port a chunk of your new stuff to the older operating system, creating a lot more work for little gain.
And why do all of that when over 80% of the installed base will be running iOS 17 within 8 months, so what are you really gaining?
They actually can figure that out, though [0]. I hope this can solve some of it because their deployment model is the dumbest fucking thing. I'm glad they figured out how to backport async/await, it's just impossible to use in a serious library otherwise.
Apple need to ensure as many apps as possible raise their deployment target as soon as possible so that users with old devices are encouraged to upgrade to newer devices.
I’m actually really looking forward to this. I tried building a few apps in 100% SwiftUI coming from React/Node.js and it was a pretty major pain. I also don’t know UIKit so I couldn't easily fallback.
The typing of NSPredicate seems like a big upgrade as well. I went through all the old outdated docs for core data but still things aren’t very clear in my mind. Hoping the typing helps
Apple has like >80% of devices released in last 5 years on iOS 16. Nowhere near the fragmentation of Android. Given only a minority of users are not on the latest major OS, worrying about supporting older firmware, at least in this case, is not worth the time or money.
This is made possible by Swift macros, which also will make migration easier.
I can imagine starting out with SwiftData @Model's, but then redefining the @Model macro to work with another backend -- even deploying the same models to different backends on different platforms (e.g., CoreData on iOS and MySQL on Linux).
"API-compatible" now includes attributes. This could be a great opportunity for alternatives to the CoreData stack.
Readit News
I was all bought into RealmSwift, with iCloud syncing. Because I added a layer already that syncs Realm with iCloud, I expect transitioning to SwiftData (or from it to anything else) will work nearly out of box, without having to rip out the Realm code yet either. It'll receive the same iCloud data as Realm does.
I used SQLite a few years ago for a Swift/SwiftUI macOS app, and this looks like what I would have used if it was available. All in all, Apple is going in a good direction with Swift, SwiftUI, SwiftData, etc.
The more interesting addition to me looks to be CKSyncEngine, which would allow for easily adding a CloudKit sync engine to something like GRDB.
Defining models in structs and extending and conforming them to various protocols, using them in SwiftUI and passing them across threads feels much more natural to me.
Can I ask what experience you had with CoreData and SwiftUI? And what do you prefer now instead? Thank you.
Now I’m confused, should I abandon it and go with the first hand solution? I would actually prefer that but this requires the new versions of the Apple platforms. Why wouldn’t Apple make these available downstream?
Because it probably relies on new stuff that's only in the new version of the operating system. Otherwise, you'd have to back port a chunk of your new stuff to the older operating system, creating a lot more work for little gain.
And why do all of that when over 80% of the installed base will be running iOS 17 within 8 months, so what are you really gaining?
Because Apple cannot figure out that their deployment model is hamstringing adoption of their technologies.
[0] https://github.com/apple/swift-evolution/blob/main/proposals...
80% of iPhones run the latest OS precisely because they are dead serious about long term support for devices.
I can imagine starting out with SwiftData @Model's, but then redefining the @Model macro to work with another backend -- even deploying the same models to different backends on different platforms (e.g., CoreData on iOS and MySQL on Linux).
"API-compatible" now includes attributes. This could be a great opportunity for alternatives to the CoreData stack.
Deleted Comment