Why I Still Test In Safari First (And The Bugs It Catches Early)

Yes, I Still Open Safari First

I build and test new frontend work in Safari first. On purpose. Repeatedly. Sober.

I know that sounds backwards. Everyone else ships for Chrome, patches for Firefox, then grudgingly opens Safari when QA files a bug with a YouTube link and zero details.

I used to work like that too. Then I got tired of having my nicest builds break on the client’s actual devices. Which were almost always iPhones and iPads running whatever Safari Apple felt like shipping that month.

So I flipped my workflow. Safari first, Chrome second, everything else after. It feels contrarian, but it has paid for itself in stress avoided and bugs caught before they became someone else’s problem.

Why Safari Is A Useful Enemy

Safari is stubborn. It sticks to specs when Chrome is “helpful”. It ships stuff slower. It has some… opinions.

I treat that as a feature, not a flaw. Safari is a strict teacher. If something feels fragile in Safari, it usually is fragile. Chrome just hides it with sugar and duct tape.

Rough pattern I see:

• Chrome: “Looks fine.”
• Firefox: “That’s technically wrong but I will try.”
• Safari: “You broke the rules. No.”

That “No” is valuable. I want to hear it on day one, on my own machine, not in a client email that starts with “so we noticed on mobile…”

A Real Example: The Layout That Only Broke On iPad

A while back I shipped a fancy editorial layout. CSS Grid, variable fonts, a bit of scroll-linked animation. It looked beautiful in Chrome. Pixel perfect in Firefox. I was happy.

Then I opened it in Safari on an iPad. The primary grid column collapsed to something like 40% width on orientation change. The sidebar became a weird floating island. Touch scroll felt sticky.

The root cause was boring. I had a combination of:

• minmax() grid tracks with percentages
• a flex wrapper around the grid for a layout experiment I had abandoned
• some height: 100vh elements that hated mobile Safari’s dynamic toolbar

Chrome guessed my intent and kept the layout together. Safari followed the spec and smoked out all three problems in one go.

If I had built in Chrome only, that bug would have surfaced after going through content population, QA rounds, and probably some UAT demo. That kind of late-stage layout bug is brutal to fix quietly.

By starting in Safari, I was forced to simplify the layout rules. I dropped the pointless flex wrapper, replaced the 100vh stuff with logical properties and calc, and tightened my min/max values. The layout got more robust on every browser as a side effect.

Safari Makes Me Choose My CSS More Carefully

When I start in Chrome, I reach for the shiny thing first. Subgrid, fancy masking, weird blend modes, random viewport units.

When I start in Safari, I ask a different question:

What is the smallest, most boring CSS that still gets me the experience I want?

That question saves me from myself. A few patterns Safari-first testing has pushed into my workflow:

• I ship more layouts with plain Flexbox and classic Grid, less “spec tourism”.
• I lean harder on intrinsic sizing and content flow instead of fixed heights and magic numbers.
• I use fewer overlapping transform stacks and less hacky nesting that relies on “Chrome vibes” rather than predictable behavior.

The end result is a codebase that feels boring when you skim it, but keeps working when a browser team changes something in the rendering engine.

Forms And Inputs: Where Safari Refuses To Babysit You

Forms are where Safari-first really shines. Chrome is absurdly forgiving here. You can mess up types, attributes, focus states, and still get something “fine”.

A few specific bugs that Safari surfaced early for me:

Focus Outlines And Custom Styles

I had a custom input style system. Tailored focus rings, accessible color contrast, nice transitions. Everything felt tight in Chrome.

On Safari, tabbing through the form felt wrong. Focus outlines flickered, border-radius changed mid-focus, and some inputs lost their ring altogether on keyboard nav.

The reason: I had hacked away default outlines inconsistently and relied on Chrome’s focus heuristics plus some internal timing. Safari did not play that game.

Safari first forced me to implement a simple rule: I handle all focus styles myself, across the board, with predictable states. No mixing and matching browser defaults by accident.

Autofill, Dark Mode, And Input Backgrounds

Safari’s autofill and dark mode behavior is opinionated. Chrome quietly lets you live with slightly mismatched background and text colors. Safari goes straight to unreadable text if you are sloppy.

By starting there, I fix color and background mismatches right away. The autofilled value has to be visible in the harshest condition on Safari first. Chrome ends up looking better as a side effect.

Mobile Safari Performance Bugs Chrome Hides

Desktop Chrome on a good machine is a lie. You can throw irresponsible amounts of JS, repaint-heavy transitions, and parallax nonsense at it and still get 60fps. Then you hand it to someone on an older iPhone and watch it chew their battery.

Safari on iOS feels closer to reality. Less RAM. Tighter limits. Harsher scheduling. If something feels janky there with a cold cache, you built something heavy.

Examples of what Safari-first performance checks have caught for me:

• Scroll-linked animations that hammered the main thread. Chrome smoothed them. Safari stuttered, especially with heavy images.
• Oversized shadow and blur effects on large elements that looked nice on desktop, but murdered Safari’s GPU on mobile.
• Over-eager third-party scripts loading in the critical path. Chrome absorbed the punch. Mobile Safari visibly froze for a moment.

My rule now: if it feels smooth in Safari on a mid-range iPhone, I am allowed to start tuning it for Chrome “delight”. Not the other way around.

The iOS Viewport Pain You Either Face Early Or Late

The viewport situation on iOS Safari is chaos. Dynamic toolbars. Keyboard pushing everything. Viewport units that tell the truth only half the time. Old news, but still painful.

If you only ever test in desktop Chrome until late in the project, you will 100% get hit by this. The classic examples:

• “Full height” sections with 100vh that clip behind the address bar on iOS.
• Sticky headers that un-stick while scrolling due to weird viewport changes.
• Modals that are perfectly centered in Chrome and half off-screen when the iOS keyboard shows.

When I start in Safari, those are not “edge cases”. They are the baseline. I build the layout with the dynamic viewport in mind right away. That has pushed me to:

• Favor content-driven vertical layouts over full-screen hero sections unless they truly earn it.
• Use modern viewport units and fallbacks in a deliberate way instead of sprinkling 100vh everywhere.
• Test keyboard + focus flows on iOS while the form markup is still easy to change.

It is annoying. But less annoying than redesigning a hero or modal flow after a client shows you an iPhone screenshot in a meeting.

Why Chrome-First Gives You A False Sense Of Security

Chrome is a confident liar. It tells you your layout is solid when it is secretly held together with heuristics and internal smoothing.

The classic trap: you get a thumbs-up from DevTools, Lighthouse, and your own eyeballs in Chrome. You feel safe. Then reality hits:

• A design glitch report from a client demo on an iPad.
• Strange tap targets on iOS because of unexpected relative positioning.
• A weird gap or overlap that only happens at a specific Safari breakpoint with real content.

Those bugs are expensive, not because they are technically hard, but because they arrive late. Late means:

• Copy and imagery are already in.
• Stakeholders are already attached to specific visuals.
• Your own mental model of the layout is frozen, so deep changes feel dangerous.

Safari-first flips the script. I assume the strict parent is watching me from day one. It keeps the code simple and my ego in check.

My Actual Workflow, Step By Step

This is how I run things in practice on a new feature or layout.

1. Start In Safari Desktop

I open Safari on macOS, not Chrome, and build the layout there first. No feature flags, no prefixing, just raw HTML and CSS.

I test:

• Resizing the viewport aggressively. Small to huge, landscape to portrait.
• Keyboard navigation, focus outlines, skip links.
• Performance while throttling network and CPU in the dev tools.

If I catch myself thinking “ah, Chrome will probably handle this”, I stop and refactor the layout until Safari handles it cleanly.

2. Switch To iOS Safari Early

Before things look “done”, I airdrop the URL or use a local tunnel and open it on an iPhone and iPad. Real hardware, not just responsive mode.

I check:

• Orientation changes.
• Scrolling, pull-to-refresh behavior, sticky stuff.
• Forms with the keyboard open and closed.

If something breaks here, I accept that as feedback on my architecture, not a “mobile quirk”. That mindset shift helps.

3. Then I Reward Myself With Chrome

Only when it feels solid in Safari do I open Chrome. That is when I let myself add the polish that Chrome does so well:

• Subtle transforms.
• Smoother transitions.
• Optional enhancements that don’t break the core layout.

By that point, the hard structural problems are solved. Chrome is just the candy coating.

But What About Feature Gaps?

Sometimes Safari simply does not have the shiny new CSS thing I want. Container queries used to be like that. Certain advanced mask and filter combos still are.

My rule is simple. If the feature is non-essential, I treat it as progressive enhancement and move it behind a feature check or class. The core layout must work without it in Safari.

If the feature is essential to the concept, I think hard about whether the concept is actually worth tying to a single browser engine. Usually it is not. When it is, it is a deliberate tradeoff, not a surprise late in the project.

Safari First, Not Safari Only

I am not a Safari fanboy. I keep multiple Chromes installed. I like Firefox a lot. I care about Edge for corporate contexts. This is not religion.

Testing in Safari first is just a constraint that raises the floor. It forces me to write CSS and markup that can survive a stricter interpretation of the rules and the wonkiest mobile viewport in mainstream use.

The upside is simple. I get fewer “urgent” bug tickets about layout issues. My builds age better when browser teams ship new stuff. Clients trust the work more because it behaves on the actual devices they hold in their hands.

If you are tired of last-minute Safari bugs blowing up your timelines, try it for one project. Close Chrome. Open Safari. Build the next page there first.

You will hate it for two days. Then the bugs it catches early will pay you back for months.