My site works on Android but breaks on iPhone/Safari — why, and how do I fix it?

If a site works on Android but breaks on iPhone, the cause is almost always the browser engine: Chrome on Android uses Blink, while on iPhone Safari and the other browsers, Chrome included, run on Apple's WebKit. The usual culprits are full-screen sections sized with 100vh, date strings Safari can't parse, background video without muted and playsinline, CSS that older iOS only reads with a -webkit- prefix, and blocked third-party cookies. Sometimes the problem is on the visitor's own iPhone instead (a content blocker, a VPN, Private Relay or Screen Time), so rule that out first.

Below you'll find a quick check that tells the site apart from the phone, a symptom-to-cause table, the fix for each cause, and how to test in Safari even if you don't own an iPhone.

First check: is it the site, or just that one iPhone?

Before touching any code, rule out the visitor's phone. Ask them to try these (or do it yourself on any iPhone):

• Open the page in a Private tab. If it works there, stored data (cache, cookies) or an extension is the likely cause; for stored data, clearing it under Settings > Apps > Safari > Clear History and Website Data usually helps.

• Turn off content blockers for that page from Safari's page settings menu, or under Settings > Apps > Safari > Extensions. Ad and tracker blockers often hide booking forms, chat widgets, maps and cookie banners.

• Switch from Wi-Fi to mobile data and temporarily turn off any VPN and iCloud Private Relay.

• Check Screen Time: Content & Privacy Restrictions can block websites on a child's or company phone.

• Make sure JavaScript is on: Settings > Apps > Safari > Advanced > JavaScript.

• Note the iOS version (Settings > General > About). An iPhone that can't update any more also keeps an old Safari.

Rule of thumb: if the problem shows up on several iPhones running current iOS with blockers off, it's the site. If it only happens on one phone, it's almost certainly that phone's settings or an outdated iOS. And if the layout is off on every phone, not just iPhones, the cause is usually responsiveness rather than Safari; see My site looks different on phone than on computer.

Why iPhones behave differently: on iPhone, even Chrome is WebKit

Every browser has an engine that turns code into what you see on screen. Chrome, Edge, Samsung Internet and most Android browsers share the same one, Blink. On the iPhone, Safari, and also Chrome, Firefox and Edge, run on Apple's WebKit.

Apple has allowed other engines in the EU since iOS 17.4 and in Japan since iOS 26.2, but as of mid-2026 the big browsers on iPhone, Chrome included, still ran on WebKit; a Blink build for iOS that Microsoft's Edge team showed in June 2026 was described as a research prototype, not a product. So in practice, if something breaks on an iPhone, it's a WebKit issue, whatever browser your visitor appears to be using.

Two more things are worth knowing. Safari on iPhone is updated together with iOS, so an older iPhone that no longer gets updates is stuck with an older engine, and a feature that works on a new phone can fail there. And engines differ in small defaults, not only in features: input that Chrome quietly tolerates, like a loosely formatted date, can simply fail in Safari.

Symptom → likely cause

The most common causes and how to fix each

Full-screen sections cut off (100vh). Safari's toolbar on iPhone shrinks and expands as you scroll, and 100vh is calculated for the screen with the toolbar collapsed. While the toolbar is visible, a "full-screen" section is taller than what you see, and the button at the bottom disappears under it. Use height: 100dvh (dynamic viewport height) with a 100vh line before it as a fallback. Safari has supported dvh since iOS 15.4.

Dates Safari can't read. A plain date like "2026-07-11" is fine. The trap is a date in a non-standard format: Chrome guesses its way through strings like "07-11-2026" or "2026-07-11 18:30:00 GMT+0300", while Safari returns Invalid Date, and a countdown, booking calendar or event date goes blank only on iPhone. Older Safari versions, still found on iPhones that no longer update, also reject a date and time joined by a space ("2026-07-11 18:30:00"), a format many databases and plugins output. The safe choice is the ISO format with a T ("2026-07-11T18:30:00", plus an offset such as +03:00 if the time zone matters), or parsing dates with a library.

Background video that won't play. Safari autoplays video only when it's muted or has no audio track, and on iPhone it also needs the playsinline attribute to play inside the page instead of going full screen. Even then, Low Power Mode turns autoplay off by design and shows a play button. So: autoplay, muted and playsinline together, a poster image that works on its own, and no essential information that exists only inside the video. More in Homepage background video: when it helps and when it wrecks speed and conversions.

Blur or "glass" effects missing. Until iOS 18, Safari only understood backdrop-filter with the -webkit- prefix. If your CSS or your build tool writes only the unprefixed property, iPhones on iOS 17 and earlier show a flat background, sometimes with unreadable text on top. Write both, -webkit-backdrop-filter and backdrop-filter, and make sure the text stays readable without the blur.

Menus, sliders or forms dead on older iPhones. One JavaScript feature the visitor's Safari doesn't know can stop an entire script file, and everything that depends on it. A typical example is regular-expression lookbehind, supported only from iOS 16.4: on older versions a script containing it fails with a syntax error before it even runs. Set realistic browser targets in your build tool so the code gets transpiled, check support on caniuse.com or MDN before using new features, and read the console on a real device (see below).

Images missing on older iPhones. Safari shows AVIF from iOS 16 and WebP from iOS 14. If the site serves only AVIF, older iPhones get empty boxes. Use the picture element with a JPEG or PNG fallback, or let your CMS or image CDN pick the format per browser.

Login, booking or payment widgets that fail. Since iOS 13.4, Safari blocks third-party cookies by default. A booking calendar, chat, login or payment form embedded from another domain in an iframe can lose its session, loop back to the first step or refuse to submit, only on iPhone. Ask the provider whether they have a Safari-compatible embed, open that step in a new tab or via a redirect instead of an iframe, or, if you build the widget yourself, use the Storage Access API that WebKit recommends.

Form fields that zoom in. When an input's text is smaller than 16px, Safari on iPhone zooms in as soon as it's tapped and the layout jumps. Give form fields at least 16px. Don't "fix" it by disabling zoom in the viewport tag; that also blocks people who need to zoom in to read.

Phone numbers that change color. Safari on iOS turns text that looks like a phone number into a call link, which can change its color and break your design. Make your real numbers proper tel: links and style them deliberately; to stop automatic detection elsewhere, add the format-detection meta tag with telephone=no.

How to diagnose, with or without an iPhone

A real iPhone is still the most reliable test, but it's not the only option:

Safari on a Mac shares the engine, so many CSS and JavaScript bugs show up there too. It has no shrinking toolbar or touch input, though, so some iPhone-only problems won't appear on desktop. Playwright's WebKit is close to Safari but not identical, so confirm the final result on a real device.

To inspect a real iPhone from a Mac (as described in Apple's Web Inspector guide):

• On the iPhone: Settings > Apps > Safari > Advanced, turn on Web Inspector. On iOS 17 and earlier the same switch is under Settings > Safari > Advanced.

• On the Mac: Safari > Settings > Advanced, tick "Show features for web developers".

• Connect the iPhone with a cable, trust the Mac if asked, then open the Develop menu and choose the iPhone and the page. The console shows the exact error, and the elements view shows which CSS rule is applied.

Then work methodically:

• Ask precisely: iPhone model, iOS version, which browser, a screenshot or screen recording, and whether Low Power Mode is on. "It doesn't work" says nothing; "the button under the form is cut off on iPhone 12" says everything.

• Test in isolation: switch off animations, video, blur effects and third-party widgets one at a time. When the problem disappears, you've found the culprit.

The golden rule: reproduce the problem first, then fix it. Guesswork fixes usually break something else.

How to prevent it from the start

The cheapest Safari bug is the one you never write. The principles we work by:

• Test on a real iPhone BEFORE launch, not after clients complain, and on an older iPhone too if you can.

• Decide which iOS versions you support and set your build tool's browser targets to match.

• Check new CSS and JavaScript features on caniuse.com or MDN before relying on them, and give them a fallback: @supports in CSS, a JPEG for browsers without AVIF, a poster image for video.

• Use the right units and attributes from day one: dvh, playsinline and muted, 16px form fields, ISO dates.

• Prefer simple, proven solutions over the latest trick that only works in Chrome, and avoid heavy animations that behave unpredictably across engines.

• On WordPress or a page builder, recheck sliders, pop-ups and full-screen sections on an iPhone after every major theme or plugin update.

That's why, at MPO Web Studio, a small web studio in Cluj-Napoca, we first build a free demo of your site and test it on iPhone and Android before we ever talk money. You see the real result, on your own phone, not a promise. We work fully remote, with transparent pricing.