Any more feedback on this? The sample App works as expected. But, it is only after a share has been accepted by another that I have access of MY and THEIR nameComponents. I'd like to get the User's nameComponents when my app starts that very first time and the user has accepted iCloud access. See the OP code at 'more directly' - why does that not produce a populated nameComponents? Thank you.

But, my use case is: my App starts, I require iCloud access, when try await container.accountStatus returns .available I'd like (expect?) to have access to the user's name. But I don't - the nameComponents are empty. How do I get the user's name? (See OP for what I've tried.) Thank you. /end

If, on the main screen, I tap 'Manage Shares' and then select the share and then select 'Manage Participants', the resulting Participants overlay screen shows no participants. If instead I select 'Manage With UICloudSharingController' I see both participants ('Me' and 'Owner') So, the share's participants have a PersonNameComponents value w/ the names filled in. But... /2

Long tap on the participant side brings up a contextual menu - that menu does not have a 'Participants' item, it does have 'Manage Participation'. If I tap that I see the names of the two participants with 'Me' and the 'Owner'. Fullnames are shown. If I expand 'Me' I see my phone number; if I expand 'Owner' I see their email address. /1

Also, if I recall, that sample App is the one referenced in the 'discoverability interfaces have been deprecated' documentation. I looked at it in the past and didn't see how it addresses discoverability (other than by getting another's info from the participants property in something that has already been shared).

I will check and report back. Note, in my case, I am trying to establish the User's name when the App first starts. If I have to wait until there is a share, that is a bit late. Hence my attempt at creating a 'dummyShare'. Is there a better way to establish the User's name? If is frowned upon (and hence is difficult)?

So at least my expectation was correct. #if DEBUG ... #endif does allow the Archive build to complete

Thanks. Yes, every #Preview creates a controller (to pass as an @EnvironmentObject or from which to derive the NSManagedObjectContext) - clearly create a #Preview-specific controller.

Saying Location was an example; it is a more complicated data structure, associated with a location. However, truth be told, I've not get a definitive size of the entire database. Another aspect is that locations are meant to be crowd-sourced during use of the app. Sounds like it would work to keep the data in the CloudKit .public database AND simply let it sync fully to CoreData in the App on first startup. And then track changes, which would be minor. Is that a viable approach?

And, why are there multiple .import notifications for the same store on App start (that calls loadPersistentStores(...)?

My Persistence Controller has an 'inMemory' option. How can it be invoked for a Preview?

This event is guaranteed on App startup, either with 'succeeded' or 'error', on startup for every 'storeIdentifier'? Even if no changes have occurred between App startups? That is, container.loadPersistentStores(...) for an NSPersistentCloudKitContainer produces these events?

How does CKRecord to Struct solve the problem? You cross the CK interface, providing CKRecord, CKSubscription, etc and it is that interface that you must await on. It seems your other comment "@unchecked Sendable" is the only solution? Or perhaps you could add extensions to CloudKit to define some 'shadow functions' that mark the non-sendable parameters as isolated; but, this could get tedious and won't work on returned values.