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.

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