Values not always persisted in App group between companion app & app extension

Question

From time to time, but not always (I have had this working for a bit), the app/extension gets in a state where I can't read a flag set in my App Group between my companion app and my app extension. Don't know how it gets in this state or why the values differ, but it's critical to my application these always be in sync.

Companion app viewDidLoad:

NSUserDefaults *myAppSettings = [[NSUserDefaults alloc] initWithSuiteName:@"group.myapp"];

.....

[myAppSettings setBool:true forKey:@"myBool"];

[myAppSettings synchronize];

NSLog([myAppSettings boolForKey:@"myBool"] ? @"Companion app - bool TRUE" : @"Companion app - bool FALSE");

App extension viewDidLoad

NSUserDefaults *myAppSettings = [[NSUserDefaults alloc] initWithSuiteName:@"group.myapp"];

[myAppSettings synchronize];

NSLog([myAppSettings boolForKey:@"myBool"] ? @"App extension app - bool TRUE" : @"App extension - bool FALSE");

Console output

Companion app - bool TRUE
App extension - bool FALSE

I also synchronize before my companion app will enter background. I have my app group set up in the portal etc.

What am I doing wrong?

EDIT

Apparently others having this problem too: https://devforums.apple.com/message/977151#977151

"I think that this is currently very glitchy.

Sometimes the data sharing works, then a change and all of a sudden the widget can't see the shared data anymore (both on Simulator and device).

Annoying and hope it's a bit more reliable in next beta!"

EDIT 2 Looks like another person has reported this exact issue as well:

"I also noticed the same thing too.This not only happen to the NSUserDefaults, but also all the files in the container folder. The keyboard extension suddenly will lose read/write pemission to the container folder after using the keyboard for a while."

EDIT 3 More evidence: https://devforums.apple.com/message/1028078#1028078

After I upgrade to beta 3, I noticed that sometimes the keyboard failed to open the database because it failed to access to the DB file. The keyboard has been able to access to the file before.

EDIT 4

Seems like this could be because the keyboard loses the RequestsOpenAccess flag. But I can't reproduce it, and there's no way for me to tell for sure.

EDIT 5

Seems like others are reporting this in the iOS8 GM build:

This issue still persists for me in the GM. It seems related to a keyboard crash.. but also there seems to be some contention between keyboard and containing app in terms of who creates the suite in what order. I think this problem is on Apple's end. Trust me, I WANT it to be my fault but I've spent countless hours with trial and error. No matter what I do in code and verify with NSLog, it will end up in this state eventually. Hoping someone finds a magic pill. :S

Has anyone solved this yet?

Monteria

you have this tagged as iOS 8. is the problem for that specifically? – Carvelbuilt

Yes - this deals with app extensions, which are only found in iOS 8 – Monteria

You're doing everything correctly as far as I can tell, this definitely smells like an Apple bug :[ – Garwin

I can't get this to work for a keyboard extension either, using the Gold Master Xcode & iOS 8. Very frustrating. Been testing on device and haven't seen it work once. Just tried on the simulator and it worked, but it's not very reassuring. Anybody have any luck? – Outfox

Same here as Jared Egan – Symons

I think this must be an Apple bug. Checking the iOS 8 release notes, here's what's included for keyboards. "Network access" is necessary for sharing the datastore. "Keyboards Known Issues - Network access gets disabled after adding a new keyboard from the same bundle. Custom Keyboards may go blank after app switching. Workaround: Dismiss the keyboard and bring it up again; this should reload the view." developer.apple.com/library/prerelease/ios/releasenotes/General/… – Outfox

Just a thought: Have you tried to move the App extension code into viewDidAppear or viewWillAppear? – Vesperal

Answer 1

You must request open access in order to access shared NSUserDefaults. It's stated directly in the App Extension Programming guide:

By default, a keyboard has no network access and cannot share a container with its containing app. To enable these things, set the value of the RequestsOpenAccess Boolean key in the Info.plist file to YES.

Be sure you change the RequestsOpenAccess field to YES. You'll find it in keyboard's Info.plist > NSExtension > NSExtensionAttributes > RequestOpenAccess. Then remove the keyboard in Settings, delete the app, run it again, and add the keyboard again. After you add it, tap on the keyboard name and then flip the switch to enable Allow Full Access. You'll need to instruct the users to follow those same steps to grant access (and reassure them you're not evil), otherwise it simply will not work and you'll never get the data that's stored in your shared container. Note that in iOS 8.3+, if the user hasn't enabled full access the keyboard will be able to access the shared container, but writing to it will not save the data, for security and privacy purposes. In 8.2- you can't access that data without open access granted.

Lateritious

Answer 2

I can confirm that the problem is related to RequestsOpenAccess flag. Assuming that everything done right (NSUserDefaults use initWithSuiteName, all Capabilities for main application and custom keyboard were set, etc.) I have the next steps:

1) Install the main application and a custom keyboard on device

2) Set 'Allow full access' for the custom keyboard to YES

3) Add some items (in my case this is a simple text templates) in the main app

4) Go to keyboard and check that all items, that were added from the main app, appeared in custom keyboard

5) Go to main app and add a few more items

6) Go to keyboard and now you will see that nothing changed

7) Go to settings and switch 'Allow full access' to NO and then to YES

8) Go to custom keyboard again and check that item which were added in step 5 appeared.

Faris