Sonoma temp folder permission alert breaks XCUITest

Question

Created Oct ’23

Replies 3

Boosts 0

Participants 2

I used to be able to test my app by making it save files to a temp folder (with a file URL created in the XCUITest runner), and then comparing them to files in the test bundle, but in Sonoma, this will issue a blocking "[App name] wants to access files from other apps" security alert, which has to be dismissed manually. This breaks the test flow.

It kind of makes sense, as I'm trying to save from the app to the temp folder of another app (the test runner.) Is there any way around this? Is there a temp folder that both applications can access without security alerts?

Answered by DTS Engineer in 769184022

It kind of makes sense

Yep. This is one aspect of the new container data protection feature of macOS 14. See the link in Trusted Execution Resources.

Is there any way around this?

I’m not sure if there’s a way around this within the XCTest space. However, you could try saving these files to /Users/Shared. AFAIK that’s still a free-for-all space.

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

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’23

Accepted Answer

It kind of makes sense

Yep. This is one aspect of the new container data protection feature of macOS 14. See the link in Trusted Execution Resources.

Is there any way around this?

I’m not sure if there’s a way around this within the XCTest space. However, you could try saving these files to /Users/Shared. AFAIK that’s still a free-for-all space.

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

0

Answer 2

Dalaplan OP

Oct ’23

Thanks!

I've also noted that the alert only seems to appear when writing to a file using the NSData writeToURL:options:error: method with the NSDataWritingAtomic option. Not with options: set to 0. Not when writing to the same "illegal" directory with the NSFileWrapper writeToURL:options:originalContentsURL:error: method or NString writeToURL:atomically:encoding:error:.

0

Answer 3

DTS Engineer OP

Apple

Oct ’23

Right. When you write a file atomically, Foundation:

Creates a temporary file.
Writes the data to that.
Moves the file on top of the previous file.

The move in step 3 is atomic so, if something goes wrong, you’ll end up with either the old file or the new file, not some mishmash of the two.

When you use a non-atomic write, Foundation opens the file and overwrites the data, which doesn’t give you that protection.

Presumably this temporary file issue is kicking in at step 1.

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

0