Is it possible to customize the Update Available window view?

[peternowell]

I would like to make some cosmetic changes to the window that appears when an update is available. For example, I include release notes HTML and I would like to modify the dimensions and style of web view and some related things. Is there a way to access the view controller from my Swift app, to make these adjustments? Or can/should I create a subclass of the current view controller and assign it to Sparkle somehow?

[zorgiepoo]

There's a private API to access the updater alert's window controller (discussed here) which would allow you to traverse through the view hierarchy. Naturally, this is a more fragile path prone to breaking in the future if any of the UI changes later on.

Other options are contributing changes if you think some of the changes you want to make would be a benefit/enhancement to everyone or others. If they are only specific to you, I don't recommend this however. Another option is forking Sparkle which may make it more difficult to update later.

Another bigger option is using your own custom UI entirely. This has the downside of needing to take care of a lot of details yourself that are otherwise considered by Sparkle's standard UI.

[peternowell]

@zorgiepoo I've been trying to implement the private API solution you described, and I was able to get the Obj-C header set up in my Swift app. It looks like I need to create a custom class that conforms to SPUStandardUserDriverDelegate and defines the method standardUserDriverWillHandleShowingUpdate. I did that and passed the delegate into the SPUStandardUpdaterController initializer, but my method doesn't seem to be called (I just tried a print statement in it). Furthermore, it's not clear to me how the delegate can access the userDriver unless I add a property to my delegate to store it. I feel like I'm missing something basic.

Here's the code I'm using:

/// This view model class manages Sparkle's updater and publishes when new updates are allowed to be checked.
final class SparkleUpdaterViewModel: ObservableObject {
	private let updaterController: SPUStandardUpdaterController
	
	@Published var canCheckForUpdates = false
	
	init() {
		
		let customUserDriverDelegate = MySparkleUserDriverDelegate()
		
		updaterController = SPUStandardUpdaterController(startingUpdater: true, updaterDelegate: nil, userDriverDelegate: customUserDriverDelegate)
		
		customUserDriverDelegate.userDriver = updaterController.userDriver
		
		updaterController.updater.publisher(for: \.canCheckForUpdates)
			.assign(to: &$canCheckForUpdates)
	}
	
	func checkForUpdates() {
		updaterController.checkForUpdates(nil)
	}
}

final class MySparkleUserDriverDelegate: NSObject, SPUStandardUserDriverDelegate {
	
	weak var userDriver: SPUStandardUserDriver?
	
	func standardUserDriverWillHandleShowingUpdate(_ handleShowingUpdate: Bool, forUpdate update: SUAppcastItem, state: SPUUserUpdateState) {
		print("Showing update alert!", userDriver)
	}
}

I also took the time to mock up how I wish the Update Available window looked:

[zorgiepoo]

Nothing is retaining your MySparkleUserDriverDelegate to keep it alive, so try storing it in an instance variable. The lifetime of the updater(controller) and the delegate should correspond to your app's lifetime. Not that familiar with SwiftUI to verify whether your app structure is good (it may be weird to store it in a "ViewModel"). The userDriver assignment I guess is fine, but doesn't need to be weak.

[peternowell]

Thanks for catching that! I was able to get it working as you suggested. And I've been able to change a few characteristics of the window and certain views (ex: changing the control size of the buttons). I'm curious what you think the most reliable way is to target/identify these views. For example, rather than relying on the "Auto install" checkbox being the last child view, I'm currently checking the title property for certain words. But I'm guessing this wouldn't hold up when the title is localized. Or would it? I understand that this whole approach could be brittle, and I'm trying to build it to fall back gracefully. But how would you recommend identifying/targeting these views? Is there another property that's more reliable? Thanks again!!

[zorgiepoo]

We could potentially assign accessibilityIdentifiers to the controls which could also be useful for UI tests. Indeed localizations and right-to-left languages like Arabic, where the controls may be in reversed order, may trip you up.

[zorgiepoo]

A better current way is to look at the control's actions/selectors.