Do I Need a Native App?

The Jargon, the Buzzwords, and the Reality of Designing and Developing for Smartphones and Tablets

Over the past few years, these things that we now call Apps have exploded all over the marketplace. It used to be cut and dry who needed an App and who didn’t – Apps used to be mostly games or tools or widgets of some sort for a specific task.

Now, nearly every website has an App component. The better Apps consist of the core functionality of the website – pared down, focused, and optimized for smaller screens and touch interfaces. The bad ones try to cram everything into a small screen without actually redesigning the experience, or do not take advantage of the native features that make smartphones so useful – geolocation, push notifications, accelerometer and the like.

As a newcomer to the marketplace, how do you determine what your company needs? Do you know what the buzzwords actually mean – Native Apps, HTML5, wrappers, or responsive design? How does your company plan to distribute the App? What sort of investment should you expect to make, and will it cost the same or more than the website that you just developed?

The Distribution Decision: The App Store Question

There is one main question to ask when deciding whether or not your company or product needs a Native App. The question is simply: Is it important that your mobile application be something that can be downloaded from the Apple App store? That’s it. If it is important to your company, then you need a Native App. If you need to make money by selling the App, a place in the App store shelf is a necessity. Apple will only approve Apps that have a Native component and conform to their HIG (Human Interface Guidelines).

If not, then you have more options – develop a Native Android App and distribute it through the Google App store, distribute it yourself to a closed network of employees, or the “App” could simply be a glorified web site that a user can still bookmark on their home screen.

Why is this the most important factor? 116 million iPhones and 67 million iPads,¹ that’s why. Apple has defined the market and practically defined what a smartphone is to many people. Since they are the cultural standard, their delivery system – the App store – is very important to someone distributing an App. Without it, your App can not get onto the iPhone.²

To answer this question, look at some of your own visitor statistics. If you use Google Analytics (why aren’t you using Google Analytics?) then you have access to a whole slew of data about your users. Are a major share of your current mobile visitors on one platform or the other? Can you predict which platform will be stronger if there is an App available? Do users in your market prefer one platform or are they more diverse? Are Blackberries on your radar (and if so, how much ibuprofen do you have access to)?

For some companies, this is an easy way to think about it. ”Yes, the main slice of our mobile users are iOS owners. Case closed.” Great. For others, it is not so easy, but either way, the distribution network is a key factor in any decision.

The Technology Decision
(and Why Your Users Don’t Care)

The end user does not care how a website or App is built, they only care about how well it works. If you answer the question “What does the App need to do?” then you can let the developer decide how the App needs to be built. After all, that is their job.

It’s potentially a bold statement to say that you shouldn’t care how something is built. Let me use a more familiar metaphor to explain:

I am in the market for a car. I know I want a car. I know I want four doors, wheels, and an engine. I know what it is and I know it when I see it. I may not care about color or how many cylinders it has or even how many doors, I just know that I need a car, and I don’t need to know more. I can go out into the marketplace and buy one. I know I am not going to buy a motorcycle, and I am not going to buy a bus, because I want a car.

Over simplistic, sure… but that’s what we are talking about here. Once you decide you need a car, you go and look at cars and the various options they have. There are as many ways to build an Native App as there are to build cars,³ and in both cases the engineers decide how they get put together. They build them the way that the market wants to see them — sports cars that are really fast, wagons that are more practical, trucks that are heavy duty — and an App can be built to be fast, simple to use, or robust, and sometimes all three.

How an App is built is a conversation that will continue to change and evolve as mobile devices become more powerful, screens get finer detail, and development methodologies evolve to match. Define what your user’s need to accomplish, and the rest can follow.

So you want some examples…

No doubt you want to “see” what we are talking about here. “What makes up a popular App that I might use everyday?” Here are two well-known brand Apps and the various technologies that make them work.

Facebook

I guess we can’t talk about anything these days without talking about Facebook.⁴ Their mobile App is a mixture of many things, and it is a good example of what we now call a Wrapper App.

A Wrapper App has some native code and functionality (Objective C for iOS, Java for Android) around a few web views of typical HTML content. Native code handles communicating with the phone’s hardware features and stores much of the UI. Other views are built with HTML, which is better at showing streams of content. Native code is better at handling some interface actions and can cut down on what would otherwise be HTTP server requests.

The “Wrapper” is a good way to cut deployment and development time and concentrate the App on doing a few things very well through a mix of technologies. Using this hybrid approach can have pitfalls⁵ if not done well, but in general, it is the preferred way to develop most non-game Apps.

LinkedIn

The business social network launched a redesigned App recently to much fanfare and many positive reviews. They also use a Wrapper approach with a layer of native code wrapped around different types of web views.

LinkedIn’s App is said to be only 5% native with the rest being HTML5 web views, but people are surprised how Native it feels (especially when compared to the reviews that the Facebook App gets). One of the tools in their belt is the new HTML5 local storage options for caching content locally, which allows them to store views more readily and load views before they are requested.⁶

The key components of the App is its Native feel – it takes full advantage of how users have come to expect the touchscreen interface to work. Swipe events are built into the workflow seamlessly, making the App a joy to use. As a case study for user experience, LinkedIn is a good one – they broke their user base into the At-work user, the On-the-couch user (tablet), and the 2-minute user (smart phone) and they designed specific experiences for all three.

Angry Birds

Games fall outside the scope of our discussion today (it is a highly specialized industry) but they are good examples of full Native applications.

For those of you living in a cave,⁷ Angry Birds is a game where you flick angry-looking bird characters at various items to knock them down. There’s more to it, but that’s the basic premise. It relies heavily on game physics and native swipe gestures. I’m not positive, but I think it is safe to say that it was built completely in Native code.

The benefits of Native code are speed (not in development, but in the way the App works) and the access to smartphone hardware like the accelerometer or camera.⁸ The pitfalls are the development time, cost and specificity: the iOS version of the App will not work on Android, and vice versa. There are ways for developers to share a code base to make this easier, but know that the costs associated with developing for both platforms is almost double.

Conclusions

The mobile web is confusing, but that’s ok. There are people like us whose job it is to make things more simple, and to worry about the details when they need to be worried about.

For most projects, a fluid web design that scales to the viewer’s screen size is enough. In fact, we only develop responsive sites, which should be ready for the devices that haven’t even been conceived yet.

For those of you considering a tablet or mobile App to complement your website, there are some decisions to be made early on to help inform what kind of approach you need. Above all, the user experience should be suited to the device being used and the App needs to concentrate your core functionality to make it a joy to use – snappy downloads and interactions, swipe actions and form elements that feel “Native”, etc…⁹ Without that, you’ll end up with one more App in a sea of mediocre Apps, and no one wants that.

Originally published on ProjectEvolution.com