Talk to us
Talk to us

Decision guide

Web app, Android app or iPhone app: which should you build first?

Start with the person using it and the place they use it in, not with the technology. What each kind of app is good at, and the costs that people forget.

For anyone planning an app8 min read

Read the guide Talk to us about your app This guide as Markdown

Six ways to put software on a screen

Mobile app development in Kenya starts with the same choice as anywhere. "An app" can mean any of these, and they differ in what they cost to build, what they can do on a phone and how a customer gets them.

Six ways to put software on a screen
Way What it is Works well when Watch out for
Responsive web app Software that runs in the browser on a computer or a phone. Nothing to install. The users are staff at a desk, or customers who will use it once or rarely. Less access to the phone's features, and no place in the app stores.
Installable web app A web app that can be added to the home screen, and can work partly offline. Also called a progressive web app. You want an icon on the phone without building a separate app. What it can do differs between phones, and some features are not there.
Android app A native app built for Android phones and published in its store. Your users mostly have Android phones, and the app needs the camera, the location or notifications. It leaves out people with iPhones.
iPhone app An app built for iPhones and published in Apple's store. Your users mostly have iPhones. It leaves out people with Android phones, and has its own store rules.
One app for both phones (cross-platform) An app built with tools that share most of the code between Android and iPhone. You need to reach both and the app is not extremely demanding. Still two stores, two sets of tests, and some features done twice.
USSD or SMS service A menu or messages that work on any phone, with no data plan. Your customers may have no smartphone or no data. Limited screens, and it costs the customer or the business per session.

Decide by who uses it, where and on what

Write down the answers about your business before you talk to a developer.

  • Who uses it: staff at a desk, staff in the field, customers, or all of them?
  • On what: which phones, computers and browsers do they really have?
  • Where: at a desk, in a shop, on a road with poor signal?
  • What it needs from the phone: the camera, the location, notifications, the fingerprint, the contacts.
  • How often: every day, or once a year at the moment of buying?
  • How it is found: do people look in a store, follow a link, or are told by you?
  • What it must connect to: payments, your accounts, your other systems.

Which phones? Look at your own numbers

Do not assume. A market may be led by one kind of phone, and the numbers differ from one group of customers to another.

  • Ask a sample of your customers and staff which phone they use.
  • Look at your website's analytics: it records the device of each visitor.
  • Look at the phones your staff already have, or will be given.
  • Ask whether some customers have no smartphone at all, and whether USSD or SMS reaches them better.

Start where most of your users are

If one platform clearly leads among your users, build for it first. A second platform can follow once the first has proved the idea.

What the app stores ask of you

A mobile app is published through a store, and the stores set the rules.

  • Accounts: you need a developer account for each store, in your company's name, with someone who can sign in to it.
  • Review: an app is checked before it is published, and so is each update. Plan for the time it takes.
  • Rules: each store has rules on what an app may do, how it takes payment for digital goods and what it says about personal data. Read them early.
  • Updates: people do not all update at once, so the back end has to keep older versions of the app working.

Poor signal and offline use

If the people using the app work where the signal is weak, this decides more than the platform does.

  • List the things that must work with no signal, such as recording a visit, taking an order or looking up a record.
  • Decide what is kept on the phone, how it is sent when the signal returns and what happens when two people changed the same thing.
  • Ask how much of the app a user can reach before they have to sign in with a connection.
  • Test it on a real phone with the signal switched off, not only on a fast connection in the office.

Taking M-Pesa in an app

An STK push works from a web app and from a mobile app alike: the phone shows the prompt and your server hears the result. The guide to M-Pesa integration goes through the ways to collect and what goes wrong with each.

A sensible path

An app does not need to begin everywhere.

  1. Start with the job

    What must a person be able to do in the first release? Write it in a sentence.

  2. Build the first release where it is cheapest to learn

    For staff tools, and for ideas you are testing, that is often a web app.

  3. Add a mobile app when a feature needs it

    The camera, the location, notifications or offline use are the usual reasons.

  4. Choose one app for both phones, or two

    One app for both reaches people sooner. Two separate apps may be right where speed or the phone's own features matter most.

  5. Plan the updates

    Phones and stores change every year, and the app has to change with them.

Costs people forget

These are rarely in the first quote.

  • Developer accounts for the stores, and the time to keep them in order.
  • Testing on real phones and several versions of each system.
  • Updates every year as phones and stores change.
  • The server behind the app, and its hosting, monitoring and backups.
  • SMS, notification and payment charges that grow with use.
  • Support for the people who use it.

Two platforms are not twice the price, but they are not one

Sharing code saves work, but each platform still has to be tested, published and updated on its own. Ask for the cost of one and of both, side by side.

Keep reading

Common questions

Should I build a web app or a mobile app first?

Build first where you can learn most cheaply. For staff tools and ideas you are testing, a web app is often enough. Build a mobile app when the app needs the camera, the location, notifications or offline use, or when your customers look for it in a store.

Should I build an Android app or an iPhone app first?

Build for the phones your users have. Ask a sample of them and look at your own analytics rather than assuming. If one platform clearly leads among your users, start there.

What is a progressive web app?

A progressive web app is a web app that can be added to the phone's home screen and can work partly offline. Unlike a native app, which is built for one kind of phone and published in a store, it is built once for the browser, but what it can do differs between phones.

Is one app for both Android and iPhone cheaper?

It can save work because most of the code is shared, but each platform still has to be tested, published and updated. Ask for the price of one and of both side by side.

Do I need a mobile app or is a mobile website enough?

A mobile website is enough when people use the service once or rarely and do not need the phone's features. An app helps when they use it often, need offline use or notifications, or need the camera or the location.

How do app store accounts work?

Each store needs a developer account in your company's name, with a person who can sign in. Apps and updates are reviewed before they are published, so plan for the time that takes.

Can an app work without internet?

Yes, if it is built to. Decide what must work offline, what is kept on the phone, how it is sent when the signal returns and what happens when two people changed the same thing.

Planning an app?

Tell us who will use it, where and on what. We will say what we would build first and why.

Talk to us about your app