[BUG]: MacOS: System permissions and Launchpad position reset after updating

[Kurtjwest]

Describe the Bug

Very minor bug on MacOS Sequoia 15.2. PCSX2 is recognized as a new app by MacOS after updating, causing it to require the user to re-grant permissions to the app after relaunch. Also, the Launchpad position reverts to the games category as if it was downloaded for the first time (this is not typical behavior for app updates on MacOS). These are likely due to the versioned app name ("PCSX2-v2.3.110.app" vs "PCSX2.app"), and/or the metadata in the plist.

Reproduction Steps

1. Open PCSX2
2. Update App
3. Re-grant Permission to access documents folder, like when first installed
4. Find app in Games category in Launchpad, where it initially appears when first installed

Expected Behavior

1. Open PCSX2
2. Update App
3. Find app in Emulators category in Launchpad, where I had moved it before the update

PCSX2 Revision

v2.3.110

Operating System

macOS 15 (Sequoia)

If Linux - Specify Distro

No response

Logs & Dumps

No response

[TellowKrinkle]

You can try renaming the app to remove the version from the name so it keeps the same name when updating
But I suspect this might be because we don't sign PCSX2, in which case there's not much we can do about it since no one on the team wants to both pay for an Apple developer account and publish their legal name, which are both required to get the ability to sign applications

[shinra-electric]

...pay for an Apple developer account and publish their legal name, which are both required to get the ability to sign applications

You can ad-hoc sign an app with codesign --force --deep --sign - /path/to/app. This is sufficient for most use-cases.

[Kurtjwest]

You can try renaming the app to remove the version from the name so it keeps the same name when updating But I suspect this might be because we don't sign PCSX2

Manually renaming the app unfortunately does not work since it reverts to a versioned app name after an update. While I am not an experienced apple developer by any means, it is my understanding that MacOS, or at least launchpad, identifies apps by name and metadata stored in the app bundle's plist.

I could be completely wrong however, and it could all be tied to having an apple developer account, which I completely understand not being willing to pay for.

[TellowKrinkle]

Manually renaming the app unfortunately does not work since it reverts to a versioned app name after an update.

Did you try or are you just assuming it will?

[TellowKrinkle]

You can ad-hoc sign an app with codesign --force --deep --sign - /path/to/app. This is sufficient for most use-cases.

I doubt this will help. The reason they keep re-asking for perms is because they can't verify that the application you're launching is still trustworthy. (How do they make sure that a malicious app can't borrow the ID of an already-installed non-malicious app to steal its permissions?) Usually, they'd do it by saying "Well if the application changed but it's signed by the same organization that signed the version the user gave the permissions to, we'll consider that OK". But our application isn't signed, so they instead go "well we'll only grant perms if the application is identical to the one the user trusted". If we ad-hoc sign the application, what's preventing a malicious application from also ad-hoc signing their program and stealing our perms? Nothing. So I'd expect macOS to give the same level of trust as an unsigned application.

Just in case, I checked the TCC db (located at ~/Library/Application Support/com.apple.TCC/TCC.db, copy it elsewhere using finder if you don't want to grant your sqlite db viewer full disk access). You can then grab the csreq field and send it into cat binary-csreq-file | csreq -tr - to see what's stored there.
Here's one for Discord: identifier "com.hnc.Discord" and anchor apple generic and 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] = "53Q6R32WPB"
Here's an unsigned PCSX2 2.3.122: cdhash H"cc92b25e4852d4398cbfa8aedc145b5e04690de6"
Here's an ad-hoc signed PCSX2 2.2.0: cdhash H"83d8cf2069502c6a41c038d139b4f8ea135509ef"
Both the unsigned and ad-hoc signed PCSX2 are identified by an application hash, which isn't stable across updates.

As a side note, nothing in the tcc db includes the name of the app (just its bundle id), so that's likely not a factor. The name may affect launchpad placement though.

[Kurtjwest]

Manually renaming the app unfortunately does not work since it reverts to a versioned app name after an update.

Did you try or are you just assuming it will?

First thing I tried...

[TellowKrinkle]

What did you rename it to?
I just tested with a PCSX2 named PCSX2.app and it updates in place just fine.