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.
Chinchin69
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
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.
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.
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?
@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.
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
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.
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
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.