Introduction

Over the years, there has been a war raging between two mobile camps. In one camp, you have the "Native or Bust" population. On the other side of the fence are the "HTML5 Rocks" guys. As with all things, the best answer tends to be a needs-based compromise between extremes. When discussing this with colleagues, one question almost always comes up. "When should I use a hybrid vs a native solution?" In my #ThinkMobile presentation, I discussed the advantages and disadvantages of these two app types. Additionally, I gave an overview of the 5 "app types""App" is used loosely here to include both traditional and mobile web. found in today's market.

There are 5 types of mobile apps. Successful developers must know when and why to use each.

So what are the 5 types of mobile applications and when is each appropriate? Let's get into it.

Traditional Web

First up is the traditional website. A traditional website isn't mobile, is it? There was a time when it wasn't. Before 2007, standard websites were almost completely incompatible with mobile devices. Sure there were a few browsers that sort of rendered a version of basic websites, but the experience was horrible. When Apple introduced the iPhone in 2007, it made the traditional web a first class citizen of the mobile world. The new experience was not perfect (no Flash, for example), but it was almost as good as the desktop experience for the first time.

The good news here is that you probably already have one of these. If you don't, they are relatively easy to build. The bad news is that, compared to the other solutions discussed in this post, traditional websites offer the worst user experience. "Pinch to zoom" seemed like a brilliant concept at the time, but it quickly becomes a pain when browsing the internet. Additionally, these sites were likely not built with mobile in mind, so there are lots of missed opportunities when it comes to using the device to fully engage your users.

Traditional websites offer the worst user experience of all mobile solutions.

So when should you use this approach? In short, you shouldn't. I'm not saying you should never build a traditional website again; just that you should not consider it to be your "mobile" presence.

Mobile Web

Traditional websites, while easy, are lacking when it comes to mobile user experience. One of the quickest fixes for this is to convert your site to a mobile web site. In fact, if you're going to redesign your site for mobile, you should make it a responsive website (so that it presents the best experience for both mobile and desktop).

Despite the fact that traditional websites, for the most part, render fine on mobile, the mobile web is really the most basic solution you should consider when developing your mobile strategy. The advantages here are that it's just as easy to develop as a traditional website, but presents a far better user experience. You also get to target the widest possible audience since the vast majority (if not all) smartphones will support it. You can take advantage of many mobile device features to fully engage your users. There is even support for offline functionality that you can use if needed.

The main disadvantage of the mobile web is that you are at the mercy of the browser.

On the other hand, your main disadvantage is that you are at the mercy of the browser and unfortunately, not all browsers are equal. If you've been a developer long enough, you'll remember the browser wars on the desktop. Things might not be that bad anymore, but there are still quite a few inconsistencies to deal with.

Go with a mobile web solution when:

• you are looking for the least expensive way to target the widest audience.
• you wish to avoid dealing with the various app stores.
• you must support e-commerce and don't wish to share your profits with today's mobile platform vendors.
• you do not have very strict Data at Rest security concernsData at Rest is an IT term referring to inactive data which is stored physically in any digital form (e.g. databases, data warehouses, spreadsheets, archives, tapes, off-site backups, mobile devices etc.)..
• you are not concerned with having your code in the open.

If none of the above apply to you, perhaps you need a hybrid or native solution.

Hybrid Apps

Until now, the mobile solutions discussed above are not what the general public would consider a mobile app. There is nothing to install with those other solutions and not much you can do with them if you need deeper access to the mobile device.

This changes with Hybrid apps. These are generally web applications, wrapped inside of a mobile app. The mobile app wrapper itself uses a web viewer (basically a scaled down version of a browser) to display the web pages. Naturally, your web pages are developed with the same technologies you'd use for both the traditional and mobile web; namely, CSS, HTML and JavaScript.

With hybrid applications, you get all of the advantages of the mobile web and many of the benefits of having an actual app. While you are still at the mercy of the browser for rendering and overall performance, you now have the power to dive into the device's API for additional functionality.

Be aware of the uncanny valley when building hybrid apps.

The downside of the hybrid approach typically centers around the UI and performance. Since you are not using native controls, you have to create your own (or use a packaged set). Many of the packages today tend to have a strong bias to a single platform. While you can target many platforms, your apps tend to look like they were written for one platform only. For example, both Sencha Touch and jQuery Mobile defaults to an iOS-centric look. The same app running on Android or Windows Phone seem like they've been ported over, rather than written for these platforms. Additionally, the components tend to leave your app in the uncanny valleyThe uncanny valley is a hypothesis in the field of human aesthetics which holds that when human features look and move almost, but not exactly, like natural human beings, it causes a response of revulsion among some human observers.See Martin Fowler's post for information on the uncanny valley as it relates to hybrid mobile apps. There are many hacks that developers have come up with to get over the performance hurdle. Some work; some create more maintenance issues than they are worth.

A hybrid solution is right for you if

• your target users are spread out over most of today's mobile platforms.
• you want to leverage the various platform-established stores for distribution, payments and in-App commerce.
• you need more access to device APIs than is afforded by the mobile web solution.
• you have Data at Rest security requirements.
• you don't have very high performance requirements.

Need even more power? A native solution may be your best bet.

Native

Native apps give you access to everything there is for a given platform. These are typically the best performing mobile solutions available today. When going over this particular option with my clients, I break it down into two categories; Native and Near Native. Let's take a look at each one.

Native Apps

Again, native apps give you access to everything under the hood of your chosen platform. These apps are written in the language specified by the platform (Objective-C or Swift for iOS, for example). While 3rd party libraries are often used, no part of a truly native mobile application is written in a language that is foreign to the platform except in one situation. There are times when you need to display a webpage in your app. The content of that webpage might be extended functionality written in HTML, CSS and JavaScript. In fact, it is this very approach that is used by the hybrid solution discussed above.

Consider a native mobile solution when performance and security are paramount.

Performance, security, API access, native look and feel are all enhanced with native solutions. Almost everything is better. The downside comes into view when you need to target multiple platforms. You often can't reuse code, so this can be an expensive proposition for some situations.

You should consider a native solution when

• you have a critical need in the area of performance and/or security.
• you need access to the full range of device APIs for your selected platform (or at least much more access than is typically available for hybrid solutions).
• your UI's platform fit is crucial to your success.
• you are only targeting a single platform.

Near Native Apps

Often, the requirements for a mobile app include those of a native solution plus the need to target multiple platforms. This is where the near native solution can be a perfect fit. Near native apps have their business logic core written in a language other than that which is provided by the platform. In this regard, they are similar to hybrid apps. However, the UI and almost every other aspects of the app makes full use of native components and APIs.

Apps developed with Appcelerator's Titanium are great examples of this. They are written primarily in JavaScript, but make use of all native components. The end result is an app that can be targeted to multiple platforms but run natively on each. This means your app looks and behaves as though it was built specifically for the platform it is running on.

Near Native Mobile Apps: All the benefits of being native, plus the ability to go cross-platform.

The big win here includes almost all of the full native advantages plus the cost reduction resulting from a very high percentage of code reuse across platforms. For this, you sacrifice a small amount of performance in some cases. You also may not always have access to 100% of the native APIs. This last part is mitigated by the fact that you can usually extend these solutions to include anything that is not included in your chosen near native framework.

A near native solution is a good fit when

• you have a critical need in the area of performance and/or security.
• you need access to the full range of device APIs for your selected platform (or at least much more access than is typically available for hybrid solutions).
• your UI's platform fit is crucial to your success.
• you are targeting multiple platforms.

Conclusion

So there you have it. When it comes to having a presence in the mobile space, there are really 5 basic solutions. Though Apple and its iPhone made traditional websites much more usable on a mobile device, the user experience is severely lacking compared to the other solutions.

When working with clients, I tend to start the evaluation process with the near native solution front and center. This is because it offers what I believe to be the best compromise when considering API access, cross-platform requirements, performance and security. From there, I work with them to move toward a Hybrid approach or full native depending on their needs. I mostly hold off on recommending a mobile web solution unless there is a specific need to avoid distribution via a platform's store.

What's your approach? Do you have other reasons for picking one solution over the other? Let us know about them in the comments.