When and why should you use NSUserDefaults's synchronize() method?

Solution 1:

There seems to be so much confusion about user defaults. Think of it this way. It's essentially the same as you having a global dictionary available throughout your app. If you add/edit/remove a key/value to the global dictionary, that change is immediately visible anywhere in your code. Since this dictionary is in memory, all would be lost when your app terminates if it wasn't persisted to a file. NSUserDefaults automatically persists the dictionary to a file every once in a while.

The only reason there is a synchronize method is so your app can tell NSUserDefaults to persist the dictionary "now" instead of waiting for the automatic saving that will eventually happen.

And the only reason you ever need to do that is because your app might be terminated (or crash) before the next automatic save.

In my own apps, the only place I call synchronize is in the applicationDidEnterBackground delegate method. This is to ensure the latest unsaved changes are persisted in case the app is terminated while in the background.

I think much of the confusion comes from debugging an app during development. It's not uncommon during development that you kill the app with the "stop" button in the debugger. And many times this happens before the most recent NSUserDefaults changes have been persisted. So I've developed the habit of putting my app in the background by pressing the Home button before killing the app in the debugger whenever I want to make sure the latest updates are persisted.

Given the above summary, let's review your questions:

should it be called every time the user changes the app's settings?

No. As described above, any change is automatically available immediately.

Or should I just trust that the background api is going to handle that?

Yes, trust the automatic persistence with the exception of calling synchronize when your app enters the background.

And does the leaving of the view immediately after a settings change in memory result in that change being lost?

This has no effect. Once you add/edit/delete a key/value in NSUserDefaults, the change is made.

Also, when might a failure to call synchronize() result in user settings not getting changed correctly?

The only time a change can be lost is if your app is terminated before the latest changes have been persisted. Calling synchronize when your app enters the background solves most of these issues. The only remaining possible problem is if your app crashes. Any unsaved changes that have not yet been persisted will be lost. Fix your app so it doesn't crash.

Furthermore, what is the cost (performance, memory or otherwise) of calling this method? I know it involves reading and writing from/to the disk but does that really take that much effort on phones?

The automatic persistence is done in the background and it simply writes a dictionary to a plist file. It's very fast unless you are not following recommendations. It will be slower if you are misusing NSUserDefaults to store large amounts of data.

Solution 2:

UPDATE

As anticipated, it has been deprecated as mentioned in Apple Doc

synchronize()

Waits for any pending asynchronous updates to the defaults database and returns; this method is unnecessary and shouldn't be used.

Original Answer

-synchronize is deprecated and will be marked with the NS_DEPRECATED macro in a future release.

-synchronize blocks the calling thread until all in-progress set operations have completed. This is no longer necessary. Replacements for previous uses of -synchronize depend on what the intent of calling synchronize was. If you synchronized…

— …before reading in order to fetch updated values: remove the synchronize call

— …after writing in order to notify another program to read: the other program can use KVO to observe the default without needing to notify — …before exiting in a non-app (command line tool, agent, or daemon) process: call CFPreferencesAppSynchronize(kCFPreferencesCurrentApplication)

— …for any other reason: remove the synchronize call

Solution 3:

Apple's documentation for synchronize() has been updated and now reads:

Waits for any pending asynchronous updates to the defaults database and returns; this method is unnecessary and shouldn't be used.