← Back to list

Many Teams Will Apply Liquid Glass the Wrong Way: After WWDC26, the Real iOS Design Lesson Is Not…

As of June 13, 2026, after reading the current WWDC26 materials, I think the easiest mistake people can still make about Liquid Glass is to…

Hasan Ali Siseci · 2026-06-13 23:01 · 0 claps · 6.1 min read paywalled
#wwdc26 #liquid-glass #swiftui #uikit #ios-design
Open on Medium ↗
Wiki topics: 📱 · Mobile Development 📚 · Books & Reading

Many Teams Will Apply Liquid Glass the Wrong Way: After WWDC26, the Real iOS Design Lesson Is Not the Effect

As of June 13, 2026, after reading the current WWDC26 materials, I think the easiest mistake people can still make about Liquid Glass is to treat it like a new visual effect. But when Apple’s current iOS guide, design sessions, and UIKit modernization guidance are read together, a tougher conclusion appears. The real shift is not the effect itself. It is where brand belongs in the interface, and where it no longer should.

I think this matters because teams tend to react quickly when a new design language arrives. A little more blur gets added. Toolbars become shinier. Buttons get a glass-like treatment. Custom top bars appear everywhere. Then the app looks “new” without really feeling like iOS. Apple’s current message is almost the opposite of that instinct.

The WWDC26 session “Communicate your brand identity on iOS” draws a very clear line. Brand expression matters, but the experience on iPhone should still feel like iOS first. Branding that breaks the platform’s navigation, hierarchy, and interaction patterns can make a product feel less distinctive, not more. It can simply make it feel dated.

I do not see this as a taste-only design topic. This is directly an iOS development topic. In SwiftUI and UIKit, how well you rely on standard components, which surfaces you customize, where you place color, and which layout assumptions you depend on now reveal product quality much faster.

Apple’s Clearest Lesson: The UI Layer and the Content Layer Are Not the Same Thing

The most valuable idea in the WWDC26 design session, in my view, is this: think of the iOS interface as two layers. The first is the UI layer. This is where the tab bar, top toolbar, navigation, and global actions live. The second is the content layer. This is where your product’s voice, media, tone, color, and real identity are supposed to be strongest.

That sounds simple, but I think many teams will struggle exactly here. For years, branding often meant coloring navigation first, customizing the top bar, making the tab bar look special, and letting every control carry its own visual identity. Apple is now recommending the opposite: keep the UI layer as a familiar foundation and let the brand come through more strongly in content.

That framing also puts Liquid Glass in the right place. Its job is not to make everything glassy. Its real job is to make global navigation feel lighter, more floating, and more system-native. If a team fills that layer with unnecessary color, custom chrome, and crowded actions, the new design language does not get stronger. It starts to break.

The “Let’s Customize Everything” Reflex Just Got More Expensive

Apple repeats a simple point in that same session: people expect apps on iPhone to look and feel like iOS. That does not mean every app should look like Apple’s own apps. But familiar behaviors, standard components, and platform logic still need to be preserved.

That leads me to this conclusion: in the period after WWDC26, one of the riskiest team behaviors will be redesigning utilitarian surfaces for no strong reason. If the system already gives you a good foundation for settings, menus, filters, secondary actions, or toolbar structure, being different for the sake of being different becomes an expensive decision.

Apple’s examples do not ban customization. In fact, meaningful customization is encouraged in high-impact areas. But the goal is clear: the user should first understand how to move through the product, and only then feel your brand. If that order gets reversed, the experience becomes harder to trust.

I also think this is a strong click angle because many teams still reduce adaptation to the new iOS look into one narrow question: which modifier should we use? The bigger question is different: which parts belong to the platform, and which parts belong to our product identity?

Apple Is Pushing Color Out of UI Chrome and Into Content

One of the most practical lessons in the WWDC26 session is about color. Apple explicitly explains that the solid-color toolbar and tab bar approach that was common before the new design language is now weaker. The recommendation is very clear: move more brand color into the content area of your app. Put it into scrollable content, media, background rhythm, and meaningful emphasis points. Let Liquid Glass controls dynamically pick up those tones above that layer.

I think that matters because “looking branded” and “painting everything in the brand color” are not the same thing. In the new system, the second one can become tiring much faster. Apple is not removing color. It is relocating color to a smarter place.

So in an iOS app today, the better move may be to enrich the content instead of painting the top bar, and to use accent color selectively for state, feedback, and action instead of making the tab bar heavier. Brand expression gets stronger when it lives in the active, living part of the screen rather than in the chrome.

This distinction is especially important in SwiftUI. Standard components are already inheriting the new look, while unnecessary custom overlays and fixed color blocks may become the fastest-aging parts of a product.

Typography Builds Brand Better Than Fighting Navigation

Apple’s message around typography in the brand identity session is just as important. Brand is not only logo, iconography, or color. In many products, the most mature differentiation appears through typography. But even here, the system should not be treated like an enemy.

If you use custom fonts, you have to support Dynamic Type properly. Breaking the user’s larger text preference and then defending it with “but our font has character” is not high-quality brand work on iOS. It looks more like a forced web transplant. Apple’s examples are useful because they show that a product can still feel distinct even when it leans heavily on system typography.

To me, that clarifies something important: after WWDC26, more teams will need to think of brand less as component skinning and more as voice, rhythm, spacing, motion, and content behavior.

Resizable iPhone Experiences Turn This Design Topic Into a Code Topic

This is not just aesthetic. The “Modernize your UIKit app” session and the current iOS guide make it clear that iPhone apps now need to adapt more flexibly to iPad and iPhone Mirroring environments. Apple explicitly says not to rely on user interface idiom checks or orientation logic for layout decisions. Use size classes and the available space instead.

Why does that matter in a Liquid Glass article? Because the lighter navigation model breaks more visibly when an app is built on fixed-screen assumptions. If your interface depends on stacked custom bars, rigid heights, and a “the phone always looks like this” mindset, the new design language exposes not only visual debt, but layout debt too.

If I were preparing an app for this shift today, I would not stop at a color audit. I would also check the following:

  1. Do tab, toolbar, and search surfaces still carry unnecessary custom chrome?
  2. Is most of the brand energy living in the UI layer rather than the content layer?
  3. Do custom fonts and compressed headers break under Dynamic Type?
  4. Does hierarchy collapse in resizable iPhone scenarios across top bars, search, and content?
  5. Are we still hand-drawing something that standard SwiftUI or UIKit components could now handle better?

These questions are easy to frame as design review items. I think they are now shipping-quality questions.

The Most Common Failure Will Be Putting Brand Identity Into Navigation

My strongest takeaway on June 13, 2026 is this: after WWDC26, the teams that apply Liquid Glass badly will not just be the ones that overuse the effect. The more dangerous group will be the teams that put brand in the wrong layer.

If the tab bar has to carry the brand, the top toolbar has to carry the whole personality, every menu is custom drawn, and content gets pushed back, the app may become more branded in theory but less like iOS in practice. The core lesson I take from Apple’s official materials is simple: people do not want to decode the system first. They want to use the app fluently. Brand gets stronger when it sits on top of that fluency. When it tries to replace it, the product becomes tiring.

That is why I think the harshest sentence in this piece is also the most useful one: in the new iOS cycle, the most expensive design mistake will not be a lack of boldness. It will be trying to redesign what iOS has already solved.

Conclusion

As of June 13, 2026, after reading Apple’s WWDC26 iOS guide, the “Communicate your brand identity on iOS” session, and the UIKit modernization guidance together, I think the picture is clear. The real lesson of Liquid Glass is not a new material. It is a new discipline. The UI layer stays more system-like, lighter, and more familiar, while brand, color, typography, motion, and content expression grow stronger in the underlying product layer.

Reading this shift only at the “glass effect” level misses the point. The teams that win will be the ones that separate more clearly which surfaces belong to the platform and which surfaces should carry their own identity.


메타데이터
post_id
acc9d97ff3dc
slug
many-teams-will-apply-liquid-glass-the-wrong-way-after-wwdc26-the-real-ios-design-lesson-is-not-acc9d97ff3dc
url
https://medium.com/@hasanalidev/many-teams-will-apply-liquid-glass-the-wrong-way-after-wwdc26-the-real-ios-design-lesson-is-not-acc9d97ff3dc
canonical_url
https://medium.com/@hasanalidev/many-teams-will-apply-liquid-glass-the-wrong-way-after-wwdc26-the-real-ios-design-lesson-is-not-acc9d97ff3dc
author_url
https://medium.com/@hasanalidev
status
ok
fetched_at
2026-07-15 19:28:09