If you’re like me, you just spent several days refactoring a framework shared between a host app and its app extension–say, a keyboard extension–into its own project and repository. You finally got everything building again, resolving all the broken framework search paths; then you got everything running again, resolving all the broken bundle paths; but now you’re seeing errors like this when you try to use UserDefaults or the keychain on a device:
2019-01-06 21:29:04.948196-0800 Keyboard[7501:295823] [User Defaults] Couldn't read values in CFPrefsPlistSource<0x163d75700> (Domain: group.com.xxxx.keyboard, User: kCFPreferencesAnyUser, ByHost: Yes, Container: (null), Contents Need Refresh: Yes): Using kCFPreferencesAnyUser with a container is only allowed for System Containers, detaching from cfprefsd
2019-01-06 21:29:04.966103-0800 Keyboard[7501:295823] [User Defaults] Couldn't write value for key test_key in CFPrefsPlistSource<0x163d75b80> (Domain: group.com.xxxx.keyboard, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access
Weird, right? You googled these errors and found just a couple of things related to sandboxing on macOS, and a bug in a beta iOS release a few years ago. You went down the rabbit hole. You tried adding entitlements to your newly standalone framework. You tried code-signing it. You tried removing and re-creating your App Group.
Then you retraced your footsteps. Started from scratch. And a couple of days into that, you realized that what you didn’t try, after cleaning your entire environment and resetting your device, was turning the keyboard Full Access setting back on.
You’re welcome.
Tweet