Liquid Glass Is Here: Testing Considerations for Developers and Quality Engineers

Surya Polavarapu — Thu, 03 Sep 2026 11:12:57 +0000

Liquid Glass is Apple's new design language announced at WWDC 2025 & shipped with iOS 26. Apple calls it their "broadest software design update ever" - the most significant visual overhaul since iOS 7 moved from skeuomorphism to flat design in 2013.

All UI elements like tab bars, buttons, switches, sliders - are now translucent and dynamic. They mimic real glass: they refract light, reflect their surroundings, and change appearance based on what's underneath them. Scroll a page and the navigation bar shifts in real time based on the content beneath it. The same button can look completely different against a dark wallpaper vs a light one.

What happened when it reached real devices?

In beta builds, users reported a lot of functional rather than purely aesthetic problems: 

Notifications on the lock screen were barely visible against transparent background. The Control Centre blended into whatever was behind it, making toggles hard to find
Navigation became unpredictable: Safari's forward button appears and disappears depending on context, search bars moved, and back buttons sometimes vanished entirely.
Touch targets got smaller and more crowded - tab bars were squeezed, spacing reduced
Contrast was insufficient for anyone with even mild vision difficulties - many users immediately turned on "Reduce Transparency" and "Increase Contrast" in accessibility settings just to make their phones usable

The Nielsen Norman Group published a detailed analysis in March 2026 that was unusually pointed for a publication that typically stays measured: the interface is restless, less predictable, less legible, and constantly pulling focus rather than supporting seamless access to content. They specifically called out that Apple has crowded and shrunk touch targets, seemingly tossing out the long-standing guideline of at least 0.4cm between targets and 1cm × 1cm tap areas.

Apple eventually responded in iOS 26.1 beta 4 by introducing a "Tinted" setting that tones down the transparency - a soft reversal of one of its most disputed visual decisions. The community largely received this as an acknowledgement that the initial implementation went too far.

The Mandate

Apple understood that a change this large needed a runway. So when iOS 26 shipped, they built an opt-out into Xcode, but requires all iOS apps to fully support the Liquid Glass design system by September 2026. 
This isn't optional. The iOS 27 beta, released at WWDC June 2026, confirms that UIDesignRequiresCompatibility , the flag teams used to opt out of Liquid Glass - is ignored when building with the iOS 27 SDK. Teams that used this flag to defer the migration now have regressions hidden in their code that QA never considered. Those regressions will all surface simultaneously when they adopt the new SDK.

Critical Considerations

The most important action for any team still using the compatibility flag is to remove the flag, build against the iOS 26 SDK, run the app on a physical device, and do a full regression pass now - before Xcode 27 is made mandatory, before a bug fix release forces the issue. 
Visual testing breaks down. Tools comparing pixel to pixel will flag everything during regression and the actual failures would get buried in the noise. Liquid Glass elements render differently depending on what's behind them - wallpaper, content, dark vs light mode, even time of day in some cases. There is no stable baseline to compare against. The same screen, in the same device can produce a different visual output on every run. Pixel-diffing tools flag everything as a regression.

Touch target testing becomes necessary. The NN/g piece documents that Apple went against its own guidelines on tap target sizing. For apps adapting to Liquid Glass, elements that previously passed accessibility and tap-size checks may no longer. Every interactive element in a migrated app needs re-verification - not just against design specs but against real device behaviour.

The hidden regression problem. Teams that deferred Liquid Glass via the compatibility flag now have untested code paths. The single most important action for these teams: remove the compatibility flag, build with Xcode 26 against a physical iOS 26 device, and run a full regression pass - discover the regressions at your own pace rather than under Xcode 27 deadline pressure. Most haven't done this yet.

What testing against Liquid Glass actually requires

When Liquid Glass migration shifts the position of a tab bar item, reformats a navigation element, or resizes a button, test steps that relied on the previous element location or identifier fail. Not because the feature broke but because the anchor the test was using no longer sits in the same place. Many elements shifting simultaneously, across many screens, where the alternative is manually triaging and rewriting every broken test step by hand.

At QApilot, our AI native system works through a resolution hierarchy - accessibility identifiers, relative positioning, visible text, and a vision-based fallback that identifies the element the way a human tester would: by what it looks like and where it sits in the flow. The healed step is flagged for review before the fix persists in the system - the team sees what changed and approves it.

Our Auto Bug Finder surfaces accessibility gaps per screen during Crawler execution - contrast issues, missing labels, elements that fail WCAG checks - precisely the category of failure Liquid Glass migration is most likely to introduce.

Liquid Glass shipped with real performance issues on older devices - early builds showed sluggish rendering and elevated GPU load that Apple progressively resolved through subsequent updates. An app migrating to Liquid Glass today still carries that risk, particularly on devices outside the latest hardware generation. QApilot captures CPU, memory, battery, and rendering metrics during test execution - surfacing performance regressions as part of the same run that validates functional behaviour.

The September 2026 deadline and the Xcode 27 SDK mandate are arriving in the same window. For any team planning a release in the next twelve months, the question of whether their app has been tested against Liquid Glass is worth asking now.

Google upgraded Android's UI language, can test automation keep up?

Surya Polavarapu — Thu, 13 Aug 2026 10:48:42 +0000

On May 19, Google made it official: Jetpack Compose is now the only way forward for Android UI. The older approach of writing screens in XML, the markup language that defined app development for over a decade, is now placed in maintenance mode. No new feature launches, bug fixes only. 

For most developers, this landed as good news. Compose is genuinely better to build with: less code, faster iteration, cleaner architecture. So most of the attention since has been on what developers gained and barely anything on what happens to the test suites!

What actually changed under the hood

To understand why this matters for quality teams, it helps to know what automation tools have always relied on.

Android testing frameworks typically found elements on screen using identifiers: resource IDs, class names, positions in a structure called the View hierarchy. Every button, text field, and screen element in an XML-based app lives in that hierarchy. Your test says "find the element with ID btn_checkout" and the framework finds it.

Compose doesn't produce Views. It produces a semantics tree - a structure closer to how a screen reader navigates an app than to how traditional layouts worked. These are two different models.

Appium can interact with Compose, but not in the way most teams currently have it set up. It requires switching to the UIAutomator2 driver specifically - not the Espresso driver - and it only works if developers have explicitly added testTag modifiers to Compose elements and enabled testTagsAsResourceId in the app configuration. Those are deliberate, manual steps that someone on the engineering side has to take for every element that needs to be reachable by a test.

Most teams migrating existing apps to Compose haven't done this. The result is a test written to find btn_checkout by its resource ID will silently fail on a Compose screen - not because the button disappeared, but because the element it was looking for no longer exists in that form. Tests stop finding elements and the suite starts failing. So when teams are quickly rewriting UI code, they are quietly invalidating years of recorded test steps, locators, and automation logic

The same problem we solved for Flutter is now arriving for the Android native ecosystem

This isn't a new class of problem. Flutter introduced a version of it years ago, and it was worse. Flutter renders entirely on its own canvas, bypassing the native UI framework completely. UIAutomator2 sees nothing. XCUITest sees nothing. There is no View tree, and no semantics tree accessible through standard drivers. The only reliable paths are Flutter Driver - which only works on debug builds, not release ones.

At QApilot, we built our proprietary layer using advanced methods like OCR & computer vision precisely because standard locators find nothing. No custom framework setup or coordinate scripts - the test finds the element visually, the way a human would.

Compose is a step along the same spectrum. The accessibility layer is still reachable if the app is configured correctly. The problem is that "configured correctly" now requires deliberate choices from the development team that most aren't making yet.

The abstraction layer we've built normalises Native, Flutter, React Native, and WebView apps into a single locator and action interface. Compose First is another reason why that kind of abstraction matters. The specific UI framework your team chose to build in shouldn't be a variable that determines whether your test suite survives a platform update. 

It's worth watching how quickly Android teams migrate. Compose adoption has been steady but slower than Google would prefer - partly because legacy codebases are large, and partly because migration comes with invisible costs that don't show up in a developer experience comparison.

DEV Community: Surya Polavarapu

Liquid Glass Is Here: Testing Considerations for Developers and Quality Engineers

Google upgraded Android's UI language, can test automation keep up?