The most accurate way to test a website on iPhone without owning one is the iOS Simulator that ships with Xcode on a Mac. It runs real iOS Safari, so it shows Safari’s rendering bugs, the on-screen keyboard and the browser chrome. On Windows or Linux there is no official iOS simulator; your options are WebKit through Playwright, a paid cloud device service, or a mobile view in Chrome for a layout check.
Here is how each option works and what it catches.
Why iPhone testing needs Safari, not Chrome
Every browser on iPhone, including Chrome and Firefox, has historically had to use Apple’s WebKit engine. Apple now allows other engines in some regions, but WebKit remains what nearly all iPhone users see. WebKit has its own behaviour around things like 100vh and the collapsing address bar, position: fixed with the on-screen keyboard, form controls, date pickers and some newer CSS features.
That is why a page can look perfect in Chrome’s iPhone emulation and still break on an actual iPhone. Chrome can copy the iPhone’s screen size and user agent, but it draws the page with its own engine.
Option 1: Xcode Simulator on a Mac (free, closest to real)
- Install Xcode from the Mac App Store. It is a large download.
- Open Xcode, go to Settings > Components (called Platforms in older versions) and install an iOS runtime if one is not installed.
- Open the Simulator from Xcode > Open Developer Tool > Simulator.
- Choose a device with File > Open Simulator, open Safari in the simulated phone, and type your URL.
The simulator shares your Mac’s network, so http://localhost:3000 works inside it without extra setup. You can rotate the device, change text size in the simulated Settings app, and test dark mode.
Inspecting the page with Safari Web Inspector
To debug what you see:
- On the Mac, open Safari and go to Settings > Advanced, then turn on Show features for web developers.
- In Safari’s Develop menu, pick the simulator and then the open page.
You get the full Web Inspector (elements, console, network) for the page running in iOS Safari. The same menu also lists a real iPhone connected by cable once you enable Web Inspector on the phone under Settings > Apps > Safari > Advanced (on older iOS versions, Settings > Safari > Advanced).
Option 2: WebKit through Playwright (Mac, Windows, Linux)
Playwright is an open-source browser automation library that ships a WebKit build for all three desktop systems. It includes device descriptors for iPhone models, which set the viewport, pixel ratio, user agent and touch support.
This is not iOS Safari. It is the WebKit engine on a desktop OS, without iOS-specific browser UI. It still catches a good share of WebKit rendering differences, and it is scriptable, so you can take screenshots of every key page at iPhone size in CI. For developers on Windows it is the cheapest way to see WebKit at all.
Option 3: cloud real-device services
Services such as BrowserStack, LambdaTest and Sauce Labs rent access to real iPhones in a data centre and stream the screen to your browser. You get real hardware, real Safari and many iOS versions. They are paid, usually with a limited free trial, and the remote screen has some lag.
Use them for final checks on important flows (sign-up, checkout) when you have no Mac and no iPhone, or when you need an older iOS version.
Option 4: a quick iPhone-sized view in Chrome
For pure layout questions (does the menu fit at 390 px, does the hero image crop well), an iPhone-sized view in Chrome is enough and takes seconds:
- Chrome DevTools device mode with an iPhone preset, covered in the Chrome mobile emulator guide
- a mobile view extension such as Mobile View Extension, which reloads the tab in an iPhone frame with the iPhone user agent and screen size
Treat this as the first pass. Anything that looks off, or anything involving forms, scrolling or fixed elements, deserves a check in Option 1, 2 or 3.
Which option catches what
| Problem | Chrome mobile view | Playwright WebKit | Xcode Simulator | Cloud real device |
|---|---|---|---|---|
| Layout at iPhone width | Yes | Yes | Yes | Yes |
| Server serving a different mobile page | Yes (user agent) | Yes | Yes | Yes |
| WebKit CSS and JavaScript differences | No | Mostly | Yes | Yes |
Address bar and 100vh behaviour |
No | No | Yes | Yes |
| On-screen keyboard covering inputs | No | No | Yes | Yes |
| Real performance and memory | No | No | No | Yes |
A practical iPhone test routine
- Check layout at 375 px and 393–402 px in a Chrome mobile view.
- Open key pages in the Xcode Simulator (or Playwright WebKit on Windows).
- Fill in every form field and watch the keyboard and any sticky elements.
- Scroll long pages to see how fixed headers and the address bar interact.
- Run the most important flow once on a real iPhone or a cloud device before launch.
Current iPhone viewport sizes are listed in the iPhone screen size chart. For the other browsers your visitors use, see the cross-browser testing checklist.
Frequently asked questions
Can I test a website on iPhone Safari from Windows?
Not with an official simulator; Apple’s Simulator runs only on macOS. On Windows, use WebKit through Playwright for engine-level checks or a cloud real-device service for real Safari.
Is the Xcode Simulator the same as a real iPhone?
It runs real iOS and Safari, so rendering matches closely. It runs on your Mac’s processor, so performance, memory limits and some hardware features differ from a real phone.
Why does my site work in Chrome’s iPhone emulation but break on an iPhone?
Chrome’s emulation copies the iPhone’s size and user agent but renders with Chrome’s engine. Bugs specific to Safari’s WebKit engine only show up in Safari.