Spent weeks making sure the app itself held up on a real phone. Same day it went to Apple, someone pointed out that the website — the thing everyone actually sees first — had headings running flush against the edge of the screen on mobile, with text nearly touching the glass. Not a Safari quirk, not dark mode, not a rendering fluke. A real, plain CSS mistake, sitting there the whole time.
Invisible until the layout changed underneath it
Four sections on the homepage — Features, Preview, FAQ, and the final
call-to-action — each combine their own class with a shared
.wrap utility class that's supposed to give every section
24px of breathing room on the left and right. Each of those four
sections also set its own padding using CSS shorthand,
something like padding: 80px 0 20px;. That shorthand sets
all four sides at once — top, right, bottom, left — and the 0
in the middle silently zeroed out the left and right padding
.wrap was supposed to provide. The bug had been live the
entire time. It just didn't matter while the text inside those
sections was centered, because centered text doesn't reach the edges
even with no padding at all. It became obvious the moment those
sections switched to left-aligned text on mobile — which is exactly
when headings started sitting right on the edge of the screen instead
of a few lines in from it.
Why it took longer to find than to fix
The actual fix was swapping the shorthand for explicit
padding-top and padding-bottom on those four
rules, leaving left and right alone so .wrap's spacing
survives. Four lines, once I knew where to look. Finding it meant
ruling out the more obvious suspects first — a scroll-reveal animation
that really was lagging on fast scrolls, a missing iOS text-size reset
that really was missing, Safari's own floating toolbar that really
does sit over the bottom of the screen on every site, apple.com
included. All three were real. None of them were what was actually
being described. The padding bug only showed itself once I stopped
trusting theories and started grepping for which elements shared a
class with .wrap.
The part that actually stings
The app went through a real testing pass on real hardware before submission. The website that's supposed to sell that app never got the same treatment, on the assumption that "it's just a static page, it's fine." It wasn't fine. It's fixed now, live, and it's a reminder that the marketing site is a product too — one that doesn't get a review process to catch what a careless line of CSS lets through.
Download Snugit — and check it on your own phone if you don't believe it's actually fixed.
Before this: the button that started the waiting — it's with Apple now.