Engineering

The iOS Safari Bug That Hid Our Login Button (And Other Auth Layout Nightmares)

A deep dive into mobile auth UX: fixing iOS viewport overflow, standardizing layouts across Intro/Login/Onboarding, and the small CSS change that saved our conversion funnel.

By Lumo EngineeringFeb 8, 20262 min read

Here's a fun one: our "Sign in with Google" button worked perfectly on every device except the ones that mattered — iPhones with the keyboard open.

The bug was subtle enough that it passed QA, survived two rounds of internal testing, and only surfaced when a beta tester sent us a screenshot with the caption "where's the login button?" The button was there. It was just 200 pixels below the visible screen, hidden behind the iOS soft keyboard, patiently waiting for someone to scroll down on a page that shouldn't have scrolled at all.

The Root Cause: h-screen vs Reality

The auth screens used h-screen (100vh in CSS) to fill the viewport. On desktop browsers, this works exactly as expected. On iOS Safari, 100vh includes the area behind the URL bar and the keyboard. When the keyboard opens, the "visible viewport" shrinks, but 100vh doesn't change. Your carefully positioned CTA button slides off the bottom of the visible area.

This is a well-documented iOS bug that has ruined developers' days since approximately 2015, and Apple has shown zero interest in fixing it.

The fix was one CSS unit change:

- className="h-screen"
+ className="min-h-dvh"

dvh (dynamic viewport height) accounts for the keyboard, URL bar, and any other browser chrome that eats into the visible area. When the keyboard opens, 100dvh shrinks to match what the user actually sees. The login button stays visible. Users can actually sign in. Revolutionary concept.

Standardizing Auth Layouts

While we were in the auth flow, we audited every screen: Intro, Login, Registration, Onboarding. They'd been built at different times by different states of mind, and it showed. The Intro screen had 24px padding. Login had 16px. Onboarding had a mix of both depending on the step.

We introduced a shared design token system for auth screens:

  • Consistent padding and safe area insets across all screens
  • WCAG 2.1 AA compliant focus rings on social auth buttons — because accessibility isn't a nice-to-have when someone is trying to give you their financial data
  • Hero assets converted from PNG to WebP, dropping initial paint weight by ~240KB
  • Tab navigation flows verified end-to-end across Login → Onboarding → Dashboard

The visual difference is subtle. The conversion difference is not. When your auth flow looks inconsistent, users notice — even if they can't articulate why. They just feel like the app isn't polished enough to trust with their money.

The Lesson

Mobile web development is still, in 2026, a minefield of viewport bugs, keyboard interactions, and platform-specific quirks. The fix was a three-character CSS change. Finding the fix required reading a 47-comment WebKit bug thread from 2019, testing on four different iOS versions, and briefly questioning whether native development was actually the answer all along.

It wasn't. But I understand the temptation.


Abdul Rafay Founder, Syntax Lab Technology

Loading...