Zac Hall (July):
Apple just updated TestFlight for iPhone, iPad, Mac, and more. The new version, 4.3, introduces “a search field to quickly find apps.”
John Gruber:
But when Apple implemented this change, they also changed the sort order of the list of apps you’re registered to test. Starting with this update, the list is sorted in alphabetical order. For as long as I can remember — perhaps dating back to when TestFlight was a third-party utility — the list was ordered by recency. The most recently updated app was at the top; the oldest at the bottom. Sorting by recency is really the only sort order that makes sense when you’re registered for dozens (or more) of apps. For me, trying to see if there is an update to a new app whose name starts with U now requires scrolling through over 100 items.
[…]
Also, if I consider the broader view, this really speaks to how much we’ve lost in terms of UI vocabulary. For decades, any list of items with names and dates could be sorted by name or date, ascending or descending, through the standard use of clickable headers at the top of every list. This was true for almost any such list in any app, on any platform — Mac, Windows, Unix, Amiga, whatever. This was just basic GUI stuff.
[…]
iOS in 2007 introduced a simplified UI vocabulary that omitted many of these baseline GUI features. That seemed like a reasonable trade-off for a device with a 3.5-inch display and fat fingers as the only input device. But then iOS became popular and Apple stopped bringing the richer UI vocabulary of the Mac to iOS[…]
And it starting bringing iOS limitations to the Mac.
It certainly shouldn’t have taken until July 2026 to be able to search in TestFlight, either. And being able to search, and see the results sorted alphabetically, shouldn’t mean you can no longer view the full list sorted by recency.
John Gruber:
Whatever is going on with this sort order, it isn’t affecting everyone. John Siracusa, amongst many others, has the same problem I do — his list is now alphabetical, and it’s driving him nuts too. Ryan Booker, amongst many others, still has his list sorted by recency.
John Gruber (September):
For both of us, yesterday’s v4.3.1 update fixes the bug.
But there should still be more sort options.
Previously:
App Store Design iOS iOS 26 Mac Mac App Store macOS Tahoe 26 TestFlight
James Calligeros (Hacker News, Phoronix):
Asahi Linux now officially supports Macs with an M3 series SoC!
Linux support for M3 series SoCs and the machines powered by them is now in a state where almost
everything supported on the M1 and M2 series machines just works. This includes the webcam, internal
microphones, USB (up to the hardware limit of USB 3 10 Gb/s), hardware
accelerated video decoding including support for AV1, WiFi, Bluetooth, and much more! The only major
exceptions remain full DCP support and the GPU, which we will have more news on in the
coming months.
[…]
Sleep currently does not work due to limitations with the firmware-provided framebuffer.
This will be addressed once full DCP support is wired up for M3.
[…]
Although MacBooks and iMacs are supported (M3, M3 Pro and M3 Max), the Mac Studio (M3 Ultra) is not yet supported.
Previously:
Apple M3 Apple M3 Ultra Linux Mac Sleep
John Brayton:
NSTrackingSeparatorToolbarItem adds a white band over the top of the leading split view panes when in full screen mode on macOS 27 [beta 3]. That white band appears to have the height of the toolbar.
He says this was fixed in Beta 4.
John Brayton:
macOS 27 developer beta 5 (26A5406e) introduces a bug that causes a white bar to appear over window content if the window’s toolbar has an NSTrackingSeparatorToolbarItem. I filed FB24266969 with Apple describing this.
Steve Troughton-Smith:
NSSearchToolbarItem has been screwed last minute in Catalyst with less than a month to go? Cool, cool…
That’s the kind of thing that can halt my release plans entirely 🫠
Ron Elemans:
Also screwed up in AppKit, with the macOS 27 beta 5 release.
Also, the titlebarSeparatorStyle setting seems to be ignored. Toolbars in beta 5 always have a separator line and a blurred slightly lighter background.
Weirdly enough Apple’s own apps don’t have these issues.
John Brayton:
In macOS 27 developer beta 5, search fields in toolbars (NSSearchToolbarItem instances) have their placeholder text, search strings, and magnifying glass icons vertically off-center. I reported this as FB24286690.
Mario Guzmán:
Beta 6 also fixes the UI issues with NSSearchToolbarItem. Elements are now re-aligned again, the recents menu is in a good position, and the focus ring is perfectly outlining the entire bounds. :D
Previously:
Catalyst (Marzipan) Cocoa Mac macOS 27 Golden Gate
Natalia Panferova:
I thought it would be useful to have a single reference for the different ways we can style the toolbar in SwiftUI on macOS 26.
Phil Zakharchenko:
The toolbar id creates a stable customization domain, and each item id gives the framework something stable to persist when the user adds, removes, or reorders controls. This identifiability of toolbar items is a requirement for customization. Under the hood, when SwiftUI inevitably bridges your toolbar contents to NSToolbar, these identifiers will be directly translated to the NSToolbarItem’s itemIdentifiers.
As we continue the migration to a customizable toolbar, we are likely to encounter a few surprises related to this model.
[…]
After a closer inspection, and perhaps a few minutes of digging through the documentation, we come to the bleak realization: there is no customizable ToolbarItemGroup API.
[…]
The regular toolbar model and the customizable toolbar model overlap, but they are not interchangeable. You cannot give a ToolbarItemGroup an id, and you cannot place one directly inside toolbar(id:content:).
Majid Jabrayilov:
Let’s take a look at another example. This one is a bit tricky, because on macOS, you will get Action 1 in the top trailing position and the whole group of actions centered in the navigation bar. On iOS, you will get Action 1 pinned to trailing and all other items collapsed.
[…]
The final addition to the Toolbar API is the toolbarMinimizeBehavior view modifier allowing us to minimize toolbars while scrolling up or down. You can minimize tab, bottom, window and navigation bars with it.
With new modifiers SwiftUI gives us a much better balance between system-driven adaptation and explicit control. We can now decide which actions are more important, which items should always stay visible, which groups should intentionally live in the overflow menu, and how toolbars should react to scrolling.
Natalia Panferova:
iOS 27 includes a few smaller additions that make toolbar content easier to configure.
We can remove the default padding around an item whose content should extend to its edges with contentMarginsRemoved(_:)[…]
[…]
The status bar is now represented by ToolbarPlacement.statusBar, so its visibility can be controlled through the same toolbar API as other bars[…]
[…]
ForEach now conforms to ToolbarContent, which means we can generate toolbar items directly from a collection[…]
Natascha Fadeeva:
Together, the toolbar APIs let us express the importance of each action while SwiftUI continues to handle the toolbar’s layout across different sizes.
Previously:
iOS iOS 27 Mac macOS 27 Golden Gate Programming Swift Programming Language SwiftUI
