Mobile Website Development Pitfalls

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.

Stimulators – Are they constant?

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 do not 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.

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!

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.

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.

If you have further suggestions on general mobile web development pitfalls, please reach out to me on Twitter or Facebook and I will do my best to incorporate them into this article. Thanks for reading and for preventing these mistakes in the future!