That did work, Thank you! However, would CloudKit change notifications work too from Command Line app too?

Yes, my usage of word "daemon" was a little ambiguous. I meant it in context of anything that runs without UI. Whether launchd daemon or launchd agent. But CKSyncEngine has following event hook - accountChange(CKSyncEngine.Event.AccountChange) - wouldn't presence of this hook imply that CKSyncEngine (and hence also CloudKit subscriptions) could in theory work also from launchd daemon? At least when user signs in on MacOs?

Yes, my usage of word "daemon" was a little ambiguous. I meant it in context of anything that runs without UI. Whether launchd daemon or launchd agent. But CKSyncEngine has following event hook - accountChange(CKSyncEngine.Event.AccountChange) - wouldn't presence of this hook imply that CKSyncEngine (and hence also CloudKit subscriptions) could in theory work also from launchd daemon? At least when particular user signs in on MacOs?

Thanks for the pointers. I forgot to mention that in my example, the firstName and lastName fields are not mutable, and the combination of these fields is guaranteed to be unique (i.e., there can only be one John Smith). The age field, however, is mutable. Given this constraint, I believe there could be a more elegant sync approach than the "Create duplicates in CloudKit and delete one" method if only it would be possible for me to set recordName as I wish.

Isn't await keyword supposed to serve as synchronization point and line after it executed only when current line is await-ed? FWIW I added following prints to dump time: entered shareConfiguration function at 1724102594.9793549 returning from shareConfiguration function at 1724102595.200552 setting showingShare to true at 1724102595.200789 <-- this is logged just before setting showingShare to true.

@darkpaw Still the same behavior - I see "No sheet to show": Here is what I changed: DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { print ("Setting showingShare to true at \(Date.now.timeIntervalSince1970)") showingShare = true } entered shareConfiguration at 1724105717.827956 returning from shareConfiguration at 1724105718.080661 Setting showingShare to true at 1724105721.139563

@darkpaw I reintroduced in my project isProcessingShare state property to reflect sharing progress and now the sheet shows up correctly the first time. Likewise, if from official Apple CKShare demo app I merely remove isProcessingShare then official Apple demo app stops working. I think Apple demo app is poorly designed that for CKShare to work there needs to be progress redrawn.

You are completely right! The way Apple designed this part of CKSyncEngine does not seem well thought through. It should be not just CKrecordID that is passed to nextRecordZoneChangeBatch, but also RecordType.

I am facing the exact same issue as adamek. Only because RecordType is not passed together with RecordID in the nextRecordZoneChangeBatch I have to do lookups in all possible local storage tables to find local record. Unnecessary extra code and slows down my application.

That's a bummer that values are not retained. However, wouldn't the SwiftData Undo feature imply that under some circumstances previous values could be retained?

This is neither work or school device. But it is wireless carrier subsidized phone. I tried to check profiles installed but could not find unless I looked into wrong place. Any tips where I could see these "configuration profiles" in the settings?

To me it seems that automatic UI refreshes when data is changed from background is again broken. I am now on 18.1 (22b5069a) and it does not work. In the past I tried older builds and I am willing to swear that it worked back then for at least one of the Beta releases.

To give more context: what I am trying to create is parental controls where unwanted apps are immediately killed. I was not able to get the Apple Screen Time APIs (ManagedSettings, FamilyControls etc) that work on iOS to work on MacOS. So I thought second best thing would be to simply kill unwanted apps.

How would one go about implementing sharing model where with one User action two zones are shared and two zones are accepted?

Would that hit an assert() - which is basically unhandable crash? Or throw an exception? Also, why would assert be hit only on release builds and not debug builds with exact same code? @Model final class WorkspaceModel: MyModelProtocol { typealias DTOType = WorkspaceDTO var recordName: String final class WorkspaceDTO: MyDtoProtocol { typealias ModelType = WorkspaceModel var recordNameType: String