I like this update in many ways, probably because I share @zorgiepoo 's desire to minimize wide expanses of blank space, and because the updated design looks "fresh" but also "familiar."

One key change I'd recommend is to limit the content from the release notes to the "safe area" (to borrow a term from Apple) of the window. I like the edge-to-edge layout of the release notes area but I think a borderless web view that imposes a margin against the window would look nicer and be more scannable:

There were some questions in the conversation on #2731 about how closely this design matches the Tahoe alert style, and whether it will appear "native" or not. As I said there, to my eye this already looks pretty native to me, but I also haven't seen too many examples of panels with comparable complexity that have been updated by Apple for Tahoe. The Print panel leaps to mind as something to possibly take inspiration from, though its UI is unhelpfully more akin to Settings with its vertically scrollable options. Another loosely comparable UI is that of the "Connect to Server" panel in the Finder:

If anybody discovers macOS Tahoe based panels with some interactive complexity, it would be interesting to make more comparisons.

As to the question of preserving backward compatibility, I wonder if it might be both preferable from a UX point of view, and easier technically, to split the panel UI into two discretely loadable choices, and only load the "modern" UI either by request from the developer, or by default based on the OS and/or AppKit link version. Adopting the AppKit link version approach would mirror the way that Apple's own UI defaults only apply to apps that have been built against the macOS 26 SDK, on the assumption that developers would have had the opportunity to update the rest of their app's UI to match.

We can play around with adding margins. I think we'll need some sort of box or custom view, but we need to move away from the legacy box view style Sparkle uses today and be more aesthetically pleasing. Currently the PR is using custom 1-point divider views on top/bottom. Do you know if we can get a box view like in noah's mockups? (May have time to look later today / tomorrow, not experimenting at the moment).

I'd prefer not having an option to go to an old mode because I don't want to maintain it and there's little point if it's mostly inferior. Currently there are no new APIs being used but I still need to check the UI on a more older OS. Many/some of these changes could have been done back in 10.10 or 11.0 days. We can see how this plays out.

That makes sense about keeping it simple and avoiding an "old mode". I'll probably not find the proposed design too jarring once I see it in context on an older OS.

I'm not sure I understand why we would need a box or custom view, unless you want to add a border to the release notes? I was thinking just to have the content indented, which could be achieved with a simple custom view or else a custom box if there is something about boxes we desire, more than the functionality of a border.

One key change I'd recommend is to limit the content from the release notes to the "safe area" (to borrow a term from Apple) of the window. I like the edge-to-edge layout of the release notes area but I think a borderless web view that imposes a margin against the window would look nicer and be more scannable:

I really like the updated design, Zorg! Would like to second Daniel's suggestion, those same margin insets occurred to me as well.

This is how it looks with the margins imposed on the release notes:

My instinct is that the icon should be bigger and the text should be vertically aligned to its center.

Another thought: I think that small font sizes have a tendency to make UI look outdated. Here's a trial with larger icon and text sizes. This also helps balance the likely larger size of the release notes content.

Even larger heading text for contrast with the question text, and an example of what it looks like when the release notes are long enough to scroll off the bottom:

I'm still coming to terms with what the predominant uses of white backgrounds in Tahoe means. The grey top/bottom of older OS's typical design would help to offset the release notes from the window's controls.

This is the current iteration of this PR (on Tahoe; it's decent on older OS's too):

Without release notes:

• Bumped the image view size back to 64x64 again. It turns out the extra 'padding' around the icon is normal and you'll see everywhere including standard NSAlert's
• Added back release notes label and Software Update window title for now. I wanted to de-emphasize the release notes label, not have it in bold like in Sparkle today, though. Inspired from Kaleidoscope above in this thread.
• Bumped the button sizes to large, which also gets the capsule border shape. I think large buttons are used in standard alerts too. Also bumped them in the status/progress window.
• Left the new version header / question field fonts alone for now. When I compare them to -[NSFont preferredFontForTextStyle: options:] with NSFontTextStyleHeadline and NSFontTextStyleSubheadline it seems the style & size is already pretty identical.
• Using Standard + 4 spacing leading/trailing margins around the window to make it seem less tight(?)

--

I tried to stack the app icon and header text vertically. It really does not feel good or work well to me. A part of it is that unlike standard alerts, Sparkle's update window is larger and can grow. As with the accessibility prompt or noah's other examples, or system notifications (see below), not all dialogs in Tahoe are vertically stack the icon with this respect. So I don't think it's out of place.

This is at an older commit I had with the app icon being vertically stacked for reference:

I had a go at adjusting the margins. I think following the system's metrics looks nice:

Reference

Looking at system alerts and windows, it seems that:

• Closely-related elements are separated by 8 points of space
• Other elements are separated by 15 points of space. (this also applies to the margin around the window edge)

Some notes

• In addition to just changing numbers, including the overall stack view's spacing, I did have to do one hackish thing: give the “automatically download” checkbox a negative margin of -7. This is so that the checkbox is spaced 8 from the button row, even though they're in the stack view, which is 8-spaced. Doing this more cleanly would require adding a wrapper view, to group these two rows.
• At this point, it feels like having two different storyboards might be a good idea. The design looks strange on Sequoia (see screenshot below) because of its margins, and button size. Also, I still strongly prefer the “vertically stacked header” variant, and having two different storyboards would allow doing that, without weirding out pre-Tahoe users.
• Merging storyboards is really hard, so maybe the changes I made are only useful to create these screenshots; but you can have a look at the margin-tweaking commit.

I like your work on the margins @Cykelero!

I implemented the pure-code drop-in replacement for SUUpdateAlert.xib which I talked about:

https://github.com/noah-nuebling/Sparkle/blob/modernize-update-alert/Sparkle/SUUpdateAlert_CodeOnly.m

It's not very polished yet, but it should be functional. It has a const int layout variable which you can set to 0, 1, or 2 to switch between the 3 layouts we've been discussing, if we parametrize this based on macOS version that should solve the issue.

I haven't tweaked the margins and all that to look good.

If this is of any interest, I can clean it up, write documentation, and adjust things to you liking, so everything is easy-to-maintain. This should already be useful for playing around with the different layouts.

Thanks! I'm good with most of the changes. My first gut reaction is there's too much vertical spacing between the app icon and the top of the window, and maybe after the icon and before the release notes label. But you probably think it's too crowded otherwise. Or maybe I'm not used to it.

With those wide margins, it feels a little bit better to me to make the titlebar non-transparent again:

Hiding the release notes:

In addition to just changing numbers, including the overall stack view's spacing, I did have to do one hackish thing: give the “automatically download” checkbox a negative margin of -7. This is so that the checkbox is spaced 8 from the button row, even though they're in the stack view, which is 8-spaced. Doing this more cleanly would require adding a wrapper view, to group these two rows.

This does not need to be done like this. You can set custom spacing after views using -[NSStackView setCustomSpacing: afterView:]. So in this case I believe the spacing can be kept as 0 in Interface Builder, and a custom spacing of 8 can be used instead of 15 programmatically.

At this point, it feels like having two different storyboards might be a good idea. The design looks strange on Sequoia (see screenshot below) because of its margins, and button size. Also, I still strongly prefer the “vertically stacked header” variant, and having two different storyboards would allow doing that, without weirding out pre-Tahoe users

I personally feel like the vertical layout looks odd on both OS's given the window's size and this design looks fine on Sequoia. Maybe we can tweak margins and button sizes but I don't like the idea of having drastically different UIs. Tweaking button sizes and margins doesn't warrant a separate nib (neither would changing the orientation of the app icon / header if we wanted to do that)

edit: Showing the titlebar nontransparent looks kind of weird though, since the header looks more of a separate section, maybe better off just removing the top padding, or maybe I'm just off here.

edit2: I am not sure about the margins. I'll give it some more thought. I want to re-iterate Sparkle's update window is not like a system alert though.

I agree the top margin being 15px looks strange, after all.
Maybe, though, you could both make the titlebar transparent again (the separator does look weird) and hide the title—after all, we have the “A new version of Sparkle Test App is available!” text that effectively does the title's job.

(on the other hand, I think the 15px margin above the release notes is important; these are different sections of the window, after all. and on that note, I'd even advocate for removing the “Release Notes:” header, as the content feels self-explanatory)

About the vertical layout: maybe it only really works for narrower windows. Have you tried making the window less wide, matching the previous width, to assess the vertical layout?

You can set custom spacing after views using -[NSStackView setCustomSpacing: afterView:]

Oh, awesome! I'll mistakenly thought this API was iOS-only.

I came across an interesting thing:
There are actually still square boxes used in macOS.

Here's Xcode:

Click here to reveal

System Settings:

Click here to reveal

I'm not sure what the pattern is for when these are used. But I thought it was an interesting datapoint, since I think before, we assumed that square corners = outdated.

By the way, I also really liked the update to the little progress bar window that sometimes shows up. I haven't studied it in in detail, but I remember it felt very modern and sleek to me. Great work! I like where this is going.

before, we assumed that square corners = outdated

To me that's still a good assumption; those UIs you found in Xcode and Settings might simply not have been updated yet.

Apple's much better than some other companies at updating all of their software, when releasing a big redesign, but they're not perfect, either!

To me that's still a good assumption; those UIs you found in Xcode and Settings might simply not have been updated yet.

Fair take!

I have one more input: I interpreted window margins on NSAlert to be 20 px, with the large rounded buttons being inset 5 px closer to the window edge.

The pattern doesn't seem 100% consistent, so maybe I'm interpreting it wrong, but here are some screenshots that more or less follow this pattern:

Click here to reveal

I think it looks quite good to have the rounded buttons "spill" into the corners a bit like that. But the current mockups also look very good. It's a very small thing.

I agree the top margin being 15px looks strange, after all.
Maybe, though, you could both make the titlebar transparent again (the separator does look weird) and hide the title—after all, we have the “A new version of Sparkle Test App is available!” text that effectively does the title's job.

(on the other hand, I think the 15px margin above the release notes is important; these are different sections of the window, after all. and on that note, I'd even advocate for removing the “Release Notes:” header, as the content feels self-explanatory)

Current PR keeps titlebar transparent. Hiding title and removing the release notes label is something I'm going back and forth about so I do like you brought that up.

More margin below the title section may be good for localization too when lines wrap I suspect..

About the vertical layout: maybe it only really works for narrower windows. Have you tried making the window less wide, matching the previous width, to assess the vertical layout?

NSAlerts have a vertical preferred layout since Big Surr (Tahoe notably changes the leading aligned app icon). The alert design is intended for narrow window with small amount of information. Alerts try to make the button choices vertically laid out too depending on how much text content there is; the style is dynamic depending on the content presented. Dialogs with more information need to use regular/larger windows as fitted here (paraphrased from Big Surr release notes). Horizontally laid out app icon & text is common elsewhere including system software update UI and notifications. But I would say Sparkle's current UI is uncommon (app icon horizontally laid out with large column). NSAlerts are somewhat special.

With boxes I think rounded corners are all well.

Margins are kind of arbitrary to me on the exact px to use. Currently using some of the standard spacing, extra spacing to group some of the elements together. Not sure if it should be 15. Not totally convinced margins should be copied from NSAlerts.

The pattern doesn't seem 100% consistent, so maybe I'm interpreting it wrong, but here are some screenshots that more or less follow this pattern:

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

Fair points!

I interpreted window margins on NSAlert to be 20 px, with the large rounded buttons being inset 5 px closer to the window edge

Oops, you're very right. I got it wrong when measuring myself. That's probably the metrics we should be shooting for, then.

Current state:

Sequoia:

I just removed the window title and release notes label, made the button sizes regular < Tahoe. The custom vertical spacing between "groups" is 12 currently (maybe will bump to 15?). Horizontal is standard (likely 20). It seems like at this point this will be very close to what it'll be.