In the system of iOS17, I store the login information through NSUserDefaults, but after the application is closed, I open it again, and the information stored in NSUserDefaults does not exist. I have not found the specific reason. I did not find this problem in the system before ios 17. This issue only appeared after iOS 17.
Hello :)
Can you share the piece of code to see where the problem might appear? Do you save the information locally or synchronized with CloudKit?
A few points here:
a) At this point I don't have enough information about the specifics of your app to accurately guess at what your specific issue might be. The information below is comes from my own experience, but I'd need to know more about the details of your app before I could say anything more specific. Those details include things like: basic app architecture (SwiftUI vs UIKit vs 3rd party tool), where/when you're storing the data into you NSUserDefaults, when it's being retrieved, what's missing, etc.
b) While this doesn't directly address your issue, sensitive information like login data should always be stored in the keychain, not NSUserDefaults:
Related to that point, in my experience this kind of issue is far less common with the keychain than with NSUserDefaults (more on "why" that is below).
c) I'm not aware of any issue with NSUserDefaults on iOS 17 and, more importantly, NSUserDefaults is so heavily used that any problem tends to be very visible. Whatever is going wrong here is most likely an issue in your app.
d) Related to that point, I generally help a few developers every year with issues very similar to what you're describing ("NSUserDefaults not working right on system X"). What actually causes these failures is the combination of:
A preexisting app issue which was masked by some detail of how the system managed the apps lifecycle.
The major system update changed the system behavior in a way that "unmasked" the previously hidden behavior.
Note that the kind of system "changes" I'm talking about here are often small tweaks to it's own behavior that were never formally documented, not major modifications. Changes like tuning how/when apps are launched into the background, when EXACTLY a specific API will suspend an app, changes to overall system memory load, changes to the exact sequence of operations in the view system, etc.
e) In terms of what the preexisting failure might be, I've seen a huge range of different failures, but the most common failure point is general issues with file protection, and the Default Data Protection Entitlement in particular.
The issue with the Data Protection Entitlement is that it's underlying implementation may not match most developers expectations. What it actually does is set the protection level of the directory your apps data is stored in, which is then "inherited" by all the files/directories inside your container. That is, any file/directory will be created with the protection level of it's outer container.
The unexpected piece here is that this behavior basically means that the protection level changes can extremely "sticky". That is:
The combination of those two factors means that different users running the same version of your app can have COMPLETELY different data protection configurations, depending on what version of the app you installed. This issue tends to effect NSUserDefaults in particular because while the data is stored "in a file", that's not how the API presents itself nor does it have any way to manipulate NSUserDefaults protection level.
The "classic" way this issue plays out is:
This dynamic is why these issues are less common with the keychain. The keychain API differentiates between "data doesn't exist" vs "data can't be accessed" and is also structured in a way that the possibility of failure clear.
In any case, I don't know if this is what's happening in your case, but this is the most common case I've seen.
-Kevin Elliott
DTS Engineer, CoreOS/Hardware