Torn between a web app and a native app? For most startups the answer is: start with a web application, or with a cross-platform app if your product truly lives on the phone. A fully native app, with separate code for iOS and Android, is rarely needed for a first version. In reality you aren't choosing between two options but four: a web application, a PWA, a cross-platform app or a fully native app. This article explains what each route is, what it can and can't do, what it costs and how to choose.

The short version

  • Web application: runs in any browser, can be shared with a link and is the fastest to launch. The best start when your users are mostly at a computer or use your product occasionally.
  • PWA: a web application people can add to their home screen and that can send notifications. A good intermediate step, but more limited on iPhones than on Android.
  • Cross-platform app: one codebase for iOS and Android, in the App Store and Google Play. The logical choice when your product revolves around the phone: camera, notifications or daily use.
  • Fully native: separate apps for iOS and Android. Only needed for very specific demands on the device or performance.

The four routes explained

1. Web application

A web application is software that runs in the browser, on a computer and on a phone. Think of a client portal, a booking system or a SaaS product.

  • Strong at: usable straight away via a link, no download. Updates go live for everyone at once, without app store review. Pages can be found in Google.
  • Limits: less access to the device, such as running in the background, and no presence in the App Store or Google Play.
  • Fits: products people use with a specific goal, often on a computer too, and products you want to test quickly.

2. PWA (progressive web app)

A PWA is a web application that behaves more like an app. Users can add it to their home screen, it opens without an address bar, and it can partly work offline and send push notifications.

  • Strong at: an app-like feel without an app store, one codebase for every device and the same fast updates as a website.
  • Limits: on iPhones, push notifications only work once the user has added the PWA to the home screen (since iOS 16.4), and support is more limited than on Android. Many users also don't know how to "install" a website.
  • Fits: a web application that occasionally needs to send a notification, or an intermediate step to test whether people want your product on their phone.

3. Cross-platform app

A cross-platform app is a real app in the App Store and Google Play, built from one codebase for iOS and Android, for example with React Native. That's how we build mobile apps.

  • Strong at: full access to camera, notifications, location and background processing, discoverable in the app stores, and one codebase instead of two.
  • Limits: every update goes through Apple's and Google's review, which usually takes a few days. For digital purchases inside the app, the stores charge a commission.
  • Fits: products people use daily on their phone or that need device features.

4. Fully native app

A fully native app is built separately per platform, in Swift for iOS and Kotlin for Android.

  • Strong at: maximum performance and immediate use of each platform's newest features.
  • Limits: two codebases means roughly building twice and maintaining twice.
  • Fits: heavy applications such as games, advanced video or apps that push the device to its limits. Rarely needed for a startup's first version.

Where the difference really lies

  • Device features. Camera and location work in the browser too, but background processing and reliable notifications are strongest in an app.
  • Distribution. You share a web application with a link and it's usable straight away. An app has to be downloaded first, which is an extra hurdle, but then it sits on the home screen.
  • Updates. Change a web application and it's live immediately. An app update goes past Apple and Google first.
  • Discoverability. A web application with public pages can be found in Google. An app is found in the app stores.
  • Payments. On the web you take payments through your own provider, such as iDEAL or cards. Digital purchases inside an app fall under the stores' rules and commission.

Examples from our projects

  • Haagse Taxi: web. Customers enter their route, see a fixed fare straight away and book online. Someone booking a taxi once doesn't want to download an app for it, so a web application is the right choice.
  • Spichaser: app. The app warns drivers in time about a possible pursuit. That needs reliable notifications, so we built an app in React Native, with one codebase for several platforms.
  • Roof Connect: both. The website is the home for news, trade magazines and suppliers and gets found in Google. The iOS and Android app keeps roofers up to date on the go.
  • Tapp: app. Festival visitors order drinks in an app. For bar staff we also built a POS tablet in React Native that scans the QR codes of orders.

Checklist

Choose a web application when:

  • users also or mainly use your product on a computer;
  • they use it occasionally, not daily;
  • you want to test quickly and adjust often;
  • you want to be found through Google.

Choose a cross-platform app when:

  • your product revolves around the phone and daily use;
  • you need the camera, location or background processing;
  • notifications are the core of your product;
  • your audience expects to find you in the App Store or Google Play.

Choose a PWA as an intermediate step when you have a web application some users want to use like an app, but you're not yet sure a real app is worth the investment.

Start with web, add an app later

For many startups this is the smartest order. A web application tests your idea fastest: no downloads, no store review, and you can fix it the same day users get stuck. If it turns out people use your product daily and ask for an app, you build it on the same backend. The work on your data, accounts and logic is already done.

Do choose an app from day one when the core problem can't be solved without one, as with Spichaser, or when your users are on the move without a computer at hand, like festival visitors at Tapp.

Tip: if in doubt, look at your core feature. If it works fine in a phone browser, start with web. If it falls apart without notifications or device access, you need an app.

What does each route cost, and how long does it take?

With us, a web application and a cross-platform app fall in the same price ranges: an MVP with just the core feature costs €3,000 to €5,000, a simple version with accounts and an admin panel €5,000 to €8,000, and a complete version with several roles, payments or integrations €10,000 to €15,000. Where you land depends mostly on what the first version must do. Read more in How much does it cost to build an app?.

A first version is live in 4 to 8 weeks. For an app, add a few days for Apple's and Google's review. A fully native app costs more, because you build and maintain two apps. How such a project runs is covered in How long does it take to build an app?.

Not sure which route fits?

In a free intake we look at your users and your core feature, and advise which route proves your idea works fastest. You get a fixed price and a delivery date. Read more about having a web application built or getting an app built.