On this page · 9 sections
Summary. Apple's reference page for UIDesignRequiresCompatibility now says the system ignores the key when you build for iOS 27, iPadOS 27, Mac Catalyst 27, macOS 27 or tvOS 27 or later. Apple's notice of 9 September 2026 and its submitting page add the deadline: starting April 2027, iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS and iPadOS 27 SDK or later and target iOS 15 or later, and tvOS apps need the tvOS 27 SDK. So the first iOS, iPadOS or tvOS update you upload after the cut-off ships in Liquid Glass, whatever your Info.plist says. At WWDC26 Apple said it was removing the option to keep the old design. Apple has not named the day, and on 11 November 2026 its Upcoming Requirements page had no April 2027 entry. Plan for 1 April 2027, 141 days away. Mac App Store apps are not on the April list, but any macOS or Mac Catalyst build made with Xcode 27 ignores the key too. The work sits in custom bar backgrounds, materials, contrast (4.5:1 for text up to 17 points), Reduce Transparency, Increase Contrast and the new iOS 27 clear-to-tinted slider. Flutter draws its own widgets, so mainly native surfaces change; React Native's native tabs and headers change on their own.
About this article. For iOS, iPadOS and macOS engineering leads, designers and agencies whose apps still set the opt-out key or carry custom navigation chrome. We checked every requirement on 11 November 2026 against Apple's developer documentation, news posts, release notes, Human Interface Guidelines and the WWDC26 Platforms State of the Union transcript, and the Flutter and React Native details against Expo, Flutter and package sources. Apple can name the April date or revise its pages, so re-check before you lock a release plan. No vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.
Our April 2027 SDK checklist covers the whole floor: the UIScene life cycle, resizing, launch screens and iPhone Duo screenshots. This guide takes one line from it, the end of the Liquid Glass opt-out, and turns it into a redesign plan. For the SwiftUI and UIKit glass APIs in more depth, see our Liquid Glass migration guide for Xcode 27.
What Apple has published about the opt-out
The facts sit on six Apple pages, and one of them is out of date. The table summarises the key's reference page, the WWDC26 State of the Union, the September notice, the submitting page, the Upcoming Requirements page and the Adopting Liquid Glass overview.
| Apple source | Date | What it says | What it means for you |
|---|---|---|---|
| UIDesignRequiresCompatibility reference | Live on 11 Nov 2026 | A temporary key for reviewing your UI; ignored when you build for iOS 27, iPadOS 27, Mac Catalyst 27, macOS 27 or tvOS 27 or later | The key does nothing in any Xcode 27 build |
| WWDC26 Platforms State of the Union | June 2026 | Support for opting into the old design is being removed; apps recompiled with Xcode 27 use Liquid Glass automatically | Apple framed this as the end of the transition, not a pause |
| News: App Store submissions now open | 9 Sept 2026 | From April 2027, iOS and iPadOS uploads need the iOS 27 and iPadOS 27 SDK; tvOS, visionOS and watchOS uploads need their 27 SDKs | Every iOS, iPadOS and tvOS upload after the cut-off ignores the key |
| App Store: Submitting | Live on 11 Nov 2026 | Repeats the floor and adds a minimum target of iOS 15 | Users on iOS 15 to 18 still see the older design from the same binary |
| Upcoming Requirements | Checked 11 Nov 2026 | No April 2027 entry yet; newest entries are the iOS 13 minimum target (since 9 Sept 2026) and the Xcode 26 SDK floor (since 28 April 2026) | Watch this page for the exact day |
| Adopting Liquid Glass overview | Live on 11 Nov 2026 | Still says you can add the key to keep the earlier look while shipping with the latest SDKs | Stale on this point; follow the reference page |
The last row matters because teams searching for the key often land on the overview first, and it omits the iOS 27 caveat. On timing, the April SDK floors listed on the Upcoming Requirements page began on 25 April 2023, 29 April 2024 and 28 April 2026. That pattern points to late April, but Apple has not said so, so treat 1 April as the working deadline.
The Xcode 27, 27.2 and 27.3 beta release notes do not mention the key. They do set limits for your test plan: Xcode 27.2 requires macOS Tahoe 26.6 or later and debugs on devices running iOS 17 or later. Icon Composer 2.0 can preview icons in both the new and the original design generation, so refresh app icons in the same release.
What changes, platform by platform
The key arrived in the 26.0 SDKs for iOS, iPadOS, macOS and tvOS, and its reference page lists no watchOS or visionOS entry. The April 2027 floor covers a different set of platforms, so the effect differs. Apple's adoption guide supplies the tvOS and watchOS details in the table.
| Platform | Key ignored when you build for | Forced by the April 2027 floor? | Practical effect |
|---|---|---|---|
| iOS and iPadOS | iOS 27 or iPadOS 27 SDK | Yes | The first upload after the cut-off ships Liquid Glass |
| tvOS | tvOS 27 SDK | Yes | Same; Apple TV 4K (2nd generation) and newer render Liquid Glass, older models keep their current appearance |
| Mac Catalyst | Mac Catalyst 27 | Not named on Apple's list | Any Catalyst build made in Xcode 27 loses the key |
| macOS (AppKit or SwiftUI) | macOS 27 SDK | No; macOS is not on the April list | Nothing Apple has published stops Xcode 26 Mac uploads yet, but your first Xcode 27 build switches |
| watchOS | Key not documented for watchOS | Not applicable | Apple says watchOS changes are minimal and appear even without building against the latest SDK |
| visionOS | Key not documented for visionOS | The SDK floor applies, the key does not | No opt-out to lose |
For Mac teams, the missing macOS floor is a scheduling choice, not a reprieve. Xcode 27 builds your iPad app and its Catalyst variant from the same target, so keeping the Mac version on the old design means a separate Xcode 26 build lane. Our guide to what AppKit apps can ship with Xcode 27.2 and 27.3 covers the other macOS 27 work.
Who needs a redesign
The size of the job depends on which of three groups you are in.
- Apps that froze the old look. They set the key to
YES, so every screen changes at once. These need the full plan below.
- Apps that dropped the key but kept heavy custom chrome, such as painted navigation bars, home-made tab bars and blur views behind toolbars. These need a targeted fix pass.
- Apps built mostly from standard SwiftUI, UIKit or AppKit components. These need a verification pass; Apple says apps already using Liquid Glass get the iOS 27 refinements without recompiling.
Binaries on the store keep their look until the next upload
Apple ties the change to how you build, not to the device. A binary built with the iOS 26 SDK and the key set to YES was built under the old rules, and nothing in Apple's documentation says it changes on its own. The catch is the next upload. After the cut-off, any update, including an urgent fix for a payment or login bug, must use the iOS 27 SDK and ships with the new design attached. Without the redesign done, your hotfix becomes a redesign release. The safer pattern is to ship the Liquid Glass version as a planned release well before April.
Two design generations in one binary
The submitting page allows a deployment target as low as iOS 15. Users on iOS 15 to 18 see the older system design from the same binary, while users on iOS 26 and 27 see Liquid Glass. The glass APIs exist only from iOS 26, so custom glass needs an availability check and a fallback. Xcode 27.2 debugs only on iOS 17 or later, while Xcode 26.6 still debugs on iOS 15, so checking the older look on iOS 15 or 16 means TestFlight or a Mac that keeps Xcode 26.6.
The redesign audit, area by area
Apple's advice for existing apps is to build with the latest SDKs, run on the latest releases and look at what changed. The five areas below are where that first build usually shows problems.
1. Find the key and every piece of custom chrome
Start with an inventory. Each app extension has its own Info.plist, so a widget or share extension can still carry the key after the main app drops it. Also check any build script that injects Info.plist values.
# Every Info.plist that still sets the opt-out key, including extensions
grep -rl --include="*.plist" "UIDesignRequiresCompatibility" .
# Custom bar, background and blur code worth reviewing by hand
grep -rnE "UINavigationBarAppearance|UITabBarAppearance|setBackgroundImage|UIBlurEffect|toolbarBackground|ultraThinMaterial" \
--include="*.swift" --include="*.m" .
Remove the key, build with Xcode 27.2, and capture every primary screen before changing anything else. That baseline is your evidence for the rest of the plan. Apple's adoption guide lists the usual suspects: custom backgrounds in split views, tab bars and toolbars that can clash with Liquid Glass and the scroll edge effect, hard-coded control metrics, visual effect views added to popovers, and section headers. Lists, tables and forms no longer render section headers in all capitals, so write them in title-style capitalisation.
2. Navigation bars, tab bars and toolbars
Liquid Glass forms a functional layer for controls and navigation that floats above the content layer. Most of the visible change in a redesign happens here, and Apple's adoption guide covers each item below.
- Remove custom bar backgrounds. Apple recommends letting the system decide the background of bars and toolbars. Opaque appearance objects and background images are the first things to delete.
- Register custom bars for the scroll edge effect. System bars blur and fade content that scrolls beneath them. A custom bar does not, unless you register it with
safeAreaBar(edge:alignment:spacing:content:)in SwiftUI orUIScrollEdgeElementContainerInteractionin UIKit.
- Decide on tab bar minimising. iOS tab bars can shrink while people scroll. It is opt-in, through
tabBarMinimizeBehavior(.onScrollDown)in SwiftUI or thetabBarMinimizeBehaviorproperty in UIKit.
- Use a semantic search tab so iOS separates search and places it at the trailing end of the tab bar.
- Let tab bars become sidebars on iPad with the
sidebarAdaptablestyle, and extend content under sidebars withbackgroundExtensionEffect()orUIBackgroundExtensionView.
- Group toolbar items, separate groups with
ToolbarSpacer, and give every icon-only item an accessibility label. Hide the item itself, not the view inside it, or you get an empty glass capsule.
Sheets change too: half sheets are inset with larger corner radii, and action sheets now originate from the control that triggered them, so set a source view or item for each.
3. Materials and custom controls
Apple's Human Interface Guidelines draw a clear line. Liquid Glass is for controls and navigation; the standard materials (ultra-thin, thin, regular and thick) stay in the content layer. Do not put Liquid Glass in the content layer, and use it sparingly on custom controls.
Liquid Glass comes in two variants. Regular blurs and adjusts the luminosity of what sits behind it, and Apple recommends it for text-heavy components such as alerts, sidebars and popovers. Clear is highly translucent, and Apple reserves it for components over visually rich backgrounds such as photos and video, with a dark dimming layer of 35% opacity when the content behind is bright.
For custom elements, prefer the system button styles (.glass and .glassProminent) to hand-made effects. When you do need a custom surface, gate it on iOS 26 and fall back to a standard material on older systems:
import SwiftUI
struct ChromeSurface: ViewModifier {
@ViewBuilder
func body(content: Content) -> some View {
if #available(iOS 26, *) {
content.glassEffect(.regular, in: .capsule)
} else {
content.background(.ultraThinMaterial, in: .capsule)
}
}
}
When several glass shapes sit near each other, wrap them in a GlassEffectContainer. Apple says this gives the best rendering performance and lets the shapes blend and morph into each other. In UIKit, the equivalent surface is a UIVisualEffectView with a UIGlassEffect.
let effect: UIVisualEffect
if #available(iOS 26, *) {
effect = UIGlassEffect(style: .regular)
} else {
effect = UIBlurEffect(style: .systemThinMaterial)
}
let chromeView = UIVisualEffectView(effect: effect)
On the Mac, AppKit offers NSGlassEffectView and the NSButton.BezelStyle.glass bezel. Controls across platforms also have rounder shapes that follow the curvature of the hardware; ConcentricRectangle in SwiftUI and UICornerConfiguration in UIKit keep custom shapes concentric with their containers.
4. Accessibility and contrast
Translucent chrome over moving content is where legibility fails first, and where users notice first. Apple's accessibility guidelines list these WCAG Level AA values, which Accessibility Inspector uses as its contrast guidance.
| Text size | Text weight | Minimum contrast ratio |
|---|---|---|
| Up to 17 points | All | 4.5:1 |
| 18 points and larger | All | 3:1 |
| All sizes | Bold | 3:1 |
If your default colours miss those values, Apple asks that the app at least offer a higher-contrast scheme when Increase Contrast is on, checked in both light and dark appearances. For any custom colour used in controls or navigation, Apple recommends light and dark variants plus an increased-contrast option for each.
iOS 27 adds one more variable. At WWDC26 Apple introduced a Settings slider that adjusts Liquid Glass from ultra clear to fully tinted, and said Liquid Glass adapts to the reduce transparency and increase contrast settings. System components follow those settings; your custom elements need testing. You can read the accessibility settings with UIAccessibility.isReduceTransparencyEnabled or SwiftUI's accessibilityReduceTransparency environment value. For the slider, a Flutter contributor who inspected the iOS 27.2 SDK headers and Apple's documentation in November 2026 could not find a public API that reads its position, while noting that this does not prove none exists. Test both ends by hand.
A workable test matrix for each screen is two appearances (light, dark), three accessibility states (default, Reduce Transparency, Increase Contrast) and two slider positions (ultra clear, fully tinted). That is 2 × 3 × 2 = 12 states per screen.
5. Testing on current releases and betas
As of 11 November 2026, Apple's releases page lists iOS 27.2.1 (9 November), Xcode 27.2 (29 October) and the first iOS 27.3 and Xcode 27.3 betas (3 November). Use the released Xcode for anything you upload and the beta track to catch regressions early.
- Build release candidates with the current released Xcode, 27.2 today, on Macs running macOS Tahoe 26.6 or later.
- Run the same build on the iOS 27.3 beta on at least one device, so material changes in the next point release do not surprise you.
- Keep one device on iOS 18 or earlier, if your deployment target allows it, to check the older design generation.
- Give TestFlight builds to testers who use Reduce Transparency or Increase Contrast every day.
Automate the screenshots. A 40-screen app tested in 12 states produces 40 × 12 = 480 screenshots per pass, and 960 across a before-and-after pair. Snapshot tests turn that into a diff review you can repeat every release; reviewing it by hand is not realistic.
Flutter and React Native apps
Cross-platform teams often assume the key does not concern them. It does, in different ways.
Flutter
Flutter renders its own widgets, so Material and Cupertino screens do not change when the system ignores the key. What does change is everything UIKit draws on Flutter's behalf: platform views, and view controllers that plugins present, such as share sheets, pickers and alerts. Those appear in Liquid Glass next to Flutter-drawn screens, which can look inconsistent.
Flutter's Cupertino widgets have no Liquid Glass look in a published release yet. After WWDC26, the Flutter consultancy Very Good Ventures reported that the Flutter team is reviewing how Cupertino should evolve, and that community packages exist for teams that need the look now. The latest cupertino_ui release on pub.dev is 1.1.6 of 3 November 2026, with no Liquid Glass widgets. A Liquid Glass widget suite was merged into a separate liquid_glass branch of the flutter/packages repository on 6 November 2026, and a Flutter issue opened on 7 November describes that import as unpublished. Review community glass packages on pub.dev like any third-party dependency.
Flutter teams have three options. Fix only the native surfaces and keep the Flutter-drawn design (lowest effort, less native on iOS 26 and 27). Adopt a community glass package for bars and key controls (closer look, extra dependency). Or host native UIKit bars through platform views (closest match, a second rendering path to maintain), the trade-off Very Good Ventures says it weighs project by project.
The same Xcode 27 build also requires the UIScene life cycle, or the app will not launch, and that is the bigger Flutter risk. Our Flutter iOS 27 launch crash guide covers that migration.
React Native and Expo
React Native renders its core components as native UIKit views, so native tab bars and native stack headers pick up Liquid Glass once built with the iOS 27 SDK, with no JavaScript change. Expo's native tabs documentation lists the side effects. On iOS 26 and later the system draws the tab bar with Liquid Glass from the content behind it, so the backgroundColor, blurEffect, shadowColor and disableTransparentOnScrollEdge props only affect iOS 18 and earlier. Expo's known issues include a white flash when switching tabs and flickering glass header buttons in dark mode, both fixed by wrapping the layout in Expo Router's ThemeProvider, and FlatList scroll-edge detection that can leave the tab bar transparent.
Tab bars drawn in JavaScript do not change at all. Decide whether to move to native tabs (expo-router/native-tabs from Expo SDK 58, or expo-router/unstable-native-tabs in SDK 54 to 57) or keep a deliberately custom bar. For custom glass surfaces, Callstack's @callstack/liquid-glass renders an ordinary opaque View on older iOS versions and on Android.
The plan: five phases to April
The table gives two schedules: one for teams starting now, with 141 days to 1 April 2027, and a compressed track for teams starting on 22 February 2027, which leaves 38 days.
| Phase | Work | Starting in November | Starting in late February | Done when |
|---|---|---|---|---|
| 1. Inventory | Find the key in every target, list custom chrome, capture baseline screenshots | November | Week 1 | Every screen has a baseline image and an owner |
| 2. Chrome | Remove custom bar backgrounds, fix toolbars, sheets and search placement | December | Weeks 1 to 2 | Navigation looks right in light and dark |
| 3. Materials | Replace fake blur, adopt system button styles, gate custom glass on iOS 26 | January | Weeks 2 to 3 | No custom glass in the content layer |
| 4. Accessibility | Run the 12-state matrix, fix contrast and Reduce Transparency fallbacks | January to February | Weeks 3 to 4 | Text meets 4.5:1 or 3:1 per Apple's table |
| 5. Release | TestFlight, beta-track check, ship the Liquid Glass release, keep a hotfix lane on Xcode 27 | February | Weeks 4 to 5 | The design release is live before the cut-off |
Two rules make the plan hold. Ship the redesign as its own release, not bundled with the UIScene migration, so a regression points to one cause. And make Xcode 27 the CI default before April, so an emergency fix never waits for a toolchain change.
A note for agencies and teams in India
The floor applies to every app uploaded to App Store Connect, whatever storefront it sells in, so a Gurugram or Bengaluru team shipping for a US or UK client faces the same date. Agencies should run phase 1 across their whole client portfolio now. A dormant client app that needs one small fix in May will need the redesign first, and the client will have to approve a visual change they did not ask for.
How eCorpIT can help
eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our AI mobile app development practice can run the five phases above for Swift, Flutter or React Native apps, from the key and chrome inventory to the 12-state accessibility matrix and the release plan. Talk to us at /contact-us/.
Last updated: 11 November 2026.
