Error accessing shared defaults controller under Sonoma 14.5

I’m not aware of any change in macOS 14.5 that would affect user defaults.

on a latest build on Sonoma and the most recent version of Xcode when I run the app I receive errors trying to access a plist file via a shared defaults controller which contains preferences.

What version of Xcode is that?

Does this problem only show up when you run the app from Xcode? Or does it show up when you run the app from the Finder?

Might it be tied to your user account? If you run the app from the Finder on a ‘fresh’ machine, do you still see the problem? [1]

If you take an old version of your app, one built with an older version of Xcode, does it exhibit the same behaviour on macOS 14.5?

And which OS release did this last work on? One of the macOS 14 versions? Or did you last see this work on macOS 13? [2]

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

[1] I usually use a VM for this sort of testing, so I can restore from a snapshot between each test. If you don’t have a VM set up, the next best thing is to create a new user account.

[2] This matters because were significant changes to container management in macOS 14.

I am running xCode 15.3 on Sonoma

The problem occurs both in xCode and in notarized apps distributed to customers.

A prior build on an earlier version of Sonoma (I believe 10.14.2) and the current version of xCode works fine on Sonoma 14.5 as do earlier builds.

The problem is that I receive an error indicating I cannot access the preferences file and that I need to set an entitlement user-preference-read but I cannot find this entitlement

I supplied Apple with a simple test case which just starts by attempting access to the preferences file and receives the same problem.

This is a hardened, sandboxed app as required for notarization so I need an answer as to how to set the needed entitlement or adjust the code.

This is a hardened, sandboxed app as required for notarization

That doesn’t make sense:

• Mac App Store requires App Sandbox but doesn’t require the hardened runtime.

• The notary service requires the hardened runtime but doesn’t require App Sandbox.

Applying both of these options is a good idea security-wise, but it’s not a requirement.

The problem is that I receive an error indicating I cannot access the preferences file and that I need to set an entitlement user-preference-read but I cannot find this entitlement

There are no public sandbox entitlements for accessing preferences. If you’re seeing a sandbox violation like this, something weird is happening.

What is the exact text of that message?

I supplied Apple with a simple test case

I got that, but I’m unable to build it because there’s no project file.

I was able to locate the user defaults code and it’s a pretty straightforward application of the API. Specifically, you’re using the standard user defaults, accessed via +[NSUserDefaultsController sharedUserDefaultsController]. If you’re building a typical application, something that the user double clicks in the Finder, then this should work out of the box, without any special action on your part.

It is weird that you’re using NSUserDefaultsController, rather than NSUserDefaults, but there’s nothing fundamentally wrong with that.

To investigate further I:

1. Created a new test project from the macOS > App template. This defaults to having both the App Sandbox and the hardened runtime enabled.

2. Added your +initialize method to the AppDelegate delegate.

3. Set a breakpoint at the top of that method.

4. Ran your app on my Mac (I’m using Xcode 15 on macOS 14.5) and stepped through the code.

I didn’t notice anything weird. The code seemed to work as expected and there were no weird log messages.

I recommend that you repeat this test and see what you get.

IMPORTANT Give your new test project a new bundle ID. In my case I used com.example.apple-samplecode.Test60239.

You didn’t respond to this point from my earlier post:

Might it be tied to your user account? If you run the app from the Finder on a ‘fresh’ machine, do you still see the problem? [1] [1] I usually use a VM for this sort of testing, so I can restore from a snapshot between each test. If you don’t have a VM set up, the next best thing is to create a new user account.

Did you try this? What was the result?

There’s a reason I suggested this test. I suspect that the issue you’re seeing is tied to macOS 14’s app container protection [1]. It’s possible that there’s a mismatch between your app’s container setup on disk and the way that your app is now being signed. If you start on a fresh machine, or even with a fresh user account on your main machine, you’ll start with a fresh app container. If that doesn’t have the problem, it’s a good indication of where to investigate next.

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

[1] I have a link to the WWDC session that talks about this in Trusted Execution Resources.

There are no public sandbox entitlements for accessing preferences.

Oi vey! that’s not right.

I was just reminded of com.apple.security.temporary-exception.shared-preference.read-only and com.apple.security.temporary-exception.shared-preference.read-write, described by the legacy docs. However, that doesn’t obviate this conclusion:

If you’re seeing a sandbox violation like this, something weird is happening.

You’re using the standard user defaults, which accesses its database within your app’s container, so you shouldn’t be seeing sandbox violations.

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

That is what I thought as the .plist file being used is within my container.

I took an old project which successfully built and was released in May, 2023 and also one in January 2024. Both were built using the then current versions of Sonoma and xCode. I encountered the same issue on these two old projects using xCode 15.4 and Sonoma 14.5 (there was absolutely no change to the project or other changes on the Mac, just the updates to xCode and Sonoma.

I then downloaded older versions of xCode 15.0.1, etc which were in place for those earlier builds and encountered the same problem.

So the issue is either caused by newer versions of Sonoma or some other problem on my Mac - though again nothing has been done intentionally other than updating Sonoma and xCode and there have been no system crashes since the last successful build in January.

Also, how would i try that legacy entitlement? even though it should not be relevant as the error message is indicating it is needed?

Thanks for the latest updates. However, it’s still not clear whether you actually ran the test I suggested earlier:

Might it be tied to your user account? If you run the app from the Finder on a ‘fresh’ machine, do you still see the problem? [1]

[1] I usually use a VM for this sort of testing, so I can restore from a snapshot between each test. If you don’t have a VM set up, the next best thing is to create a new user account.

This matters for the reasons I outlined in my earlier post (on 30 Jul).

how would i try that legacy entitlement?

By signing your app with the entitlement as its described in the docs.

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

Hi,

I did try what you suggested by creating a new account as I don't have a second Mac.

With respect to setting the entitlement, I know the name but do not know how I find it in xCode under the signing and capabilities tab, please specify the steps on this tab to add the entitlement

I did try what you suggested by creating a new account as I don't have a second Mac.

I presume you meant “did not” in the above.

You don’t need a second Mac to run this test. There are two options:

• The best option is to run macOS in a virtual machine. This requires some setup, but it allows you to run repeatable ‘from scratch’ testing. For example, this is how I test Gatekeeper issues, as explained in this post.

• Alternatively, you can create a new user on your main Mac in System Settings > Users & Groups. This is a more limited option. There are numerous issues where this test isn’t as a reliable as testing in a VM. However, it’s very easy to set up, and it’s should yield useful results in your specific case.

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

HI

I meant did

I setup a new account Then I copied the project onto its desktop and encountered the same issue

Then I copied the last project two projects that successfully notarized and ran (May 23 and Jan 24)

None of the above has worked

I really need to resolve this issue soon - can you provide the steps to set the entitlement you mentioned as I cannot find it on the signing and capabilities tab?

Also, I'd be willing to setup and try a VM if you can provide clear instructions as to how to do it or a post which provides such instructions in a concise manner

As I have not been able to produce a working release for more than a week. I coded around this unresolved issue and produced a working application. I then archived it and have been unable to notarize after more than 20 attempts since yesterday. I have opened another issue on this forum requesting help with notarization - If I can successfully notarize my workaround I'll no longer need a resolution to the preferences problem.

I meant did

OK.

On the VM front, honestly, I don’t think it’s worth going down that path in this case. A new user account is a fine way to test stuff like this. Just remember to delete and re-create the account each time you make a significant change.

However, just in case you want to explore this, I’m not using any Apple magic here. I use an off-the-shelf VM app and install macOS there.

If I can successfully notarize my workaround I'll no longer need a resolution to the preferences problem.

OK.

I have opened another issue on this forum requesting help with notarization

I’ll respond over on your other thread.

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

I consider this thread closed as I have coded around this. My belief is that there is a bug in Sonoma/Xcode which produces an error when none should exist (the plist file is in the container not outside it)