Why You Should Lead with Mobile Web Apps (Not Native Apps)

Aug 22 2012 by Rob Banagale | 5 Comments

Why You Should Lead with Mobile Web Apps (Not Native Apps)

Based on my experience, when you’re developing apps for multiple mobile device platforms, there is a huge advantage to having your HTML5 mobile web developer lead the production effort as opposed to your native app developer (e.g., iOS, Android, etc.)

In this article, I’ll share my thoughts and opinions on why building mobile web apps first is a good strategy.

A Bicycle Racing Analogy

In team-based bicycle racing, riders from the same team often form a group called a peloton to protect the team leader from wind resistance.

New Zealand Team PursuitImage credit: "New Zealand Team Pursuit" by Velo Steve

A well-formed peloton uses domestiques (supporting team members) to protect its leader from wind drag, thereby saving him energy and giving him a better chance of winning the race.

Product managers tasked with delivering both mobile web and native apps will be able to work most optimally by arranging their teams into pelotons that can move products forward more quickly and efficiently. (Read about the differences between mobile web and native apps.)

Positioning your HTML5 mobile web developer as the primary domestique (flanked by UX design and UI design) is the best way to cut through the "wind resistance" of developing for multiple mobile platforms.

Cycling in the Wind

Most startups engaged in the Mobile space are focused on developing apps that run natively on iOS, Android or both.

Expressing your idea as a native application gets you reliable access to push notifications, the user’s address book, precise geo-location, the device’s camera, etc.

For all of the success that can come from releasing a native app, they can be challenging to build.

For one, talented native iOS and Android developers are in relatively short supply right now. If you’re in a position where you must contract a native app developer, you’re probably spending a premium for each hour of development.

Native app development can also be particularly slow if you’re iterating on a product concept. Seemingly small customizations of a UI control can turn into an extended effort. Requesting new navigation paths or revisions to previous design decisions may have serious time implications and incite frustration within the team.

I’ve seen wind resistance in mobile app development from a variety of sources, both in our startup (Gliph) and in projects for Fortune 500 companies.

  • Product managers iterate quickly and may shift between ideas for the user experience.
  • User feedback on a production release may cause tasks to suddenly be reprioritized.
  • Each change of plan may drive new backend requirements and redevelopment.

When your native app developers are leading your peloton, you risk tiring them out by exposing them directly to all of that wind drag.

If you want the native app experiences to be the centerpiece of your product, you need to conserve those riders’ energy.

Leverage Your Domestiques

The product manager, mobile web app developer, UX designer and UI designer work together as perfect domestiques for cutting through the wind resistance of multi-platform mobile app development.

Working together, these folks can rapidly prototype and refine features. They can play a crucial role in uncovering issues that would affect native app development.

For example, suppose you want to implement an app feature. This feature generally starts as a wireframe or a high-fidelity prototype. Typically, these flat images would be handed over to a native app developer. She would be expected to work directly with the UI designer and server-side web programmer to get the assets and services she needs. This may lead to loss of valuable native app development time.

A completed mobile web app serves as a practically complete, very concise specification for native mobile app developers. It acts as a living example of exactly how a feature set is supposed to work, and ensures services are hooked up and ready to go.

Bumps in the Road

Bicycle races vary by course, and so do mobile apps. HTML5 has come a long way in bringing smartphone functionality to mobile browsers. However, in some cases, it won’t be possible to fully prototype and realize your product in mobile web. For example, you may need to simulate the camera on desktop web by allowing Shockwave-assisted image uploads.

It may be hard to deliver a mobile web app that is similar to a native app experience. For example, native app SDKs usually include things that speed up development time, which you may have to build from scratch if you were to do the same thing in mobile web (though HTML5 mobile web app frameworks like Sencha Touch does even out the playing field quite a bit). As a result, there may be certain features your mobile web app developer is unable to build significantly faster or cheaper than your native app developers.

Communication between your team members is critical when moving from a feature created in mobile web, into a native app implementation.

Project managers must not only track the progress of the leading mobile web app effort, but also ensure the native app team is keeping pace.

Championing Mobile Web

For all of the hype around native app development, a robust mobile web app implementation has never been more important than it is today.

At our startup, we’ve found mobile web development not only protects native app development from headwind, but also gets out in front of the pack to explore the racecourse ahead.

Native app development for iOS and Android is currently the most expensive and difficult-to-recruit resource in the Mobile space, based on my experience.

That isn’t to say a great mobile web app developer is easy to find either. The critical role they can play in successful rapid mobile app development should not be overlooked.

Protecting native app developers from wind resistance can allow you to advance the most important parts of your mobile product faster and more efficiently. When directing the creation of a multi-platform mobile app project, cut through the drag by keeping track of your product leaders and forming a peloton to protect them.

Related Content

About the Author

Rob Banagale is Co-Founder and CEO of Portland, Oregon-based privacy startup, Gliph. He’s also a mobile strategist who specializes in mobile product development. If you’d like to connect with him, follow him on Twitter: @jetsetter.

5 Comments

Aaron

August 22nd, 2012

Great article too bad Apple / iOS and Android are constantly changing the way they allow for data to be saved locally on a device. Which can be a good thing and a bad thing, it can mean continued work on an existing mobile app if you are doing it for a client. It can also mean continually chasing your tail. I had a couple apps built in Sencha Touch break on me when iOS went from 5.0 to 5.1. So it’s important to keep in mind that both Android and iOS will continue to change the way these apps are allowed to work on the device and that their preferred method for a native app is to use native code and not embed everything into a web view powered native wrapper which is at the core of packagers like Phone Gap and Sencha Touch. So keep in mind, if you go with a hybrid approach or a native web view app, you may find your app breaking every time new system software is released.

Deon Robinson

August 22nd, 2012

Show me a mobile web developer and I’ll show you fool.

Brian Blankenship

August 27th, 2012

We use Appcelerator Titanium – the only cross-platform tool that I’m aware of that creates true Native apps (you can also create HTML5 apps if you like as well). This gives you and your customers/clients the native apps that they want for iOS and Android, but w/o the time/cost/resource disadvantages you mention and w/o the tradeoffs that come with HTML5 that you mention.

John

August 29th, 2012

Why would you leave a HTML5 developer to take the lead as long as HTML5 is still experimental?

Bob

September 1st, 2012

@John: Because most of the elements aren’t as experimental as you state it like above. 90% of modern browsers know how to deal with HTML5 so I see no excuse to not use HTML 5.

Leave a Comment

Subscribe to the comments on this article.