Thanks for the help.
Looks like SecItemUpdate is not affected by this issue, so we ended up with the following solution: for modifications use SecItemUpdate instead of SecItemDelete + SecItemAdd
for cleanup use SecItemUpdate with an empty data as a fallback when SecItemDelete fails
victor-pavlychko
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
From
Kyiv, Ukraine
Post
Replies
Boosts
Views
Activity
I can reliably reproduce the same issue: SecItemDelete returns errSecInvalidOwnerEdit after renaming the app bundle.
This is a rename in the Finder, right?
And the app is not running at the time you do the rename?
Yes, a simple rename in Finder is enough to break this.
Another use case is for app to copy itself under a different name using FileManager.default.copyItem(at:to:). In this case, the app is running at the moment of copying. The copy won't be able to modify any pre-existing keychain items due to the same error.
And the app is signed, right? Is this Developer ID signing?
Or is this a Mac App Store app?
The app is signed using Developer ID and notarized.