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)
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
#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
#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
#iosdev #buildInPublic #coredata #uikit #swiftTesting
Added my first set of unit tests - just creating a single instance of each of my core entities - pushed to GitHub for those that care! Next step is to add tests for the relationships: for example, adding a Tune to a TuneSet and then reordering them.
Found a neat trick on testing Core Data without leaving droppings - use /dev/null as the store. See
https://medium.com/tiendeo-tech/ios-how-to-unit-test-core-data-eb4a754f2603
25/n
Snapp iOS Weekly
Badly-read literary snob
Wil Macaulay
