Over the past couple of weeks, I’ve been trying to make sense of Apple’s latest user-interface redesign — Apple calls it Liquid Glass — that will affect all their platforms in the next iteration of their respective OS versions. But it’s hard to make sense of it when, after checking Apple’s own guidance, I’m mostly left with the feeling that at Apple they’re making things up as they go.

If you’ve been following me on Mastodon, you’ll be already familiar with a lot of what follows. I just wanted to gather my posts there in a more organic piece here.

Let’s start with a few notes on Adopting Liquid Glass, part of the Technology Overviews Apple has made available on their Developer site.

In the Navigation section, we find this figure:

The text above it says:

Key navigation elements like tab bars and sidebars float in this Liquid Glass layer to help people focus on the underlying content.

Now take a look at the area I’ve highlighted in the image. Why would you want to “focus on the underlying content” here? Tab bars and toolbars still cover the underlying content, and the more transparent/translucent they are, the worse. When something fades to the background, it literally ceases to be in the foreground, so there’s no point in focusing on it. This is like proposing an interface that helps you focus your sight on your peripheral vision.

Below the figure, in the paragraph starting with Establish a clear navigation hierarchy, developers are advised to:

Ensure that you clearly separate your content from navigation elements, like tab bars and sidebars, to establish a distinct functional layer above the content layer.

Which is in direct contrast to what you’ve just shown on the image above. First you propose to blur the lines between controls and content, then you advise to “clearly separate your content from navigation elements”. Which is it? If you stop and think, it’s ironic that Ensure that you clearly separate your content from navigation elements, like tab bars and sidebars, to establish a distinct functional layer above the content layer is the exact description of what’s happening in the ‘Before’ image!

Moving on, we get to this figure related to the Extend content beneath sidebars and inspectors paragraph:

In other words, create the illusion of an image that extends under a sidebar, and while you won’t actually be able to see the part of the image under the sidebar, on the other hand the transparency effect applied to the sidebar will make the text on it less legible overall. A great lose-lose situation, visually, don’t you think? Also, this might be just a matter of personal perception, but to my eyes, the blank area below the image you can see behind the sidebar looks weird, as if there’s something missing.

In Organisation and layout we find this:

To give content room to breathe, organizational components like lists, tables, and forms have a larger row height and padding. Sections have an increased corner radius to match the curvature of controls across the system.

Which is largely unnecessary. It reduces the amount of information displayed on screen, and you’ll have to scroll more as a consequence. Look at the Before and After layouts: the Before layout doesn’t need solutions to increase its clarity. You’re just injecting white space everywhere. It’s also ironic that where more space and ‘breathing room’ are actually necessary, the header (“Single Table Row” in the figure) is pushed even nearer to the status bar.

And don’t get me started on those redesigned, stretched-out switches. They’re the essence of ‘change for change’s sake’.

Then I went to have a look at the current Human Interface Guidelines and I still can’t get over that introduction:

Let’s start with Hierarchy: “Elevate and distinguish the content beneath them”: is this really the role of controls and interface elements? Should content and controls even occupy the same space? Should the lines be blurred between them?

In my opinion, the best way both controls and content can shine is by having each their own space: controls are out of content’s way, letting it shine and helping the user focus on it. And in their own space, controls can be clear, neatly organised, ready to be accessed in order to manipulate the content.

Next, Harmony:

Align with the concentric design of the hardware and software […]

No, seriously, how does one align in a concentric context? Is that a matter of picking a circle, an arc, a shape? All snark aside, this just sounds poorly worded to me. I get what Apple means here: in your app design, you should pick shapes that resemble the contours of the hardware — the shape of a MacBook’s display and bezel, for example — and the typical shapes that you find in the system’s UI. Pretty obvious stuff that’s wrapped in ‘pretentious designer vocabulary’.

Last but not least, Consistency:

[…] to maintain a consistent design that continuously adapts […]

The definition of consistent is something that is “unchanging in nature, standard, or effect over time”. So, how does a consistent design continuously adapt?

This paragraph should have read something like: Adopt platform conventions to create a design that remains visually and functionally consistent across window sizes and displays.

In the Design section of the guidelines for App icons, we find this:

Find a concept or element that captures the essence of your app or game, make it the core idea of your icon, and express it in a simple, unique way with a minimal number of shapes. Prefer a simple background, such as a solid color or gradient […]

Not only is this the recipe for blandness, it’s also borderline contradictory. Like, Make a unique dish using a minimal number of simple ingredients. While it’s possible to make a few different dishes using just two or three things, you touch the ceiling of uniqueness and variety pretty damn soon.

Another thing that irks me about this obsession with icon simplification is that when you abstract things this much, you dilute their meaning instead of distilling it. Take the progressive degradation of the Dictionary icon, for example. In its subsequent iterations (as soon as it loses the ‘book’ shape), it could just be the icon for a font managing app. Because it ends up losing a lot (if not all) of its uniqueness.

This image is taken by this post on the history of some of Mac OS icons by Basic Apple Guy. Go take a look at that post and you’ll see a pattern emerge with application icons: they get progressively abstracted to the point that they barely represent what they should represent: the icon for Stickies goes from being an actual depiction of a few yellow sticky notes to being some small vague rounded rectangles inside a clear rounded rectangle. The icon for Notes goes from representing an actual notepad to being a flat square with two lines and a coloured top area. The icon for Calculator, same thing: from depicting a calculator to being what looks more like a security keypad. Game Centre: from an icon representing different types of games, to… a group of colourful bubbles.

The most recent iteration of Migration Assistant’s icon is yet another example:

Migration Assistant icon in Mac OS 15 Sequoia (left) and how it appears in Mac OS 26 Tahoe Beta 2 (right)

Look at it. It’s utterly meaningless. Maybe it can work in an airport to mark an emergency exit or something. The old one is so simple and clear. From an ‘old, now inactive’ system to a ‘fresh new one’. Migration, indeed. Right there. All while preserving the Mac identity. This once again feels like changing things for change’s sake and nothing else.

I’m pretty sure that if you were to interview one of the designers at Apple responsible for this icon devolution, they would say something about reducing icons to their essence. To me, this looks more like squeezing all life out of them. Icons in Mac OS X used to be inventive, well crafted, distinctive, with a touch of fun and personality. Mac OS X’s user interface was sober, utilitarian, intuitive, peppered with descriptive icons that made the user experience fun without signalling ‘this is a kid’s toy’.

Same for NeXTSTEP, from which Mac OS X originates. Here, some icons have a more 3D effect, others are flatter; some are logos (like the icon for the Webster’s Dictionary), others are descriptive to a fault (the user’s Home folder is an illustration of a tiny house), but they’re instantly memorable. They do what icons are supposed to do and they take full advantage of the high resolution monitors NeXT sold for their workstations (also remember that some of those monitors were greyscale, so icons had to work even with limited palettes).

In recent years, the reverse has happened: Apple has been infantilising and dumbing down Mac OS’s user interface in order to be more similar to simpler mobile devices and to their UIs, while transforming the icons into something bland and ‘corporate’.

But it gets worse.

In the iOS 5 days, the HIG for icons weren’t too restrictive, apart from some basic requirements and guidance. This gave developers plenty of freedom, and the results (if you exclude the usual trash apps) were tasteful and varied; some opted for a rich, skeuomorphic look; others for flatter designs; others for something in between. Apps were instantly recognisable.

Now Apple gives you the option of removing colour and depth to all icons. To make everything look samey and nondescript…

…So that you can “complement your wallpaper.”

On my main Mac I’ve left the default Ventura wallpaper because the only time I see it is when I wake the Mac mini from sleep and I’m presented with the Login screen. People who actually work with computers and mobile devices don’t stare at wallpapers and matching icons.

But it’s not just that, it’s that these ‘Icon Appearances’ also remove colour, depth, and personality from third-party app icons too. This further dictates (and interferes with) what kind of design a third-party developer may choose for their apps. All this after recommending employing “a minimal number of shapes” and “prefer[ring] a simple background”.

As C.M. Harrington rightly notes:

I’ve said this before, but Apple is forcing third party devs to be in service of Apple. The guidelines and rules are meant to sublimate the brands of the third party, and replace it with Apple.

And I also must quote Louie Mantia who, in his brilliant piece Rose-Gold-Tinted Liquid Glasses writes (emphasis mine):

Apple has effectively infinite resources and operates on their own timeline, but everyone else does not have this kind of luxury. Springing big changes like this all at once forces so many independent developers, entire companies, and the industry as a whole to freeze their own development schedules to accommodate Apple’s design system.

It’s asking a lot. For almost nothing in return. I keep looking at all the changes Liquid Glass brings, and I cannot find one instance where it has markedly improved the experience in any way.

Everything that got rounder—except for the things that didn’t — why? Everything that got inset that wasn’t before — why? Everything that is now blurry — why? I don’t think it’s a secret that the content area of some apps decreased. The margins and padding increased — except where it didn’t.

In some ways, there’s almost more UI variance than there was before, which doesn’t make any sense. But in other ways, everything feels far more restrictive than it once was. Which I admit, also doesn’t make much sense. App icons weren’t just more expressive on OS X, they could be a much wider-range of materials than merely glass.

I know I can still draw anything I want within that square, and that the glass appearance on objects inside of it is purely optional. But the edge of every icon now has a glass appearance I can’t do anything about. If my icon is paper, wood, metal, or—god forbid—leather? It has a glass specular highlight. On macOS, it’s currently locked at a 45° angle. Which is not something I agreed to.

Swinging for the fences like this comes with substantial risk. Especially for matured products like macOS. This product is almost 25 years old, and I would hope there would be a little more caution when expecting effort from and forcing changes upon a developer community you’ve largely lost your goodwill with. These kinds of decisions have long-lasting effects and I’m sure many developers would’ve appreciated their time being considered before asking them to incorporate a design they did not sign up for.

And in the paragraph just preceding this section I’ve quoted, Mantia writes (emphasis his):

In a way, one could say Liquid Glass is like a new version of Aqua. It has reflective properties reminiscent of that. One could also say it’s an evolution of whatever iOS 7 was, leaning into the frosted panels and bright accent colors. But whatever Liquid Glass seems to be, it isn’t what many of us were hoping for.

Mantia’s piece is so good it’s difficult to extract a few quick quotes. Please take your time and go read it in full.

In Adopting Liquid Glass there are a few passages that unequivocally convey the message that Apple is in control of your app’s appearance (or part of it). Take for example this, in the Visual Refresh section:

Any custom backgrounds and appearances you use in these elements might overlay or interfere with Liquid Glass or other effects that the system provides, such as the scroll edge effect. […] Prefer to remove custom effects and let the system determine the background appearance […]

Or this, under App icons:

Let the system handle applying masking, blurring, and other visual effects, rather than factoring them into your design.

Compare and contrast this with the language used in the 2010 iOS Human Interface Guidelines under Application Icons:

Try to balance eye appeal and clarity of meaning in your icon so that it’s rich and beautiful and clearly conveys the essence of your application’s purpose. Also, it’s a good idea to investigate how your choice of image and color might be interpreted by people from different cultures.

After recommending to create different sizes of your application icon for different devices, the guidelines note that

When it’s displayed on an iPhone Home screen, iOS adds rounded corners, a drop shadow, and a reflected shine.

But:

You can prevent iOS from adding the shine to your application icon. To do this, you need to add the UIPrerenderedicon key to your application’s Info.plist file […]

Sure, even back then there were visual requirements for icons, but I wouldn’t define this short list as particularly restrictive:

Ensure your icon is eligible for the visual enhancements iOS provides. You should produce an image that:

• Has 90° corners
• Does not have any shine or gloss (unless you’ve chosen to prevent the addition of the reflective shine)
• Does not use alpha transparency

The language in these guidelines from 2010 strikes me as supportive, like in this passage:

Create a 512×512 pixel version of your application icon for display in the App Store. Although it’s important that this version be instantly recognizable as your application icon, it can be subtly richer and more detailed. There are no visual effects added to this version of your application icon.

The language in the Adopting Liquid Glass document is overall more prescriptive and impersonal, and as I was reading all the various recommendations, I couldn’t help but feel the underlying message, We created this beautiful look based on glass effects, don’t you dare ruin it with your custom designs, effects, materials, brand identity.

The language in the current guidelines for app icons isn’t much different. It also reflects Apple’s current philosophy of ‘keeping it simple’ which, out of context, could be valid design advice — you’re designing icons with small-ish dimensions, not full-page detailed illustrations for a book, so striving for simplicity isn’t a bad thing.

And yet — and I might be wrong here — I keep reading between the lines and feel that these guidelines are more concerned with ensuring that developers maintain the same level of blandness and unimaginativeness of Apple’s own redesigned app icons:

Embrace simplicity in your icon design. Simple icons tend to be easiest for people to understand and recognize. An icon with fine visual features might look busy when rendered with system-provided shadows and highlights, and details may be hard to discern at smaller sizes. Find a concept or element that captures the essence of your app or game, make it the core idea of your icon, and express it in a simple, unique way with a minimal number of shapes. Prefer a simple background, such as a solid color or gradient, that puts the emphasis on your primary design — you don’t need to fill the entire icon canvas with content.

Going back to the Mac OS X Human Interface Guidelines from 2009 is like entering a different dimension. The chapter dedicated to icon design starts off like this:

Aqua offers a photo-illustrative icon style — it approaches the realism of photography but uses the features of illustrations to convey a lot of information in a small space. Icons can be represented in 512×512 pixels to allow ample room for detail. Anti-aliasing makes curves and nonrectilinear lines possible. Alpha channels and translucency allow for complex shading and dimensionality. All of these qualities allow you to create lush, vibrant icons that capture the user’s attention. […]

Icon genres help communicate what users can do with an application before they open it. Applications are classified by role — user applications, software utilities, and so on — and each category, or genre, has its own icon style. Creating icons that express this differentiation helps users distinguish between types of icons in the Dock.

For example, the icons for user applications are colorful and inviting, whereas icons for utilities have a more serious appearance. Figure 11–2 shows user application icons in the top row and utility icons in the bottom row.

You may argue that these are simply different icon design guidelines from different eras reflecting different tastes and aesthetic sense, and that it’s not a matter of one being better than the other, or a matter of right versus wrong, and I’ll concede that. But the older guidelines were informed in such a thoughtful way as to give third-party developers a lot of room for creativity and a wide range of choices while remaining within the required system-wide aesthetics of the time. If you look at the Figure 11–2 above, you could have very illustrative icons like the ones for Disk Utility (the hard disk with a stethoscope) or Front Row (the theatre armchair), but also more minimalistic designs such as the icon for the Terminal and AirPort Utility applications.

Tangentially, I found this bit ironic given where we are now:

Use transparency only when it is convincing and when it helps complete the story the icon is telling. You would never see a transparent sneaker, for example, so don’t use one in your icon.

This piece of advice is reiterated in the 2013 edition of Mac OS X’s Human Interface Guidelines:

Use transparency when it makes sense. Transparency in an icon can help depict glass or plastic, but it can be tricky to use convincingly. You would never see a transparent tree, for example, so don’t use one in your icon. The Preview and Pages app icons incorporate transparency effectively.

Also, since the introduction of retina (high-resolution, high-density) displays in 2012, this part was added in the HIG:

Take Advantage of High-Resolution Display

Retina display allows you to show high-resolution versions of your art and icons. If you merely scale up your existing artwork, you miss out on the opportunity to provide the beautiful, captivating images users expect. Instead, you should rework your existing image resources to create large, higher-quality versions that are:

• Richer in texture
• More detailed
• More realistic

The aesthetics for icon design may have changed dramatically in the intervening years, but I just find it sad that, with the gorgeous displays we have today, Apple recommends simple designs made out of a few boring shapes, and everything is now in service of a ‘liquid glass’ effect the system superimposes on every aspect of the user interface — as if this surface gimmick is more important than the elements it distorts.

I’m sorry to sound like a broken record by now, but this is, once again, form before function, looks before workings. And don’t bother deviating from this new norm, because your app will be assimilated.