Apple's iOS 27 SDK will ignore UIDesignRequiresCompatibility, ending the Liquid Glass opt-out

An opt-out with an expiry date

When iOS 26 shipped with the Liquid Glass redesign, many teams deferred the visual rework by adding a single Info.plist entry: UIDesignRequiresCompatibility set to YES. Apple's documentation, quoted in a dev.to post by Muhittin Camdali, always described the key as a stopgap — "Temporarily use this key while reviewing and refining your app's UI" — and it now has a hard cutoff: "The system ignores this key when you build for iOS 27 or later."

The timing is largely out of developers' hands. Apple's App Store submission guidance states that from April 2027, iOS apps uploaded to App Store Connect must be built with the iOS & iPadOS 27 SDK or later. As Camdali notes, the current Upcoming Requirements page still asks for the iOS 26 SDK, so teams have lead time, but the cutoff is fixed.

A simulator comparison recorded in his repository on 27 October 2026, which he says he did not rerun for the post, shows the practical effect: the same UIKit app built with Xcode 27.1, with and without the key, renders identically on iOS 27.0 but differently on iOS 26.4. While the key remains in the plist, one binary serves two designs depending on the device it runs on.

The code that paints over the glass

Deleting the key is a one-line change; locating the code that fights the new design is the actual work. Apple's Adopting Liquid Glass guide warns that custom backgrounds and appearances in bars "might overlay or interfere with Liquid Glass". In a UIKit app that predates the redesign, Camdali's example shows the usual suspects: a UINavigationBarAppearance with an opaque background, a brand background color and a cleared shadow; a UITabBarAppearance set to opaque and non-translucent; and a UIToolbar barTintColor. None of that is wrong — it is a brand decision made for an older design — but with the opt-out ignored, it sits on top of a material the system now wants to draw itself.

The subtler trap is layout math that assumes fixed bar geometry, such as pinning a panel 49 points above the bottom safe area — the height of the classic tab bar. The suggested fix is to constrain against safeAreaLayoutGuide instead of adding a bar height, avoid reading the tab bar's frame for layout, and test the screen with the tab bar minimized.

A scanner for the migration

Camdali is also the author of glassready, an open-source, MIT-licensed CLI published on GitHub that reads native iOS, Flutter and React Native/Expo projects and lists both the opt-out and the spots where custom styling collides with the new design. It is purely static: it does not build, run or modify anything. On his UIKit fixture, glassready 0.1.3 reported one error for the ignored opt-out, four warnings covering opaque bar appearances and legacy color and translucency settings, and two informational findings: a blur layer with no Liquid Glass counterpart, and the fixed-height safe-area arithmetic.

Each finding comes with a fix. Opaque appearances should be removed or gated behind if #available(iOS 26.0, *), with brand colors moved to tintColor. Legacy barTintColor and isTranslucent assignments get the same treatment. Blur layers behind floating panels should switch to UIGlassEffect on iOS 26 and later, keeping the old blur as a fallback.

Cross-platform projects are covered too. In React Native the key lives in the iOS Info.plist; in Expo it can be set under ios.infoPlist in app.json. On a React Native 0.88.1 fixture the tool flagged a native stack header painted via headerStyle.backgroundColor and a bottom tab bar drawn in JavaScript — which, per the rule data, keeps its own look under the iOS 27 SDK while the native headers and sheets around it turn to glass. For Flutter, the rules flag Cupertino bars that Flutter renders itself and UiKitView platform views placed next to Flutter widgets.

Known limitations

The tool matches patterns rather than compiling code: its rules are regular expressions over source text, so generated code, macros or unusual formatting can slip through or trip false positives. It reads only the app's own sources — no CocoaPods, external Swift packages, node_modules or Flutter plugins — and it does not parse .xcconfig files. Camdali also cautions that a warning marks where code paints over a bar, not that the choice is necessarily wrong; the screen should still be checked on an iOS 27 simulator before deciding.

Why it matters

The April 2027 SDK requirement turns a one-line escape hatch into a scheduled migration. Every app that opted out of Liquid Glass now has a bounded window to reconcile its custom bar styling with the system design, and the work is finding code, not flipping a flag. Cross-platform teams face an extra wrinkle, because JavaScript- and Flutter-drawn bars will sit visually apart from native chrome that does adopt Liquid Glass. One caveat worth weighing: this account comes from a single dev.to post written by the scanner's own author, so the Apple documentation quotes are the firm facts here, while the tool's coverage claims are self-reported.