Thanks for being a part of WWDC25!

How did we do? We’d love to know your thoughts on this year’s conference. Take the survey here

NSUserDefault issue after upgrading to iPadOS 17.7.7

Our app needs to read server settings that are configured in the app's settings. In iPadOS 17.7.7 specifically (iPadOS 17.7.6, iPadOS 18.5, and other versions works fine) one can't retrieve any setting from the settings bundle using:

if ([[NSUserDefaults standardUserDefaults] objectForKey:@"setting_hostname"] != nil)
        serverHostname = [[NSUserDefaults standardUserDefaults] objectForKey:@"setting_hostname"];

Also, when writing a custom value in NSUserDefaults like:

    [[NSUserDefaults standardUserDefaults] setObject:@"Test" forKey:@"test"];
    [[NSUserDefaults standardUserDefaults] synchronize];
    NSString* test = [[NSUserDefaults standardUserDefaults] objectForKey:@"test"];
    NSLog(@"%@", test);

Shows an error in the console:

Couldn't write values for keys ( test ) in CFPrefsPlistSource<0x3017ecc60> (Domain: <redacted_bundle_id>, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): setting these preferences requires user-preference-write or file-write-data sandbox access

When closing the app and reopening it, and then reading the value of [[NSUserDefaults standardUserDefaults] objectForKey:@"test"]; returns null

Answered by DTS Engineer in 840189022

Following up on this, yes, this issues is fixed in iOS 17.7.8.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I don’t have any concrete info to share right now, but I just wanted to make a quick post to let folks know that:

  • We’re aware of this issue.

  • We’ll update this thread once we know more.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

I noticed it (incorrectly) thinks there's a sandbox access violation only when you write but not when you're trying to read (according to the console logs) so its bizarre that it still fails to read the values that were written in a previous OS version that didn't have this issue.

Following up on this, this is a known bug (r.151313939) caused by a security fix that is validating access against the wrong process sandbox.

As a bit of background on this point:

I noticed it (incorrectly) thinks there's a sandbox access violation only when you write but not when you're trying to read (according to the console logs) so its bizarre that it still fails to read the values that were written in a previous OS version that didn't have this issue.

The log message is misleading. The issue isn't actually about your apps access to those files, it's about other processes (in this case, cfprefsd) access to the files in your sandbox. All access is being blocked (so cfprefsd can't read the file either), but difference in how the read flow works mean that the read failure isn't being explicitly flagged as a sandbox violation in the way the write case is.

In any case, I can't provide specifics about how/when the issue will be addressed, but the problem is obviously quite serious and being very actively worked on.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

solved with 17.7.8 today

Following up on this, yes, this issues is fixed in iOS 17.7.8.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

NSUserDefault issue after upgrading to iPadOS 17.7.7
 
 
Q