First-time launch of updated apps on Sequoia launching the old / replaced and not the newly downloaded app version

[core-code]

Sorry for posting something here that is clearly not a bug in Sparkle, but we noticed some extremely disturbing behavior in Sequoia that Sparkle (using) developers should be aware of. So this is for the record.

It seems like Sequoia basically breaks Sparkle's functionality of actually (re-)launching the updated app after the update.

More specifically, it seems that when an app is updated via Sparkle on Sequoia, the first run of the updated app will be "broken", i.e. the old and not the updated app will be executed. Whether this only affects the executable code or also the other app resources i don't know. Also it is unknown if the issue is only triggered when an app is updated via Sparkle or whether there are other ways to trigger the issue.

To make matters worse if crash-reports are produced for those "broken first runs", the crash report will list the updated version numbers, while in fact the old (removed) app version was executed!

This means you can no longer trust the crash-logs of a Sparkle using app that was executed on Sequoia. The crash might have happend with old code from the previously installed version while the crash logger already lists the new version numbers.

We have received dozens of those "fake" crash reports...they list a crashing symbol that is not even contained anymore in the version of the app that has allegedly been launched.

We've filed this with Apple as FB://FB15898887

I'll post here when Apple claims that the issue is resolved.

Things that would be interesting: a.) finding a way to reliably reproduce the issue and b.) finding a workaround to prevent the issue e.g. by forcing cache invalidation.

Since this is not actually a bug in Sparkle but an(other) macOS bug feel free to close this at any time.

[zorgiepoo]

For this kind of suspected issue I'd try putting some code early on in main() or earlier (e.g. via __attribute__((constructor))), don't rely on NSBundle / nib loading which happens later. It could technically be possible Sparkle could execute the old app before swapping but it shouldn't happen. I cannot reproduce the issue as well. Another possibility is if the user or something on their system launches the app before Sparkle finishes the installation (i.e swapping bundles) but this is very unlikely, or if multiple instances of the app were running before. Anything on Sparkle's end shouldn't be a "new" issue..

For the feedback issue to Apple, if not already you should probably attach a full crash report and copy of the correct/new app bundle (and perhaps also the old version if you know which one was launched). Actually, that may be useful for me to check too here.

Since this is not actually a bug in Sparkle but an(other) macOS bug feel free to close this at any time.

Moving to Discussions for now.