"I need to build a mobile app…where do I start? HELP!"

There is no shortage of confusion around the question of which path to take when targeting mobile devices. Entire white papers cover this topic and are still incomplete. With that in mind, my goal with this post is to provide, perhaps, a starting point. Getting answers is critical, of course - but knowing the questions to ask is the first step.

Let's start with the obvious question.

What are my options?

Perhaps the easiest to answer (though this isn't an exhaustive list - remember, just a starting point):

Application Type Pros Cons
  • Full Access to Native UI Features
  • Discoverability via app stores
  • Access to all device capabilities
  • Multiple target platforms/languages/tool sets
  • Expensive w/very thin margin
  • Extremely wide reach
  • Often re-use existing (responsively-designed) web sites
  • Extremely limited access to any device hardware
  • Limited discoverability (no app store presence)
  • Usually much more difficult to monetize
  • Natively-installed & run apps, built with JavaScript, HTML and CSS
  • Same code base targeting multiple platforms
  • Same discoverability as native apps
  • Access to many device capabilities (and can reach more via plugins)
  • UI performance affected by native webview implementation & (potentially) inefficient code
  • Differing web view implementations on each target platform

So which one should you use? To quote the classic reponse: "It depends…" Each native effort represents a new body of discipline you must either hire for, or train your existing developers to master. In a world where 67% of those developing mobile applications for profit are below the "app poverty line" (more on that in a bit), these kinds of commitments cannot be made lightly. However, hybrid approaches are significantly changing the landscape. (Hybrid/cross-platform options like Cordova – often called "PhoneGap", see this to learn more about the differences – involve effectively hosting a web application inside a native application container. This enables you to write natively-installed mobile applications using HTML, JavaScript and CSS.) With fairly minimal changes, an existing web developer can bring their skills (and often existing code) to bear in a hybrid mobile app.

Why Should I Care About Hybrid Options?

This is an incredibly fascinating time to be in development. I think it's nearly impossible to overestimate the level of disruption we are currently witnessing – and not just the mobile & tablet disruption of the desktop market, but the disruption within mobile development. In their Cross Platform Developer Tools report in 2012, VisionMobile (borrowing from Dan Adams) called the explosion of cross-platform tools the "democratisation" of mobile software development. Developers can now target platforms that would have been difficult or impossible to reach otherwise. You should care because the growth of cross-platform tools means you have the option to leverage existing skill sets in web technologies to target multiple platforms. Utilizing existing skill sets means bringing established maturity in HTML, JavaScript and CSS to bear in the mobile space (60% of cross-platform developers have more than five years of experience in web development). This can be a critical component of making your decision when you weigh the short-time-to-market constraints against ramping your team up on entirely new language and platform tools. Even more so if your intent is to support more than one mobile OS.

For more financial incentive, consider this: in the Developer Economics 2013 report, VisionMobile had 82% of the survey respondents indicate they were developing mobile apps to make money. Out of that group, 67% of them are below the "app poverty line" - making less than $500 per app, per month. Ouch.

This chart, from VisionMobile's Developer Economics 2013 report, provides a nice view into the selection critiera driving the decision process(es) that led to choosing cross-platform/hybrid tools (by the way, Icenium is Cordova-based, like PhoneGap, so we fall under that category below):

Mobile Mindshare Chart from VisionMobile

  • Does your team already have web experience?
  • Do you plan to target more than one device?
  • Do you have serious time-to-market constraints? (Who doesn't?)
  • Do you want a development process that lends itself well to simultaneous release on your target mobile platforms?

If you've answered "yes" to any of the questions above, and you are not critically dependent on device-differentiating features, then a hybrid approach is definitely worth looking at.

But wait - what are the trade-offs?

Deep Native Integration & Performance Concerns

It's no secret - if you build an Cordova-based application and you need access to native APIs that aren't already available via Cordova's API, then you have three choices:

  • Write a Cordova plugin
  • Embed Cordova WebViews inside the native application (it is a hybrid, after all)
  • Choose to roll without the feature (never the option anyone wants to pick)

Remember that Cordova-based apps use the native web view of the target platform - so UI performance is constrained by the performance of the web view. As many Cordova/PhoneGap developers have discovered, this has made hybrid apps targeting older Android versions (v 2.3.7 and earlier) especially painful at times. This is a very important consideration - given the fact that our desktop browsers are typically much more capable at brute-forcing their way through inefficient JavaScript, DOM reflow, etc., paying close attention to the performance of your code is essential. In other words, while the native web view implementations matter a lot, many current performance problems in hybrid mobile apps could be drastically reduced or eliminated with better engineering discipline in how the app is built. Andrew Trice has a fantastic post on performance and ux considerations here.

Why not mobile web?

A Forrester report makes the recommendation that many companies should start with the web first, then move to hybrid applications. Of course, this really depends on your target audience, what kind of discoverability you want your site/app to have, whether or not you need offline capabilities, etc. The good news is that – if care is taken in how your web application code is structured – a large portion of it will be re-usable in your hybrid application. (In theory, nearly all of it could be re-usable, but even modertately complex applications will run into differing implementation needs in hybrid vs web scenarios.)

Just as there are trade-offs between native and hybrid approaches, web vs hybrid has them as well, as nicely described in this chart from VisionMobile's 2012 Cross Platform Developer Tools report:

Hybrid Trade-Offs Chart from VisionMobile

It's Going to be a Fun Ride

We haven't even talked about the abandonment rates of each cross-platform tool, the statistics on the average number of cross-platform tools each developer will use this year (around 2), nor the ever-accelerating level of hardware capability in mobile and tablet devices. It's an area ripe for continued disruption and exciting advancements. Sure, hybrid development for native-niches, like high-performance games, lags behind what is currently possible with native implementations. However, the gap between hybrid & native for line-of-business, social media and other (more common) types of applications continues to narrow. When you combine all of the factors:

  • rapid time-to-market
  • razor-thin margins (if that) in mobile application revenue
  • multiple target platforms (each representing a significant technological commitment on the part of your company)
  • existing & mature skill sets in web technologies that you might already possess

…the question isn't "why would you consider hybrid apps?", but "why wouldn't you consider" it?

About the Author

Jim Cowart

Jim Cowart is an architect, developer, open source author, and overall web/hybrid mobile development geek. He is an active speaker and writer, with a passion for elevating developer knowledge of patterns and helpful frameworks. 

Related Posts


Comments are disabled in preview mode.