Ok, so the order of the added pending changes is guaranteed not to be changed by CKSyncEngine, right? Is there a way to know the batch size before the batch is built? I know that CloutKit will tell you if you try to save a batch that is too large, but that happens async in a different context, so it is quite difficult to map that error to the batch afterwards.

Hi Chen, that is exactly my question, how does Apple archive this custom sharing flow without using Messages, Mail etc ind the Passwords App? Greetings, Johannes

I have the exact same issue. I haven't tried it yet, but I think a lookup over persisted CKRecord encodeSystemFields should work. Since you need to persist the system fields anyway, there is no extra work to do. The only difference would be that you would have to persist the system fields before telling CKSyncEngine what to do.

I have the exact same issue. I haven't tried it yet, but I think a lookup over persisted CKRecord encodeSystemFields should work. Since you need to persist the system fields anyway, there is no extra work to do. The only difference would be that you would have to persist the system fields before telling CKSyncEngine what to do.

I have not implemented it yet, but I think my concern is a logical assumption according to the way CKSyncEngine works. I'd assume that, when triggering nextRecordZoneChangeBatch(_:syncEngine:), CKSyncEngine will ensure the records that have dependencies are included in context.options.scope (CKSyncEngine.SendChangesOptions.Scope), if you put the records together when adding a pending change. I have been unable to find any information regarding how CKSyncEngine handles this. Could you please advise if there is a way to be sure about that, or if we have to guess and see if it fails in edge cases? Greetings, Johannes

@DTS Engineer Did you have time to try that out Quinn? Without a workaround or a fix, SwiftUI multiplatform apps are not really usable then.

The problem with SwiftUI multiplatform apps at the moment is that it is not possible to declare different app groups for iOS and macOS because they do not use the same app group naming scheme. @DTS Engineer Is there any solution to this?

I have exactly the same problem. According to https://developer.apple.com/documentation/xcode/configuring-app-groups, the app group name on macOS should look like this: $(TeamIdentifierPrefix)com.example.mygroup. This does solve the popup problem, but unfortunately creates another one for multi-platform applications. Because the Xcode UI does not allow you to create different app groups for different platforms, app group names that are valid for macOS are invalid for iOS and vice versa. I have not found a solution yet.

I think you miss the point of SwiftUI. The main benefit of SwiftUI is that your UI is the output of a function where the input is the state you want to display. I cannot think of a better way to solve this problem. The bad part of SwiftUI is, that it is not mature enough to replace UIKit - but it will be in some years.

As far as I understand property wrappers, the type of myProperty *is* String, and the type of *_myProperty* is Published<String>.Publisher. And since myProperty is changed, it should call didSet.