When is UserDefaults right, what are its limits, and native types?

WHAT THIS TESTS: This question checks whether you understand the intended scope of UserDefaults and can distinguish it from heavier persistence layers. Interviewers want to see that you know it is a plist-backed key-value store designed for small amounts of user preference data, and that you are aware of its performance, security, and type constraints. Senior candidates should also mention the threading model and the cost of automatic synchronization.

A GOOD ANSWER COVERS: First, the appropriate scenario, which is lightweight user preferences such as toggle states, last-selected tab indices, or low-volume configuration flags. Second, the native types that UserDefaults supports directly because it serializes to a property list: String, Number including Int and Double and Float and Bool, Date, Data, Array, and Dictionary, plus URL via a special method. Third, the main limitations: data is not encrypted at rest by default, there is a practical size limit often cited around one megabyte beyond which performance degrades, writes happen synchronously to disk on the main thread if you call synchronize explicitly though modern behavior is optimized, and there is no support for querying, indexing, or relational data. Fourth, the correct alternatives: Core Data or SwiftData for object graphs and querying, the Keychain for passwords and tokens, and files or cloud services for large or binary payloads.

COMMON WRONG ANSWERS: A major red flag is suggesting UserDefaults for sensitive information like authentication tokens or passwords because it offers no built-in encryption. Another is proposing it for caching images or large JSON blobs, which bloats memory and slows app launch. Candidates also err by claiming it can store arbitrary Swift structs or classes directly without encoding them to Data first, or by treating it as a replacement for a database without mentioning the lack of search and relational capabilities.

LIKELY FOLLOW-UPS: An interviewer might ask how you would store a custom struct, which requires conforming to Codable and archiving to Data. They might ask about the threading behavior, where you should note that modern UserDefaults caches in memory and writes are coalesced but that heavy usage can still impact the main thread. They could also ask how to share preferences between an app and its extension, leading to App Groups and shared UserDefaults suites.

ONE CONCRETE EXAMPLE: Suppose a news app lets users choose a default font size and a dark mode toggle. Storing these two small preference values in UserDefaults is ideal because they are primitive booleans and strings, they are read at launch to configure the UI, and they do not contain sensitive information. If the same app wanted to cache downloaded article images or store the user's subscription credentials, UserDefaults would be the wrong tool; the images belong in the filesystem cache and the credentials belong in the Keychain.