The short answer
Your app does not change until it is rebuilt against the newer SDK, and then large parts of it change by themselves. Standard controls take on Liquid Glass automatically, custom interfaces do not, and the mixture is what looks broken. So the real question is not whether to adopt the new look but when you next recompile, and what you will fix in the same pass.
For most businesses the honest timeline is one planned release rather than an emergency. The apps that will suffer are the ones that recompile for an unrelated reason and ship the result untested.
What Liquid Glass actually is
Apple introduced Liquid Glass at WWDC in June 2025 as a single material language across its operating systems, and it shipped with iOS 26. Navigation bars, tab bars, sheets, sidebars and controls became translucent surfaces that refract the content behind them and react to scrolling and light. It is the largest visual change to iOS since the flattening in iOS 7.
Apple has been clear that the direction is permanent and has continued refining it through point releases, adding controls for how translucent the interface feels after the first wave of complaints. The refinements are real, but the architecture is not being reversed.
The mechanism that decides your timeline
Three facts do the work here:
- Apps built against the iOS 26 SDK adopt Liquid Glass automatically wherever they use standard components.
- A plist key, UIDesignRequiresCompatibility, currently lets a build opt out and keep the old appearance.
- That key is going away with the next Xcode and OS generation, and Apple requires new App Store submissions to be built against a recent SDK from a cutoff each spring.
Put together: the opt-out is a deferral, not a decision, and it expires on Apple's schedule rather than yours. Developer commentary has converged on an April 2027 expectation by extrapolating from previous SDK cutoffs, but Apple has not published that as a Liquid Glass deadline, and it is worth being precise about the difference between a pattern and a commitment.
What breaks, in practice
The failures are rarely catastrophic and almost always visual. From the apps we have looked at, the recurring ones:
- Custom navigation beside standard navigation. A hand-built header next to a system tab bar now reads as two design languages sharing a screen.
- Text over translucency. Copy that was legible over an opaque bar loses contrast over a refracting one, particularly on photo-heavy backgrounds.
- Brand colour drift. Tints render differently through glass, so a carefully specified brand colour arrives slightly wrong.
- Crowded controls. Reviews of the new interface, including Nielsen Norman Group's, flagged tighter navigation and touch targets with less separation than long-standing guidance recommends. Your own dense toolbars get denser.
- Icon and asset mismatches. Icons drawn for a flat interface can look flat in the wrong way against depth and refraction.
None of these is a rewrite. All of them are the kind of thing that turns up in a one-star review as "the update ruined it".
Accessibility is the part to take seriously
Translucency and contrast are in tension by definition, and the design of a glass interface makes it easy to ship text that passes on a designer's screen and fails on a real one over real content. iOS ships Reduce Transparency and Increase Contrast for exactly this reason, and an app that only looks right with them off is not finished.
The test is cheap: run your main screens with those settings enabled, over the busiest background your app will ever show, at the smallest supported text size, in bright daylight. If anything becomes hard to read, the fix is a solid backing layer behind the text rather than a lighter shade of grey. The general principles we set out in accessible design that stays premium apply directly, and they are not in conflict with the new look if the depth is used deliberately.
What it costs to adapt
Scope depends almost entirely on how much of your interface is standard. A broad pattern from the work we have seen:
| App type | Typical effort |
|---|---|
| Mostly standard SwiftUI or UIKit components | Recompile, audit screens, fix contrast and spacing. Days. |
| Heavily custom interface with a design system | Decide what becomes glass and what stays solid, update tokens, retest. A short project. |
| Cross-platform, React Native or Flutter | Depends on package support; more testing, more edge cases. |
| Legacy app nobody has opened in two years | The SDK bump surfaces everything else that has rotted. Budget for that, not for glass. |
If you are choosing a stack for something new, this is a live example of the trade we set out in SwiftUI versus React Native versus Flutter: native apps inherit Apple's redesigns for free and inherit the deadline with them, while cross-platform apps inherit neither on schedule.
Should your website follow?
Mostly, no. Apple's design language has always rippled outward, and glass effects are easy to approximate in CSS with backdrop blur and layered translucency. The reasons to be careful are the same ones that make it hard on iOS: contrast over unpredictable content, plus a real performance cost from stacked blurs on mid-range phones.
Use the influence where it is structural rather than decorative. Depth to separate a floating control from content, a single translucent layer over a controlled background, motion that responds to scroll. Apply it to every panel on a marketing page and you get a site that looks of its moment for one season and dated the next, which is the trap described in why every website looks the same.
What to do this quarter
Pull your app up on a device running the current OS. Note which screens already look inconsistent. Decide the release in which you will recompile deliberately, with a design pass attached, rather than the release in which you will recompile by accident. If the app also needs the wider health check that any SDK bump triggers, the cost discussion in what an iPhone app costs to build is the right frame for it.
If you want the design pass done properly alongside the technical one, send us a build and the screens you are worried about.