#coredata — Public Fediverse posts

#buildInPublic #iosDev #coreData #swiftTesting

So I now have a start at a merge strategy I can test. Note that in the case of UUID conflicts between inbound and existing entities I’m taking the inbound UUID, so that if I modify the local storage it doesn't trigger another modification on the remote - a “sync loop”. It is still possible to get duplicates locally by creating a new Tune (with a UUID) and then modifying user data to be identical to an existing Tune with a different UUID.
8/n

#buildInPublic #iosDev #coreData #swiftTesting

new merge rule:

if inbound has UUID {
if there is existing with same UUID {
update existing with user data from most recently modified
} else { //no UUID match
if existing with same user data {
update existing with incoming UUID
} else { //no user data match
insert new with incoming UUID and user data
}
}
} else {//no incoming UUID
insert with new UUID
}
7/n

#buildInPublic #iosDev #coreData #swiftTesting

To see if inbound changes apply, I need an invariant identifier so I can tell if I've seen this object before. I don't have one, so I need to add a UUID

6/n

#buildInPublic #iosDev #coreData #swiftTesting

Directly editable attributes are displayName, isFavourite and Notes, others are set by the app. To properly merge logic I must decide
- is an inbound Tune identical to an existing one
- should changes to an inbound tune apply to an existing one.

The rule will be:
A - an inbound tune with identical displayName+notes to an existing one is considered identical
B - isFavourite will be set if either the existing or inbound tune has it set

5/n

#buildInPublic #iosDev #coreData #swiftTesting

So the obvious next step is to be able to import Tune - they're my first entity, and in the real app Tunes can be imported from existing datastores and edited via a text editor.

In my existing basic data model I have:

Tune (inherited from Searchable)
collatingName : String
createdDateTime : Date
displayName : String
isFavourite : Boolean
modifiedDateTime : Date
notes : String

Tune - extension
tuneSets : (many:many) to Set

4/n

#buildInPublic #iosDev #coreData #swiftTesting

I'm going to need test data for the obvious CRUD scenarios, but also special cases to support merging sets and collections, as well as modifying a previously synced entity. The ability to import a text/JSON file would allow me to test merge logic in a repeatable way without worrying about actually setting up cloud sync.

3/n

#buildInPublic #iosDev #coreData #swiftTesting

Since I’m eventually going to have to take a populated database and convert it from the old model to the new model, I’m going to tag the current repo so I can come back to it and build my test data. I should build a test database now that covers all the cases, but I am pretty sure that I’ll think of more as I go along.

Nevertheless, first order of business is to build some infrastructure to populate the test database.

2/n

#buildInPublic #iosDev #coreData #swiftTesting

Since I’m eventually going to have to take a populated database and convert it from the old model to the new model, I’m going to tag the current repo so I can come back to it and build my test data. I should build a test database now that covers all the cases, but I am pretty sure that I’ll think of more as I go along.

Nevertheless, first order of business is to build some infrastructure to populate the test database.

2/n

#buildInPublic #iosDev #coreData #swiftTesting

Since I’m eventually going to have to take a populated database and convert it from the old model to the new model, I’m going to tag the current repo so I can come back to it and build my test data. I should build a test database now that covers all the cases, but I am pretty sure that I’ll think of more as I go along.

Nevertheless, first order of business is to build some infrastructure to populate the test database.

2/n

#buildInPublic #iosDev #coreData #swiftTesting

Since I’m eventually going to have to take a populated database and convert it from the old model to the new model, I’m going to tag the current repo so I can come back to it and build my test data. I should build a test database now that covers all the cases, but I am pretty sure that I’ll think of more as I go along.

Nevertheless, first order of business is to build some infrastructure to populate the test database.

2/n

#buildInPublic #iosDev #coreData #swiftTesting

Since I’m eventually going to have to take a populated database and convert it from the old model to the new model, I’m going to tag the current repo so I can come back to it and build my test data. I should build a test database now that covers all the cases, but I am pretty sure that I’ll think of more as I go along.

Nevertheless, first order of business is to build some infrastructure to populate the test database.

2/n

#buildInPublic #iosDev
Back to this after a hiatus of several weeks. Starting a new thread

previous thread is here https://mastodon.social/@Tom_frog/115686636425331266

I'm going to need to develop the alternate #coreData model described in the previous thread, then develop a data migration. Finally, I’ll need to sync and deduplicate. I will use the the #swiftTesting functions I added in the first phase to test the migration.

staying well away from AI since I want to actually understand what I’m doing at the end.

1/n

#buildInPublic #iosDev
Back to this after a hiatus of several weeks. Starting a new thread

previous thread is here https://mastodon.social/@Tom_frog/115686636425331266

I'm going to need to develop the alternate #coreData model described in the previous thread, then develop a data migration. Finally, I’ll need to sync and deduplicate. I will use the the #swiftTesting functions I added in the first phase to test the migration.

staying well away from AI since I want to actually understand what I’m doing at the end.

1/n

#buildInPublic #iosDev
Back to this after a hiatus of several weeks. Starting a new thread

previous thread is here https://mastodon.social/@Tom_frog/115686636425331266

I'm going to need to develop the alternate #coreData model described in the previous thread, then develop a data migration. Finally, I’ll need to sync and deduplicate. I will use the the #swiftTesting functions I added in the first phase to test the migration.

staying well away from AI since I want to actually understand what I’m doing at the end.

1/n

#buildInPublic #iosDev
Back to this after a hiatus of several weeks. Starting a new thread

previous thread is here https://mastodon.social/@Tom_frog/115686636425331266

I'm going to need to develop the alternate #coreData model described in the previous thread, then develop a data migration. Finally, I’ll need to sync and deduplicate. I will use the the #swiftTesting functions I added in the first phase to test the migration.

staying well away from AI since I want to actually understand what I’m doing at the end.

1/n

#buildInPublic #iosDev
Back to this after a hiatus of several weeks. Starting a new thread

previous thread is here https://mastodon.social/@Tom_frog/115686636425331266

I'm going to need to develop the alternate #coreData model described in the previous thread, then develop a data migration. Finally, I’ll need to sync and deduplicate. I will use the the #swiftTesting functions I added in the first phase to test the migration.

staying well away from AI since I want to actually understand what I’m doing at the end.

1/n

If you have a #SwiftUI List/Grid and you are iterating over Model objects using id: \.self you may encounter a duplicate key in dictionary error resulting in a crash.

Changing to id: \.id or removing the id parameter entirely should resolve this issue.

for example:

forEach(photo, id: \.self) *boom*

forEach(photo) or forEach(photo, id: \.id) all good

Tricky to debug from the error message/trace but easy fix.

#iOSDev #macOSDev #SwiftData #coredata

NSManagedObjectContext can now cross Swift isolation domains — but it's not a compiler change. Apple quietly added NS_SWIFT_SENDABLE annotations to the SDK in Xcode 26, making it Sendable. A subtle but significant shift for Core Data developers.

🔗: https://fatbobman.com/en/posts/sendable-nsmanagedobjectcontext/ by Xu Yang (@fatbobman)

#Swift #CoreData #Concurrency

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

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

#iosdev #buildInPublic #coredata #cloudKit

Enough for tonight. Tomorrow I'll start prototyping the migration from explicitly ordered many:many to implicitly ordered via intermediate attributed relationship objects.

13/n

#iosdev #buildInPublic #coredata #cloudKit I also have make sure I'm selecting the Private database and the com.apple.coredata.cloudkit'recordName' is not marked queryable

https://lyons.app/2021/07/05/how-to-fix-field-recordname-is-not-marked-queryable-in-cloudkit/

gave me the answer: I have to modify the schema by adding a queryable index called recordName to the recordName metadata field for each record type so I can view the records. I also have make sure I'm selecting the Private database and the com.apple.coredata.cloudkit zone.
12/n
Edit: to fix link

#iosdev #buildInPublic #coredata #cloudKit

Got the demo working after some annoying debug sessions. Seems like it has not been revisited since 2022, and iOS 18 changed the behaviour of collectionView.dequeueReusableCell - as of iOS 18 it asserts if you call it outside of cellForItemAt indexpath. it was being called in awakeFromNib to set a font.

You would think that a company with the resources of Apple would at a minimum task interns to COMPILE AND RUN demos called out in the docs 11/n

#iosdev #buildInPublic #coredata #cloudKit

There is some Apple demo code from WWDC 2022 that gives an example of deduplication on CloudKit sync. It's a simplified demo but it does give an example of a many:many (unordered) relationship. Let's see if we can get it running.
https://developer.apple.com/documentation/coredata/synchronizing-a-local-store-to-the-cloud

10/n

And here is the blog post detailing the changes.

https://smork.info/blog/posts/beer-diary-version-2-4-released/

#ios #swift #swiftui #coredata #cloudkit

#indiedev #irishmusic #iosdev #buildInPublic #coredata #cloudKit

As an aside - I've learned a lot about CoreData and CloudKit from @fatbobman's blog.

https://fatbobman.com/en/posts/coredatawithcloudkit-1/

9/n

#indiedev #irishmusic #iosdev #buildInPublic #coredata #cloudKit

Apple has improved their migration support since I last looked - migrating to the data model outlined above would work as a staged migration:
- add the new entities and any attributes needed to define ordering or deduplication
- populate the intermediate attributed relationships
- delete the old entities

https://developer.apple.com/documentation/coredata/staged-migrations

Now we can safely move from NSPersistentContainer to a NSPersistentCloudKitContainer

8/n

#indiedev #irishmusic #iosdev #buildInPublic #coredata #cloudKit

Now we've sketched out a workable data model that works in both coreData and CloudKit, we need to work out:
- how to migrate from the existing model to the new one without losing data.
- how to handle merging databases from different devices given that the user might have duplicate entries or collections with different members or different ordering

7/n

#indiedev #irishmusic #iosdev #buildInPublic #coredata #cloudKit

diagrams of where we are so far…
6/n

#indiedev #irishmusic #iosdev #buildInPublic #coredata #cloudKit

The second case is a little more complex. Collections can contain Tunes and TuneSets. By default, they are time-ordered when users add to their contents. Users can also reorder them, and I've had requests (not yet implemented) for alphabetical and most-recent first ordering.
A superclass (Searchable) inherited by both TuneSet and Tune allows for containment of both in a Collection.

5/n

#indiedev #irishmusic #iosdev #buildInPublic #coredata #cloudKit

Tune to TuneSet is a many:many relationship ordered by the tunes’ play order. Functionally, the user can add Tunes to TuneSets and re-order or remove them. We must convert the many:many relationship to an intermediate object with an ordering attribute that we can use when we retrieve a TuneSet. We will have to be able to manipulate the ordering attribute to let the user drag Tunes to re-order them in the UI.
4/n

#indiedev #irishmusic #iosdev #buildInPublic #coredata

To zoom in a bit on the problem at hand: #cloudKit is the obvious choice for sync between devices. Apple's documentation would have you believe that all you need to do is change your NSPersistentContainer to a NSPersistentCloudKitContainer and all will be well!
Not so fast.
First of all, the coredata and cloudkit data models have to be compatible. In this case, we find the dreaded OrderedRelationship in two places.
3/n

#indiedev #irishmusic #iosdev #buildInPublic

The app started as objective-C using an in-memory data model persisted to Apple plists. I added #coredata classes soon after. Currently the data model has 4 major domain classes mirrored by core data classes, and some additional classes for convenience.

I've converted the majority of the code to Swift. I've kept all rendering and editing logic (display, audio, export etc) in Swift, using core data only for persistence and search. 2/n

Seems like this is still part of the issue where app and widget try to migrate one after another or at the same time. Did anyone implement a fully working version of the concept that widgets never migrate, wait for the app to do so, and then reload? #CoreData #SwiftUI #UIKit
https://mastodon.social/@nicoreese/115214538984790462

So I sometimes run into a #CoreData migration error. This only happens sometimes though and I only reproduced it once. Between the two model versions there's only one field that was added and the store uses the default migration options. After launching the app again, everything is fine. Any ideas?

How is it possible that changes in #CoreData relationships still do not update the UI in #SwiftUI automatically? Need to call `game.objectWillChange.send()` to make it work. And even that does not work 100% of the time.

I am still checking, butI think that I have encountered this:

https://developer.apple.com/forums/thread/734079?answerId=759407022#759407022

#CoreData presumably created a new CloudKit CKAsset field for an `externalStorage` property at runtime when it encountered an asset that is too large for the database. This causes automatic #SwiftData CloudKit sync to fail because that record doesn't exist in the server.

If so, this is broken, it should create all fields it'll eventually need so that they can be properly added to the production CloudKit schema.

Once again I'm investigating a loadPersistentStores() crash in my widget extension: Error 256 The file "xxx.sql" could not be opened.

I have never reproduced this myself.

Any experts here?

#SwiftUI #UIKit #CoreData

Anyone working on an app that uses Core Data, @FetchRequest and you're getting it ready for iOS 26 using Xcode 26?

I found a really bad bug, but only seems to happen with iOS 26 and Xcode 26. Any other combination works as expected. Posted it here with all the details: https://developer.apple.com/forums/thread/796834

#iOSDev #iOS26 #SwiftUI #CoreData

I filed this feedback to make Enums better with SwiftData: FB19106719

@ricketson @lucabernardi @curtclifton

I couldn’t find anyone working in the #CoreData or #SwiftData team so I ping you. Thank you.

It's been out for a couple weeks now, but here's my official post introducing Tap Forms Database Pro for macOS and iOS to the Fediverse! Two years in the making, dozens of new features, Apple Silicon support (finally), AI form generation, a new Reports Generator, iCloud sync across different Apple IDs, built-in Template Library, a more modern look and feel, and more!

Check it out at https://apps.apple.com/app/apple-store/id1527890083?pt=13038&ct=Mastodon&mt=8

#IndieAppDev #database #coredata #productivityapps

Ported the backend of PingU to the new #CoreData(Evolution)/ManagedModels stack and let it sizzle in the simulators "Freeway drive" for an hour - so far it all seems pretty solid.

I refuse to simply copy over the SwiftUI parts 1:1 though as I see an opportunity to do some heavy clean-up now that I don't have to fight around #SwiftData oddities anymore.

#healsCodes #iosDev #Swift #PingUApp

Ported the backend of PingU to the new #CoreData(Evolution)/ManagedModels stack and let it sizzle in the simulators "Freeway drive" for an hour - so far it all seems pretty solid.

I refuse to simply copy over the SwiftUI parts 1:1 though as I see an opportunity to do some heavy clean-up now that I don't have to fight around #SwiftData oddities anymore.

#healsCodes #iosDev #Swift #PingUApp

Mkay in the end I forked all three - CoreDataEvolution, ManagedModels and PredicateKit but the result works nicely.

Reasons for forking the first two:

Mainly to replace the dependency against swift-syntax with swift-syntax-xcframework. The later is a community project attempting to provide pre-build XCFramework versions of swift-syntax and using it instead of the source package gives an unreasonable performance boost when editing or compiling in Xcode.

Reasons for forking PredicateKit:

The way ManagedModels does it's magic results in the lack of _kvcKeyPathString compatible KeyPaths for which I built a workaround that may or may not break in the future.

I could create an issue for the KeyPath-Problem with ManagedModels but my usage of it together with PredicateKit feels like too much of niece case to bother people with.

I could also create PRs but using swift-syntax-xcf also feels like a very niece case - all three forks are available in their own branches on my GitHub though.

#healsRants #healsCodes #Swift #Swift6 #CoreData

Mkay in the end I forked all three - CoreDataEvolution, ManagedModels and PredicateKit but the result works nicely.

Reasons for forking the first two:

Mainly to replace the dependency against swift-syntax with swift-syntax-xcframework. The later is a community project attempting to provide pre-build XCFramework versions of swift-syntax and using it instead of the source package gives an unreasonable performance boost when editing or compiling in Xcode.

Reasons for forking PredicateKit:

The way ManagedModels does it's magic results in the lack of _kvcKeyPathString compatible KeyPaths for which I built a workaround that may or may not break in the future.

I could create an issue for the KeyPath-Problem with ManagedModels but my usage of it together with PredicateKit feels like too much of niece case to bother people with.

I could also create PRs but using swift-syntax-xcf also feels like a very niece case - all three forks are available in their own branches on my GitHub though.

#healsRants #healsCodes #Swift #Swift6 #CoreData

Изменение модели данных CoreData для iOs приложения с iCloud синхронизацией

Казалось бы простая задача добавления атрибута(ов) в модель данных CoreData может обернуться проблемами если в приложении используется синхронизация между устройствами через iCloud. В этом случае необходимо провести так называемую lightweight миграцию прежней базы данных в базу данных с новой моделью иначе синхронизация перестанет работать, что чревато в дальнейшем потерей данных при их восстановлении из iCloud. Здесь предлагается пошаговая инструкция как это сделать легко и безопасно на примере моего приложения для учета финансов , которым ежедневно пользуется несколько тысяч пользователей, поэтому к сохранности данных подход должен быть серьезный Итак, поехали!

https://habr.com/ru/articles/853260/

#CloudKit #синхронизация_данных #coredata #lightweight_миграция

Useful technotes about #CoreData #NSPersistentCloudKitContainer recently published by Apple:

1. Understanding the synchronization of NSPCKC: https://developer.apple.com/documentation/technotes/tn3163-understanding-the-synchronization-of-nspersistentcloudkitcontainer

2. Debugging the synchronization of NSPCKC: https://developer.apple.com/documentation/technotes/tn3164-debugging-the-synchronization-of-nspersistentcloudkitcontainer

#iOSDev

Has anyone successfully used #CoreData staged migrations introduced at #WWDC23?

Even with a simple project, the app crashes at launch with the error: 'Thread 1: "Duplicate version checksums across stages detected."' 😞

I filed #FB13647876

Code: https://github.com/alpennec/FB_CoreData_Staged_Migration

#iOSDev

Has anyone successfully used #CoreData staged migrations introduced at #WWDC23?

Even with a simple project, the app crashes at launch with the error: 'Thread 1: "Duplicate version checksums across stages detected."' 😞

I filed #FB13647876

Code: https://github.com/alpennec/FB_CoreData_Staged_Migration

#iOSDev

Has anyone successfully used #CoreData staged migrations introduced at #WWDC23?

Even with a simple project, the app crashes at launch with the error: 'Thread 1: "Duplicate version checksums across stages detected."' 😞

I filed #FB13647876

Code: https://github.com/alpennec/FB_CoreData_Staged_Migration

#iOSDev