Render Testing and Debugging on Mobile Devices


Debug all the things!

I’ve been spending quite a lot of time render checking and debugging various new features recently. Whilst unit and acceptance tests are essential for ensuring an application functions correctly, rendering is an important thing to check too and often needs a variety of methods of testing to ensure pixel perfect results on all media.

A recent challenge I faced was debugging a data driven banner which rendered incorrectly on iPhone 6. It was impossible to solve the issue using Chrome dev tools alone, since the Chrome device inspector did not faithfully reproduce the banner issue. The banner also only displayed when certain variables were set, so I needed to use an HTTP debugging proxy.

This post is an overview of each tool or method I investigated, culminating with instructions on how to use Fiddler and Charles Web Proxy Debugger to set conditions on a real device.

Chrome Dev Tools

This doesn’t really require any introduction but here’s one anyway for completeness. Chome Dev Tools provide a basic overview of how your app looks on a variety of smartphones, tablets and desktop screen sizes and are a developer’s best friend when it comes to diagnosing and fixing most layout problems.

  • Pros: Quick and easy to use, included with your browser already, easy to amend scripts using Fiddler/Charles web proxy, great for development.
  • Cons: Not always 100% accurate. You will need to test on actual devices or emulators if you want to be sure there are no problems before pushing to production.

Xcode Simulator

This can be used to emulate a number of different Apple devices on all sorts of versions of OSX. So far the rendering seems to be true to life. The device applications are updated in real time so you know you’re using the most current versions (when Apple broke Safari the other day, Safari also broke on the emulator, which was great fun). Since the simulator runs on your local machine you can just serve to localhost and go. It doesn’t take that long to load, but it’s not exactly instantaneous either. You can use Charles or Fiddler to proxy your scripts as you would when using your browser too.

  • Pros: Mirrors real device well, runs on local machine
  • Cons: Load time can get annoying if you are having to re-render something frequently, supports Apple devices only

Android Studio

I’d be lying if I said I knew a great deal about this tool. I was swiftly warned away from it by one of the other devs in my team, who explained that the rendering is not necessarily representative of the device being emulated. The fact that the tool may not render things correctly made it unfit for purpose.

iPhone + Safari on Mac

Another Apple only solution (requires a Mac too). It allows you to debug your app on iPhone/iPad and comes with a Console and Network tab. It’s pretty easy to set up.

– Switch the Web Inspector on on your device by navigating to Settings > Safari > Advanced and toggling Web Inspector to the On position.
– Load up the page you want to meddle with on your device.
– Plug your device into the Mac using a lightning cable and open Safari.
– In the Safari menu go to Develop > [Device Name] > [Name of page].

You will then be presented with the markup for your page, CSS rules and basically all the things you’d expect from Chrome dev tools. Change the code and watch your page update in real time 🙂

  • Pros: Uses actual devices, debugging possible, breadth of tools that you would normally associate with Chrome
  • Cons: CSS rules tricky to edit, not as intuitive as Chrome, Apple devices only, Apple product overload

Any Device You Like + Fiddler / Charles proxy debugger

Download Fiddler if you’re on Windows, or Charles if you’re on a Mac.

This setup will allow you to view a page on your device of choice and update its scripts. It means you can edit your test conditions (e.g. particular values for data being passed in) and view the outcome on any device you choose. Lovely stuff.

First, you need to download an SSL certificate for your particular device or OS. I used the legacy certificate even though I’ve got the most up-to-date version of Charles and it worked just fine. Make sure both your device and your computer are on the same Wifi network. Then go to your phone’s Wifi settings and add a proxy. This is fairly straightforward on iPhone, but Android make it tricky by hiding things. If you’re on Android, hold down on the name of the Wifi network to make a dialogue box pop up, then click Modify Network. Select ‘Show advanced options’ and the proxy settings should appear. Enter your computer’s IP address and the port number your proxy debugger is using. This is more than likely to be 8888, but check in Charles at Proxy > Proxy Settings > Proxies, and yes that is the real path. Check in Fiddler at Tools > Fiddler Options > Connections.

Now you should have everything up and running. Check that a) the page loads on your device and b) when said page loads, the Structure panel in Charles (unnamed panel on the left in Fiddler) picks up the activity. If either of these don’t happen, check your device and computer are on the same Wifi network and that your proxy settings are correct.

Charles Rewrite tool

This is a very handy tool that lets you modify your requests and responses so you can double check everything is rendering correctly under different conditions. Open up Tools > Rewrite. Here you can add a new ‘Set’ for each set of conditions you want to apply. In the Locations menu add the URL(s) of the page you want to modify and then start adding the Rules in. In my case I substituted the existing value of PortalName in a tag object, to allow a test banner to render for closer inspection on Android.


Fiddler custom rules

Go to Rules  > Customize Rules. Add this into the onBeforeResponse function at the bottom and substitute everything in square brackets for your required values:

if (oSession.HostnameIs([SITE_URL]) && oSession.oResponse.headers.ExistsAndContains("Content-Type","text/html")){ 

Save and close.


For simple rendering checks whilst developing, Chrome dev tools are awesome. If you want to make sure things look pixel perfect on every device, load up your test environment on real devices where possible and on emulators of the devices you don’t own. If you want to check elements that only appear when script modificaions are made, use Fiddler on Windows and Charles on Mac using the proxy instructions above.


First published on Natalie’s own blog, on 2nd February 2016.

One thought on “Render Testing and Debugging on Mobile Devices

  1. Great post! In regards to Android simulator not really being fit for purpose, the main issue is that the default “Internet” browser on the phone varies between OEMs, as they do their own customizations to it. I’ve read in the past how OEMs such as Samsung and LG have done their own improvements, where at certain points their variations achieved higher HTML5 benchmark results than other “Internet” browsers and even Chrome running on the same device. Then there is also the Webview within the app containers which could be more restricted than the default browser or Chrome. Then there is also the vast amounts of different browsers out there such as Chrome, Firefox, Opera, UC browser, etc. Which aren’t as restricted about their implementation compared to iOS which locks you to Safari’s rendering engine. So trying to tackle this on the simulator can be quite fruitless and best to tackle this on a device with the exact problem. Android does off browser debugging tools like Apple does for iOS, but they may or may not work depending on the browser itself.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s