Macadamian Blog

Handle Browser Differences on iPhone and iPad

Ah, browser inconsistencies. Every web developer's favourite topic, right?

We all remember what it was like supporting Internet Explorer 6, and 7, and 8, all for the same product. It was a nightmare! Weeks of wasted effort, all because what worked in one version of IE didn't work in another.

But we're past that now, aren't we? Every mobile browser supports HTML5 and CSS3. We should be safe with mobile Safari. Right?

Wrong.

Innovation has a Price

Apple overhauled Safari in iOS 5. We're now able to do things that were previously impossible, or at least excruciatingly difficult (I'm looking at you, sticky footer), with ease.

Here are just a handful of the incredible improvements added to Safari in iOS 5:

• Position: fixed;
• Overflow: scroll;
• Improved <input> elements.
• Web workers.

This is fantastic news for mobile web development. Now we can make better web applications, and make them faster than ever before. We can craft new experiences to delight our users, and spend less time in the trenches. This is great!

But what about iOS 4.3 and lower? They have none of this functionality, nor any of the bug fixes that came to Safari in iOS 5.

Is this something you should worry about?

Data analytics firm Chitika measured the adoption of iOS 5 at 38% for all iPhone users, one month after release. That's quite good after only one month of availability, but the majority of users are still running an older version of iOS, which means an older version of Safari.

We have a browser gap on our hands. Users with iOS 5 have a much more capable browser than users with any other version of iOS, and that opens the door to version-specific bugs — events that don't fire in 4.3, views that only seem to work in 5.0, you get the idea.

These bugs are unavoidable. If you're only testing against whatever version of iOS you happen to have on your iPhone, you're going to get burned sooner or later.

The solution is to test your webapp against multiple versions of iOS.

How to Test Multiple Versions of Mobile Safari

It's clear we need to support iOS 5, and at least one older version. How do we manage this on a large project?

In short: Make Apple's iOS Simulator your new best friend.

The simulator provides a simple menu for switching between iOS versions. With only a couple of clicks, you can switch from iOS 5 to any major release since 3.2. This makes it easy to track down, and fix version-specific bugs.

The iOS Simulator isn't just a tool for developers; it's valuable to the entire team. Your QA will be able to properly validate and retest version-specific bugs, your manager(s) will be able to demo the project to stakeholders, and your designers can better suggest tweaks to the visuals and the interactions.

By giving everyone on the project the ability to check how the app looks and feels in multiple iOS versions, you're well on your way towards an app that works properly in whatever version of mobile Safari your user happens to be running.

But there are still some situations where you just can't beat real hardware.

When to Test with Real Devices

Ultimately your users won't be carrying around a simulator in their pocket. Even though the iOS Simulator is very useful, it's important to keep a few devices on-hand for the following reasons:

1. Release testing. You're delivering a mobile web experience designed for a real iOS device, so especially around release time; you have to test using actual hardware. There's always a remote chance a bug will creep in that is somehow invisible to the simulator.
2. Performance. This is a major concern for anything mobile, and it's one area where the simulator generally fails. Your iOS Simulator is probably running on a quad-core machine with more RAM than it knows what to do with. A real device has strict processing and memory limits, so it's important to test with real hardware regularly, to ensure those fancy CSS 3 transforms aren't slowing your app to a crawl.
3. It's fun. Don't discount how novel it is to see your webapp running on a real device. This can help make the project feel more "real", and raise the team's investment in their work. It can boost spirits during crunch time. Apple's hardware is designed to elicit an emotional reaction, and sometimes that's reason enough to take a break from the simulator.

So far we've established that the simulator is great for general testing, but real hardware is necessary for some specific cases. There's one last point to address for browser inconsistencies in mobile Safari:

Shouldn't the Frameworks do this for Me?

In mobile web development, it makes a lot of sense to use a framework like Sencha Touch or jQuery Mobile. One of the things these libraries help with is writing web code that can be ported from one platform to another (like iPhone to Android or desktop). It's a sensible conclusion that these frameworks should handle browser version discrepancies as well.

They do to some extent.

Sencha and jQuery aren't going to put iOS 5-only code into their frameworks. They will do everything they can to make sure their functionality is backward-compatible, or at least ensure it degrades gracefully. But they can't stop you from shooting yourself in the foot.

It's up to you to make sure your app works in the browsers your users are equipped with. Don't rely on a framework to do this for you. Figure out which versions of iOS you want to support, then test all of them using the iOS Simulator and real devices.