{"id":45271,"date":"2024-10-07T13:28:14","date_gmt":"2024-10-07T17:28:14","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=45271"},"modified":"2025-12-16T15:48:36","modified_gmt":"2025-12-16T20:48:36","slug":"launching-before-userdefaults-is-available","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2024\/10\/07\/launching-before-userdefaults-is-available\/","title":{"rendered":"Launching Before UserDefaults Is Available"},"content":{"rendered":"

Christian Selig<\/a> (Mastodon<\/a>):<\/p>\n

\n

It seems at some point, even though UserDefaults<\/code> is intended for non-sensitive information, it started getting marked as data that needs to be encrypted and cannot be accessed until the user unlocked their device. I don’t know if it’s because Apple found developers were storing sensitive data in there even when they shouldn’t be, but the result is even if you just store something innocuous like what color scheme the user has set for your app, that theme cannot be accessed until the device is unlocked.<\/p>\n

[…]<\/p>\n

Again, who cares? Users have<\/em> to unlock the device before launching my app, right? I thought so too! It turns out, even though Apple’s prewarming documentation states otherwise, developers have been reporting for years that that’s just wrong<\/a>, and your app can effectively be fully launched at any time, including before the device is even unlocked.<\/p>\n

Combining this with the previous UserDefaults<\/code> change, you’re left with the above situation where the app is launched with crucial data just completely unavailable because the device is still locked.<\/p>\n

[…]<\/p>\n

If you use Live Activities at all, the cool new API that puts activities in your Dynamic Island and Lock Screen, it seems if your app has an active Live Activity and the user reboots their device, virtually 100% of the time<\/strong> the above situation will occur where your app is launched in the background without UserDefaults<\/code> being available to it.<\/p>\n<\/blockquote>\n

UserDefaults<\/code> doesn’t actually report an error, and this can lead to incorrect behavior and data loss.<\/p>\n\n

Christian Selig<\/a>:<\/p>\n

It’s a really rough bug, because if you sometimes can’t trust UserDefaults<\/code>, it means you can read out data from it with the intent to modify it slightly before saving it back, only now you’re modifying junk data and overwriting the good data 🫤<\/p><\/blockquote>\n\n

Quinn<\/a> (in 2015):<\/p>\n

IMO the best way around this is to avoid NSUserDefaults<\/code> 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[…]<\/p><\/blockquote>\n\n

NSFileProtectionCompleteUntilFirstUserAuthentication<\/code> and prewarming don’t apply on the Mac, but similar problems can occur there. A common cause of support issues is that the customer has entered some data or changed a setting, and the app seems to work normally for that launch, but upon relaunch all the changes are forgotten. macOS doesn’t notify the app that the data was never saved to the .plist<\/tt> file, e.g. because of a file permissions problem or because the user tried to redirect the user defaults storage using a symlink.<\/p>\n\n

Previously:<\/p>\n