I can also go through the xib file and undo all the changes that Xcode does automatically whenever you open the file. That might minimize conflicts or make things easier to review.

I forgot to test the layout when the 'question' text has 2 lines, but it works quite well:

Tahoe:

Sequoia:

I also tested on Mojave / Catalina and found some issues with the initial pull request. But I've fixed those, and now it looks like this!

Thanks for opening this.

I think overall the UI changes here are very subtle but the code changes are very non-trivial / custom. Although personally I think I prefer the UI in 2.x (I think I like the transparent titlebar). At this point I think I'd expect a single small change (both UI and code delta change) with good justification.

(I'm not sure how to test the SUUpdatePermissionPrompt.xib. I only know it exists because it showed up for me once randomly in the Sparkle Test App.)

Delete the test app user defaults. On second launch it will show permission prompt. This works when apps do not override SUEnableAutomaticChecks in their Info.plist

Ohh man I just spent the evening writing up a detailed post and then I dragged a .png onto the comment field and it tried to open the image in Safari and failed, and then I went back and the entire comment text was deleted. :'(

I'm sorry I don't have the patience to rewrite something good, so I'll just post all the images I had made for the previous post and write some sloppy stuff around that

I made this image to show how to activate the 'transparent titlebar' style which you preferred. (The code supports that)

Then I made some images outlining the 'problems' with the current visuals that the pull request attempts to improve on:

Here is this pull request by comparison:

Here with the margins painted in – same sized margins have the same color:

I then wrote about how I think your eyes can't pick up pixel-differences per-se (which I think you alluded to and I agree with) but your eyes are very good at comparing things, and the new margins create lots of 'symmetries' – things are centered between other things and close-by margins are often equal. I said that I thought that this made things look more beautiful and simple and professional and stuff.

Here are some more 'symmetries' – between the text and the app icon:

The text sits nicely between the rounded corners on Tahoe:

On Sequoia, the text lines up with the little arrow heads – I didn't plan for this and it might be an accident, but Id assume that the icon follows Apple's grid and other icons would line up in similar ways and stuff:

I also made a case for how these symmetries show up in any situation, no matter which elements are shown or hidden or what macOS version you're using.

E.g here's Sequoia with a transparent title bar:
Note that when the titlebar is transparent, the code adjusts the top margin so that the app icon is centered between the traffic lights and the releaseNotesBox. This works on all macOS versions that Sparkle supports (I think – I tested 10.14 and up)

Here are margins for when checkbox is hidden on Tahoe:

Margins when releaseNotesBox is hidden on Tahoe:

I then I tried to make a case for the code:

Basically my point was that, when you strip away the if-else cases which I just left in fyi or so you can decide what you like better, the added code is just this:

Which is mostly just changing NSLayoutConstraint sizes on Tahoe – it's really not that complicated, it's just maybe a bit verbose because NSLayoutConstraint API.

Beyond this, there are two 'architectural changes' to the UI:

1. Change:

The icon has been wrapped in a wrapper view which 'deletes' the margins contained in the image from the layout, by applying negative margins. This allows us to visually align the app icon with the other elements on screen very easily. It also allows us to resize the the app icon without affecting all the margins. This makes it much simpler to make the app icon bigger on Tahoe – which I think is good because otherwise the app icon looks too small on Tahoe – especially in contrast to the big buttons (But all the controls and the title bar have gotten bigger in Tahoe.)

-> So I think this change actually allows for simplification of the layout logic and also easier iteration on the design in the future. (Because you can now very easily change the size without affecting the margins.)

2. Change:

Using 'spacer' views instead of -[NSStackview setCustomSpacing:afterView:] (and wrapper views with margins.)

This is almost the same thing. Spacer views can do the same things as -[setCustomSpacing:afterView:] but are more flexible and powerful, since:

1. They allow you to specify different spacing between different views in the stack right in interface builder.
2. You can use a spacer view to create a space at the very top of the stack view, which isn't possible with setCustomSpacing:afterView:
3. You can stack multiple spacer on top of each other and then hide one of them programmatically

This simplifies the code in our case, because we can define the spacing at the very top of the window edge in the same way as any where else. We used this to define the _spacer_underneath_trafficLights, which we configure to line up with the bottom edge of the traffic-lights exactly, and then we put another spacer directly below which defines how far our content should be away from the traffic lights.

Also the checkbox previously had a wrapper view with a margin (Which, IIRC, stacked up with the [setCustomSpacing:afterView:] spacing, which is a bit hacky and confusing.).

I changed it to a spacer to be consistent.

All of this would be a bit more hacky with [setCustomSpacing:afterView:] and wrapper views that contain the margins – but at the end of the day it's almost the same thing. If you want me to revert it back to match more closely with how it was I can do that.

Anyways, the code is only affected by all this in two tiny places:

I'd say this simplifies things. We removed the '.superview' thing which was a bit hacky. And we removed the SUUpdateAlertGroupElementSpacing stuff which is also slightly hacky.
Now the logic is just "If we wanna remove something from the stack, we just hide it and also hide the spacer below it".
And all the spacers are set up so the layout looks perfect after you do that.

Delete the test app user defaults. On second launch it will show permission prompt. This works when apps do not override SUEnableAutomaticChecks in their Info.plist

In my original post I also said thanks for that. Thanks!

I also said that I understand if the changes are out of scope or don't align with your vision for the project. But since you talked about wanting a good justification for any changes I tried to make a more detailed case for why I think these changes are good.

Another thing I said was that I think the visual changes are small but I think people do pick up on these visual symmetries and balanced-ness and will perceive the UI as a bit more simple, beautiful and polished, and thoughtfully crafted, and that they will appreciate that.

But again – the changes are pretty small, and I think that if the UI ships as it is in 2.x it's already much more beautiful than before!

I just tried to improve and polish things to the best of my abilities.

There is a lot of information to process here. I'm trying to stabilize 2.8 so I want to take smaller changes with low risk (if possible).

As for the leading padding on the icon images, I've noted before that seems to be intentional, depending on the image I guess? I have seen that in NSAlerts and in notifications too with the same icons too. Even though it is questionable.

I'll see if I can come back to this thread and the details written here. I've other important things to work on meanwhile.

I'm trying to stabilize 2.8 so I want to take smaller changes with low risk (if possible).

That sounds reasonable. I understand. Thanks for looking into this.

As for the leading padding on the icon images, I've noted before that seems to be intentional, depending on the image I guess? I have seen that in NSAlerts and in notifications too with the same icons too. Even though it is questionable.

That's an interesting point. One argument for aligning the icon with other things here is that the icon is like an "integrated" part of the layout for us while for standard NSAlert it feels more like it sits on top of the main layout separately.

In that notification you linked to I cannot clearly see where things are aligned. I haven't looked at it closely, yet, but that's interesting.

As for this comment you linked to:

App icons always have additional padding I believe. Assuming the additional padding is 5 (not sure it is), the margin is still 20.

The padding is 5 if the NSImage size is 60, which it is on NSAlert - if the image is larger, then the padding increases. The code changes in this PR make the two things independent.

Good luck with the 2.8 update!

Not taking changes right now and I don't think I can in the form of this PR. The icon alignment is tempting but I see app icons insetted in so many places. I believe the padding is baked into the images themselves, so it doesn't feel right to hardcode/assume a constant padding to negate by.