How to debug problems on Mobile Safari

When you are developing and/or testing a web app on iOS, having the ability to inspect and understand what is happening in the browser is incredibly useful. For just this reason Mobile Safari can use the same developer tools that are built into Safari on macOS.

To start debugging you’ll need your iOS device, a mac and a lightning cable. Then start by making sure both devices are configured to allow this.

Configure devices:

  1. Launch Safari on your mac; open preferences and within the advanced tab click the checkbox for “Show Develop menu in menu bar”.
    1. Confirm, you should now see a menu called Develop in the top bar
  2. On your iOS device (iPhone or iPad) go to Settings > Safari > Advanced and slide the toggle on for Web Inspector.

Debug a site in Mobile Safari:

  1. Connect your iOS device (iPhone or iPad) to your mac
  2. On the device browse to your site in Mobile Safari
  3. On your mac’s Safari, under the Develop menu you should see an option for your iOS device (either called iPhone or iPad).
  4. In that sub-menu you should see the url of the website you want to debug. Click that url and it will open a new Safari window with the full Safari Dev Tools.
  5. Start your investigation!

Safari Dev Tools

A few weeks back I was testing changes to review submissions (buy a product, leave a review) and on Chrome desktop everything worked fine (including Chrome’s mobile emulator). However after testing on a real device, Safari didn’t behave the same way. Luckily we were able to debug using this same method and fix those remaining issues before any customers saw problems.

It just goes to show real device testing matters!

Oh and if this article worked for you please consider sharing it or buying me coffee!

It’s easier to write about tooling

It’s easier to write about tooling than it is to write about the decisions we took and models we made prior to choosing it. (The same is true for talking about tooling). I can write about a specific test I designed with WebDriverIO far easier than I can write about the strategy taken, oracles used or even the trade offs.

Aside from being a popular approach, there’s a lot of value in this directness. I’m able to succinctly communicate a specific problem and solution that might help someone else solve a similar problem.

The downside is when someone doesn’t understand this subtle communicative strategy and makes the wrong assumption(s) about the decision path. This seems to be a common pattern when talking with someone new to automation in testing: they just want the tool and none of the other fluff.

My solution for this problem is a bit of fishing: I will recommend a tool and then ask a lot of background questions even if that means I retract my initial recommendation.