Liquid Glass, Apple’s system-wide redesign that shipped with iOS 26, changes more than app icons and translucency — it changes how core navigation behaves. Tab bars now shrink and recede as a user scrolls through content, then fluidly expand again when they scroll back up. Controls morph, collapse, and reappear based on context rather than sitting in a fixed state. That’s a genuine UX improvement for content-first apps, but it’s also a trap for anyone tracking engagement using metrics that assume navigation elements are always visible and always in the same place — tap-through rate on a tab bar item means something different when the tab bar itself is intermittently collapsed.
The bigger risk is misattribution. If engagement with a nav element drops after your app adopts Liquid Glass, the naive read is “users are less engaged.” The accurate read might be “the control was visible and tappable for less of the session than before, because it’s now designed to recede.” Teams that don’t separate visibility from intent will end up chasing a UI-driven metric shift with product changes that don’t address the actual cause — and will miss the cases where Liquid Glass genuinely does change user behaviour, which is worth knowing.
Data Points to Track
- Control visibility state changes (expanded/collapsed) for tab bars and floating controls, logged as their own event stream rather than inferred from surrounding activity
- Interaction rate normalised against visible time, not total session time, so a collapsed-by-design control isn’t penalised for having fewer opportunities to be tapped
- Scroll-triggered UI transitions per session, as a proxy for how much of the experience users are spending in the “focused content” state versus the “chrome visible” state
- Pre/post-migration cohort split, comparing users on the Liquid Glass build against a held-back cohort still on the previous UI, rather than a blind before/after comparison
- Rage taps or repeated gestures near collapsed control regions, which often indicate users reaching for a control that receded before they expected it to
Setup Steps
- Instrument UI-state transitions directly — log when a tab bar or floating control expands or collapses, tied to the scroll event that triggered it.
- Compute engagement rate as interactions divided by visible time, not session time, for every control affected by the new adaptive behaviour.
- Hold back a comparison cohort on the pre-Liquid Glass build if your release process supports staged rollout, so the redesign’s effect can be isolated from concurrent changes.
- Add rage-tap detection in the screen regions where controls now recede, to catch discoverability friction early.
- Re-baseline your engagement dashboards post-launch rather than carrying forward thresholds calibrated against the old, always-visible UI.
Actionable Insights
A drop in raw tap counts on a nav element paired with a stable or improved visible-time-normalised rate means the control is working as intended — it’s just visible less often, which is the point of the redesign. A drop in the normalised rate itself is the real signal: users are seeing the control and choosing not to use it, or failing to find it when it reappears. Rage taps clustering near recede zones are the clearest early warning that the animation timing or trigger threshold needs tuning before it shows up as a broader engagement decline in your top-line metrics.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert