iPhone Web Optimization, Lesson 4: Smart Testing

In the previous lessons, we've had a look at how to optimize web content for the iPhone, particularly the types of wireless connections supported by it. The logical next step is to properly test our content, ensuring that it works smoothly on the iPhone, no matter how good or bad the current network connection is.

How can we do that? After all, you cannot run around town, looking for places with different reception qualities, just to test your content under various circumstances. There has to be a better way to do this.

We can break down our demands for a testing environment into two distinct categories: Simulating the iPhone and simulating the iPhone's connectivity.

The iPhone Simulator
Simulating the iPhone as a device is ridiculously easy, now that Apple provides a simulator as part of the iPhone SDK. You can download the SDK from the iPhone Dev Center, but you need to sign up for a free account to do this.

If you are absolutely opposed to giving out your personal info to Apple, you can download Marketcircle's iPhoney instead: While it's less full-featured than Apple's simulator, it's good enough to see how your content will look on the iPhone, either in portrait or landscape mode.

Using either of these applications, simulating your content on the device is a breeze. Keep one caveat in mind, though: Due to the iPhone screen's extremely high pixel density, the simulator appears much larger than a life-sized iPhone on your screen. Thusly, you have to be careful when planning out your content's dimensions: Things will look smaller on the iPhone than they appear in the simulator! This can get in the way if you're planning to include lots of tiny buttons or similar things in your content, which might become way too little on the actual device.

Keep this in mind and be sure to test your content on the actual device too. Testing in the simulator is mostly meant to get a quick glance at your content as you evolve its design, but it does not replace testing on the device itself.

While simulating the device is obviously a no-brainer, simulating the connection is probably not so easy. How can you turn your super-slick, blazingly-fast DSL pipe into the thin straw that is GPRS?

As you may know, MacOS X is based on Darwin, which is, in turn, based on BSD. The latter has had an incredibly useful feature for a while now, which is called dummynet. In short, it is an extension to set up simulated network pipes that can be configured to provide for a certain bandwidth, link quality and propagation delay. This feature is available in MacOS X as well.

The drawback is that you'll have to do this from the command line. Let's have a look at how we can set up a simulated EDGE connection to connect to our development web server, which we will assume to be running at the IP address (of course, you'll have to replace this address with your own server's address — if you can't use the address of your content server for whatever reason, replace the address with "any" in the commands below to let the pipes affect all connections). Run the following commands in a Terminal window.

sudo -s
ipfw add 1 pipe 1 ip from to any in
ipfw add 2 pipe 2 ip from any to out
ipfw pipe 1 config bw 120kbit/s delay 250ms plr 0.1
ipfw pipe 2 config bw 120kbit/s delay 250ms plr 0.1

Let's examine what these commands do: First, we sudo ourselves to superuser privileges, so that we can modify the firewall settings.

The next two commands add two dummynet pipes at position 1 and 2 in the firewall ruleset (these low positions ensure that the rules will be evaluated before all other rules). We set pipe 1 to be our incoming pipe, which is the pipe our web content will travel over from the server into our iPhone simulator. Pipe 2 is the outgoing pipe, i.e. the one over which our iPhone simulator sends requests to the server.

The last two commands configure our pipes. We set them both to a bandwidth of 120kbit/s, a propagation delay of 250ms (which is a pretty pragmatic estimate of what to expected from an actual EDGE connection) and a packet loss rate of 10% (i.e. 0.1).

Fire up your iPhone simulator now and reload your content to test it over the dummynet pipes. Do you see how it's loading much slower now?

You can reconfigure your pipes at any time by simply repeating the last two commands with different settings: Cap the bandwidth to something between 6 and 8 kbit/s to simulate a GPRS connection, set it higher to simulate 3G, play with "worst-case" propagation delays or jack up the packet loss rate to simulate bad reception. You can simulate any type of connection easily and conveniently right from your desktop Mac!

Once you want to get rid of the pipes again, you can delete them like this (be sure you're still in the sudo'd shell)

ipfw del 1
ipfw del 2

These commands simply delete the 1st and 2nd firewall rule, which is where we set up our pipes. Easy.

Of course, you can modify the commands to suit your needs better (such as inserting the pipes at different positions in your firewall rules, for example). You can find lots of documentation on the ipfw command by simply googling it or reading its manpage. And here's a link to more info on dummynet.

One more thing to keep in mind: Dummynet only helps you simulate the network link, but what it can't account for is the lower rendering speed of MobileSafari in comparison to the desktop version. However, if you keep your iPhone-optimized content reasonably simple and apply the optimization techniques described in the previous lessons, this effect will be negligible.

In this lesson, we've learned how to simulate the iPhone device and connectivity types from the convenience of our development Macs in order to test our iPhone-optimized web content's performance.

With dummynet, we can simulate lots of different connectivity situations that we could hardly create on our iPhone. After all, you may have a hard time to find a place with bad reception if you're in Europe, or with good reception if you're in the US ;-)

Nevertheless, it is important to note that testing our web content this way is purely focused on performance and appearance, but not on usability. In order to find out how your web content "feels" on the iPhone, you will have to test it on an actual iPhone. Only there you may find out that some button is a tad to small, some elements are too close together, etc. You may easily overlook such issues if you constrain your testing to the simulated environment, where you neither use multitouch to navigate your content, nor see it at its actual screen dimensions on the phone.

This concludes my mini-series on iPhone web content optimization. We've talked about the iPhone's technical peculiarities in respect to web content performance, how to optimize our content and how to test the effects of our optimization.

As closing words, don't be mislead by the availability of the native SDK. It will not obsolete iPhone-optimized web content. Rather than that, with the rising popularity of the iPhone and iPhone 3G, as well as its availability in many different countries by now, the desire for iPhone-optimized web content will also grow. No matter wether you're a startup or an established player, providing an iPhone-optimized version of your web content will give you a competitive edge. It's worth it.

Previous iPhone Web Content Optimization Lessons
Lesson 1: The Thin Pipe
Lesson 2: The Dreaded Request Count
Lesson 3: Requests and Images

iPhone SDK