Building the mobile app : web or native

Posted on by — No Comments ↓

With the rise of mobile devices (phone and or tablet sized), many enterprises are starting to rethink their existing front end systems.  Where in the late 90’s it was common to heard the cry of “We Need a WebSite” followed by buckets of money thrown at people who couldn’t even spell HTML (happy days 🙂 ), now the call is “We Need a Mobile App”, as a short term fix for a missing check on someones CYA list.

So, assuming that the web site isn’t static (or updated rarely) there are a range of ways to deliver the functionally to the user, with pluses and minus.

  •  Standard web site.
    • +
      • Your doing it already
      • known process / technology
      • no new money spent or budgeted.
    • –
      • Not finger friendly.  small links and buttons are hard to select with finger.
      • Hover-overs are not touch. if mouse hover-overs are used to reveal information in navigation then it’s unusable to mobile users.
      • Dependent on zoom to see, read text and select links in large wide pages.
      • if you’re using Flash, or other special plugins, then it unusable to mobile users.
  • separate special mobile web app  m.website.com
    •  +
      • Uses server side user agent detection to redirects mobile devices away from the main (“real”) site.
      • uses known process / technology
    • –
      • Problems with user agent detection : too many agents (+2000); and user agents lie.
      • work is done to run and support a separate mobile site in addition to the main (“real”) site.
  • New response web
    • +
      • Uses html5 features of mobile browsers
      • responsive to all device sizes, broadly.
      • One web site for mobile and desktop.
      • Use media size and feature detection.
      • Progressive shims as fallback to support features.
      • The new version is available right away to end users, as soon as they are put into production on the server.
      • It is easy to share content with other people, a link opens the right link on the web;  links don’t open native app’s.
    • –
      • For very old browsers may be sub optimal without extra work to implement progressive shims.
      • some new skills needed.
      • new designs to make one web site work across all media sizes.
      • May not be able to take advantage of all features and functions, especially camera &  orientation.   Dependent on JavaScript libraries and/or browsers supporting feature.
      • May want to use CSS to lightly skin for different look and feel for different platforms.
  • Native app
    • +
      • Native look and feel
      • Can be best performance
      • Can take advantage of all the features and functions of the platform.
      • In the app store / marketplace
        • Discovery
        • You don’t build your own payment hooks for buy or in app purchases.
    • –
      • Need to build that native look and feel for each platform. Skills for each platform are completely different.
      • Rolling out changes depends on the app store approval and timing, and user actually updating.
      • App store / marketplace is very crowded , discovery is tough.
      • the App store needs to approve the purpose of the App, and you did so in an approved manner.
      • The platform get a cut of each purchase.
      • Hard to share content with other people outside the app.
      • How many Native devices and Native platform operating systems?:
        • IOS 5 and 6 : hardware iPhone 4 and 5; iPod’s; iPad’s and soon iPads mini’s.
        • Android 2, 3, 4 : a million phones from 3.5 to 5 inches; Kindles; Nooks; and other Tablets from 7″ to 11″
        • older RIM OS and the new Rim BB10 on phones and play books tablets
        • Window Phone 7, 7.5 and 8 (Metro)
  •  Hybrid app
    • +
      • Use Native HTML wrapper to render html5 from server in a native app.
      • Gets you in the app store for discovery and purchasing
      • Lots of reuse of HTML with some native app look and feel.
      • Sometimes able to use platform features not possible in browser.
      • Able to release changes right away by severing up new html5 from server.
    • –
    • Performance is often worse than running in a browser.
    • not native looking.

Look at your logs and ask several questions :

  • when will mobile usage exceed non mobile usage? can you assume a linear increase?
  • are you seeing or hearing from frustrated users with mobile devices.

So given that more and more traffic is coming from mobile devices, what to do.

I would suggest :

  • your existing site is broken for mobile uses and the separate mobile site is a long term headache.
  • So, build a responsive web site,
  • If you have an existing mobile site, transition that m.website.com site to the responsive site.
  • The aim of the responsive site is to become the only web site, once you are comfortable with that.
  • The design aims of responsive design is good web design, regardless of size.
  • The responsive design lessons can be applied to your Native app.
  • Build / modify your back end to serve up html pieces and data pieces (via a RESTful json web service).
  • Build / test each feature quickly on the back end and make it available to all your front ends (web and native).
  • Discovery on the web is a) links your friend sends you; b) Social Networks; c) Search.
  • There are websites being built today that rival anything being build natively on desktop or mobile.
    • Angry Birds on HMTL5
    • first person shooters in a browser.
    • spreadsheet entry and polished visualization that match excel.
    • document management in the cloud.
  • If you really need to be in the native app store :
    • use the design work you have done on the responsive site.
    • try a Hybrid app to build experience building on the Native platforms.
    • take advantage of your modify back end to devise a better experience.
    • go fully native if and when :
      • once your feature set and design is stable.
      • there is a feature that can only be delivered natively at this time.
      • you can live with or work around the platform lock in and restrictions, and payment issues.

The goal is to have the best experience for your users / customers, always.  Which means a the best web experience and when needed the best native experience on targeted devices.

There is one scenario where I might skip the web and go directly to native : single purpose product applications.  If it has a narrowly defined function then it might make sense to build a native app.  For a broad, general purpose site or set of applications then the zero install, the always up to date web is the preferred vehicle to deliver.   But to deliver a single feature and to have it at the users finger tips, theoretically a single click away, then I would look to a native app, with a detail responsive web app for SEO linking to the app in the various play stores.

So it’s not Web or Native, its Web and then Native.

Update : HTML5 mythbusting on the Mozilla Hacks site makes many of the same points about modern html5 applications / websites.

Leave a Reply