Once you’ve decided your business needs a mobile app, the next question arrives fast: how should it be built? There are three common answers. You can write one codebase that runs on both iPhone and Android, build a separate native app for each, or make a web app that people install from their browser. Each is right for some apps and wrong for others. What decides it is what the app has to do and who’ll be using it, far more than any liking for a particular technology.
Start with how people will use it
Before you compare tools, answer a few questions about the app itself:
- Who’s it for: your customers, your own staff, or both?
- Will they open it every day, or now and then?
- Does it need the phone’s own features (the camera, location, notifications), and how heavily?
- Do your users expect to find you in the App Store or Google Play?
- Is there a website or back end it has to work with already?
Usually, the answers point clearly to one of the approaches below.
Cross-platform with React Native
React Native lets one codebase run on iPhone and Android. You write most of the app once, in JavaScript or TypeScript, and each phone draws it with its own native interface components: on an iPhone it uses the iPhone’s own controls, and on Android, Android’s. Expo adds the tools for building the app and getting it ready for release.
Many business apps fit here: customer accounts, bookings, orders, content, forms, dashboards. Because there’s one codebase, a change is made once and reaches both platforms at the same time, rather than being built twice and kept in step. React Native also uses the same language as React websites and Node.js back ends, which helps when the app sits next to a web product you already have.
Native with Swift and Kotlin
A native app is built with each platform’s own language and tools: Swift for iPhone, Kotlin for Android. You end up with two codebases. In return, each one has direct access to everything the platform offers, as soon as Apple or Google makes it available.
Go native when the app leans heavily on the phone itself. That covers demanding graphics or animation, constant use of sensors or other hardware, heavy work in the background, and features the platform has only just introduced. If your app is mostly screens, forms and data, you probably won’t need that extra reach, and one cross-platform codebase is the simpler path.
An installable web app (PWA)
Not every app needs an app store. A progressive web app (PWA) is a web app that people install from their browser onto their home screen. It opens like an app and can keep working when the connection is poor. When you publish a change, people get it the next time they open the app, with no store review in between.
The trade-offs are real. People install it from the browser, not from a store, and on iPhone that step is easy to miss. Some phone features are limited or unavailable to web apps, particularly on iPhone. And if your users go looking for you in the App Store or Google Play, a PWA on its own won’t be there.
A PWA works well for apps that are mostly information and forms, or for a first version you want in people’s hands quickly. If what you really need is a tool your team uses in the browser at work, that’s closer to our custom web application service.
The app stores are part of the project
A store app isn’t finished when the code is. Apple and Google each have their own developer accounts, listings and review rules, and an app has to pass review before anyone can download it. The listing needs its own screenshots, description and privacy details. New versions of the app go through review too.
So plan for the stores from the start, not as the last step. We prepare the app for release and take it through both stores as part of the project, so launch day isn’t the first time anyone reads the rules.
How we help you choose
We build mobile apps all three ways, so we’ve no reason to push you towards one. You tell us what the app needs to do. We’ll ask about the people who’ll use it, your business goal and any constraints, then recommend a scope and an approach, including whether cross-platform, native or a web app fits. While we build, we share progress so you can try the app before launch. Then, for a store app, we release it on the App Store and Google Play, and we can carry on with ongoing development and maintenance afterwards.
Most apps need something behind them too: accounts, data, and the systems the app talks to. If yours can’t share their data with an app yet, our Node.js and API development service builds that part.
If you’re planning an app, have a look at our mobile app development service, or tell us what you have in mind and we’ll recommend an approach.