Adapting Your App to iOS 26's Liquid Glass — Before Apple Makes You

Apple announced Liquid Glass at WWDC in June 2025 and shipped it with iOS 26 that September — the most sweeping visual change to the platform since iOS 7 flattened everything in 2013. A year on, the grace period is effectively over: App Store submissions are now built with the iOS 26 SDK, and apps compiled against it get the new look whether their developers planned for it or not.

I went through this with my own apps, and the work splits cleanly into what the system does for you, what it quietly breaks, and a small set of design decisions you can't delegate.

What Liquid Glass actually is

Liquid Glass is a system-wide material: translucent surfaces that refract what's behind them, respond to motion, and concentrate controls into floating, rounded layers. Tab bars float above content and shrink on scroll, navigation bars give way to content scrolling underneath, buttons and sheets pick up a real-time glass rendering, and corner radii across the system are larger and concentric with the hardware.

The design intent is hierarchy: content is opaque and primary; controls sit on glass above it. Apps that already keep chrome minimal adapt almost for free. Apps with heavy custom chrome have decisions to make.

The deadline that actually matters

The mechanism Apple uses isn't a memo, it's the toolchain. Once your build uses the iOS 26 SDK — which current App Store submission rules require — your app renders with Liquid Glass by default. There is a temporary escape hatch: setting the UIDesignRequiresCompatibility key in Info.plist keeps the previous appearance, but Apple documents it as temporary and has said it will be removed in a future release. Treat it as a migration buffer, not a strategy.

<key>UIDesignRequiresCompatibility</key>
<true/>

If you ship React Native: nothing about the flag is special for you — it's the same Info.plist, and with Expo you set it once via the ios.infoPlist field in app.json while you finish adapting.

What you get for free

Everything that renders through native UIKit/SwiftUI controls inherits the new material automatically:

• Navigation bars, tab bars, toolbars, and sheets take on glass and the new floating geometry.
• System controls — switches, sliders, segmented controls, context menus — update themselves.
• Standard React Native and Expo components that wrap native primitives (headers from React Navigation's native stack, native tab bars, alerts, action sheets) come along for the ride.

This is the strongest argument I know for a rule I've repeated across this blog: prefer native primitives over fully custom chrome, because platform redesigns then cost you days instead of months.

What you have to fix yourself

The breakage list from my own migrations, most common first:

1. Hard-coded opaque backgrounds behind bars that are now translucent — you see seams and mismatched rectangles where content scrolls underneath.
2. Custom tab bars and headers built from plain Views. They don't become glass; they now look dated next to every system app. Either adopt the native bars or deliberately restyle.
3. Contrast failures — text or icons sitting directly on glass over busy content. Apple's guidance: content on glass must stay legible over anything that can scroll beneath it.
4. Corner radii — small radii that used to look fine now clash with the system's larger, concentric rounding.
5. Screenshots and store assets — your App Store screenshots suddenly look one OS generation old, which quietly hurts conversion.

The React Native angle

React Native apps adapt in three moves. First, recompile with the current toolchain and audit every screen on a real iOS 26 device — most of the visual drift shows up immediately. Second, replace custom chrome with native-backed components where possible; the ecosystem has caught up, and Expo ships a GlassView that wraps Apple's real glass APIs for the cases where you want the material on your own surfaces. Third, resist the urge to smear glass everywhere: Apple's own guidance is that glass belongs to the control layer, not to content, and apps that fake it with stacked blur views read as imitation and pay for it in performance.

A design-token system makes all of this dramatically cheaper — when backgrounds, radii, and elevation live in tokens, adapting to a platform redesign is a token edit, not a hundred-file hunt. I wrote about that setup in Light & Dark Mode in React Native with Design Tokens, and it's baked into the React Native Starter.

Keep it classy: three rules

• One glass layer. Controls float on glass; content stays opaque. Glass on glass on glass is how you get the muddy look.
• Legibility beats spectacle. Test over your busiest screen content, in light and dark, and honour the system's Reduced Transparency accessibility setting — iOS falls back to more opaque materials automatically; don't defeat that with custom rendering.
• Let the system move. The shrink-on-scroll bars and refraction are system behaviours; recreating them manually is wasted effort that will drift out of sync at the next OS release.

The quiet lesson of iOS 26 is the same one iOS 7 taught: apps that lean on the platform's own components absorb redesigns almost for free, and apps that rebuilt the platform from scratch pay the bill all at once.