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)?

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.

I see the same issue with some packages as well.

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.

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

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.

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 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'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 found it by right-clicking on an item in the build results, and select "View in Timeline".

Did you ever resolve this issue? If so, how? I also see other apps that have the same exact name on iOS and Mac App Stores, even though they are separate purchases. But when I try to rename my iOS app to match the macOS version, I get the error: Name did not save because the app name you entered is already being used for another app in your account. If you would like to use the name for this app you will need to submit an update to your other app to change the name, or remove it from App Store Connect. Thanks.

I created a bug report: FB10035567 Even for a developer tool, I wouldn't expect it to crash an app just because it detected a duplicate column name. The framework already throws all sorts of parsing errors, for e.g. if you specify a 'date' column and it can't parse the input in the cell, it'll throw a failedToParse error. You can see CSVReadingError for more details.

Thanks! Yes, I was able to replicate the issue with a CSV file with duplicate column names, as well as with a CSV file with some extra empty columns. I guess the next question is how to best handle this situation, since this happen when I just load the CSV file into the TabularData framework and it just crashes the app. I'm not sure how to 'prepare' the file before loading it, to check for duplicate columns or extra columns etc. Because that would, y'know, require a CSV parsing framework like TabularData! I would actually assume that theTabularData framework would be able to handle these situations, and return an error instead of crashing completely. Is there any other error handling I can do to avoid the crash?

I found a crash report for the same issue through Xcode's Organizer. Would that help? It seems to have more detailed symbols for the TabularData framework. Attaching it here. 2022-05-20_23-41-45.6298_-0400-92c46331ffce6efc87ab9eed1aa3082179e49628.crash

Hi, Adding the full crash report. Let me know if there's anything there that helps narrow down the issue. crashreport.txt