Core Data still powers many apps but its API feels dated alongside modern Swift. CDE is an experimental toolkit that bridges the gap with macros, actor isolation, and type-safe predicates - plus testing utilities, a CLI tool, and complementary tools for cloud sync.

🔗: https://fatbobman.com/en/posts/cde-an-attempt-to-make-core-data-feel-more-like-modern-swift/ by Xu Yang (@fatbobman)

#CoreData #Swift #iOSDev

CDE - An Attempt to Make Core Data Feel More Like Modern Swift

In my previous article, I discussed the current reality of Core Data in today's projects: it hasn't disappeared, and it still has unique value, but the disconnect between it and modern Swift projects is becoming increasingly apparent. In this article, I will introduce my experimental project Core Data Evolution, exploring whether we can make Core Data continue to exist in modern Swift projects in a more natural way?

fatbobman.com

Working on an app that uses Core Data? You may find this open-source AI skill useful — it guides your agents to follow well-established patterns when working with 𝐶𝑜𝑟𝑒𝐷𝑎𝑡𝑎.

🔗: https://www.avanderlee.com/ai-development/core-data-agent-skill-now-available-open-source/ by Antoine van der Lee (@swiftlee)

#CoreData #Swift #AI

Core Data Agent Skill: Now available open-source

Learn about the Core Data Agent Skill, a resource for developers using the traditional Core Data framework effectively.

SwiftLee
So what’s the way to use #CoreData in the context of #Swift concurrency? Looks like I won’t be migrating to SwiftData anytime soon and I need tips

So it looks like #SwiftData migrations aren’t there yet, and the whole reason I wanna replace #CoreData is the awful XML-based migration system. So my question is: can I write mapping models manually? (Yes, manually, in this economy.) I don’t even care if they must be XML, the problem is how opaque they are. The data is hashed somehow, it fucking sucks.

And now that we are here, can I replace the data model too?

#iosdev #buildInPublic #coredata #swiftTesting

Swift Testing error messages can be annoyingly obscure - “cannot convert value of type 'nonisolated(nonsending) @Sendable (String, String) async throws -> Void' to expected argument type '@Sendable (String.Element, String.Element) async throws -> Void' (aka '@Sendable (Character, Character) async throws -> ()”

in other words: I forgot my testing macro arguments “abc”,”def" need to be arrays [“abc”],[”def”].

31/n

#iosdev #buildInPublic #coredata #swiftTesting #irishmusic

Just a little done these last couple days. Put together (and pushed) a few more unit tests for core data testing. Concentrating on the ordered many:many since that's what I need to test.
30/n

#iosdev #buildInPublic #coredata #swiftTesting

Random thoughts for future development:
Object identity is not straightforward.

If I change a collection name on device A, the change should propagate to device B.
Should two collections with the same name on different devices but with different members be merged? I think the principle of least surprise would argue that they should.

OTOH, two tunes with the same name but different melodies should be distinct (common in #irishmusic)

29/n

#iosdev #buildInPublic #coredata #swiftTesting

Not much time to do stuff over the last little while - refactored the unit tests to parameterize them and added some helper functions, added a runtime flag to choose a real file for the SQLite backing store vs. /dev/null
Changes are in GitHub if anybody is interested https://github.com/Wil-Macaulay/attributedRelationships

28/n

GitHub - Wil-Macaulay/attributedRelationships: Demo code for Core Data/Cloudkit

Demo code for Core Data/Cloudkit . Contribute to Wil-Macaulay/attributedRelationships development by creating an account on GitHub.

GitHub

#iosdev #buildInPublic #coredata #swiftTesting

Will be exploring Apple’s cktool for #cloudkit setup, which hopefully will let me populate data that will let me test sync

https://developer.apple.com/icloud/ck-tool/

27/n

cktool - iCloud - Apple Developer

Find details on using cktool.

Apple Developer

#iosdev #buildInPublic #coredata #uikit #swiftTesting

This is going to be super important when I change the underlying data model. Maybe I should add a little facade over the CoreData so I can preserve the API and leave the unit tests unchanged? That’s the ideal when refactoring, run the exact same suite of tests and have them succeed.

Still not sure on my approach for testing when synchronization across multiple devices…

26/n