❌

Reading view

MacOS 27 Golden Gate RC Available to Download for Testers

Apple has released MacOS 27 Golden Gate as a Release Candidate (RC) build #26A428 for all users enrolled in the beta testing programs for Apple system software. A Release Candidate build typically signals the end of the beta testing process, absent any significant last minute issues, and can sometimes match the final Golden Master (GM) ... Read More

The post MacOS 27 Golden Gate RC Available to Download for Testers appeared first on OS X Daily.

  •  

NSToolbar in Golden Gate

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

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

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

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

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

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

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:

  •  

MacOS 27 Golden Gate Beta 5 Update Now Available to Download for Beta Testers

Apple has released MacOS 27 Golden Gate beta 5 for Mac users who are currently running the beta operating system. For those in the public beta testing program, the same build typically arrives for them soon after. MacOS 27 Golden Gate emphasizes performance improvements to the general system as well as features like Spotlight and ... Read More

The post MacOS 27 Golden Gate Beta 5 Update Now Available to Download for Beta Testers appeared first on OS X Daily.

  •  

How to Make a MacOS 27 Golden Gate Virtual Machine with VirtualBuddy

If you’re curious about testing out MacOS 27 Golden Gate beta but you aren’t ready for the full commitment of installing it as your primary operating system, the simplest and safest way to run MacOS 27 Golden Gate beta is within a virtual machine. While one of our authors dove right into MacOS 27 Golden ... Read More

The post How to Make a MacOS 27 Golden Gate Virtual Machine with VirtualBuddy appeared first on OS X Daily.

  •  

Golden Gate Application Support Protection

Wojciech Reguła:

Looks like moving the user’s TCC db to /private/var/containers/Data/ProtectedSystem/[UUID]/Data/Library/Application Support/com.apple.TCC/ was not the only change in the whole privacy castle of macOS 27. (What btw was a great move as now attackers with full disk access permissions can’t modify your privacy settings)

macOS 27 quietly ships a new privacy mechanism I hadn’t seen documented anywhere: it extends the com.apple.macl protection that has always guarded sandboxed apps’ ~/Library/Containers/<bundle-id>/Data folders to a hand-picked set of non-sandboxed apps’ ~/Library/Application Support/<name> folders too. I noticed it by accident — Firefox’s profile folder was suddenly inaccessible from Terminal, while MacPass, a password manager sitting right next to it, was wide open. That asymmetry didn’t sit well with me, so I pulled the thread. It ends in a hardcoded app allowlist baked into /usr/libexec/sandboxd (thx @ciphwall for the hint), meant to be updated live via XProtect.

Previously:

  •  

The Real System Requirements for OS 27

Apple has finally completed its silicon transition: macOS 27 drops all Intel-based Macs, and iPadOS 27 and watchOS 27 each leave five models by the wayside, whereas the iPhone compatibility list remains unchanged.

macOS Hidden Treasures: Quick Look

  •  

Siri AI Beta

Federico Viticci (Mastodon):

The AI frontier from the two big labs (and – we have to be honest with the numbers here – probably SpaceXAI and Meta now, too) is in a completely different league at the moment. I spent my first couple of weeks with Siri AI trying to convince myself that I could replace Codex with Siri AI, and that was the wrong approach. There is a potential future in which Siri AI can become a more proactive and capable agent, but that’s not what Apple is shipping this year.

[…]

Siri AI is a dramatically better Siri for typical Siri stuff. The new Siri understands your commands and nuanced requests better because of the LLMs behind it; it can often perform multiple requests in one go (such as setting multiple timers with one command); the new expressive (and customizable!) voices sound great, and they’re terrific at reading and summarizing notifications. Apple’s first advantage compared to other chatbots is right here: only Siri can integrate with the iPhone and iPad to this extent, so even if the Foundation models aren’t as smart as the competition, Siri can do a lot more for most people on their devices because neither OpenAI nor Anthropic have OSes they can control.

[…]

The biggest issue I’ve encountered is the inconsistency of it all. Very often, the new Siri AI still replies with a generic “Uh oh, something went wrong“ error that doesn’t explain what the error was or why it happened. Sometimes, I ask a question via voice, and it errors out, but then a few seconds later, I type the same question in the app, and it’s fine.

[…]

My problem is that, right now with Apple’s own apps, both the index and Siri’s ability to perform actions are very inconsistent. The assistant hallucinates abilities it doesn’t have, and it frequently just doesn’t work.

Dan Moren:

The good news is that Siri AI is capable: impressively so, at times. In the lowest of low bars, it certainly beats the pants off the previous incarnation of Siri, but its access to your own personal data and all of the app on your phone also unlocks a host of new possibilities.

But it’s also not without the pitfalls that underlie all LLM-powered chatbots: errors in understanding, hallucinations, and so on.

[…]

The app itself is pretty barebones, letting you view those conversations in List or Grid layouts, select multiple conversations to delete them, and pin or rename any single conversation. In Settings : Siri, you can choose to either open to the overview or to a new conversation and decide whether old conversations are kept for 30 days, 1 year, or forever. It’s a little strange that one-off queries (“What’s the average height of the Norwegian World Cup team?”) are stored alongside more involved conversations (“Can you help me build a specific RSS feed for this site?”); I also ended up with a few orphan blank “New conversations” which I deleted, but it’d be nice if you could filter to find those. Conversations are fully searchable and sync between devices via iCloud.

John Voorhees:

Despite the current limitations, if you use chatbots as a replacement for Google Search, you’ll probably have a good experience with the new Siri app. That’s because even in these early betas, if you ask Siri something like, “Give me a day trip itinerary for a trip to Chicago this Saturday,” you’re likely to get good but pretty middle-of-the-road recommendations. From there, though, you can drill down with follow-up queries to get something more in line with your tastes. The results include source links you can follow, too. Given the ad-strewn mess that web search has become, using Siri for this sort of thing is a meaningfully better experience.

The one caveat on Siri’s world knowledge is that it’s roughly 2-3 weeks stale in some places.

[…]

A good example is Music. You can prompt Siri to play a song, but most of the rich metadata in the app isn’t exposed to Siri, which is a shame because it is exposed elsewhere, for example to AppleScript.

Previously:

Update (2026-08-04): Benjamin Mayo:

Thanks to the top-to-bottom revamp that is Siri AI, Siri is reliably intelligent. Finally. We are still in the midst of beta season, and Apple is yet to confirm whether Siri AI will formally launch with iOS 27 in September or sometime later in the year, but the feature is up to scratch. There are bugs and glitches and edge-case quirks, but on the whole, it wipes the floor with old Siri and is competent enough to supplant my everyday usage of other chatbots too.

[…]

Siri AI can get a snapshot of what’s on screen, but it cannot control the UI for you autonomously. As such, if you ask it to do something outside of its library of available app actions, it will say it can’t do that. Often, it can quote the relevant steps for you to do it yourself, but obviously that falls short of the ideal experience. This feels a bit lacklustre to people already embracing AI agents en masse. Claude and Codex on Mac do not hit these walls; they are all too keen to move your mouse for you and run terminal commands until the job is done.

Previously:

  •  

Apple Intelligence to Launch in China

Hartley Charlton:

Reuters reports that China’s Cyberspace Administration registered Apple’s on-device generative AI service this week, putting it on a list of newly cleared providers that also includes homegrown systems from Chinese phone makers.

An unnamed source told the outlet that Apple’s AI features in the country will draw on models from both Baidu and Alibaba.

William Gallagher:

China has complex requirements for regulatory approval, and sufficiently so that US firms typically need to involve a local partner.

John Gruber:

This isn’t about Siri AI, announced last month at WWDC for iOS 27 — this is the initial approval for Apple Intelligence, which was announced two years ago and rolled out in iOS 18.

Previously:

  •  

Golden Gate Squircle Jail

Paul Kafasis:

With last year’s release of MacOS 26 (Tahoe), Apple made a mess of app icons. In the first betas of MacOS 27 (Golden Gate), however, there are signs of a turnaround. We’re urging Apple to continue making improvements, by restoring the ability for MacOS app icons to have distinct shapes.

[…]

After decades of beautiful, memorable Mac icons in varying shapes, Tahoe flattened personality to obtain bland uniformity. The platform is worse for it.

Past icons weren’t just more expressive. They were also more usable. Having distinct shapes provided a useful way to tell icons apart. Tahoe eliminates that cue by forcing everything into the same squircle, leaving color as the primary way to tell icons apart at a glance.

Jason Snell:

Kafasis makes the important point that uniform shapes make it more difficult for users, especially those with vision issues including color deficiency, to differentiate between icons.

John Siracusa:

Squircle Jail is the worst design-related thing Apple has ever done to Mac developers, and probably the worst icon-related thing it has ever done, period. Incredibly developer-hostile.

If squircled icons are actually better, then let that design win in the market. That’s how we transitioned from the classic Mac OS icon style to the more photorealistic Mac OS X icon style. Developers adopted it because they wanted to, and because users desired it.

John Gruber (Mastodon):

The squircles, I will point out, are not in and of themselves the problem. The problem would be the same with any mandated shape, like, e.g., VisionOS’s circles.

[…]

I can’t think of any other design crime Apple has ever foisted on Mac developers that I’d argue (with Siracusa) was worse.

[…]

It’s like Apple decided every single one of its own apps must wear a stupid-looking hat, and they put those stupid-looking hats on third-party apps too, whether the developers of those apps want them or not. Scratch that. Not hats but helmets.

[…]

Just the mere silhouette of the old Keynote icon is more recognizable, and thus more iconic, than any icon on any platform from Apple today.

Jeff Johnson:

The traffic sign analogy hits me personally, because the StopTheMadness icon used to be shaped like a stop sign, but I was practically forced into making it a generic road sign.

Gus Mueller:

I get why Apple did it, but I think it’s completely wrong for the Mac.

Marcin Wichary:

On his blog, Jim Nielsen writes how Apple filed away so much expression by forcing rigid icon bureaucracy in macOS. Nielsen focuses mostly on distinctiveness; previously, you could make the icon unique by its general shape or the shape of its contents, but one of these two levers has now been taken away[…]

[…]

However, one also can’t help but notice how ugly and amateurish the Creator Studio icons are, so it all feels absolutely like a net negative – the new system took something away and the proposed replacement feels low quality[…]

Rui Carmo:

I, too, find the squircles aesthetically offensive and utterly pointless.

[…]

The part that genuinely breaks my brain, though, is that I now find icons on Linux more distinctive than on macOS, which would be impossible for my ten-year-ago self to believe. The platform that built its reputation on craft and visual identity has spent a year sanding it off, while the one everyone used to mock for its inconsistency is where individuality survives.

Jeff Johnson:

The subliminal, Orwellian message of the squircle jail is that all software is subservient to Apple, merely accessories to Apple devices, interchangeable cogs in the machine.

Mario Guzmán:

Had to grab the rest of the icons from #MacOSX Leopard. Gosh, they’re so, so pretty. So finely crafted. Gorgeous. Love it.

Dr. Drang:

I agree, but Apple’s 50th anniversary has gotten me thinking a lot lately about the early days of the Mac, so it’s only natural that my mind shifted to the highly constrained icons Mac applications had back then.

[…]

Many of the complaints about squircle jail are about the loss of icon elements that “stick out” from the rest of the design. As you can see, this idea was there from the very start; the hands stick out from the tilted rectangles.

John Gruber:

I never loved the hand on these icons. It felt too uniform. It functioned like a “this is an application” badge, but such a badge never felt necessary to me.

[…]

I think it’s less that Apple gave up on them and more that it came into focus that the “hand holding a pen over a diamond-shaped document” convention was intended for document-based apps. It signified “This is a creative tool that you use to create documents”. Apps that weren’t about creating document files — like Disk First Aid and Font/DA Mover — got different icons. Font/DA Mover’s truck icon in System 2 signified that you use this tool to move things. Disk First Aid’s ambulance was an obvious metaphor for repairing something unwell.

[…]

But the main thing about the “hand holding pen over diamond” convention was that it was only ever a convention.

John Gruber (Mastodon):

(a) I don’t think this is a good mandate for iOS either;

(b) it was always so for iOS, though, so it’s not like Apple has ever taken away rich creative icon shapes on the platform;

(c) MacOS is a far richer and more precise environment than iOS.

[…]

App icons on the iOS home screen are effectively simple buttons. I think it’s rather obvious that’s why they have had that squircle/roundsquare shape ever since the iPhone was announced in January 2007 (source). They’re one-tap launchers. App icons in MacOS are not mere buttons. You can drag them, move them, and drop things on them. You click them to select, and double-click to launch. They are richer objects that deserve a richer visual vocabulary. iOS is a world meant for fat-tipped Magic Markers and blunt safety scissors. MacOS is a world meant to support fine-tipped drafting pens and precision razor-sharp X-ACTO knives.

Louie Mantia (Mastodon):

While developers have submitted full-bleed square images for iOS app icons since 2008, for these new squircle icons in macOS 11, Apple provided a template to compose app icons in an image editing tool like Photoshop, with full control over the canvas beyond the suggested—but not required—squircle. This template made it easy-ish for designers to compose macOS app icons that were identical to or synonymous with an iOS app icon, while leaving the door open to continue using arbitrarily-shaped app icons on macOS.

[…]

The second type of Squircle Jail is more controversial, because these app icons were specifically drawn with the intention of fitting in. Overriding that intention feels like punishment for having done the right thing. App icons in a style that was recently encouraged by the system are now scaled down and put inside the squircle as if it were a container. Every icon that was utilizing the previous squircle shape suddenly looks much worse than before.

[…]

Instead of taking care to design and develop solutions specifically for Mac and iPhone, newer and bigger companies that don’t only make apps often ship apps with logo icons, rather than app icons. We’ve all seen it.

[…]

I would love if Apple provided a way for designers to poke outside that squircle boundary. Some of my favorite app icons did that. But also some of my least-favorite app icons ignored this shape entirely, when it was used for every system icon in the last five years. Whenever those apps showed up in my Dock, it was like a stain on my shirt I couldn’t get out.

John Gruber:

Ultimately this is what I object to with the squircle mandate. It favors the bottom of the heap by restricting the top. It makes bad icons mediocre but pushes great icons toward mediocrity too. That’s not The Macintosh Way.

Nick Heer:

Mantia touches on all the pragmatic reasons to unify the shape of icons in an operating system, all of which I have considered, and then drops the above paragraphs — and things started to make more sense to me. This is a different way to think about it. This is not a situation where a cleaner looks like a zesty beverage with toxic consequences. The shared general function of these icons does help communicate something and makes them less ambiguous in that sense.

But a broad category of functionality is only part of the story of an icon and — with respect to Mantia’s long and illustrious history of work in this area, and that of co-Parakeeter Luka Grafera — taking away a difference of shape also limits what an icon can communicate. It may not be a cleaning product that looks and is packaged like juice, but imagine if every consumable liquid was in identical bottles with only a different label.

Steve Troughton-Smith:

Louie’s squircle jail post just underscores that the squircle jail benefits 99% of apps, and is better for the platform overall. There is only ever a handful of apps that make great Mac app icons, and a withering number of ‘great Mac app icon designers’ — you can probably only name one or two left in the scene.

Jeff Johnson:

Mantia talks as if it were more important for apps to “belong to the Dock” than to allow Dock users to quickly select the right app in the list. That’s choosing form over functionality.

“The shape of apps is a squircle.” But Mac users already knew those were apps in the Dock!

See also: Accidental Tech Podcast.

Tyler Hall:

If you’re lucky enough to distribute an app outside the Mac App Store, you can break free of squircle jail using NSDockTilePlugIn. It’s not strictly the intended use-case of that API. And it’s not allowed in the Mac App Store, either. But it can solve the problem.

BasicAppleGuy:

If you recognize these icons, it’s probably time to schedule your routine back exam.

Previously:

Update (2026-07-17): Louie Mantia:

But my perspective right now is to be very pragmatic. The decision to mask all icons with squircles is a long-time coming. It was perhaps the most predictable thing to happen in Apple’s history. For 20 years, it’s been leading up to this.

I want to make nice things for macOS, whatever macOS is. And this is what it is.

Roger Wong:

Some of my favorite icons over the years have had interesting shapes, like the truck for Transmit, the vise for Compressor, or the cute bird for Twitteriffic.

[…]

But I also recall clicking some icons and not being able to select them. Why? Because I was inaccurate in my click and instead my cursor landed in the empty space just outside the shape.

[…]

If I recall correctly, developers could use a different mask for the click target to help users out. But I don’t think many did all the time, including Apple, which you can obviously see in the video above.

Louie Mantia:

I don’t want to step on toes regarding your new [StopTheMadness] icon which has great color— but I don’t understand why you elected to abandon the octagon as the outer shape. That’s a choice. You are not forced to abandon it. Why not do something like this?

I like this.

Nick Heer:

Losing some of the artistry in an icon makes it more difficult to distinguish between legitimate and well-crafted Mac apps, and everything else. It is not a perfect proxy, to be sure, and there are some very nice squircle icons. But it is nevertheless a unfortunate change that makes apps of varying levels of quality look more similar.

  •  

SpamSieve 3.3.1

SpamSieve 3.3.1 is an update of my Mac e-mail spam filter that improves the filtering accuracy and includes various optimizations, fixes, and updates for macOS 27. Some interesting engineering issues were:

  • I’m still supporting macOS 10.13, but the app can now build with the macOS 12 deployment target in preparation for Xcode 27. The way Swift handles calling deprecated APIs remains annoying. You need workarounds like protocols to suppress a warning in a particular region of code. Often, I am updating to a newer API, but I want to continue using the old one on earlier versions of macOS. Right now I am heavily testing on macOS 26, so I would like to only deploy the new code there. Sometimes the initial versions of APIs are buggy, and I don’t want to have to retest every feature on every version. But Swift doesn’t like me to gate the calls to macOS 26 and later if the new API was actually introduced in, say, macOS 11.

  • The most risky update was probably switching to the Swift API for Scanner. This is tricky because the current scan position changes from being based on UTF-16 indexes to String.Index. And in some cases my code was intentionally scanning into the middle of a combining character. I was really glad to have extensive tests here.

  • Recent versions of Tahoe introduced a Core Data bug that broke save recovery (when invalid Unicode can’t be written to the database and we have to fix it up first). When the error comes in, SpamSieve looks under the NSDetailedErrorsKey key, but the value of this key is "NSDetailedErrorsKey" while the actual error info is under the key "NSDetailedErrors".

  • Database corruption combined with a Core Data bug and two Swift behaviors were causing crashes. The root problem, I think, is that in this situation Core Data neglects to set the error pointer for -[NSManagedObjectContext countForFetchRequest:error:]. Normally, Swift would detect this and throw a generic nilError. However, this method signals errors by returning NSNotFound instead of nil. It’s annotated as swift_error(nonnull_error), which I think means that Swift doesn’t even look at the return value, only the (unset) error. So my code was receiving NSNotFound on the non-error path, treating it as a real count, and doing some math with it, which (by default in Swift) leads to a crash if there’s overflow. Now my code checks for NSNotFound and uses Int.addingReportingOverflow().

  • I reimplemented Core Data batch fetching because of two problems with the fetchBatchSize option. First, it logs spurious errors when fetching from multiple stores at once. Second, it leads to high memory use. It will load objects in batches, but it never releases the earlier batches. You can manually refault objects that you no longer need, but it will still hold onto the full object shells, which can add up. My implementation only holds onto IDs, and it can fetch the IDs using a different context than the objects to push more work to background threads.

  • I’m now using String.makeContiguousUTF8() in various places to avoid slow iteration of bridged strings.

  • There was a regression where some menu code could crash on macOS 10.13. -[NSMenu setItemArray:] is only available on macOS 10.14 and later, whereas the getter is always available. With old Objective-C, the two methods could be annotated with separate availabilities. The Objective-C property syntax doesn’t allow this, so there’s no way for the compiler to flag calls where the setter is missing.

  • The AppleScript support works much better with large data sets. The key, I think, is to never return an array to Cocoa for a scripting property/element. First, if you give it a lazy array it will sometimes try to access all the elements even if it only needs a few. And, second, AppleScript will run out of memory if the array is too large. By using indexed accessors, you can maintain laziness and only convert one object to a descriptor at a time. By caching a batch-fetching collection, you can limit the number of fetches and respond quickly when AppleScript requests individual objects.

Previously:

  •  

macOS 27 Public Beta

Juli Clover:

Apple today released the first public beta of macOS Golden Gate, expanding the macOS 27 beta test to non-developers. You can sign up to test the update on Apple’s beta website, and then download it by going to System Settings > General > Software Update and toggling on the macOS 27 beta.

Jason Snell:

The fact that there are more design changes in macOS than any of Apple’s other 27 updates speaks volumes about how broken many of the Tahoe design decisions were. Apple describes the design as “even more refined,” because in Apple marketing-speak, broken features are never remedied or fixed—past features are just improved. The truth is, Apple has rolled back numerous missteps and made changes to others to mitigate the issues they caused.

Antonio G. Di Benedetto:

The Golden Gate developer beta has proven stable in my everyday use on an M5 MacBook Air and M5 Max MacBook Pro, which is notable since dev betas often have side effects like tanking battery life or causing hardware to run hotter than normal.

[…]

Would I still prefer to go back to the flatter design of macOS Sequoia? Yes, unequivocally. But at least Liquid Glass is more tolerable and less distracting now.

John Voorhees:

Nowhere is the Snow Leopard of it all more apparent than in the hundreds of little changes made to improve the day-to-day use of your Mac. I’m not going to catalog them all here, but I’ve used Golden Gate on two different Macs at this point, and based on my experiences so far, the changes are meaningful.

Jeff Johnson:

This is the crazy Finder column view file selection dragging behavior I’m seeing in the latest Golden Gate developer beta.

Matthias Gansrigler-Hrad:

With the release of the macOS 27 Golden Gate public beta, can we finally submit Mac apps built with Xcode 27?

Previously:

  •  

Sunsetting CoreStorage

Apple:

In macOS 28 and later, the Mac OS Extended file system format will be supported only for volumes (disks and other storage devices) that aren’t encrypted. For future macOS compatibility, either decrypt or reformat any encrypted Mac OS Extended volumes.

I think Apple removed the user interface for creating such volumes way back in Big Sur. It’s not really surprising that they’re going away, although only offering a year of warnings seems rather aggressive. Many people delay updating to major OS versions or wait until they get a new Mac. There will be users that switch to a Mac that can only run macOS 28 and get rid of their old one before realizing that some drive they haven’t connected in a while won’t mount.

The other surprising part is that Apple’s options—reformat or decrypt—are not great. During the initial transition to APFS, macOS would transparently convert an encrypted HFS+ boot volume to encrypted APFS without rewriting any data. This functionality is nominally still available via the diskutil apfs convert command, but Apple hasn’t mentioned this or built an automatic upgrader GUI.

[Decrypting] doesn’t apply to encrypted Time Machine backup disks.

It’s obvious why. The old Time Machine format with hard links is totally different from the new one based on APFS snapshots. But this means that you’ll either need to buy a new Time Machine drive for use with macOS 28 or delete your backup history. Even if you keep the old drive, you’ll need an older boot drive or an old Mac in order to be able to access it.

Previously:

Update (2026-07-24): Marcus Mendes:

Apple has now revised the page to add a third option, allowing users to convert an encrypted HFS+ volume directly to encrypted APFS without decrypting it first.

[…]

The company has also removed its previous instructions for decrypting the volume first, converting it to APFS without erasing it, and then optionally re-encrypting it.

Hammer:

Ignore Apple’s guidance and do not use Convert to APFS in Disk Utility for disk images.

The first encrypted HFS+ disk image I tried to convert that way failed and left me with an unusable disk image. If I didn’t have backups I’d have lost its contents.

It didn’t corrupt the disk images that I tried, but it didn’t work, either, instead failing with an error about expecting a GPT partitioning scheme.

Update (2026-07-28): Howard Oakley:

As encrypted disk images have never used CoreStorage, withdrawal of support for that has no impact on the continued use of any form of encrypted disk image, including those using HFS+ as their virtual file system.

This is a good point. Apple’s support page refers to “encrypted Mac OS Extended disks,” but the developer release notes refer to CoreStorage specifically. So this shouldn’t affect most encrypted disk images, which show up in Finder as unencrypted after mounting. The encryption is at the disk image level rather than at the file system level. However, I’m not sure that all encrypted disk images are safe. Presumably, a device image, which directly copies the blocks rather than the files, would still use CoreStorage.

  •  

Apple Sues OpenAI Over Trade Secrets

Sarah Perez (PDF, Hacker News, MacRumors):

The iPhone maker alleges that this misconduct, which it says reveals a pattern of theft from OpenAI employees who previously worked at Apple, was directed by OpenAI’s senior leadership, including Chief Hardware Officer Tang Tan.

The lawsuit, which was filed in the U.S. District Court for the Northern District of California, accuses Tan of using Apple’s confidential project code names during OpenAI’s recruiting process, asking job candidates to bring in Apple hardware components to their interviews, coaching departing Apple employees on how to evade the company’s security procedures, and asking for details about the company’s unannounced products.

Apple’s allegations are detailed and shocking, and it sounds like they have a lot of evidence.

Chance Miller:

The lawsuit names Chang Liu and Tang Tan as two of the defendants. Tang Tan served as VP of product design at Apple, leading iPhone and Apple Watch product design. He departed the company in February 2024 to work with Jony Ive. Chang Liu, meanwhile, worked at Apple for eight years and was a senior system electrical engineer before departing to join OpenAI in January 2026.

Apple’s lawsuit also names OpenAI and io Products as defendants.

OpenAI’s hardware efforts are being led by Jony Ive, Apple’s former chief design officer.

[…]

Ive, Hankey, and Cannon are not personally mentioned anywhere in Apple’s initial filing today.

Emma Roth:

Here are the most surprising claims in Apple’s 41-page filing.

Marcus Mendes (MacRumors):

OpenAI’s Director of Strategic Communications, Drew Pusateri, took to X to comment on the company’s behalf.

In his post, he claims OpenAI has “no interest in other companies’ trade secrets,” adding that OpenAI remains “focused on building innovative technology that empowers people everywhere.”

This seems like a weak response, given that Apple says it reported its findings to OpenAI in February and never heard back. Presumably, they’ve already investigated but see the situation as serious enough that they need to say as little as possible.

It’s not clear to me the extent to which Apple believes the behavior was limited to the named defendants. It’s hard to believe that the rest of OpenAI’s leadership—including Altman and Ive—were unaware, given the scale of their recruiting from Apple. It’s equally hard to believe that they were aware and thought they could get away with it. I guess little from Altman would surprise me at this point. I’d like to believe that Ive wasn’t part of it, but then are we to believe that his former coworkers all kept him in the dark?

Nick Heer:

What is immediately notable about this whole thing is the myriad conflicts of interest. Apple, of course, has a current partnership with OpenAI to power Apple Intelligence features, something repeatedly mentioned on the previous version of its marketing webpage, and conspicuously absent on the current one.

But the history runs far deeper. Among the defendants in the suit is io Products — do not blame me for that capitalization choice — founded by Jony Ive and acquired by OpenAI last May. Total mentions of “Ive” in the body of this lawsuit? Zero. Also, one of the investors in Ive’s company was Emerson Collective, founded by Laurene Powell Jobs, and which now has equity in OpenAI. Neither Emerson nor Powell Jobs are defendants.

M.G. Siegler:

It all reads a bit as if Apple has been building up evidence of these allegations for some time and recently got their smoking gun. It’s not just nebulous “trade secrets” either, there are specific mentions down to “metal finishing techniques” that Apple apparently invented and protected.

It also comes a little less than a month after OpenAI was rumored to be threatening Apple with a lawsuit over the perceived failure of their deal to bake ChatGPT into the iPhone. As I wrote at the time, even just that threat was clearly not going to go over well in Cupertino.

John Gruber (Mastodon):

Footnote 13 on p. 15 states:

Apple and OpenAI have a commercial relationship involving the integration of OpenAI’s ChatGPT into Apple Intelligence. The companies have entered into a written agreement governing that integration. That agreement is not at issue here. OpenAI’s acts of trade secret misappropriation alleged herein do not arise from and have no connection to that agreement.

Be that as it may legally speaking, in practical terms it seems untenable for that Apple Intelligence partnership to continue after this.

Jason Snell:

All that bubbling-under-the-surface tension between Apple and OpenAI is now out in the open!

M.G. Siegler:

Namely, while Apple frames OpenAI – or at least its fledgling hardware division – as “rotten to its core” (interesting terminology!), they really only have a case against two and maybe three individuals. But they also clearly believe that if this case goes to trial, they will have a case against a lot more.

[…]

The parallels to the Anthony Levandowski situation after he left Google for Uber have been drawn.

[…]

It is interesting that Apple is not suing Yu-Ting “Alyssa” Peng, who is named in the suit as a co-conspirator with Liu while she was still employed at Apple, before she also subsequently went to work at OpenAI. Is it possible she’s cooperating or has cooperated with Apple in this investigation?

[…]

Even if these allegations are found to be untrue or embellished, can he reasonably stay at OpenAI now? And perhaps that’s the real outcome Apple is looking for here, as they clearly frame him as the ringleader of the 400-plus people who have come over to OpenAI from Apple.

Hartley Charlton:

OpenAI’s ambitions to build a hardware rival to the iPhone are already running into trouble because of Apple’s trade secret lawsuit, according to Bloomberg’s Mark Gurman, who argues the damage is showing up well before any court ruling.

[…]

The scale of the talent drain is a major part of why this matters to Apple. More than 400 former Apple employees now work at OpenAI, including former Apple design chief Jony Ive, and Gurman says the company poached so heavily from Apple’s iPhone product design group specifically that Apple had to rebuild parts of the team. Apple has responded with bigger retention bonuses and executives personally working to keep engineers from leaving.

Jeff Johnson:

OpenAI stole stuff? I can’t believe it! I thought they were done with stealing after they stole literally everything on the internet.

Colin Cornaby:

I’m sure there’s no problem with sending this company all your source code they pinky swear not to train on.

Steve Troughton-Smith:

I can’t believe this awful company solicited confidential information and stolen trade secrets, hiring from this other company while pretending to partner with them. ‘Rotten to the core’ indeed

😛

He’s referencing Apple doing this to Masimo. And, of course, Steve Jobs himself directed Apple to engage in illegal hiring practices.

Previously:

Update (2026-07-17): See also: Dithering.

Tim Hardwick (FT, Hacker News):

Apple has reportedly sent legal letters to dozens of former Apple employees now working at OpenAI, telling them to preserve potentially relevant documents and communications as it continues to pursue its trade secret lawsuit against the AI company.

Update (2026-08-06): Hartley Charlton (PDF):

OpenAI has asked a federal judge to dismiss Apple’s lawsuit accusing the AI company of stealing trade secrets, calling the allegations “meritless.”

Previously:

  •  
❌