Apple might have undone the macOS Tahoe menu icons decision, but this wasn’t the only contentious iconography issue in their ecosystem.

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:

This over-emphasis on “systems” design seems endemic to modern software. Systems prescribe rules because they are the easiest attributes to document, enforce, and automate — “All icons must use this shape, this lighting, this stroke.” Excellence, by contrast, is harder to systematize. It requires judgment, taste, care, experience, and a sensitivity to context — all in service of meaning and purpose, not superficial similarity.

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:

Elsewhere, on Rogue Amoeba’s blog, Paul Kafasis straight up asks Apple to undo the 2025 decision to contain macOS icons inside squircles:

Apple’s prohibition on shapes is a step backward for both usability and creativity in app icons. Icons are now harder to distinguish because they’re no longer allowed to be distinctive. But there’s no technical reason for it. Apple could, and should, once again allow icons to take on a wide variety of shapes.

Both these prompted me to think a bit of Apple’s app iconography as a system.

Let’s start with iOS:

• I believe the rigid squircle shape of app icons starting with the first iPhone was to make them look like a grid of buttons, and also to establish apps as a new primitive, particularly with the subsequent arrival of the App Store. (Similarly how over time “a face in a circle” became recognizable as a “personal avatar,” a user proxy primitive.)
• Soon, the rigid shape also helped when custom Springboard wallpapers arrived in 2010 – it reduced the likelihood of apps blending with the background.

• Recently, a new option has been added to remove names of apps, which is another way to disambiguate them.

• Also recently, Apple’s generally unpleasant-looking theming options (color tinting and glassification) reduced color coding as a way to recognize a particular icon.

At the same time, iOS is still highly spatial. Most apps have a specific physical place on a specific page of the Springboard, or inside a specific folder. I believe that this helps a lot even if shape coding, color coding, and name disambiguation are failing or turned off to begin with.

Now, for MacOS:

• The original Mac OS X followed in the footsteps of the classic Mac OS and allowed arbitrary shapes, allowing for more flexible shape coding, although with some guidance on angles and styling:

• However, more recently, the iOS squircle shape has been first strongly suggested (in 2020) and then rigidly enforced (in 2025) for macOS as well.

But then, the usage of app icons in macOS is different than in iOS.

First of all, macOS isn’t nearly as spatial as it used to be, and I would say not as spatial as iOS. Even Dock is more malleable compared to the memory palace rigidity of the Springboard, and its overflow section with suggestions and hand-off is very fluid. ⌘Tab is completely non-spatial and just like the Dock doesn’t upfront identify apps by their names. App icons also appear in more fluid contexts like Spotlight, Finder, and the right side of the menubar (I know iOS has some of those as well, but I would imagine they’re getting much less use overall). This all increases the pressure on icons to be easily distinguishable.

At the same time, there are fewer issues with custom backgrounds on macOS. Most icon surfaces have opaque backgrounds and while you can keep your apps on the desktop or put backgrounds in Finder windows, I don’t think that’s very common.

I’m probably missing some other aspects, but this would be my summary of where we’re at:

• Apple has not done a good job shepherding their app iconography system. The system feels too rigid, and some of its ostensible benefits (dark mode, color tinting, glassification) have been executed poorly. You could imagine a better tinting system that doesn’t feel like a cheap CSS filter applied to the icon, or (my dream!) a way to tint individual app icons. I personally love when apps – here Raindrop, Bear, and Retro – give you a lot of icon options in various colors, so I can invest in color coding:

• People’s trust in Apple’s skillset has deteriorated after the unveiling of horrendous icon redesigns in 2025’s Tahoe, and more recently in the abovementioned Creator Studio (the 2026 updates are nice, but very minor). This is in some contrast with other controversial visually-motivated changes appearing at the same time. Say what you want about Liquid Glass, but there are moments it looks absolutely gorgeous (see the video below for perhaps my favourite Liquid Glass surface). Forced menu icons felt similar: embarrassingly naïve as a system, but with icons themselves executed well (which you can still appreciate when perusing SF Symbols). But the app icon changes seem to have been assigned to the team that delivered on neither good visual craft, nor good systems thinking.

• I think it’s fair to look at Creator Studio specifically, and fear Apple is following in Microsoft’s and especially Adobe’s unforgivable footsteps in prioritizing abstract corporate identity goals over both functional and visual aspects of app iconography. Adobe’s product icons used to be beautiful and distinct before they got all shoved into the same “uppercase + lowercase letter” framework that became a canonical example of a system that took something away from the user but didn’t really give anything in return:

• I also feel this feeds right into another fear of Apple’s actions steamrolling over particularly indie app developers where being able to express one’s identity via the app icon feels much more important than it would be for a huge company.
• I don’t see Apple abandoning their stance on the rigid, distinctive app icon squircle shape. It’s possible that iOS apps will start appearing on touchscreen Macs outside of screen mirroring. Even without that, it just simplifies things for them, even if the jobs for macOS app icons are not the same as those for iOS app icons.
• At the same time, I could see Apple allowing the app icons to stick out of the basic squircle shape, like some macOS apps did in between 2020 and 2025; I believe it would even be possible to detect programmatically if the basic squircle shape is still there in the background. This would improve shape coding, and give icon designers some clearly much-desired flexibility. The icons below still register as squircles to me – why not allow this as an option? (For both macOS and iOS.)

• I wish Apple standardized app icon changing UI on iOS. Right now, each app offers their own interface in a different place – you could see that above – and rarely links to that place from the Springboard’s long-press menu. But imagine if you could nicely change app icons in situ in the same flow when you’re customizing the Springboard itself! (And then, the same for Dock and macOS.)
• I think it would also be a nice gesture to allow to rename iOS Springboard apps to whatever you want the same way you can rename folders, to give some users an opportunity to disambiguate by that if everything else fails.

John Gruber on Daring Fireball:

Perhaps the worst UI crime in MacOS 26 Tahoe was the inexplicable decision to add inscrutable, distracting icons next to every item in the menu bar. You will recall Jim Nielsen writing about it, rightly describing it as exactly the sort of thing that Mac users look down upon in platforms like Google Docs and Windows. You will also recall Nikita “Tonsky” Prokopov writing about it, illustrating that the bad idea wasn’t even implemented well, with different Apple apps using entirely different icons for the same menu items. […]

Top third-party developers rightly rejected the design, adopting open source code from Brent Simmons to disable the default “icons in all standard menu items” behavior. […]

Wonderful news in MacOS 27 Golden Gate: the icons are gone. It’s like Tahoe’s menu item icons never happened.

Kudos to Nielsen and Prokopov for pushing on this and explaining the problem so well. This wasn’t about ugly icons. This was about improper use and misunderstanding of iconography.

(Also may I try to manifest something:) Looking forward to reading the oral history of macOS 26 Tahoe and Liquid Glass some time in the 2030s!

Two nice follow-ups to topics we covered before.

In February, Nobert Heger did some analysis of precisely which pixels in Tahoe are intercepted by mouse when trying to resize a window. In April, Steve Ruiz, author of tldraw, did this more extensively for all the drawing apps like Canva, Figma, Illustrator, and so on:

When a user has one or more shapes selected, we display an interactive overlay that allows the user to transform their selection: a drag inside the box will translate the selection; a drag on the edges will resize along that axis; a drag from the corner will resize along both axes; and a drag from further out on the corners will rotate the selection.

Like many features in tldraw, my design here was meant to follow the conventions of design tools. This meant a broad survey of other applications, both new and old, reconciling differences between them, and picking a design that I felt best served the user while remaining conventional.

Remember the “if you put the Apple icon in reverse” joke from January? Last month, Jim Nielsen on his blog pulled on that thread and showed a few more examples:

Some 3rd-party apps continue to fight a good fight, even as Apple’s definition of what an icon should be — or what’s even possible — shrinks all around them.

One finding from this blog post for me was that things changed. In Big Sur, the squircle form factor was encouraged, but not enforced. Well, it is enforced now, when even shapes very similar to the squircle are now inside “the gray box of hell”:

These gray boxes are not some pedestal for icons. They’re the actual icons.

Anyway, I always appreciate efforts of people methodically documenting things so we can all learn and notice patterns and/or continue the work from the best possible starting point.

The biggest smallest GUI design schism between Apple’s platforms and Windows isn’t the black vs. white cursor or where to put the menu bar. It’s the presentation of keyboard shortcuts.

On a Mac, the shortcuts are iconographic. Command is ⌘. Option is ⌥. Shift is ⇧. Control is ⌃. Fn is 🌐. There are also icons for all the other non-printing keys, from the relatively well-known Tab (⇥), through the perennially confusable End and PgDn (⤓ and ⇟), to the absolutely cryptic Esc (⎋).

On Windows, the keyboard legends are mostly text. PC lost the icon battle in the early 1980s – IBM had them on their 1970s computers, worldwide, but apparently American users of the early IBM PC hated them – and the names are spelled out (Shift and Enter and Home), or close to it (Ctrl, Esc, PgDn, Prt Sc).

Why did Apple go this way? My speculation is the revered Braun and generally hi-fi hardware: a lot of stuff sold in Europe defaults to iconography in part because that makes exporting easier. Icons are also more compact – putting ⇧⌘C in a menu or a tooltip takes up a lot less space than Shift+Ctrl+C – and more beautiful when done well. Here’s Figma’s right click menu on Mac and Windows:

But there are also challenges, as icons are more cryptic and confusing. “Command” tells you something about itself out of the box, but “⌘” is completely abstract. (Arguably, only arrow keys and symbols like ⇥ and ↵ explain themselves visually.) The attendant issue is that icons are hard to talk about if you don’t know their names, hence tons of jargon like “propeller,” “splat,” or “beanie” for ⌘, for example.

It’s a hard situation. Here is one of Mac’s own menus being thoroughly inconsistent, and an example of CleanShot using both the icon and the label to be sure:

“Why not both” seems to be the best way in places you can afford it. Apple started doing that on the keyboards too, but it took them decades to get there for modifier keys alone. Even on the 2026 computers, many other keys like Esc and Tab are still single-legended:

With all that in mind, I want to show you what I saw the other day in Google Docs, on my Mac:

This is one of those cryptic things that I would love to understand the thinking behind. Because, on the surface, this breaks so many rules:

• A strange hybrid of Mac and Windows styling: some modifier keys are spelled out, and the others are iconographic. (It’s very strange to see ⌘ conjoined with others using a plus!)
• Complex and generally uncommon dual key shortcuts – to collapse the sidebar, you really need to press ⌃⌘A and then press ⌃⌘H, in sequence.
• Three-modifier-shortcuts are in general really unpleasant and Google Docs does not seem complicated enough to warrant them.
• (You can’t see that, but they’re also unreliable! ⌃⌘A ⌃⌘H doesn’t always work and seems to depend on where the focus is.)

There is also a visual argument that cannot be ignored. We’ve been there once before; if in your menu keyboard shortcuts start overwhelming the commands themselves, you are probably doing something wrong.

The only explanation for this I can think of off the top of my head is this: these were invented somewhere else (Word?) and inherited by Docs to respect motor memory of the users transition from the older app. That still doesn’t cover the presentation, plus there is a way for Docs to redesign the shortcuts to be better for people who are starting anew.

Ultimately, I think all of this also breaks a cardinal rule: it makes keyboard operation feel more scary and intimidating than it needs to be. Shortcuts are scary enough on their own, and they don’t need any help in this area.

Since the early 2000s, Mac OS X had a few orientations of icons depending on whether they were applications, files, utilities and so on:

In 2020, macOS Big Sur unified those styles and made them more iOS-like:

A few years later, Jim Nielsen revisited the icon “Big Sur-ification”, and showed examples of apps that did the transition really well, but also those where the transition felt… lazy, essentially shoving their previous icon into a roundrect.

For those, Nielsen proposes some alternatives that are delightful to see:

The Word/​Excel/PowerPoint/​Outlook explorations are particularly nicely done.

★★★★★ (as books)
★★★★☆ (for the purposes of this blog)

I still remember Mac OS X arriving on the scene with icons that felt infinite in every possible way: in size, in color palette, in dimensionality. We got used to them over the last quarter century, but Michael Flarup’s books rekindled that feeling for me; the icons presented here are lavish, larger than life, and basically pixel-less.

I do not generally like coffee-table books. But I really liked these. The iOS App Icon Book came out in 2022, and the macOS App Icon Book followed two years later. They’re “almost-coffee-table” – which is a compliment! – extremely well-made but portable, and with soul, and thoughtful details, and inspiring evidence of being labours of love.

Each one has an almost-absurd amount of icons (I counted almost 1,200 in one book, and consequently didn’t even attempt counting in the other), but it’s not just the quantity that impresses. The icons are laid out carefully on gorgeous color-coordinated spreads. Many appear in variations so you compare their evolution over the years. Each one is big enough and printed so well you can study it in detail, and I have not noticed one technical flaw in their reproduction.

In addition to beautiful collections of beautiful icons, the book also veers a bit into history, and design advice, and adds ~10 interviews with icon designers each. Those are welcome additions that elevate the books from a boring coffee-table existence, but those are also its weakest parts – although “weakest” in a comparative sense. The things missing for me in the book are: more work in progress and rejected efforts, more specific advice and hard-learned lessons rather than general-interest interviews, a bit more about recognition of icons when reproduced small on screens, and some harder/​cerebral conversations about iconography and its place in the universe.

On the other hand, I know that of all icons it’sapp icons that get to be least concerned with semantics and semiotics, as they’re maybe the closest to just pure art and graphic design. I can understand how talking through it all would be an extremely hard task; all of the fantastic icon designers I know personally would struggle with explaining why their output is better than others. It’s possible the extra “left-brain” stuff I want from these books would also make them less desirable for those who just seek visual or artistic inspiration.

Both books are otherwise basically a love letter to app iconography, and awash in memorable details: delightful covers, colour-coordinated ribbon bookmarks, beautiful ex librissen, and a product index and an artist index.

The price – $84 without shipping (they’re printed in Denmark, so for once Europe gets an advantage) – might be a bit of a showstopper. The books are well-made, but you are definitely paying a premium for a short/​bespoke print run. The volumes complement each other well on a shelf, but you’ll do no wrong with getting either one if two is too much for your budget. (There is also a half-price PDF version, if that’s of interest to you, but I cannot vouch for that.)

Just a few hours after writing about floppy disks, I stumbled upon a bona fide floppy icon in the Bluesky’s iOS app, anno domini 2026:

I imagine this, in a nerdy view deep inside settings, might be more of a fun nod, but it made me curious – does Word still use a floppy icon?

Yes, it does! Right next to the icon-less AutoSave toggle, deep within a veritable kowloon walled city of interface elements.

And yet, maybe I should chill with the jokes – NN/Group revisited the save icon in July of last year and surprise! People still understand them.

83% of participants associated the floppy disk icon with saving. […] Another 13% described this object literally with responses such as “disk,” “disc,” or “this is an SD card for storing information.” These responses were not coded as “save,” but still suggest familiarity with the image.

What a fascinating journey! The icon didn’t change at all, but its perception went from being a literal representation of a familiar object, to a skeuomorph once floppies were replaced by hard drives, to then a symbolic representation of physical media in general (a lot of people think it’s an SD card – or perhaps even that floppy disks and SD cards are one and the same), to increasingly just an abstract symbol that represents saving as a concept, registering similarly to the circular arrows for syncing, and an arrow pointing south for downloading.

NN/Group is itself kind of a floppy disk, trying to walk a fine line between their legacy and reinventing themselves. They’re dismissed by many as old-school, academic, boring enterprise software aficionados, relics of a different era. I see some of that and often disagree with them, but I also sometimes appreciate their rigor, reliance on user studies, and outright dismissal of fashion in UI design. I want to revisit their site in more detail and see how I feel about it today, 30 years after Jakob Nielsen’s books rocked my world.

A great post duet from Craig Hockenberry that flew by on Mastodon and clarified something for me:

[For] the extra work to create a custom SF Symbol, our experience is 8-10 hours per symbol. This is also an expert level task: lots of knowledge on how SVG control points work and how to maintain compatibility across different sizes and weights.

If you’re paying a designer to do this, the cost will be somewhere in the $1000-2000 range. For Apple this is an easy cost to absorb, for smaller developers it’s a big “nope”.

And, of course in the Mac menubar (and now iPadOS) you need a lot of them.

Another subtle example of how out of touch Apple Design is with day-to-day development.

So not only is the overiconification of menus in macOS and iPadOS a bad idea, but it’s also expensive. You could make an argument that it would push people into reusing SF Symbols – ergo “consistency” – but that would land better if we haven’t already seen even Apple is struggling with that on their own (previously, previously).

Savage from heliographe.studio on Threads (via Daring Fireball):

I have been wondering the other day why aren’t there more mouse pointer museums and here’s one – Amiga Pointer Archive! (Amiga was a 16-bit home computer especially popular in Europe.)

Doesn’t work so well on mobile, but it’s fun on desktop. I recommend zooming the page to 200%.

Yet another good post by Nikita Prokopov, continuing the theme of icons in Mac OS Tahoe (previously), going into more depth:

In my opinion, Apple took on an impossible task: to add an icon to every menu item. There are just not enough good metaphors to do something like that. ¶ But even if there were, the premise itself is questionable: if everything has an icon, it doesn’t mean users will find what they are looking for faster.

I always liked this kind of an exercise:

There’s a game I like to play to test the quality of the metaphor. Remove the labels and try to guess the meaning. Give it a try:

Also, this must hurt:

Microsoft used to know this.

Nick Heer at the excellent Pixel Envy, commenting on the above post, adds:

This is a gallery of elementary problems. None of this should have shipped if someone with power internally had a critical eye for consistency and detail. If Apple deems it necessary to retain the icons, though I am not sure why it would, it should be treating this post as one giant bug report.

Thank you to Scott and Ezra.

A funny 12-minute video by Chris Spargo about why traffic signs in the world are standardized only to some extent. This was interesting to me generally in the context of Europe being more iconographic, and America being more “word-y” in their sign design, which extends to devices, keyboards, and (presumably?) software.

The story why [the old STOP sign] got replaced by the American version is also the story why the rest of our signs still look different, and why they probably always will.

A good post by Jim Nielsen about icons in menus (in Tahoe).

This posture lends itself to a practice where designers have an attitude of “I need an icon to fill up this space” instead of an attitude of “Does the addition of a icon here, and the cognitive load of parsing and understanding it, help or hurt how someone would use this menu system?”

It seems a necessary ingredient of introducing icons to menus is thoughtfulness and guidance around when the icons are necessary/​useful and when not.

It doesn’t help that the Tahoe icons seems to mess up indentation. (I haven’t updated to Tahoe and might skip it altogether. Even just the planetary-scale rounded corners are something that feels very broken.)