I have an application that implements Today extension. Till iOS10 it was working fine, but now I see that it can't read keys stored in shared NSuserDefaults.
My Host app code:
NSUserDefaults *sharedPrefs = [[NSUserDefaults alloc] initWithSuiteName:kSharedGroupIdentifier];
[sharedPrefs setObject:username forKey:#"username"];
[sharedPrefs setObject:#"Test" forKey:#"test"];
[sharedPrefs synchronize];
My extension code:
NSUserDefaults *sharedPrefs = [[NSUserDefaults alloc] initWithSuiteName:kSharedGroupIdentifier];
NSString *str = [sharedPrefs valueForKey:#"test"];
And str var is always nil in extension. I have set up my App Groups in Capabilities for both Host app and extension app, and I have checked it against the settings on Apple developer portal. It is all OK. Can anyone please help, is there something different that I must do?
EDIT
Another thing that I have noticed is that I have a red exclamation mark on: "Add the Add Groups entitlement to your entitlement file", and when I fix the issue, the exclamation mark goes away, but when I close and reopen project it is there again. I have recreated provisional profiles, but still the same issue
It sounds like the issues is that your Entitlements file is missing the relevant line.
To diagnose where the issue is, start with your build settings:
Under Code Signing Entitlements there should be a file listed
Open that file and ensure that it has the App Groups key with the value that matches your kSharedGroupIdentifier
Ensure that the file is not marked read-only (this would potentially cause the "fix" to not work correctly)
Verify that all of the following match:
kSharedGroupIdentifier in both apps
kSharedGroupIdentifier and the value in your entitlements file for App Groups
Next, we can narrow the issue down to the specific key or the entire preferences domain as follows:
NSUserDefaults *sharedPrefs = [[NSUserDefaults alloc] initWithSuiteName:kSharedGroupIdentifier];
if (sharedPrefs == nil) {
NSLog(#"Error loading shared user defaults!");
}
A nil value indicates that the suite name is invalid.
Rebooting the mac solved the issue for me.
Apple RNotes WWDC Seed: Running multiple iOS simulators can cause NSUserDefaults to not work Running an iOS 8 or 9 simulator followed by an iOS 10 simulator will cause NSUserDefaults to stop working in the simulator. This can be worked around by rebooting the host Mac.
I hope it will helps you,
Thanks.
I've updated my Xcode 8 to beta 2 today and I'm trying to share data between App and Today Extension. I'm facing with this log warning:
2016-07-08 18:00:24.732472 ProjetctX[941:42801] [User Defaults] Failed
to read values in CFPrefsPlistSource<0x1700f1280> (Domain:
group.x.p.t.o, User: kCFPreferencesAnyUser, ByHost: Yes, Container:
(null)): Using kCFPreferencesAnyUser with a container is only allowed
for System Containers, detaching from cfprefsd
Anyone can help me?
This is actually a spurious warning that was introduced in iOS 10 and macOS 10.12:
NSUserDefaults tip: in the current OSs there's a logged error "…with a container is only allowed for System Containers…".
This is spurious.
Trying to catch a particular failure mode, caught a normal operation case at the same time.
My successor on UserDefaults also has not figured out a way to make this less alarming without making the symptomatic case impossible to debug :/
https://twitter.com/Catfish_Man/status/784460565972332544 [thread]
The advice of prepending your team ID will silence the warning, but will also create a new empty user defaults. This will result in any previously stored data being unreadable.
For the time being, the solution is just to ignore it.
Also, Apple staff member CFM on the forums:
The logged message is spurious unless you're doing very specific things that I don't think are possible without using private functions (it was added to catch misuse of those functions, but unfortunately also caught a normal usage case).
Here’s how to use UserDefaults with App Groups to pass data between your main app and your extension:
In your main app, select your project in the Project Navigator.
Select your main app target and choose the Capabilities tab.
Toggle the App Groups switch to ON. This will communicate with the
Developer Portal in order to generate a set of entitlements.
Create a new container. According to Apple, your container ID must
start with "group", so a name such as "group.io.intrepid.myapp" is
perfect.
Select your extension target and repeat the process of enabling App
Groups. Do not create a new App Group, simply select the group that
was just created in the main app target.
When reading or writing UserDefaults in either your app or your
extension, do not access UserDefaults.standard.
Instead use UserDefaults(suiteName: "group.io.intrepid.myapp").
Note: The suite name is the name of your App Group container created
in Step 4.
Make sure, group enable and using same group id for both extension and app capability section!
Credit goes to http://blog.intrepid.io/ios-app-extensions
Change you group name in Xcode entitlements from:
group.com.mycompany.myapp
To
group.MYTEAMID.com.mycompany.myapp
ps: you can find your MYTEAMID in developer.apple.com membership
The solution for me was to not use the same identifier for the application Bundle Identifier and the part after "group.".
Say, the app bundle id is "com.app.id", then group id as "group.com.app.id" is causing issues. After I change it to "group.com.app.id.something" it stops.
Also had same issue with my macOS app.
Solved it by: Reboot the device!
https://stackoverflow.com/a/39876271
The SuiteName (postfix) must not be the main Bundle ID.
I’m facing this same issue when I’m trying to use initWithSuiteName. Seems that this is a bug from Apple.
The only solution / workaround I found is to reset all the settings of the device.
Go to Settings -> General -> Reset -> Reset All Settings.
This doesn’t erase any content on the iPhone, just erases all the settings.
After resetting the setting, everything worked fine. Let me know if it helps you too.
Build with Xcode 8.1 Beta and you will see the same warning, but you will also get the value.
By default, if you are using the Settings.Bundle/Root.plist for displaying and editing your app preferences via Apple Settings App, it uses the UserDefaults.standard dictionary.
So if you are using App-Groups and you want to share this defaults / settings within your apps and extension, you need to change the container of your settings.
Step 1: Open your Settings.Bundle -> Root.plist
Step2: Add the key ApplicationGroupContainerIdentifier and as value set your App-Group-Id, defined in your Signing & Capabilities: Looks like group.xx.yy
After you have implemented this step, the default container for your App-Settings will now switch from UserDefaults.standard (your apps Path) to the Shared Path.
Set by example
NSUserDefaults *userDefaults = [[NSUserDefaults alloc] initWithSuiteName:#"group.com.xxx.xxx"];
[userDefaults setValue:#"value" forKey:#"key"]
[userDefaults synchronize]; // return maybe false, but it doesn't matter
Get by
NSUserDefaults *userDefaults = [[NSUserDefaults alloc] init];
[userDefaults addSuiteNamed:#"group.com.xxx.xxx"];
NSString *value = [useDefaults valueForKey:#"key"];
Although the same error will still be printed when setting, the value is indeed set and can be read correctly. But I don't know why this is happening, it's just the result of various attempts.
if you suffer this problem when you try to save data to extension APP by using userDefault, maybe you had written this code:
[[NSUserDefaults standardUserDefaults] initWithSuiteName:#"group.xxx.com"];
This code reset default userDefault.
Actually,the correct code is:
[[NSUserDefaults alloc] initWithSuiteName:#"group.xxx.com"];
http://www.jianshu.com/p/e782104c3bc3
Change from
[[NSUserDefaults alloc] initWithSuiteName:#"group.com.xxx.xxx"];
to
[[NSUserDefaults alloc] initWithSuiteName:#"nnnnnnnnnn.group.com.xxx.xxx"];
Where nnnnnnnnn is your team number, the one which you use to sign your code.
Tested under Xcode 8 GM and iOS 10 GM, and worked!
My app has the following targets:
iOS App
Today Extension
Apple Watch App
Apple Watch Extension
All of these targets have the "App Group" capability with the correct group selected. In the main iOS app, I synchronize the settings like so:
NSUserDefaults * sharedDefaults = [[NSUserDefaults alloc]initWithSuiteName:#"group.foo.bar"];
if([sharedDefaults respondsToSelector:#selector(setObject:forKey:)]){
// Example Value
[sharedDefaults setObject:#"TestString" forKey:#"TestString"];
[sharedDefaults synchronize];
}
The Today Extension uses the following to get the settings, which works just fine:
NSUserDefaults * defaults = [[NSUserDefaults alloc] initWithSuiteName:#"group.foo.bar"];
NSLog(#"String: %#", [defaults stringForKey:#"TestString"]);
// String: TestString
The watch extension uses the same line of code to get the settings as the today extension, however it does not work. In the console I see String: (null). What am I doing incorrectly?
Did you create your watch target as a watchOS WatchKit Application (watchOS 2) or as an iOS Application Extension (watchOS 1)? If targeting for watchOS 2, according to the transition guide: You cannot rely on a shared group container to exchange files with your iOS app. Fetching files involves transferring them wirelessly to Apple Watch.
Please refer to settings bundle not working on watchOS 2 Apparently the docs are not that clear on what can and cannot be done with Preferences, the only way I found was to ensure that I copy the required user defaults over and keep them synced manually (NSUserDefaults not working on Xcode beta with Watch OS2).
in iOS7 [[NSUserDefaults standardUserDefaults] objectForKey:#"AppleLanguages"] gave me an array of all languages. as of iOS8 this seems to have changed to the installed keyboards.
how can i still get an array of all languages in iOS8?
Use +[NSLocale preferredLanguages] instead of querying NSUserDefaults. Note that as mentioned in the Xcode 6.1 release notes, there is a known bug in the iOS 8.1 simulator runtime that prevents this from working there, but this will work as expected on other simulator versions and on device.
If you want a list of all supported languages rather than just the user's preferred ones, you can use +[NSLocale availableLocaleIdentifiers] which will return an NSArray of all supported locale identifiers.
We have an iOS app that has been released. The IDE is XCode6. I want to add keychain sharing to access the sessionID that exists in the app from an iOS 8 share extension.
Problem is whenever keychain sharing is turned on, the sessionID that already exists can no longer be accessed.
It can be accessed whenever keychain sharing is turned off.
This dictionary is passed into SecItemCopyMatching, which always returns -25300 (not found) whenever keychain sharing is enabled, no matter what the "Keychain Groups:" is.
[0] (null) #"svce" : #"SESSION_ID_KEY"
[1] (null) #"r_Data" : #"1"
[2] (null) #"m_Limit" : #"m_LimitOne"
[3] (null) #"class" : #"genp"
[4] (null) #"acct" : #"SESSION_ID_KEY"
[5] (null) #"pdmn" : #"ck"
Any idea why access to the key might not work? I tried setting kSecAttrAccessGroup with the bundle prefix and name and it still did not work on the simulator.
Hopefully I got your answer and the bounty :)
I had the same issue originally and came across this post, and I know you mentioned you tried with the bundle prefix and name. But let's run through a sanity check.
In the MyApp.entitlements and in MyApp Extension.entitlements I have the Keychain Access Groups set to $(AppIdentifierPrefix)com.company.MyApp (this is the default).
I accessed the value for ABCD1234 (aka AppIdentifierPrefix value) using this SO answer https://stackoverflow.com/a/20340883 however hardcoding may not be best practice here, so consider looking this a solution like this https://stackoverflow.com/a/11841898/2588957
Then note in my app all I added to make my current code to work is the following:
[keychainItem setObject:#"ABCD1234.com.company.MyApp" forKey:(__bridge id)kSecAttrAccessGroup]; before updating the item and I can now access the keychain item in my share extension.
I had a similar issue when implementing inter-app communication in iOS 7 a couple of months ago.
I found this remark on Apple's GenericKeyChain sample project:
// Apps that are built for the simulator aren't signed, so there's no keychain access group
// for the simulator to check. This means that all apps can see all keychain items when run
// on the simulator.
//
// If a SecItem contains an access group attribute, SecItemAdd and SecItemUpdate on the
// simulator will return -25243 (errSecNoAccessForItem).
So if you're testing on a Simulator you need to remove the "kSecAttrAccessGroup".
On a device it should work with this key.