I'm having the same problem. Started with macOS13.0. I have even tried passing in the default container identifier, but it doesn't work.             [request addContact:createContact toContainerWithIdentifier: [contactStore defaultContainerIdentifier]]; If you find any resolution, please post it.

I am having the same issue. Even passing in the CNContactStore's defaultContainerIdentifier doesn't help, and I get the same the app crashes. I filed FB11724222 ... hopefully someone from Apple can look into it ASAP.

I also have the same exact issue, and the app crashes for many of my users when they add new contacts (and are running macOS13). My app is an AppKit app, so this isn't just a Catalyst issue. I filed FB11724222 for this.

I might have found a solution... previously I wasn't using the "Contact Notes" entitlements in the macOS app, only on iOS. But with macOS13, I've been getting warnings in Xcode about it, soon "Certificates, Identifiers & Profiles" from the developer portal, I added the "Contact Notes" entitlements to the app identifier and created a manual provisioning profile, then in Xcode I added the "com.apple.developer.contacts.notes" entitlement to the entitlements file, and set the new profile as the developer profile in Xcode. And now it works. Am still testing some more to confirm the fix, but it might just be that the "container assignment" error is just a misdirection.

Definitely seems like a server-side issue. I've tried many addresses that seem to fail through my (production) Mac app + through iOS app on Simulator + unit tests. But the same addresses work fine on my iOS production app. But for a few users, the problem is happening on their iOS production app (even though same exact addresses work fine for me when I try them on iOS production app). Filed feedback to help track this: FB11746682

Just wanted to add : the WWDC22 presentation "What's New with In-App Purchase" mentions that "StoreKit takes care of automatically updating the App Transaction when necessary", so I assumed this wouldn't trigger the user login prompt, and I guess I'm only seeing this because my app is running from the 'build' folder, and so it doesn't have the receipt downloaded automatically. That's my guess anyways, please feel free to add more information.

I see the same issue with some packages as well.

My issue had to do with some SPM repositories, and how they were being reset to v1.0 when set to "Exact Match" to an older version. This seems to be a bug with Xcode 15 Beta1 (FB12283412). Setting it 'Up to Major Version' from 1.0 to the last acceptable version worked for me.

Thank you for the detailed response! So I have recreated this on 3 different systems ... my own, a macOS Sonoma partition, plus my spouse's machine. In each case, I downloaded the app from the App Store (so in Release configuration), then wrote something to the keychain, then downloaded the updated app through TestFlight (again, Release configuration) and tried to access the same item. I do use the file-based keychain, since I haven't been using the kSecUseDataProtectionKeychain. In fact, part of the update is to first read the values without the Data Protection flag, and then save it again with the flag so that it can use the data protection keychain. Can you check if the TestFlight fix is still in place, or it was it overwritten? I'm using TestFlight 3.3.0, on macOS 13.4. Should I expect to run into this if I use a Developer-ID signed app (just to test if it was indeed a TestFlight issue)?

I've ran the 'codesign -d -r -' tool on both the App Store and the TestFlight builds, and there's some difference there that I don't understand: App Store: Executable=/Applications/Contacts Journal CRM.app/Contents/MacOS/Contacts Journal CRM designated => (anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists / or anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] / exists / and certificate leaf[field.1.2.840.113635.100.6.1.13] / exists */ and certificate leaf[subject.OU] = ) and identifier "com.zaal.cjournalmac" TestFlight: Executable=/Applications/Contacts Journal CRM.app/Contents/MacOS/Contacts Journal CRM designated => anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.25.1] /* exists */ and identifier "com.zaal.cjournalmac" Is this expected / unrelated to the problem, Or is there something to this that might explain the issue I'm having?

I also filed a feedback with the sysdiagnose attached: FB12482242

A couple of weeks in, and no one has replied to the Feedback I filed. I know there's no guarantees when filing these, but it really puts the brakes on any progress I can make with my development.

Some more findings: after running into this issue with the TestFlight build, I create a Developer-ID (notarized) copy of the app, export it and save it in Applications (overwriting the TestFlight build). When I run this, I don't get any prompts, and it runs as expected. if I run the app from Xcode with the debugger (using Mac Developer identity), I do run into the same prompts, but that's probably because the code signing is very different between a debug build and an App Store / DeveloperID build. So it just looks like a TestFlight issue to me. But I can't really properly confirm it myself, and I'm a bit hesitant to test it out by releasing the update on the App Store, because it would lead to a lot of problems and confusion for my users if it ended up prompting them to enter in their credentials. Your feedback here would be really valuable.

In my case, the issue turned out to be the fact that I enabled the VisionOS SDK for my main app target, but it was still set for iOS compatibility mode for all my frameworks. Changing the frameworks to also build for visionOS SDK fixed this issue for me.

Hi Quinn, Thank you for the feedback! Since my app is already in the App Store, and this is happening on an update, this isn't the option for me. But I'm planning to release it now with as 'phased update' so that it rolls out slowly, and I can directly check against my own App Store installations once it rolls out. In case there's a problem I can pause the update, that'll give me 30 days to come up with another solution. Not the best way to move forward, but I do strongly believe that this is just a TestFlight issue so it hopefully shouldn't be a problem. I'll update the thread when I get the update approved and tested. Thanks!