@MODWorld You are using the old, deprecated function which never returns PHAuthorizationStatusLimited - it returns PHAuthorizationStatusAuthorized even if the user only gave limited access, for backward compatibility. You need to use the new +requestAuthorizationForAccessLevel:handler: method.

This is happening with full access too. And even if you rename the album after the initial 1 or 2 character long title, the app will keep crashing. I am getting the error either on accessing _title1 or _title2 in the following snippet (whichever should have the short, 1-2 char long, name): NSComparator albumNameComparator = ^(id _title1, id _title2) {     /* Do literally anything with _title1 and _title2, one of them will report EXC_BAD_ACCESS if either of them is the 1-2 char long title. */ }; NSSortDescriptor *titleSortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"localizedTitle"  																																	   ascending:YES                                      																comparator:albumNameComparator]; NSArray *sortedArray = [assetCollections sortedArrayUsingDescriptors:@[titleSortDescriptor]]; After debugging by using a custom comparator in +[NSSortdescriptor:sortDescriptorWithkey:ascending:comparator] I see that the issue is that when you have a short name, your localizedTitle is not of type _PFResultASCIIString (e.g memory address is \_title2 _PFResultASCIIString * 0x11b63a878 0x000000011b63a878), instead it is of type id with an invalid memory address (e.g. \_title1 id 0x9fc0bd70f2930dde), so you get an EXC\_BAD\_ACCESS error. This is faulty on Apple's side, and a timely fix is much needed. It is 100% reproducible. You delete the album that had initially 2 characters long title, and the issue goes away. You create another one with two characters, the issue is back.

Thank you Quinn for your answer and the confirmation. Reading your post again ("Packaging Mac Software for distribution"), I realized that the Mac Installer Distribution certificate will not show up with security find-identity -p codesigning because it is not a code signing certificate. I removed the -p part and then it listed the certificate as CSSMERR_TP_CERT_EXPIRED. I'm hoping this will fix the issue, but this forum question has been answered. Thanks again!

Hi, I have just found this thread, and I am an XPC/daemon developer (for an authorization plugin, which is also important here), so I cannot move to data protection keychain. Our flow has been the following: Create a keychain item in System keychain in the daemon: SecTrustedApplicationCreateFromPath to create trusted app references for all variations of authorizationhost and SecurityAgentHelper. SecAccessCreate to create a SecAccess item that includes all SecTrustedApplications from above. SecItemAdd / SecItemUpdate to save the item with this SecAccess instance added to the attributes dictionary: [kSecAttrAccess as String: access] This is all working fine. But then, if I were to Delete this keychain item in the daemon: SecTrustedApplicationCreateFromPath to create trusted app references for all variations of authorizationhost and SecurityAgentHelper. SecAccessCreate to create a SecAccess item that includes all SecTrustedApplications from above. SecItemDelete to delete the item with this SecAccess instance added to the attributes dictionary: [kSecAttrAccess as String: access] I get the above mentioned errSecInvalidOwnerEdit error. What I noticed is that if I add the daemon itself as another SecTrustedApplication to the SecAccess that is created, then the issue is solved. Why can I create and update an item from the daemon, but not delete, if it was the daemon that created the keychain item previously, in another invocation? Is this an expected behavior?

Thank you Quinn for your response! I just wanted to come back and reply to myself because I have just found the solution - then I saw your reply and it is exactly what was needed :) I first came to realize that my ACL is actually incorrect deep down because of the partition_list part (security dump-keychain -a path/to/keychain helped me figure this out). It only included the apple-tool: partition (I am creating the keychain items as a pre-run script of the target). Then I found the set-generic-password-partition-list command, the one you suggest. Changing the partition list to apple-tool:,teamid:[my_team_id] solved the problem and the prompt no longer comes up.

Based on the open-source code (this make()method is called in SecKeychainCreate()) I understand this must come from either The preference domain being set to the system domain over the user domain, but I don't understand how this could happen, given that there isn't a security command-line-tool equivalent for SecKeychainSetPreferenceDomain(). or the user having wrong settings for $HOME or passwd->pw_dir, but we did check these and they seem to be correct.

How are you running this script? From Terminal? It's a shell (bash) executor on a GitLab runner. I don't know if that qualifies as a yes or a no answer here. However it hadn't been showing differences to local Terminal-executed commands so far.