Sparkle 2.2

[zorgiepoo]

Sparkle 2.2 brings major focus changes and improvements, flexible APIs for adding gentle reminders to the standard user interface (which background-running apps will want to check out), compatibility improvements for macOS 13 (Ventura), and a slew of other improvements / bug fixes.

[core-code]

first of all, @zorgiepoo thanks a lot for all the effort you've put into recent releases. happy to see such an essential framework picking up speed again.

unfortunately i have to say that i am not happy about Sparkle 2.2 as an app vendor. while the focus/reminder changes seem to be made with best intention especially for end-users, they aren't what we want for our app, and there seems to be no way to revert to the previous behaviour.

i want Sparkle's update to be shown immediately and in-front, just as was done with previous releases. there seems to be no way to go back this standard behaviour and there seem to be different bugs in the new implementation. what i've found so far:

• sparkle's update window is even hidden when looking for updates programmatically using checkForUpdatesInBackground! while i can understand delaying update-windows until opportune times for scheduled updates, i cannot understand why programmatic requests aren't properly dealt with...
• delaying showing alerts until applicationDidBecomeActive is wrong when the app is already active. the window only appears after switching out of the app and back again...
• checking whether an app is background using the activationPolicy may not be correct for apps that dynamically show a dock icon but still are essentially 'background apps'

apart from the bugs, i just want to be able to go back to the previous behaviours. none of the delegate methods seemed to help (*) so i hacked setUpActiveUpdateAlertForScheduledUpdate to add this for the time being....

        driverShowingUpdateNow = YES;
        activatingApp = YES;
        showingUpdateInBack = NO;

maybe this helps others who have the same issue.

[*] well, not trivially it seems. maybe something could be done by retuning NO in standardUserDriverShouldHandleShowingScheduledUpdate and doing everything ourselves? that seems too much effort though...

[core-code]

thanks! we've given up on Sparkle 2.x for the time being but will revisit this in a few months.

[core-code]

If you're unhappy with this behavior and either want to change it or want to supplement it (e.g. auxiliary indicators), there are those two delegate methods mentioned above

thanks. we've had success with Sparkle 2.3 beta, which already works a lot better than 2.2.

just for reference, here is the implementation (directly based on your help!) that seems to get back pre-2.2 behaviour:

- (BOOL)standardUserDriverShouldHandleShowingScheduledUpdate:(SUAppcastItem *)update andInImmediateFocus:(BOOL)immediateFocus
{
    return immediateFocus;
}

- (void)standardUserDriverWillHandleShowingUpdate:(BOOL)handleShowingUpdate forUpdate:(SUAppcastItem *)update state:(SPUUserUpdateState *)state
{
    if (!handleShowingUpdate)
        [updater checkForUpdates];    
}

[zorgiepoo]

On second reflection, this more accurately models pre-2.2 behavior:

- (BOOL)standardUserDriverShouldHandleShowingScheduledUpdate:(SUAppcastItem *)update andInImmediateFocus:(BOOL)immediateFocus
{
    return immediateFocus || (!NSApp.isActive && NSApp.activationPolicy != NSApplicationActivationPolicyAccessory);
}

- (void)standardUserDriverWillHandleShowingUpdate:(BOOL)handleShowingUpdate forUpdate:(SUAppcastItem *)update state:(SPUUserUpdateState *)state
{
    if (!handleShowingUpdate)
        [updater checkForUpdates];    
}

As previous versions of Sparkle didn't reactivate the app and bring the update in focus when the app was presently inactive, unless the app was a background/accessory one.

[core-code]

thanks, i've updated our implementation based on your help!

[zorgiepoo]

Fyi, I am adopting AppKit's new (macOS 14+) app activation APIs in #2409 / Sparkle 2.5 (the old activateIgnoringOtherApps: APIs are being deprecated). macOS is moving in a direction such that if it doesn't look like the user is trying to activate your app, the OS may reject that request. If what you're doing "looks like" an unexpected app switch to the OS, it may not continue to work in the future.