Mobile or Web App – How to Choose

19th September 2011
All posts

Square payments and jack application
Square payments and jack application

Mobile apps for the iPhone and other devices are all the rage, but how do you decide between a web app or a mobile application?

Web based tools like Phonegap and Titanium make it easier to build an iphone app without having to be an Objective C programmer. [Edit: Though as @dcurtis has pointed out, are there any apps built in this space that are easy to use and beautiful?]

But how do you go about figuring out 1. if you should build an app or just a web application and 2. how to decide what features your app will have and how to build it?

Web-based or Mobile-app

It depends on data use and connections required. A web app requires less API load than an iPhone app which must be very stingy in order to work smoothly. The iPhone is picky when it comes to performance. The less done on the device the better, it gives a smooth user interaction.

What is the purpose of your application?

It’s important to have a clear answer on this before embarking on this journey. How easy will it be to update this app’s features to stay current? Web apps are easier to update (no reliance on the Apple App Store) but the App Store monetises well. Many users expect web apps to be free on their mobile devices.

Is the application design and concept addictive? Does it have 2-5 of the 7 deadly sins? It can do well if it appeals to 2 or more of our deadly sins like greed and coveting thy neighbor’s iphone. Too many sins, though, and the app loses favour among users.

Choose a platform wisely

Blackberry is huge in the enterprise space. Nokia serves the largest group of users worldwide, Apple iPhone has the most progressive user base that are heavy data consumers. Whichever path you choose becomes clear when run through these three scenarios. Now, a web app can be read by all these devices which is a definite plus, but a web app also depends entirely on connectivity and again is harder to monetise compared to the App Store.

Determine the features of your application

Once you decide the platform you then need to spec up features in the form of wireframes so you can get quotes. Some devs are adept at crafting a quote from thin air but 90% of them need to see something and need to see user flow in order to “Get” what you’re talking about. Wireframes can make the difference between a $50,000 quote and a $5,000 quote for the same application.

These wireframes should cover basic screens and walk through at least 6 screens of the primary function of the iphone app. If you can’t come up with these try to mockup some screens by pulling images from the web. Remember, the more clear you can be about user flow the better.

Read more here for how to develop wireframes for your mobile app.

After this wireframe step you should be well placed to get a more accurate quote on the development of your application. Be sure when you talk to a developer to make clear who’s doing the design work. iPhone, for example, has many prescribed UI elements that takes a lot of design work out of the equation, but still there’s lots of room for a vital brand experience so take advantage of this. The more design work you can handle up front the better your quote will be. See the iPhone UI Guidelines for design specs.

Determine your app’s data usage

Ask about data management limitations with your app. You can use either JSON or XML data transfer, each has its benefits and drawbacks and you need to ask your potential devs about this before getting an estimate. Read more on Stack Overflow and search the web for “json or xml” for more articles.

Minimise battery and memory drain

Managing memory and battery life on the device is critical. If your app drains the battery, no one will use it. If your app is slow, no one will use it. Find out which processes your app requires that can be run in the background so processing can be more seamless to the user.

The simplest way to think about this is to remember how many apps use a “splash screen” when they are opened while data loads.

What features can you borrow from other apps to make yours better?

Consider the way other apps do simple things that weren’t originally part of the iPhone spec like Twitter’s pull-down-to-refresh action. This is something that users start doing in other apps that is really useful and saves having to create a button for this action.

Do you have a service plan for your app?

What is your plan to service the app going forward? Have you considered how you’ll support upgrades, feature requests and bug requests? You need to factor in a support system to go with your app or no one will want to use it. Remember too that once an iPhone app is posted to the App Store you are not notified so make sure you post a note there to have your users go to the support url of your choice instead. GetSatisfaction and UserVoice are two great choices.

So now what?

So, you don’t need to know a lot about development to know how to go about gathering requirements for your iPhone app, you just need to be clear about them and to know to ask the above questions so you can avoid the common pitfalls that can make a great app merely good or even worse, unusable.

Once you do the steps above you should be able to decide if you should proceed. Is the app too expensive? Strip back the features till it’s a lean and mean fighting machine. Is the app better suited for web? Then get a web developer and designer to do the work instead.

And remember, this is the best stage to cut your losses; don’t wait till you’re nearly burned through a $20,000 budget before you realise you probably should have just left well enough alone.

Tags:

Nathaniel Flick

I'm a Front End Web Developer passionate about usability. My primary specialties are HTML5, CSS3, SCSS, LESS, and jQuery and I am very familiar with Foundation and Bootstrap frameworks. I've worked on top of and with Rails, Python, and ASP.net/Umbraco back end frameworks.