Liquid Glass vs Material 3 Expressive for Apps

The short answer: Apple now uses translucent glass and depth to separate controls from content. Google uses bigger shapes, stronger colour and springy motion to make the main action obvious. You do not have to copy either. But the more of your app that is custom-built, the more work each one creates, and on iPhone the option to keep the old look ends once your app is built with the iOS 27 SDK. For most apps the right answer is a planned refresh, not a redesign.

The two languages side by side

	Liquid Glass (Apple)	Material 3 Expressive (Google)
Announced	9 June 2025, for iOS 26, iPadOS 26, macOS Tahoe 26, watchOS 26 and tvOS 26	May 2025, alongside Android 16
The idea	Controls and navigation float on a glass layer that refracts what is behind it	Colour, shape, size, motion and containment draw the eye to what matters
How it shows importance	Depth: content below, navigation above	Emphasis: the key action is larger, bolder and more colourful
Where it shows most	Tab bars, toolbars, sidebars, sheets, buttons, sliders, app icons	Buttons, toolbars, navigation, loading indicators, type and motion
Motion	Fluid. Elements morph and react to touch	Spring-based physics. Elements bounce and settle
Main risk	Text and icons over glass becoming hard to read	Too much emphasis everywhere, and animation that stutters on budget phones
Do you get it automatically?	Largely, if you use standard components and rebuild with the current Xcode	No. Your developers adopt the updated Material components and theme

Two details from the companies themselves are worth knowing.

Apple is clear that glass belongs to the navigation layer only. Its guidance says not to put glass on content such as lists, and not to stack glass on glass.

Google says Material 3 Expressive came out of 46 studies with more than 18,000 participants, and that people spotted key interface elements up to four times faster in the expressive designs. The same research adds a warning: expressive design is not right for every context, and one of its own test designs lost usability by breaking a familiar pattern.

Our reading: both companies are solving the same problem, which is helping people find the main action faster. Start from what your users need to do on each screen. Decoration comes second.

The iPhone clock is ticking

When iOS 26 arrived, Apple gave apps a temporary switch (a setting called UIDesignRequiresCompatibility) to keep the old appearance. Apple engineers have confirmed on the developer forums that this switch is ignored once an app is built with the iOS 27 SDK. An app built with the older SDK keeps the old look even on an iOS 27 phone.

So the deadline is not a calendar date yet. It is the day Apple requires App Store submissions to use the iOS 27 SDK. Apple had not announced that date at the time of writing. For reference, the equivalent rule for the iOS 26 SDK took effect on 28 April 2026, and Apple publishes such dates on its Upcoming Requirements page, linked below. If your app is still using the switch, plan the work now so that an urgent bug fix next year does not force a rushed visual change with it.

Refresh or redesign?

Your situation	What to do	Why
Built mostly with standard system components	Refresh	Most of the new look arrives when you rebuild. You fix the exceptions
Custom tab bar, custom headers, custom sheets	Refresh, navigation first	These are the parts that now look most out of place next to system apps
Solid colour or image backgrounds forced behind bars	Refresh	Apple's advice is to remove custom backgrounds from bars and let the system material work
Cross-platform app (React Native or Flutter) with one identical UI on both phones	Refresh, with a decision	Decide whether you follow each platform's navigation or keep one brand look. Either is fine. Drifting between the two is not
Last designed three or more years ago, and navigation confuses users	Redesign	The visual update will not fix structure. Do both once
You are adding major features or changing the business model	Redesign	You are reopening the structure anyway
Banking, health or other high-trust, data-heavy app	Careful refresh	Adopt system behaviour. Go easy on expressive motion and colour

The accessibility test checklist

A new look that fewer people can read is a step back. Test every key screen with each of these system settings switched on. The names are as they appear in the system.

iPhone (Settings > Accessibility)

Reduce Transparency (Display & Text Size). Apple says this makes glass frostier and hides more of the background. Check that nothing becomes a flat grey slab with poor contrast.
Increase Contrast (Display & Text Size). Elements become mostly black or white with a border. Check your custom controls gain a visible edge too.
Reduce Motion (Motion). Glass effects become less intense and lose their elastic movement. Check your own animations respect it.
Bold Text and Larger Text (Display & Text Size). Push text to the largest size. Look for clipped labels and overlapping buttons.
Differentiate Without Colour and Button Shapes (Display & Text Size). Check that state is never shown by colour alone.
The Liquid Glass appearance option, Clear or Tinted, which was reported in iOS 26.1 under Display & Brightness. Test both.

Android (Settings > Accessibility)

Font size and Display size at maximum.
Bold text, and Outline text on Android 16 and later.
Remove animations (Colour and motion). Springy motion should stop, and nothing should break when it does.
Colour correction and Colour inversion (Colour and motion).
Dark theme.

On both

Text contrast over the busiest background your app can show: a bright photo, a map, a video.
Light mode and dark mode.
The screen reader, VoiceOver or TalkBack, on your three most important journeys.
A mid-range phone from three or four years ago. Scroll and animate. If it stutters, simplify.

An audit worksheet for your app

List every component in the app and fill in one row each. The fourth column decides the work.

Component	Standard or custom?	Where it is used	Decision	Effort
Bottom tab bar	Custom	Every screen	Replace with the system tab bar	Medium
Top header with brand image	Custom	Home, profile	Remove the background, keep the logo	Small
Primary button	Custom	Everywhere	Keep the brand colour, adopt the new shape and states	Small
Product filter sheet	Custom	Listing	Rebuild on the system sheet	Medium
Checkout form	Standard	Checkout	Test only	Small
Animated onboarding	Custom	First launch	Simplify and respect reduced motion	Medium

That is a made-up example for a shopping app. The four possible decisions are: keep as it is, restyle through design tokens (colour, radius, spacing, motion values), replace with the system component, or rebuild. The more rows that say "replace", the less you maintain in future.

Three effort tiers

We are not going to quote prices in a blog post, because the honest answer depends on how many screens and custom components you have. The tiers look like this.

Tier 1, tidy-up. Mostly standard components. Rebuild with the current tools, fix what looks wrong, update the app icon, run the accessibility checklist. Usually measured in days.
Tier 2, refresh. Custom navigation and a design system that needs new tokens. Replace bars and sheets, update tokens, retest every screen. Usually measured in weeks.
Tier 3, redesign. Structure, navigation and visuals all change, with user testing. Measured in months, and worth doing only when the decision table above says so.

On Android, a refresh pairs well with the yearly target-level update, since both mean retesting every screen. See our note on Google Play's API 36 deadline.

Three ways teams get this wrong

Putting glass on everything. Cards, lists and banners turned translucent because it looks current. That is the opposite of Apple's own guidance and it hurts readability.

Animating everything. If every element bounces, nothing stands out. Reserve expressive motion for the one or two moments that matter.

Approving it in Figma. A static frame on a large monitor tells you nothing about glass over a moving feed or a spring animation on a slow phone. Approve on devices.

Where this fits

Deciding what to keep, restyle or replace is UI/UX design work, and it should happen before a developer opens the project. The build and the testing sit with app development, for both iOS and Android.