I'm also experiencing this same issue using UserDefaults with iOS 15. It only happens to some users and it's not easily reproducible. I'm not sure what to do because my original implementation involved writing a custom file in plist format that also stopped working reliably with iOS 15.

I need to follow up again, as although I was indeed introducing a bug to try to solve the issue, it ended up not solving the bug. UserDefaults were sometimes not being read correctly and values had become corrupted. After speaking directly to an Apple engineer, it seems that there may have been an issue with file protection upon launch: the existence of the keys was seen but their values were all 0 or corrupted object data.

I wasn't able to find any easy way to debug it. I have my own debug log wrapper that I used that holds debug text in a string, and the beta tester can use a button in-app to send it to me so that I could confirm that keys in UserDefaults were being seen but they were being read in as 0s in  application(_:didFinishLaunchingWithOptions:). I have gone back to writing my own prefs file, but this time keeping multiple backups of the file in case of corruption. I'm not sure yet if this will fix the issue as I'm still beta testing, but I'm explicitly writing the backup files with no data protection as there is no private data in there.

I thought I was reading my own comment at first because I had the exact same thing happen with my mature app (also 10 years, but updated once or twice a year). Data corrupted reading during didFinishLaunchingWithOptions most likely due to prewarming. I was not using NSFileProtectionComplete, either. The fix that "worked" for me was recommended by an Apple engineer: constantly write backup files of your settings (I'm keeping 10) and if one is unreadable, go back to the next most recent. Shamefully ugly, but I've had no new user complaints since.

I need to do this on the Simulator, so that I can track down a rare bug that seems to happen on my solar time app within 24 hours of a Daylight Saving Time change across different platforms and iOS versions.

Sorry, I got the tag wrong. UIDatePicker, iOS, Objective-C.

That's what I'm thinking -- it wasn't an issue before iOS18.

As far as the purpose, I have answered that question below in a reply.