So, presumably we’re talking about Developer ID here?Application is not distributed via App Store.
Yes. Your signing identity is a key component in your app’s designated requirement (DR) and the DR is used by many macOS subsystems to identify your code. For example, if your app uses the keychain, the DR is stored in the ACL of any keychain item’s you create so that the system can authorise future accesses. If your app’s DR changes then the system will present an authorisation dialog to the user whenever you access the keychain item (because it can’t distinguish between this case and some other rogue app attempting to access the keychain item).So is there any problem on changing the signing certificate?
Code Block % codesign -d -r - /Applications/QProcessDock.app … designated => anchor apple generic and identifier "com.example.apple-samplecode.QProcessDock" and (certificate leaf[field.1.2.840.113635.100.6.1.9] /* exists */ or 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] = SKMME9E2Y8)
The code signing identifier (com.example.apple-samplecode.QProcessDock in this example), which for an app is typically the same as the bundle ID
The Team ID (SKMME9E2Y8 in this example)
If the app is moving between organisations that are all part of a greater organisation, you should continue using the old signing identity.
If the app is moving to a completely different organisation — for example, you sold it to another company — there isn’t a great solution. The options I can think of are a) educate your users about this problem, or b) change the bundle ID so it acts like a completely new app.