soledad penadés

Using Web standards and progressive enhancement provides us with a cross-platform toolkit of expected behaviour we can build upon, but differences in browser engines and user interface behaviour can make the user experience quite difficult, if not downright hostile.

So that's why while automated tests using software like Playwright, which can emulate what a user would do, are helpful as a safety harness, you should still aim to test with real devices, at least from time to time! And at the minimum, each time you introduce a new feature.

But not everyone might have access to a device that can run iOS and so run Safari.

Fortunately, if you are running macOS you can run XCode, and then you can access device simulators, which will allow you to test in Safari for iOS, even without an actual physical device.

As far as simulators go, the process to get them is relatively simple:

1. Open XCode (or install it first)
2. From the Window menu choose Devices and Simulators (or press ⇧⌘2)
3. In the window that opens, select Simulators on the top left corner. The first time you run this, there will be no simulator to select, because you have to install them first.
4. Go to the XCode Settings by clicking on the XCode top menu then Settings. (I often just use the standard Mac shortcut ⌘,)
5. Select the Platforms tab.
6. Locate the iOS section and press Get to download the simulators for iOS.
7. Once you download things, you might need to close and reopen the Devices and simulators window (I think mine was still showing nothing yet and I had to restart the whole of XCode).
8. Now when you reopen XCode and the Devices and simulators window, if you go to the Simulators you will find a prepopulated list like the one I get, with an assortment of iDevices that you can use to simulate:
9. You can also press the "+" sign on the bottom left corner to add an specific configuration if you'd like one that is not in the list.

Now, once that dance is done, to test a website on mobile Safari in a simulator:

1. Go to Safari on your desktop.
2. Open the site you want to test.
3. In the Safari Develop menu, select Open Page With and then whichever simulated device you want to use.
4. This will open the simulator for the device, so depending on how resourceful your computer's CPU is, everything might get very slow as you're running a phone inside your computer (my laptop is semi ancient now so everything gets slow, I can tell you).
5. When it finishes booting, you'll see a simulated phone running your site in Safari for iOS.

For example here is this website running on a simulated iPhone Pro 11:

and these are the DevTools inspecting that page:

Note: I think it might also be possible to launch a simulator if you find the Simulator app in your computer, and launch a specific simulator from there, but opening it from Safari helps you in that it opens Safari and the website you want to inspect.

And that's when I could say "off you go!", but here is some extra advice which can be useful:

1. Clicking and tapping on the simulated screen will work as normal when using your computer trackpad (or mouse, I suppose—I only use a trackpad).
2. But: zooming in and/or scrolling as you would do on a normal touch screen using the touchpad doesn't seem to work. It does nothing at all (weird, I know!). For that, I use page up or down to get around pages which need scrolling.
3. If you want to use Web developer tools on the simulated Safari, you do that from Safari but outside of the simulated environment. Go to the Develop menu in Safari again, but this time find the menu entry for the simulator you opened, and choose the title of the website you want to attach the devtools to.
4. This opens a sort of detached, floating Developer Tools window, and you can use the usual tools to inspect things, like the inspector, network, sources...

The weirdness of said tools when you want to achieve something that is a bit more specific probably deserves a separate post, so I will stop here.

This should help you go a long way already!

But why would you test with a simulator, when Playwright already offers support for "mobile Safari"?

I don't know for sure the low-level technical details, so I won't speculate on whether Safari on desktop is using exactly the same version of WebKit that Safari on iOS uses, or what is it exactly that makes them different, but there are behaviours that you see in Safari on iOS that you don't see on the "mobile Safari" that Playwright uses. Yet you do see them on the Safari that runs inside the simulator, so I am hoping that the 8+ Gb we download for simulating are giving us the real thing, or if not real-real, at least realer than the pseudo mobile Safari Playwright runs.

For example, the UI widgets render very differently. So things like input fields, buttons etc, will look different. Let's be clear, it is NOT a problem that different user agents might render things slightly differently (specially when it comes to interactive elements), but you might want to see how they do it, and perhaps add a bit more padding and surface area in mobile contexts, for example, and the only way to get a good feeling for how much "correction" you need is to see your code in a mobile context.

Another thing that seems different is how the browser auto scales, and in particular the auto zooming in for forms. The auto zooming that kicks in mobile does not kick in when running the same code in Safari in desktop, even if you perform the "responsive design dance" i.e. making the browser window smaller to make the viewport narrower. You have to run the code in the closest conditions as the user will in order to see what will actually happen.

And yet it is still not perfect

As I mentioned, you still want to run the code manually from time to time, to make sure there are no things that escape your testing and will make life difficult for your users. It is one thing to click with mouses and trackpads, and a very different one to hold a device in your hand as you normally would, and try to perform the same task.

For example, one funny "bug" I encountered was due to the fact that a link to edit items was on a corner of the screen. When developing, I hadn't given it a second thought; the end to end tests always passed because the link was visible and the "user" could click on it.

But when I tried to run the same code on a phone, I realised the link was actually almost not clickable: as the website did not have a lot of padding around the body in mobile (to save precious screen space), the link was just at the end of the screen, which turned out to be just where the rounder corners of the screen are. And half of the link was "eaten" by the rounded corner, so you could barely click it (and that's if you knew it was there).

So, test, test, test.