Unable to test macOS apps after updating to Sonoma

Question

Created Oct ’23

Replies 3

Boosts 1

Views 1.3k

Participants 3

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.

Answered by DTS Engineer in 769164022

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"

Boost

Answer 1

DTS Engineer OP

Apple

Oct ’23

Accepted Answer

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"

2

Answer 2

tonyarnold OP

Oct ’23

Thanks, Quinn! That's very informative.

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

0

Answer 3

jsorge OP

Jan ’24

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

0