NSUserDefaults losing its keys & values when phone is rebooted but not unlocked

Question

We are currently experiencing the following weird issue with our iPhone app. As the title says, NSUserDefaults is losing our custom keys and values when phone is rebooted but not unlocked, and this is happening on a very specific scenario.

Context:

• We are using the NSUserDefaults in the app to store user data (e.g. username).

• Our app has Location enabled on Background Mode.

• We are experiencing this issue only when distributing over the air or by Testflight. If I drag and drop the .ipa (same that was distributed over the air) into my phone using Xcode I don't experience this issue.

Situation: The user installs the app, logs in and the username is stored on the NSUserDefaults successfully. Then, the user switches OFF they device and turns it back ON and lets the phone sit around for some time before unlocking the screen.

Problem: If in that time a significant location change is triggered, the app comes to live on background but the NSUserDefaults is empty (Only has some keys from apple but none of our custom keys). Then, the NSUserDefaults never gets this keys recovered no matter what you do (e.g. if you unlock your phone and open the app you will see the keys are still missing).

Any help or idea will be truly appreciated :)

Answer 1

I was having a very similar issue. Background the application. Use other memory heavy applications till my application gets jettisoned from memory. (You can observe this event if you have your device plugged and xcode running the build. Xcode will tell you "application was terminated due to memory pressure). From here if your application is registered for background fetch events, it will wake up at some point and get relaunched but into the background. At this point if your device is locked, your NSUserDefaults will be null.

After debugging this case for days, I realized it wasn't that NSUserDefaults was being corrupted or nilled out, it was that the application has no access to it due to device lock. You can actually observe this behavior if you manually try to download the application contents via xcode organizer, you'll notice that your plist which stores the NSUserDefaults settings is no present if your device remains locked.

Ok so NSUserDefaults is not accessible if application is launched into the background while device is locked. Not a big deal but the worst part of this is, once the application is launched into the background it stays in memory. At this point IF the user then unlocks the device and launches the application into the foreground, you STILL do not have anything inside NSUserDefaults. This is because once the application has loaded NSUserDefaults into memory (which is null), it doesn't know to reload it once device becomes unlocked. synchronize does nothing in this case. What I found that solved my problem was calling

[NSUserDefaults resetStandardUserDefaults] inside the applicationProtectedDataDidBecomeAvailable method.

Hope this helps someone. This information could have saved me many many hours of grief.

Answer 2

After a while, Apple recognised this as an official bug. So we are only left with different workarounds until it's solved:

1. If you need the data while executing BEFORE the phone has been unlocked use one of the following options and set the NSPersistentStoreFileProtectionKey = NSFileProtectionNone option:

   • Save data using Core Data. (If you need to access the DB in background when the phone wasn't unlocked yet AND you don't have sensible information in it, you can add to the options Array the following option: NSPersistentStoreFileProtectionKey = NSFileProtectionNone)
   • Use the Keychain.
   • Use a .plist file.
   • Use custom made files: (e.g.: .txt with a specific format).
   • Any other way you might find comfortable for storing data.

   Choose yours ;)

2. If you don't need or don't care about the data before the phone has been unlocked you can use this approach (Thanks @maxf):

   Register to the applicationProtectedDataDidBecomeAvailable: notification and execute the following line of code inside the callback [NSUserDefaults resetStandardUserDefaults]

   This will make you NSUserDefault reload right after your phone has been granted permission to access protected data, helping you to avoid this issue entirely.

Thanks all for the help!

Answer 3

We also experienced this problem when using significant location change, on devices with pass code enabled. The app launches on BG before the user even unlock the pass code, and UserDefaults has nothing.

I think it is better to terminate the app before the synchronize occurs, because the reasons below:

• UserDefaults' synchronize should not be executed once after UserDefaults cleared by this bug.
• we can't strictly control the call of synchronize because we use many 3rd party libraries.
• the app will not do any good if UserDefaults can't be loaded (even before the user passes pass code lock).

So here's our (a bit weird) workaround. The app kills itself immediately when the situation (app state = BG, UserDefaults is cleared, iOS >= 7) detected.

It should not violate UX standard, because terminating app on background will not be even noticed by the user. (And also it occurs before the user even passes the pass code validation)

#define SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(v)  ([[[UIDevice currentDevice] systemVersion] compare:v options:NSNumericSearch] != NSOrderedAscending)

+ (void)crashIfUserDefaultsIsInBadState
{
    if (SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(@"7.0")
        && [UIApplication sharedApplication].applicationState == UIApplicationStateBackground) {
        if ([[NSUserDefaults standardUserDefaults] objectForKey:@"firstBootDate"]) {
            NSLog(@"------- UserDefaults is healthy now.");
        } else {
            NSLog(@"----< WARNING >--- this app will terminate itself now, because UserDefaults is in bad state and not recoverable.");
            exit(0);
        }
    }
    [[NSUserDefaults standardUserDefaults] setObject:[NSDate date] forKey:@"firstBootDate"];
}

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    [self.class crashIfUserDefaultsIsInBadState]; // need to put this on the FIRST LINE of didFinishLaunchingWithOptions

    ....
}

Answer 4

This is still the behavior on IOS 9.0 and has been since IOS 7.0.

I suspect that Apple will not change this, since it's a consequence of the fact that the .plist the [NSUserDefaults standardUserDefaults] loads is protected with NSFileProtectionCompleteUntilFirstUserAuthentication.

See also Why are NSUserDefaults not read after flat battery IOS7