111

Is this the case? Do NSUserDefaults get reset when you submit an update to an app on the App Store, or are they reset?

My app is crashing when updated but not crashing when downloaded fully - so I'm trying to determine what could possibly be different in the updated session to the freshly downloaded session.

Cheers, Nick.

Nick Cartwright
  • 8,334
  • 15
  • 45
  • 56
  • The files in **Documents**, and **Library** will be **preserved** as the documentation claims: http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/RuntimeEnvironment/RuntimeEnvironment.html#//apple_ref/doc/uid/TP40007072-CH2-SW7 – Geri Borbás Aug 08 '11 at 10:00

6 Answers6

122

They are usually not reset unless the user deletes the app. For basic data, NSUserDefaults is the best way to save data such as preferences, dates, strings etc. If you are looking to save images and files, the file system is a better bet.

coneybeare
  • 33,113
  • 21
  • 131
  • 183
  • 5
    Is there somewhere in the Apple documentation this is mentioned? – Nick Cartwright Oct 28 '09 at 17:25
  • 1
    Sorry - I forgot to thank you for your quick answer! - If anyone can find a link to any form of Apple documentation that says this, It would be excellent.... In the documentation for NSUserDefaults it says nothing about this, so I think I had (incorrectly) assumed the defaults get wiped. This would seem the safest way for Apple to update apps surely! – Nick Cartwright Oct 28 '09 at 17:33
  • It might be the safest way, but it would be incredibly annoying for users if they had to re-set all their preferences whenever an app got updated. I generally have three or four app updates per day; I'm sure other iPhone users have even more. Wiping preferences for each update would basically make my iPhone unusable. – Kristopher Johnson Oct 29 '09 at 01:51
  • 1
    Data in the documents folder can disappear just as easily as the NSUserDefaults. They are both rare occasions, however, and have absolutely nothing to do with the normal upgrade process – coneybeare Oct 29 '09 at 02:09
  • 1
    Thanks Kristopher - and yes I agree. My problem was I had used the NSUserDefaults to store programmatic events and had relied on them being reset when the app is installed. All my testing on the iPhone device (and Apples testing) tested the app as a new install. Without any documentation or way to test as an update I was unable to repeat the update crash all our customers are now experiencing. To sum up - probably a lesson learned the hard way!! – Nick Cartwright Oct 29 '09 at 10:27
  • Is there documentation or somewhere that this can be verified? – Grant Isom Jan 11 '17 at 15:02
  • This is true for iOS but when the user delete the app for macOS. The userdefault is not reset. – Sentry.co Jun 18 '23 at 10:59
8

I beleive the answer is YES, it will persist. This also fully documented under the Application Directory chapter in the Apple iPhone OS Programming Guide.

leon
  • 1,412
  • 2
  • 17
  • 26
4
  1. Direct answer to the posted question: YES.
  2. Your problem: Your app gets crashed due to logic issues. Suppose you store an object in defaults and the app checks it's value on launch (or elsewhere). In you update you could change the way it is checked or used, e.g. you expect a value, but the object is nil, or vice versa. This may cause a SIGABRT or EXC_BAD_ACCESS.
John Smith
  • 2,012
  • 1
  • 21
  • 33
3

If you had CoreData model and you changed something in your model and update, without managing migration, thats probably reason why your app crashes on update...

Bojan Bozovic
  • 872
  • 16
  • 35
1

I have a similar experience. Our app stores a version number in Settings.Bundle/Root.Plist. This gets displayed through the iPhone Settings app. What we find is that on an Install the version number gets loaded from the app bundle - therefore the version number is correct. On an update however the version number doesn't change. This gives the impression the user is running a previous version of the app. We don't have any logic linked to the version number, it's just for display (it could be used by contact centre staff when diagnosing faults).

Our experience is NSUserDefaults doesn't get cleared when a user updates our app, but the Settings display doesn't get updated either.

Derek Knight
  • 225
  • 2
  • 9
0

Be aware of this case, when your app is running in background and you cannot access your stored values in NSUserDefaults:

Eric:

There have been many threads and bugs about this, but it's happening to me again in ios 9. I have an app that launches in the background in response to NSURLSession tasks and content-available pushes. Reproducibly, if I reboot my phone and wait for a background launch of my app to happen, then when I open the app I find that [[NSUserDefaults standardUserDefaults] dictionaryRepresentation] contains all the system values, e.g. AppleITunesStoreItemKinds, etc. but does not contain any of the values I have set. If I force-quit and relaunch the app all of my values come back. Is there any way to avoid it caching the "empty" standardUserDefaults from before the phone is unlocked, or at least to determine when they are messed up and fix them without having to force-quit the app?

Eskimo (eskimo1@apple.com):

The problem here is that NSUserDefaults is ultimately backed by a file in your app’s container and your app’s container is subject to data protection. If you do nothing special then, on iOS 7 and later, your container uses NSFileProtectionCompleteUntilFirstUserAuthentication, a value that’s inherited by the NSUserDefaults backing store, and so you can’t access it prior to first unlock.

IMO the best way around this is to avoid NSUserDefaults for stuff that you rely on in code paths that can execute in the background. Instead store those settings in your own preferences file, one whose data protection you can explicitly manage (in this case that means ‘set to NSFileProtectionNone’).

There are two problems with NSUserDefaults in a data protection context:

Its a fully abstract API: the presence and location of its backing store is not considered part of that API, so you can’t explicitly manage its data protection.

Note On recent versions of OS X NSUserDefaults is managed by a daemon and folks who try to manipulate its backing store directly have run into problems. It’s easy to imagine the same sort of thing coming to iOS at some point.

Even if changing the data protection were possible, NSUserDefaults has no mechanism to classify data based on the context in which you’re using it; it’s an ‘all or nothing’ API. In your case you don’t want to remove protection from all of your user defaults, just those that you need to access in the background before first unlock.

Finally, if any of this data is truly sensitive, you should put it in the keychain. Notably, the keychain does have the ability to set data protection on an item-by-item basis.

Source: https://webcache.googleusercontent.com/search?q=cache:sR9eZNHpZtwJ:https://forums.developer.apple.com/thread/15685

Community
  • 1
  • 1
Grand M
  • 193
  • 1
  • 8