Unable to test macOS apps after updating to Sonoma

I've recently updated my development laptop, and my continuous integration build nodes (a pair of Mac minis) to macOS Sonoma. Prior to this update, my CI workflows passed without issue.

Since updating, every time I attempt to run my app's unit tests, an impassible alert is shown stating:

“MyApp” differs from previously opened versions. Are you sure you want to open it?

Opening “MyApp” will allow it to access data from previously used versions of “MyApp”.

My tests go no further, and my CI workflows fail.

I found that if I switched from using Ad-Hoc code signing for my tests, that this dialog is no longer shown on my local development laptop, however it is still shown on my CI nodes.

Is there some way to tell Xcode to bypass this warning? If there's not, Sonoma doesn't seem to be usable for doing testing.

Up vote post of tonyarnold Down vote post of tonyarnold
773 views
Posted by
tonyarnold
Reply
Add a Comment

Accepted Reply

I found that if I switched from using [ad hoc] code signing for my tests

Right. macOS 14 introduced a new container data protection feature. To learn more about that, see the link in Trusted Execution Resources.

The solution here is to sign your code with a stable signing identity. For day-to-day development, that should be your Apple Development signing identity. Do this locally and on your CI system.

This isn’t a new requirement. When your code is unsigned, or ad hoc signed, macOS is unable to track the code’s identity, which can cause all sorts of weird problems. I discuss this in some detail in TN3127 Inside Code Signing: Requirements.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Replies

I found that if I switched from using [ad hoc] code signing for my tests

Right. macOS 14 introduced a new container data protection feature. To learn more about that, see the link in Trusted Execution Resources.

The solution here is to sign your code with a stable signing identity. For day-to-day development, that should be your Apple Development signing identity. Do this locally and on your CI system.

This isn’t a new requirement. When your code is unsigned, or ad hoc signed, macOS is unable to track the code’s identity, which can cause all sorts of weird problems. I discuss this in some detail in TN3127 Inside Code Signing: Requirements.

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

Posted by
eskimo
Up vote reply of eskimo Down vote reply of eskimo
Post marked as solved
Add a Comment

Thanks, Quinn! That's very informative.

For CI, someone also suggested separately that using ephemeral CI environments would also prevent this situation from triggering.

Posted by
tonyarnold
Up vote reply of tonyarnold Down vote reply of tonyarnold
Add a Comment

I might be missing something (and I'm pretty new to macOS dev ops for sure) but the Development profiles that I'm creating need to have registered device UDIDs in order to properly sign apps for testing. I'm about to start running tests in VMs using Tart and Tartelet so that I can have clean environments for each test run and I don't think I can even log in to Apple accounts in Xcode whilst in a VM let alone know what the UDIDs of fresh instances would be.

So how can I go about running tests on a Development-signed macOS app in a VM? Is this even possible? Could I use a different signing style to get this done instead?

Thanks for your help and clarification in how all these things work Quinn!

jared

Posted by
jsorge
Up vote reply of jsorge Down vote reply of jsorge
Add a Comment