With developers new to the mobile web ramp up on a new project, I’ve observed a number of common pitfalls and barriers that are reoccurring patterns. This is an attempt to document the most common ones to help you in your quest to build great mobile web apps.
1. Emulator != Simulator != Device
Developers are in constant fear of anything that slows down their workflow. Thus, when challenged to build a mobile site or app, most will resort to test it on the iPhone Simulator until very late in the product development cycle. Unfortunately, simulators and emulators often behave fairly different compared to the actual device:
- The don’t feature the same rendering glitches
- Their performance is much much better than that of the actual device
- The network stack works completely different, and its performance is not the same
- Simulators are bigger on screen and use mouse input, thus buttons often end up to small for the actual device (non touch-friendly)
Simulators have been causing so much harm in the past that I’ve been strongly discouraging its use for many years now.
2. The performance difference to a PC is not linear
Many developers blindly assume that a mobile phone is roughly 10x slower than its PC counterpart. Unfortunately that does not tell the whole story: While often true for the CPU of a mobile device, the GPU is often highly specialized for certain tasks, and mobile browsers often have direct optimizations in place for things such as CSS Animations and Transforms.
Very often, developers underestimate GPU-related tasks and overestimate CPU-related tasks. Often, CSS Animations would look smoother on a tablet than on a Desktop browser!
3. Performance debugging is hard, and should be avoided
By far the biggest productivity issue with complex mobile web apps is performance debugging.
Often, web developers will develop feature after feature through emulation or simulation on their laptops, commit and deploy it, and then eventually test it on the actual device. If miraculously perf stays great, sweet! Unfortunately, there’s a very rare chance for this to happen – more likely, performance of the app is noticeably degraded on a single or multiple platforms (i.e. Android) and it will be unclear what exactly has caused the bottleneck.
Reverting commits and debugging performance of a web app retroactively is insanely hard, and will cost a lot of time and energy. Much better is a workflow in which the actual device is always the actual development preview, so when you change a single line of code and reload, the performance bottleneck is surfaced at right away and a revert or divert strategy is simple (at Chrome, we’re doing a lot of work to make this trivial by screen-casting the actual device screen onto your desktop environment).
4. Load-time hits by by cell connections (i.e. 3G) are grossly underestimated
When building mobile optimized web sites, even companies that invest heavily into actual physical test devices rarely focus on a particularly important category of testing: mobile broadband. And the reasons are clear: 3G data plans are a hassle to setup if you need to test dozens of devices, don’t really play that well with local intranets and are of course expensive.
This is why most developers will exclusively test on WiFi connections and will not experience the real world load time of their page until actual deployment to consumers. This is fatal. Cellular connections are not only slower on average, but have a much longer required activation / wake-up time, often more than a second, before any request can be attempted. Thus, developers are often shocked to see their real life load performance.
Luckily, there are a few traffic shaping tools that developers can install to at least emulate a certain network connection, and they’re much better than nothing. For Mac, checkout my favorite app Speed Limit, the new and shiny Slowy, or browse some of the other solutions.
5. Simpler features, higher maintenance costs
Mobile websites and apps are often a stripped down version of a “full” product, and even if it is the full product, features are streamlined and simplified in such a way that they’re fitting to the form factor. Features are often a lot less complex during project planning, which of course, is a good thing.
Unfortunately, while features are simpler, maintenance, i.e. debugging and bug fixing is an order of magnitude more complex, costly and time consuming. Many traditional project management processes do not take bug fixing into account, and while being a minor annoyance for desktop websites with, let’s say, 5% of the overall development process being bug fixing, it’ll become a major issue when bug fixing and debugging is a whopping 50% of all time spent on building a web site.
6. Multi-device UX is a much harder problem than multi-device code
An interesting discovery for many during multi-device development is that developers tend to finish cross-device code much quicker than they thought, while web designers and UX engineers will take a lot more time than originally estimated. This is due to the fact that most mobile browsers share a relatively modern environment and cross-browser quirks become increasingly rare(r), while issues with different resolutions, DPI, input and general difference in personas and behaviors make designing a multi-device product extremely difficult.
Especially a UI that is fluid and scales across the continuum of devices is an yet-to-be-solved problem that should never be underestimated. So try not to underestimate design work and when it doubt, double the initial estimates to be on the safe side.
If you have further suggestions on general pitfalls, please reach out to me on Twitter and I’ll do my best to incorporate them into this article. Thanks for reading and for preventing these mistakes in the future!