❌

Normal view

NSToolbar in Golden Gate

8 September 2026 at 21:13

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:

SwiftUI Toolbars

8 September 2026 at 21:12

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:

Preparing to Update to Golden Gate

3 September 2026 at 19:34

Howard Oakley:

As those new models start shipping on 22 September, the window for the first public release of Golden Gate has narrowed to 15-22 September, with greatest likelihood on the same day as the arrival of those new Macs.

[…]

At the same time as the release of Golden Gate, we should get Tahoe 26.7 and Sequoia 15.8, but it looks increasingly likely that the final version of Sonoma has been 14.8.9, released on 6 August.

Howard Oakley:

As we prepare to flee from the visual horrors of macOS Tahoe at last, this article is a reminder that it wasn’t the first major release of macOS that has had blatant bugs in its interface, although I suspect it may be unique in that those were intentional. While progress in Golden Gate has been limited, I hope you’ll find it rectifies some of the worst errors of Liquid Glass.

Many Macs will be left behind, as Golden Gate drops support for Intel.

Normally, I update around January. With Tahoe I waited until July. This time, I’m considering updating to Golden Gate soon after its release. The downside is that Xcode 26 doesn’t run on Golden Gate, so I would have to drop support for many older macOS versions (about 3% of my customers’ Macs). But it seems like Apple’s going to force that soon, anyway, as one of the next Xcode 27 updates will likely drop support for Tahoe. I want to get off Xcode 26, both to use the newer SDK and because there are various debugging/testing things that don’t work properly.

Mario Guzmán:

I am working on a new app. Right now, I am targeting back to macOS Sequoia. I think that would be a good OS to target but becoming quite old with Golden Gate just around the corner. […] I wonder if I should just target macOS Golden Gate and focus testing on that.

Previously:

Update (2026-09-04): Isaiah Carew:

i’m in the exact same boat. i’d really like to stay on macOS 15 and whatever Xcode works there. it means i can still build things in the old UI and mostly Tahoe and GG respect it.

but recent bug reports from beta testers and the inability to see these bugs on my VM has made me feel very stuck here — like apple has purposefully made it difficult to move forward and support older versions too.

Update (2026-09-11): Howard Oakley:

What if any preparations do you need to make before upgrading or updating then, or in the coming weeks?

Update (2026-09-16): Adam C. Engst:

So who should upgrade immediately, and who should wait? Let’s consider a few broad categories of users.

Ending the Golden Era for Backward-Compatible Apps

1 September 2026 at 21:08

Matthias Gansrigler-Hrad:

I don’t appreciate being forced by Xcode 27 to drop support for macOS 10.13-11.0. It’s my decision which OSes I want to support, not Apple’s. Yes, I can keep Xcode 26 around until submissions require Xcode 27, but what then?

Originally, Xcode 27 was documented as supporting Big Sur on Intel Macs, but now the earliest is Monterey.

I’m frustrated, too, but it’s more honest than the recent releases that claimed to support deployment on older macOS versions when Apple clearly hadn’t tested that it actually worked. I filed bugs, and Apple kept responding that they’d fixed it, when they hadn’t.

Using old versions of Xcode isn’t a great solution because they aren’t supported on Golden Gate. Swift also makes it more difficult to call newer APIs when using an older SDK. You can’t just copy/paste a method prototype or constant value and conditionally use it when running on a newer OS.

Ighor July:

I eventually found a hidden workaround that changes the errors back into warnings. That is good news, but it does not make the concern disappear. The setting is undocumented, absent from the normal Xcode interface, and currently being tested only in a beta toolchain. The larger question is what Apple intends to enforce when Xcode 27 is final and, later, when App Store submission requirements move to its SDKs.

[…]

Apple’s current Xcode system requirements list Xcode 26 with deployment targets beginning at iOS 15 and macOS 11. Yet developers have been able to enter older targets manually. In an Apple Developer Forums discussion about Xcode 26, an Apple product manager explained that the published deployment target range is aligned with simulator support and on-device debugging. The accepted answer confirms that an iOS 13 target can still build even though it falls below the range in Apple’s table.

My own tests went further. Xcode 26.5 compiled a project targeting iOS 9.0. It warned that the target was older than the supported range, but the build succeeded. On macOS, I have compiled current apps with deployment targets as old as macOS 10.9. Xcode warned me, but it still produced working applications.

[…]

For iOS and iPadOS, staying on Xcode 26 is not a lasting option. Apple has repeatedly made a current Xcode and SDK mandatory for new App Store submissions. […] If any one of those conditions fails, iOS and iPadOS developers will have no normal App Store path for publishing new updates that still support versions older than 15.

Previously:

Update (2026-09-07): Léo Natan:

Just want to remind you guys that if you move to Xcode 27, the only “officially” supported and sanction Xcode for GG, UIDesignRequiresCompatibility is no longer respected across the 27 OSes (apps built with older Xcodes still are). So you might suddenly find out you have a lot of work ahead of you, adding support for the dreaded Glass. And 27 Glass is not the same as 26 Glass. That can be an issue if you skipped 26 altogether but still want to support it.

Previously:

Update (2026-09-11): Nick Lockwood:

I mostly ignored the Xcode 27 betas (mainly due to the barely-usable Device Hub) so I didn’t realize the passive-aggressive prompts to drop support for iOS < 15 that you get when submitting apps is being backed up by Xcode 27 refusing to compile apps at all unless you bump the deployment target 😧

MacOS 27 Golden Gate Beta 8 Now Available to Download for Testing

31 August 2026 at 19:49

Apple has issued the 8th beta version of MacOS 27 Golden Gate to users participating in the developer beta testing program. Typically the matching build arrives as a public beta soon after, so if you’re on that beta track keep an eye out for an update soon too. MacOS 27 Golden Gate is nearing completion, ... Read More

The post MacOS 27 Golden Gate Beta 8 Now Available to Download for Testing appeared first on OS X Daily.

MacOS 27 Golden Gate Beta 7 Download Available Now

24 August 2026 at 21:54

Apple has released the seventh beta version of macOS 27 Golden Gate to users who are running the developer beta. A matching build typically arrives for public beta testers soon after. Any user can install MacOS 27 Golden Gate beta onto a compatible Mac, though beta system software is generally only recommended for advanced users ... Read More

The post MacOS 27 Golden Gate Beta 7 Download Available Now appeared first on OS X Daily.

The End of EWS in Mail and AppleScript in Outlook

20 August 2026 at 18:39

Microsoft:

Exchange Web Services (EWS) is approaching end of service in Exchange Online. We first announced this change was coming in 2018, when we announced that Exchange Web Services (EWS) will no longer receive functionality updates. In 2023, we announced that EWS will be disabled in Exchange Online in October 2026.

Today we’re announcing we will use a phased, admin controllable disablement plan that starts in October 2026 and concludes with a complete shutdown of EWS in 2027.

Apple:

Microsoft announced the upcoming end of service for Exchange Web Services (EWS) in Exchange Online. Apple is actively working with Microsoft to update Mail, Calendar, Contacts, Notes, and Reminders to use the Graph API in a future update to macOS 27, including a declarative configuration for device management services.

I’ve been eagerly awaiting Apple’s migration to Microsoft’s newer Graph API because EWS support in Apple Mail has long been buggy. It seems to have gotten worse in recent months, presumably due to server side changes as Microsoft prepares to shut it all down. Unfortunately, Apple is not as far along in the transition as I’d expected.

Jonathan Harbourne (and, alas, Claude):

What made a Mac feel like a Mac at work was the software that came with it. Mail that you could actually scan. A Calendar that was a separate application, so it could live permanently on a second screen instead of hiding behind a tab. Quick Look. Smart mailboxes. Spotlight that found things. Share sheets that worked everywhere. The system behaving as one coherent thing rather than a collection of vendor silos.

[…]

iOS and iPadOS Mail no longer depend on EWS. macOS Mail still does. Same company, same deadline, same protocol, and only one of the two platforms got the work done in time. Microsoft ended up writing the guidance Apple should have written, telling administrators in February that Apple Mail for Mac users would have to switch to Outlook until the applications were updated. […] Apple had years. It had a public deadline. It had, by Microsoft’s own account, one of the most widely used EWS applications in existence. And it let the clock run out.

[…]

Somewhere in every one of these migrations is a line in a change log that reads “users to move to Outlook”, as though a mail client were a fungible commodity, like swapping a stapler. […] This is not the death of the Mac at work. […] It is the death of the Mac experience at work.

Outlook for Mac feels very different from Apple Mail, and users are being squeezed from the Microsoft side, too. Microsoft will be ending the transition to New Outlook in October, but the new version is still missing many features that were present in Legacy Outlook (as well as Apple Mail). Microsoft had long promised that it would implement AppleScript in New Outlook before dropping support for the old version, but last week it changed course:

AppleScript workflows vary widely across organizations and often depend on behaviors from the classic app that don’t exist in the New Outlook. Because these patterns can’t be standardized, full compatibility isn’t feasible. We have decided not to move forward with this feature. We apologize for the inconvenience.

Back to Harbourne:

Access only ratchets one way. Mail was allowed because it worked, quietly, for years, over a protocol nobody was auditing. It has now been formally removed under a named cybersecurity policy. Getting it back would require someone in a security function to write a positive case for re-admitting a broad-permission third-party client to the corporate mail estate, and then put their name on it. Nobody’s career improves by doing that. Saying no costs nothing and is never wrong in hindsight.

So if Apple ships Graph support in Mail next year, the people who lost it will not get it back. The door didn’t swing shut. It was bolted, and the reason it was bolted is now written down in a policy document that will outlive the protocol that prompted it.

Apple has no leverage to change that, either. The organisations deploying Macs by the tens of thousands are not Apple partners in any meaningful sense. They are customers who buy boxes. There is no relationship to call on, no joint roadmap, no account team, nobody at Apple whose job it is to notice that a hundred thousand people just lost Mail.

October is when administrators will have to opt back into allowing EWS for a few more months, but some (like Harbourne’s) will be switching off support sooner.

Apple Mail and Outlook aren’t the only options, though. MailMaven supports both Graph and AppleScript.

Previously:

Update (2026-08-21): See also: Reddit and Mac Power Users.

Update (2026-08-24): See also: Mac Power Users.

Previously:

❌