Updating other app bundles in macOS Ventura

[zorgiepoo]

macOS Ventura, currently in beta, is introducing changes that affect external app updaters. This doesn't impact most developers; it only affects developers that develop products that update other developer's apps (or for example using sparkle-cli to update someone else's app).

Users will have to approve apps that try to update other developer's apps.

What determines "someone else's app" is if the app that does the updating and the app that is being updated have a different Team ID.

More details are in this Security & Privacy session

There is also a NSUpdateSecurityPolicy Info.plist key an app can set up to be allowed to be updated by another team ID (for example for an app that manages other apps I imagine).

I don't envision any change will need to be made here on Sparkle's end. (edit: hm, maybe except better error reporting).

[zorgiepoo]

I added changes in #2157 to report a better error when updates fail to install due to lack of write permission, both in the framework (new error code) and in sparkle-cli (with a exit status of 8). If the system is on macOS 13 or later, it will have a suggestion that Gatekeeper/security may have potential involvement here and how to allow updating if that's the case.

cc @core-code @mangerlahn for visibility on this discussion.

[core-code]

thanks for the heads-up here. i don't think it will affect Sparkle (except sparkle-cli!), but it will definitely affect MacUpdater, Latest and others. we are planning to investigate the changes ASAP and file bug-reports or TSIs if the new APIs aren't sufficient to provide an acceptable experience for our users.

[zorgiepoo]

It'll affect those who try to use Sparkle or sparkle-cli to update other's apps which indeed is not the common case.

[zorgiepoo]

Looks like in Ventura Beta 2 (22A5286j) the OS behavior changed such that a user notification alert is presented indicating that updating / moving the bundle failed, and making the user need to dismiss the notification or click on it to open up the System Settings pane where they can enable the app to make changes in the future.

Consequences currently are the first update is disregarded. One mitigation is having an onboarding process instructing user how to add their app to that pane first. If they don't do it, then the notification will remind them when an update is attempted. Other ways may involve boiling in some sort of unpleasant re-try / user-consent / timeout logic that I don't want to think much about (right now).

[core-code]

thanks for keeping us posted. definitely going to look into this in detail once i actually have some time for it. guess in july. will be happy to share anything i find.