Menu

Archive | Android

A common discussion that comes up in client meetings is on the topic of “Mobile Web vs App”.

The primary driving force in the discussion is the fear of having to develop the app for multiple platforms, instead of having to develop it just once and have it run in any smartphone’s browser. The question can be put in many ways, but essentially there are two main perspectives:

“Should we build a mobile version of our web site or build an app?”

“Should we build the app as a mobile web app, so the user can use it though the phone’s browser, or should we build native apps?”

Here is my advice.

Web Site vs App

If you want your functionality to be used, if you want to provide a rich user experience and the best user interface, then you should build an app. The app phone user prefers an app over a web site. App download and app usage data is very clear. Users rather transact and consume using apps.

However, if your site has a large volume of information that is often referenced, such as articles and posts, or other types of information such as time tables and reference tables, then you will want your web site to render nicely when users visit your site using their phone’s browser.

A typical scenario is when the user reads an email, a tweet or a Facebook post, using the phone, and there is a link to your web site. If the user follows the link, then you will want the page to render nicely. It’s a disappointment if the page renders as if the screen is a big desktop screen, forcing the user to scroll and zoom all over the page to make anything out of it.

This means that in Web Site vs App, you are likely to want to do both:

Position the app for the scenario when the user specifically chooses to interact and transact with your business.

Position the web site for the scenario when the user is taken to your site from other places, or just want to read something that is out of the app’s functional scope. In fact, the app could itself redirect the user to the site in such scenarios.

Also, for the non smartphone users out there. Even though we haven’t seen any relevant amount of web traffic data driven by these the past ten years, it is still not a bad thing to cover this base, too.

Mobile Web App vs Native App

Before addressing this question, I need to clarify one point: the user doesn’t care.

It is entirely possible to use web technologies to design app functionality, package it as an app, distribute the app through app stores/marketplaces, and the user won’t be able to tell if it is native app or web app. Note, however, that the context is the app format (design and distribution) when we discuss. As soon as the discussion implies that it is expected by the user to first start the browser, browse to a specific URL, and then use the web app, then this is not user friendly and the user does care.

So, when comparing two apps, one is native and one is web, it is possible in many types of apps to make it really difficult to tell which is which. This is key, however: don’t sacrifice user interface and user experience on the web altar. An iPhone app should look like an iPhone app, and an Android app should look like Android app. Make sure your web app looks like an app should look on each platform. If you can achieve this, then choose whatever path that suits you best (based on overall strategy, developer productivity etc).

If you want to optimize user experience and user interface, then you should build a native app. If you want to leverage the phone’s capabilities as much as possible, then you should build a native app. If your developers haven’t built an app yet, then you should build a native app. Don’t take any shortcuts if you don’t what you are short cutting. Short cuts are allowed only for those who do.

This is where cross platform vs native comes in. I don’t believe in cross platform frameworks. We’ve struggled with them for more than 20 years and they have three things in common: a least common denominator punishment, over promise and under deliver on “write once, run everywhere”, and they rarely address the user interface differences between platforms. These three issues are the primary reasons why cross platform makers are quick to state: “content is king and information is what matters”, knowing that user experience and user interface is their Achilles heel.

The most interesting development on the cross platform horizon is HTML5. With the industry wide support (Microsoft, Apple, Google, etc), we are bound for a future where some types of apps will be developed in HTML5 and related frameworks, and being able to run on more than one platform. This is, however, not an option that is mature enough yet. We are still waiting for tools and technologies enabling stable development and production.

In short: learn native, know native, build native first. If you choose to go web, package the app as an app, use HTML5 based options and make sure you never sacrifice user experience and user interface.

Summary

Build native apps

Make your web site look good in the smartphone’s browsers

Keep you eye on the developments in HTML5 and if you choose to go web, don’t leave the app characteristics

I’ve been on a tour the past three months, meeting clients interested in app projects. There are a lot of questions asked. Currently, these are the top 10 most commonly asked questions.

1. What platforms should we build for?

Only iOS (iPhone and iPad) and Android have a user base that downloads, buys, and uses apps to any relevant degree.
Other platforms are also app oriented, but their respective users are either too few or have a too weak app download pattern to be relevant. This might change in the future, but today, this is a good rule of thumb.

2. Do we need to develop different apps for different platforms, or are there any cross platform frameworks?

Yes, you need to develop different native apps for each platform. There are cross platform frameworks but none of them are strong enough. Some of the more interesting options include Sencha, SproutCore, and Titanium. Long term, I believe HTML5 will have the strongest industry support and provide a solid framework even for app development. This won’t happen in the next 18 months, though. Remember one thing: an iPhone app should look and feel like an iPhone app, and Android app like an Android app, and so on. If you go cross platform, make sure you first understand native and that you never sacrifice user interface and user experience.

3. How much more time do we add if we want to develop the app for more than one platform?

It depends on what type of app you are developing. But a general approach is to add 30-50% to the project.

4. Is it possible to distribute apps internally, ie not through any of the public app stores?

Yes, it is. Each platform has different solutions to this, but it is possible and it is becoming more and more common.

5. Can we reuse system integration efforts already done in our web project?

Yes, the app project should make use of as many current system integration efforts as possible. It’s not uncommon for the app project to add one layer to the integration architecture for JSON conversions.

It’s not about the language, but about the SDK you target (Cocoa Touch or Android SDK). Learning curve is about the same.

7. Can you sell goods through you app, how is payment done?

Yes, you can. For iPhone: Apple won’t allow you to ask the user for a credit card number. If you choose to use the user’s Apple account, Apple keeps 30% of the transaction. Most online retailers choose to have the user create a user account first, then have the user login through the app. The account can be used for invoicing/credit cards. These restrictions don’t apply in Android apps.

8. Why not just a web site adapted for mobile web browsers?

An app-phone user prefers to use functionality and consume content through an app, rather than through the web browser. Data from IDG supports this and shows that an app drives up to eight times more traffic than a mobile web site.

9. How is an app project run?

Like any software development project: goal/purpose, scope, sketches and visualizations, design and development, test and deployment. We prefer to use iterative development, such as Scrum. The app project has a very distinct focus on user experience and user interface.