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.