Technology Blog

Wanna cycle through posts?
Here's how we roll:

The author's views are entirely his or her own and may not reflect the views of Red Nova Labs. All material herein is copyright of the author or Red Nova Labs. Unauthorized reproduction is prohibited. Contact the author.

Posted by David Howe on February 16, 2012
1 Comments
Like this post?
+1

Mobile Platform Choices: Native App, Web App or Mobile Website

When deciding to take your next big idea into the mobile arena, you have an initial decision to make that is critical to your project's success: do you make it a native app, web app, or a mobile website? While all three of these choices have the power to do the job, certain ones are much better suited to certain kinds of mobile projects. For example, if it's fast, low-cost development with a broad reach you're after, you probably want to avoid building a native app. Alternatively, if you're looking to build a cutting-edge, "sticky" social platform that is going to revolutionize the way people connect, you probably want to take it beyond the capabilities that a mobile website or even a web app offers through HTML5.

Before you know it, a second level of complexity can muck things up: How far do you take your mobile experience? Do you focus strictly on mobile devices, or do you also offer a completely unique experience for tablets like the iPad or the Kindle Fire? If you do decide to go with a Web App or a Mobile Website, how much legacy support does your product need to offer? Can you get away with only supporting the latest and greatest devices (thus going full HTML5 and CSS3 support)? For now, it's best to put off these extra questions and focus on the core issue: How will you build your new mobile offering?

Let's take a closer look at each of these options in greater detail.

Native App

Building a native app means utilizing the Software Development Kit (SDK) that powers all of the applications that come with your phone. This is by far the most powerful of the three choices, as it has full access to all of the tools the original developers had (or most of them, anyway). The slickest applications you've played with to date are almost always built as native apps.

Take Clear, for example, a to-do list application that just launched on the iPhone this week. While it does not do anything that your standard fare to-do list applications already do (in fact, it does less than most), it excels at what it does by adding some extra "wow" factor to its user interface. By supporting true multitouch gestures and doing some pretty clever animation tricks, Clear takes full advantage of the iPhone's SDK in ways that would not work very well (if at all) as a web app.

Another app that has an especially over-the-top user interface is Path. Although it has been getting some hot press lately about storing a user's contacts without first asking permission, this social networking app is a definite standout for its clean but sophisticated UI. While a lot of what Path does well can be emulated as either a web app or even a mobile website, its "flair" features simply wouldn't be possible with strictly web-oriented toolsets. Take a look at the video below: the little animations the app performs between interactions with buttons like the "+" which results in a swivel rotation effect are what take it to the next level.

Okay, so if building a native app results in so much power, why doesn't everyone simply go that route? Time and money. Building a native app is considerably more difficult than building a web app or mobile website. Moreover, native apps are native to the device they were built to support. In other words, creating an app for Android means it only works on Android; the vast majority of the code and UI work you do for Android is not compatible with the iOS SDK, nevermind the Windows Phone 7 SDK.

Here's a short list of the pro's and con's to choosing a native app over its web-based counterparts:

Pro's

  • Extremely powerful, can do just about anything the device is capable of
  • Best performance, user inputs generate real-time responses
  • App's feel natural, as if intended for the device family they are being used on (because they are!)
  • Can be used if the user is online/offline
  • Can charge money for the app (one-time purchase, in-app purchase for new features, subscription model)

Con's

  • By far the most expensive option, in terms of both cost and time to build
  • Native only to the device family you build for (iOS, Android or WP7) - supporting more than one family requires nearly 2x, 3x the work
  • Need to be updated fairly frequently whenever a new build of the operating system is released to ensure no new bugs surface
  • At Apple/Google/Microsoft's mercy - if they don't like your app or find a problem with it, it doesn't go online or can be pulled at any time

Web App

First of all, what is a web app? There are technically two meanings to the term: one is a website that behaves more like an app (think Gmail.com or Twitter.com), while the other is closer to a native app in that it is downloaded from the App Store (or similar) and installed on the device, despite being powered by web technologies. For the purposes of this article, I'm considering the former to be a mobile website, while the latter is a true web app.

Web app's beat native apps in one key area: they are predominantly compatible with just about every major smartphone or tablet on the market today. Using what I call "mobile bridge" kits like PhoneGap, Rhomobile, Sencha Touch, and many others, you utilize HTML5, Javascript and CSS3 to build your application and deploy a product that works very similarly on all major devices. I say "very similarly," because like building websites, you still have to deal with slight (sometimes not-so-slight) differences in how HTML objects are rendered via CSS. It's like optimizing a website for Mozilla Firefox, then also having to optimize it to look the same in Internet Explorer 7: hopefully it looks similar, but oftentimes you have to refactor your HTML or CSS to make it work properly in both browsers.

Additionally, because building websites has been around for so much longer than a lot of these mobile SDK's, and because the languages used are simpler and easier to learn, it is generally easier and cheaper to find or build your own development team for web apps than it is native apps. Likewise, updating a web app is substantially simpler than a native app, as a lot of these mobile bridge kits serve as an intermediary API: they go out of their way to ensure that new operating system updates don't break old application code. Thus, you should theoretically not have to keep as sharp an eye on your older web apps that have been available for awhile as you would for native apps.

Here's a couple example web app's. The first, Diary Mobile, was built using PhoneGap, while the second, SugarCRM's web app, was built using Rhomobile.

Phone Gap & Rhomobile - Web Apps

It's important to note that there are some companies out there with new solutions to this entire debate. Appcelerator, for example, has a product called Titanium Mobile which is supposed to take the compatibility features that a web app platform provides and bundles it with the power that a native SDK provides. If you'd like to learn more about it, you can visit their website.

Let's take a quick look again at what separates a web app from the group:

Pro's

  • Highly compatible with all popular smartphone and tablet devices
  • Fast and relatively inexpensive to build - learning curve is less than native development
  • With HTML5 and CSS3 coupled with Javascript, provides a lot of the functionality a native app can provide
  • Can be used if the user is online/offline
  • Can charge money for the app (one-time purchase, in-app purchase for new features, subscription model)

Con's

  • Not quite as robust (feature-wise) as a native app
  • Cannot currently do some of the higher end UI tricks
  • Oftentimes feels like you're using a website, instead of a true, native app
  • At Apple/Google/Microsoft's mercy - if they don't like your app or find a problem with it, it doesn't go online or can be pulled at any time

Mobile Website

Arguably a totally different type of mobile offering altogether, mobile websites are typically extensions of your current desktop-designed website. In many cases, these are just stripped down versions of your regular website, oftentimes with some cut features and a layout that is optimized for a smaller screen. Visiting ESPN.com on your mobile browser, for example, presents you with a mobile website.

Three Mobile Websites

Because the same technology (for the most part) is used to create web apps and mobile websites, a lot of the same arguments can be made for going this route over a native app. The big defining difference between building a mobile website vs a web app is your user's access point: Does a user interested in your product/brand going to think, "Hey, let's open my mobile web browser and go to their website!" or "Hmm, let me go check the app store and see if there's an app for that!" If it's the former, then your decision is easy: go with a mobile website. This is good news for you: you get to avoid all of the App Store (and Android Marketplace, etc.) hullaballoo with getting your app submitted and approved: just throw up a web server and call it a day!

You'll find that the pro's and con's are similar to that of a web app:

Pro's

  • Highly compatible with all popular smartphone and tablet devices
  • Fast and relatively inexpensive to build - learning curve is less than native development
  • With HTML5 and CSS3 coupled with Javascript, provides a lot of the functionality a native app can provide
  • No need to deal with the App Store and its counterparts
  • Fast turnaround for site updates - just code the changes and deploy, no need to wait for your changes to be approved by a third party

Con's

  • Not quite as robust (feature-wise) as a native app or web app - does not have access to all of the API features a native or web app does
  • Cannot currently do some of the higher end UI tricks
  • Users will have a slow experience with new page loads (worse depending on their current Internet speed)
  • Can only be used and accessed if the user is online (through a cell or WIFI signal)
  • No built-in way to monetize

Great. Now what?

For most, choosing the right way to go at this point is fairly straightforward: if you have the resources and time available to build a robust, native app - go for it! Provided you design a compelling user experience that takes advantage of the power each device has, you are setting yourself up for the best current technology can offer. If the user experience isn't as important, but reaching the entire mobile market immediately while maintaining an App Store presence matters, then a web app is the best choice. Perhaps you aren't interested in building an app at all, though. In this case, just extend your current website to be better suited for mobile devices. Remember, you can have two websites at the same address that are viewed entirely differently: ESPN.com looks great on a desktop browser, and it works equally well on a mobile browser thanks to the magic of CSS. Also keep in mind that building a Native or web app and a mobile website are not necessarily mutually exclusive options! You might decide to have a mobile website for accessibility, while also building a Native or web app to tap an entirely unique market. Twitter.com and Gmail.com do this very well: despite both offering native applications for use, they also have full-blown HTML5 mobile websites too.

Categories:

    No categories are associated with this post.
Share:
  • Print
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google Bookmarks
  • Blogplay
  • Twitter

1 Comments

Tamjclem | February 26, 2012
Great detail and a thorough explanation that even we layfolks can understand. Thanks for the comparison of the three!
Leave a comment
(Public)
(Kept private)
Comments are published upon verification of appropriate content.
Red Nova Labs
Proudly powered by WordPress.