Some debugging results that feel like they matter: If the extension doesn't have the Family Controls entitlement then any attempt to access values returned by ManageSettingsStore() fails with a sandbox error. This seems as it should be. However, if you have the entitlement, this code: logger.debug("num apps blocked before reset: \((store.shield.applications ?? Set()).count)") will accurately return the number of blocked apps when run from the app. But if this same code is run from the extension it always prints that 0 apps are blocked. So we are left with a weird world where ManagedSettingsStore returns something that allows for some kind of access, but the returned store doesn't reflect the same state available in the main app.

This still appears to be broken as of 15.3

As of at least Xcode 13.2.1 I can at least add the extension in the normal way with a template (Device Activity Monitor Extension) and I get a target setup for me with sample code. Previously I had to use another extension template and modify the build by hand to give it the correct entitlement and NSExtensionPointIdentifier. The downside is that the running behavior is exactly the same. From a fresh install onto a device I can get the extension to run, but it can't correctly retrieve the current set of shields and setting the shields to null using the same code that works in the main app does nothing. So far as the extension seems to be concerned ManagedSettingsStore().shield.applications is always nil.

vova085 was right. I was trying to do some of the blocking/unblocking from within the app and some of the blocking/unblocking from the extension and that... doesn't work. I claim that it probably ought to work given that you can't have more than one app with permission to modify shields/blocks on any given device, but it doesn't. Changing my code to only communicate changes to the extension via CoreData/CloudKit and making all permission changes from callbacks there fixed the issue.

You have a function definition there rather than a function call. In the function definition you need to write the type of the thing you expect (Int) rather than any specific instance of that type (4). Later, when you call the function you have written you'll pass in 4.

One followup. Resetting the dev environment stops the errors (unsurprising), but the errors reappear as soon as any record is shared (surprising). I say surprising because the shared record hasn't been modified, so maybe this has something to do with sharing rather than synchronizing?

I'm almost certain that recordName refers to a CKRecord object that has a CKRecord.ID field, within which is the recordName. I haven't managed to work out what could be generating such a name. It doesn't match any obvious (to me) encoding scheme, and it would be really weird to try to encode real data in the name field. I can say with less confidence (but still some) that it doesn't happen on all devices. I have devices in the wild that have never seen an issue, and I have one device that sees it very reliably.

Getting the entitlement permission was quick and painless for me (a few days wait?). Releasing on the other hand, has been a consistent nightmare. My hunch is that the testing people don’t have the right tools or script to handle releases. But I’ve gotten all sorts of strange requests and rejections that read like the person on the other side didn’t even know that Family Controls were a thing.