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.

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.

This looks really nice!
Just based on vibes, I agree about going from 12 to 15 for between-group spacing.

The only big thing I'd still like to see change is window width: the current size is too wide, I think, for best legibility. Narrower line length would make reading release notes more pleasant.
And although anything narrower would do, I'd argue for the old size specifically, which would mean existing release notes would render the same as previously.

I decreased the min window width size by the amount of horizontal space that was removed (88pt if I did math right).

Note the window is resizable so the user can make is larger if they want to (and that size will be autosaved).

I think I like 12 spacing more for grouping. The header message is using standard sizes and not guaranteed to line wrap, but an additional line is fine.

It looks like there's still a difference in web content width: the previous design is 490px across, whereas this latest version is still 536px.

To be honest I think it's already narrow enough, and I think I'm happy with the initial sizes after trying several languages. I'm more concerned about the window size and not making it too narrow, rather than the release notes view. The minimum and default sizes seems to be influenced by the intrinsic size of the header fields and may differ based on language. What width the release notes view is at isn't a compatibility issue (unless it's too small?) and can be dynamic based on message, language, and past user resizing.

That's fair! And I'm realizing now, I can always just use some CSS to enforce a certain legible width, if necessary.

I'm merging this. Thanks for everyone's help here. If you see any minor issues / touch-ups feel free to make a follow up issue/change. I updated the first post here with updated screenshots.

Hey Zorg, thanks for the update and thank the both of you for all your work!

I sat down today and went over all the pixel values to see if I could make anything look slightly better.

I ended up with this:

Click here to reveal!

I'm not sure it's actually better, and the differences are very subtle. But it's the best I could come up with after going over everything. The visual balance and margins were already very good I think.

Here's the original for comparison:

Click here to reveal!

Explanation of the changes and of the 'theoretical considerations' that went into them:

I also tried some more variations:

1.

Click here to reveal

Here's a variation with 25 px margins on all sides of the icon (except the right side). This matches native NSAlerts:

I think this way the title looks a bit less 'neat' and 'clean', but more more 'bold' and exciting .... Maybe I've been staring at this for too long lol.

2.

Click here to reveal

This variation has a line under the traffic lights, possibly making it easier to tell where the window can be dragged from. I think this also makes it easier for the eye to pick up some of the symmetries, which makes it feel very 'neat' and 'friendly' and 'cleaned up' and 'geometric' to me. But maybe also slightly 'boring' or even a little old-fashioned.

One thing that came to mind is that IIRC, out of my previous mockups, number 6. seemed to get the most positive reception from the others – and that one also had a line under the traffic lights. (Not sure if that's why people preferred it but it just came to mind.)

3.

Click here to reveal

This is a combination of 1. and 2. It has a line under the traffic lights along with with 25px margins around the icon.

This makes things feel a bit more 'airy' and dynamic than 2. while making the title stand out a bit more. I think it strikes a nice balance between making the title feel punchy but still feeling neat and cleaned up, and not having too much whitespace.

I think I'm liking this one the best right now.

4.

Click here to reveal

Here's a weirder one with:

• A subtle gray box around the top section
• A lighter color for the subtitle

Discussion:

• The position of the icon here is exactly the same as in 1. – I just put the light gray box in the background.
• The colors and fonts are supposed to match System Settings in macOS Tahoe.
• I havent' spent much time trying to perfect the margins and colors here. I just kinda stubled across this and was surprised how decent it looked. If there's any interest in something like this, I can work on it more.

Update: (Thought of another reason to put a "line under the traffic lights" as in 2. and 3.)

I thought that under Sequoia, having the traffic lights as well as the top content all sit on the darker-gray window background felt a bit unusual. I think in other windows you see across macOS, when there is no line below the traffic lights, it's usually because there's a combined background for the titlebar and toolbar where the traffic lights sit along with the window title and toolbar items. But I don't think I've seen the traffic lights just sit on top of the window background directly like this?

Now on Tahoe, I think this looks fine and not weird, perhaps because all the backgrounds are white. But on Sequoia, it does look a little strange to me to have the traffic lights sit on the darker-gray window background directly, when you'd expect to see them sitting on a lighter toolbar/titlebar background. It's subtle, but something to consider perhaps.

If you see any minor issues

The only small maybe-problem I noticed which is that when you build the 2.x branch, it seems to use the older, rounded Sparkle logo and it ends up in squircle jail:

I think Zorg mentioned that users never see the logo anyways so it might not matter, but I thought Zorg's new logo looked neat, and it was squircle shaped indeed.

Finally, here's the Sketch file:

Sparkle Tahoe.sketch.zip.

It's the same one that I posted previously just with some updates.

Again, thanks for your work and collaboration! I hope and believe that our efforts will make a positive impact on the Mac that will reverberate through the community and and make the platform just a little bit more awesome.

Should I open a new issue for this?

By the way, is there a way to sponsor the Sparkle project? So many apps benefit from Sparkle being great, so I think quite a few people would love to contribute something back.

@Cykelero

for best legibility. Narrower line length would make reading release notes more pleasant.

That's a very interesting point!

@zorgiepoo

What width the release notes view is at isn't a compatibility issue (unless it's too small?)

I think you're right, but it might cause slight usability issues.

The first line of the current placeholder text:

redesigned interface: Enjoy a refreshed, modern UI that improves navigation

Has 75 characters.

The optimal characters-per-line for the best readability are 50-75 characters according to this website: https://baymard.com/blog/line-length-readability

So it may actually be a good idea to allow the update window to be a bit narrower. (I think my app also uses a smaller font than the placeholder, which would excacerbates this.)

But I think with the current design, you'd have to shorten the subtitle text or make it wrap, to allow for this, I think?

I totally get if this is out-of-scope now – but perhaps it will be interesting to keep in mind for the future.

@Cykelero

That's fair! And I'm realizing now, I can always just use some CSS to enforce a certain legible width, if necessary.

That's a smart idea! That should solve the legibility problem. Perhaps it would look a little weird if the text doesn't fill the full width of the update-notes-box? Haven't played around with that.

Yeah if you want you can create a PR with the very subtle changes and we can review them (no guarantees but I'll review them). I do not have time to review these at this specific moment :).

I was running into CI failures all of a sudden with the AssetCatalog tool using the AppIcon #2757 so I had to, at least temporarily, remove it from the test app. (Funny that it was passing here, then started to fail all of a sudden on subsequent builds..)

By the way, is there a way to sponsor the Sparkle project? So many apps benefit from Sparkle being great, so I think quite a few people would love to contribute something back.

I think following the project, pull requests (I don't have much code review in general), and contributing to discussions or changes is most helpful. I think Sparkle has always just been a spare time hobby project; at least for me that won't change in foreseeable future.

Alright Zorg, I opened a pull request! (#2759)

I tried to make all the information easily available so it's easy to understand everything and make decisions. Of course I understand if it it'll take a while to review or if it doesn't align with your goals right now.

I was running into CI failures all of a sudden with the AssetCatalog tool

Hmm that sounds mysterious. Maybe something weird with the Xcode Beta toolchain or something like that?

I think following the project, pull requests (I don't have much code review in general), and contributing to discussions or changes is most helpful.

That makes sense. I think for some companies it might be easier to give money than to have their engineers submit pull requests directly? But I'm just speculating at this point.

(I don't have much code review in general),

Oh ok. I think I saw that there was a request for review on this pull request, but since I'm not a maintainer I didn't think I had the 'rights' to do that or something.

I think Sparkle has always just been a spare time hobby project; at least for me that won't change in foreseeable future.

Gotcha, thanks very much for your work on the project! :)

That makes sense. I think for some companies it might be easier to give money than to have their engineers submit pull requests directly? But I'm just speculating at this point.

It's not about PRs or money so much as it is about having people involved in the project so it doesn't rely on a single person :).

For further discussion about the UI or 2.8 I created a discussion here #2761 . This thread is a long one, and the PR is resolved, so I think I'll lock the discussion before I think it might go out of hand.