NOTE: I have seen many other posts on Stack Overflow about NSUserDefaults
being renamed to UserDefaults
in Swift or not working on simulator until a restart. This is not a duplicate by anyway. Many of the questions SO is tagging against is from 4 years ago. My question is specific to iOS 10 from this year as this has always worked in older versions. I have mentioned in my question already that my question is not a duplicate of those questions as those were simulator bugs in swift and my issue is on device objective C bug. Please read the questions before marking as duplicate
My issue is different as I am able to reproduce this on objective C and on physical device itself.
I created a brand new project from scratch for this test. I placed this code in the viewDidLoad
of a view controller:
if (![[NSUserDefaults standardUserDefaults] valueForKey:@"checkIfInitialized"]){
NSLog(@"setting checkIfInitialized as not exist");
[[NSUserDefaults standardUserDefaults] setValue:@"test" forKey:@"checkIfInitialized"];
[[NSUserDefaults standardUserDefaults] synchronize];
self.view.backgroundColor=[UIColor redColor];
self.mylabel.text=@"NSUserDefaults was NOT there, try running again";
} else {
NSLog(@"checkIfInitialized exists already");
self.view.backgroundColor=[UIColor blueColor];
self.mylabel.text=@"NSUserDefaults was already there this time, try running again";
}
Now if I run the app about 10 times, few times it finds the checkIfInitialized
and sometimes it doesn't. No exact number on how many times it fails as it might work 3 times then fail next 2 times then work 4 times and fail once and so on.
Now something I have noticed (not 100% sure though) that the issue only seems to happen when I am testing connected via Xcode. If I run by launching the app by clicking the app icon on device without Xcode, then it seems to work fine but I can't be 100% sure.
I noticed this error occur sometimes:
[User Defaults] Failed to write value for key checkIfInitialized in CFPrefsPlistSource<0x1700f7200> (Domain: com.xxxx.appname, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null)): Path not accessible, switching to read-only
I have this very simple project on my dropbox if you want to test it out. I would suggest testing about 10-15 times to reproduce this issue.
https://www.dropbox.com/s/j7vbgl6e15s57ix/nsuserdefaultbug.zip?dl=0
This works completely fine on iOS 9 so definitely something to do with iOS 10.
EDIT Bug logged: 28287988
Response from apple DTS team:
First off, you should first determine whether standardUserDefaults or valueForKey is failing. My guess is that “standardUserDefaults” is returning NULL and, if that’s the case, then that’s something you should be guarding against generally. Notably, standardUserDefaults will return NULL if the preference file is encrypted in the environment the app is currently running in (for example, preferences is set to “NSFileProtectionComplete” and the app is running in the background). That shouldn’t be an issue for standard foreground-only apps, but it’s something to be aware of anyway.
It’s very likely that Xcode is actually inducing the problem here. Xcode vastly complicates the app launching environment in a way that’s VERY different than a standard app launch. My guess is that this is basically being triggered by Xcode’s timing inducing an an expected situation during the app launch, but if you want a more formal test of that try setting a single breakpoint in applicationDidFinishLaunching and continuing in the debugger as soon as you hit it. My guess is just adding that disrupts the timing enough to stop the problem from happening. Sort of. It’s iOS 10 only in the sense that iOS 9 will never print that log message, but that’s because the log message was added in iOS 10. The code itself is similar enough to iOS 9.3 that I suspect exactly the same behavior is (at least in theory) possible in iOS 9.
Yes, this is definitely a reproducible bug.
The bug happens on devices and on the Simulator. It is intermittent: saving will work six times and then fail. Unlike you, I did not get the "failed to write key" message.
The bug also occurs when operating directly on the device without Xcode. This is in fact how I discovered it.
You should report a bug to Apple, especially since you have a short program that will reproduce it. I will do the same.
One key difference: In my case the failure is in writing the default. The previously written value remains in NSUserDefaults. Sometimes one key is successfully written while another is unchanged.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With