NSUserDefaults, is a pretty handy thing. Simply put, it’s a lightweight way of storing a little bit of data — things on the order of user preferences, though it’s not recommended to throw anything big in there. Think “settings screen,” not “the image cache” or “the database.” It’s all based up on the Defaults system built into macOS and iOS,1 and it’s a delightfully efficient thing, from the docs:
UserDefaultscaches the information to avoid having to open the user’s defaults database each time you need a default value. When you set a default value, it’s changed synchronously within your process, and asynchronously to persistent storage and other processes.
How handy is that! All the work of writing to disk, abstracted away just like that. Neat!
Now for the downside: it’s got a very limited range of types it accepts.2 Admittedly, one of these is
NSData, but it can be a bit annoying to do all that archiving and unarchiving all the time.
One solution I use is writing a wrapper on
UserDefaults. Swift’s computed properties are a very neat way to do it, and any code you write elsewhere in your project will feel neater for it.
The basic idea is this:
There you go: you’ve got an easy accessor for your stored setting.
Of course, we can make this a lot neater; we’ll start by wrapping it up in a class, and make a couple tweaks while we do that:
First, we made a variable to point at
UserDefaults.standardinstead of doing it directly. This isn’t strictly necessary, but it makes things a lot easier to change if you want to switch to a custom
Secondly, we pulled the string literal out and put in a variable instead. Again, this is more about code maintainability than anything else, but that’s certainly a good thing to be working for. Personally, I tend to wrap all my keys up in a single struct, so my code looks more like this:
That’s a matter of personal taste, though.
You might also have noticed that I made both the keys and the
UserDefaults.standardprivate — I’ve set myself a policy that any access of
UserDefaultsthat I do should be via this Settings class, and I make it a rule that I’m not allowed to type
UserDefaultsanywhere else in the app. As an extension of that policy, anything I want to do through
UserDefaultsshould have a wrapper in my Settings class, and so private it is: any time I need a new setting, I write the wrapper.
There are a few more implementation details you can choose, though; in the example above, I made the accessors static, so you can grab them with
Settings.storedSetting. That’s a pretty nice and easy way to do it, but there’s a case to be made for requiring Settings to be initialized: that’s a great place to put in proper default values.4
In that case, accessing settings could be
You could also give yourself a Settings singleton, if you like:
I don’t have a strong feeling either way; singletons can be quite useful, depending on context. Go with whichever works best for your project.
And finally, the nicest thing about writing this wrapper: you can save yourself a great deal of repeated code.
Or, if you don’t want to have a default return, make it optional, it’s not much of a change:
You can also do similar things with constructing custom classes from multiple stored values, or whatever else you need; mix and match to fit your project.
(Thoughts? Leave a comment!)
If you’ve ever run
defaults writefrom the Terminal, that’s what we’re talking about. ↩
If it matters, it’s also not synced; the defaults database gets backed up via iCloud, but if you want syncing, Apple recommends you take a look at
If you want your preferences shared between your app and its widget(s), or between multiple apps, you need to create a custom suite; each app has its own sandboxed set of defaults, which is what
UserDefaults.standardconnects to. ↩
UserDefaultsprovides default values, depending on types, but they may not be the same defaults that you want. If you want a stored
NSNumberto default to something other than 0, you’ll need to do that initial setup somewhere. ↩