If you are building your first product or customer tool, an app in the App Store can look like the obvious goal. It often isn't the best place to start. A web app that works well on phones is usually quicker to build, cheaper to change and easier for new customers to reach. This guide compares mobile app vs web app in plain words, adds progressive web apps (PWAs) and cross-platform apps, and shows when each one is the right choice.
The four options in plain words
- Native mobile app. An app built twice, once for iPhone and once for Android, and installed from the App Store or Google Play. It gets the fullest access to the phone, but you build and look after two apps.
- Web app. An application that runs in the browser, such as a booking system, a customer portal or a dashboard. People open it from a link or a search result, on a phone or a laptop, with nothing to install.
- Progressive web app (PWA). A web app with app-like extras: people can add it to their home screen, it can work offline and it can send push notifications. It is still built once and runs in any modern browser.
- Cross-platform app. A real app for both stores, written mostly once with a framework such as React Native or Flutter. One codebase covers iPhone and Android, but you still test, publish and update two store versions.
Reach and discovery: app stores vs search and links
- A web app is one tap away. People reach it from a Google result, an email, a text or a QR code on your counter. It also works on a laptop, which matters for business customers and your own staff.
- An app asks for more commitment. A customer has to find you in the store, download the app and often create an account before they get anything done. That is a lot to ask of someone booking one appointment.
- A store listing is not marketing. It can add trust, but it won't bring you customers on its own.
Cost and time to build and update
Scope sets the budget. These factors change it from one option to the next:
- One codebase or two. A web app or PWA is built once and runs everywhere. Native means two apps in two programming languages. Cross-platform sits in between: mostly one codebase, with some work and testing for each platform.
- The back end is the same either way. Logins, the database, payments and admin screens are needed whatever the front end. Build them well once and a mobile app can reuse them later.
- Updates. A web app update goes live for everyone as soon as you publish it. An app update goes to Apple and Google for review first. Apple says it typically reviews 90% of submissions within 48 hours; Google says some reviews take up to seven days, or longer in exceptional cases. Until every user updates, you also have to support older versions.
- Store accounts. To publish, you need an Apple Developer Program membership ($99 a year) and a Google Play developer account (a one-off $25 fee). Set both up in your business's name, not your developer's.
Offline use and device features
- Offline. A plain web app needs a connection. A PWA can save pages and data on the device, so key screens still open without a signal. Native and cross-platform apps give you the most control over offline work, which helps staff on the road or on site.
- Camera and location. Web apps can use both, with the user's permission. Photographing a document or finding the nearest branch doesn't need a native app.
- Push notifications. On Android, a web app can send them once the user allows it. On iPhone, web push has worked since iOS 16.4 in 2023, but only after the user adds the web app to their home screen (in Safari: Share, then Add to Home Screen) and allows notifications. If notifications are central to your product, that extra step matters.
- Deeper features. For Bluetooth equipment, background location or health data, a native or cross-platform app is the safer choice.
Payments and app store fees
The rules are changing, so we checked these points in November 2026:
- Web apps pay no store fee. You take payments through your own provider, such as Stripe or PayPal, and pay only its normal charges.
- Physical goods and real-world services pay no store fee either. If your app sells products, meals, tickets or bookings used outside the app, Apple and Google both require you to take payment outside their in-app purchase systems.
- Digital goods sold in an app usually pay a fee. Subscriptions, premium features and digital content bought in an iPhone app generally go through Apple's in-app purchase. Apple takes 15% if you earned up to $1 million last year (or are new to the App Store) and enrol in its Small Business Program. Otherwise the standard rate is 30%.
- Google Play changed its fees this year. Since 30 June 2026 in the US and the UK, Google charges 10% on your first $1 million of earnings each year, plus a 5% billing fee when the payment goes through Google Play's billing. Its service fee page has the full table.
- Paying on the web from inside an app. Google's new US and UK terms let apps link users to pay on the web, for a lower fee. Apple allows this in US apps, but what it may charge on those sales is still before the courts. In the UK, the competition regulator (the CMA) has consulted on rules that would let iPhone apps do the same.
Maintenance after launch
Every option needs security updates, bug fixes and small improvements. Apps add a yearly job: Apple and Google release new versions of iOS and Android every year, and apps need testing and updating to keep working and meet store rules. With two native apps, you do it twice. A web app has one codebase to look after.
When to start with a web app
- Customers find you through search, links or ads, or use the tool on a laptop as often as on a phone.
- People use it now and then to book, get a quote, track an order or check an account. Customer portals and internal tools, such as a custom CRM, work well as web apps for the same reason.
- You want to launch soon and change things often while you learn what customers use.
- You sell digital subscriptions and would rather take payment on your own site than pay store fees.
- Your budget covers one product done well, not two done in a hurry.
When to go mobile first
- Customers will use it often, daily or several times a week, and an icon on their home screen keeps you in front of them.
- Notifications are the product, such as order updates, reminders or alerts, and you can't count on iPhone users adding a web app to their home screen.
- You need deeper phone features, such as Bluetooth equipment, background location or full offline work for staff in the field.
- Customers expect an app, because they search the App Store or Google Play for you, or a competitor's app set that expectation.
If you go mobile, cross-platform is usually the sensible first choice: one codebase, one team, both stores. Go native when the app leans hard on the newest phone features or needs top performance, such as heavy graphics work.
A sensible path: web first, mobile when usage proves it
- Design for phones first. Build a custom web app that works well on a small screen from day one. Clear UI/UX design and a prototype tested with real customers will tell you more than a long feature list.
- Make it a PWA. Add the home screen icon, offline basics and push notifications. On Android, you can even publish a PWA on Google Play with a tool such as Bubblewrap. Apple expects more than a repackaged website, so don't plan on that for the App Store.
- Watch how people use it. Check how many users are on phones, how often they come back, whether they turn on notifications and whether they ask for an app.
- Build the app when the numbers say so. Reuse the same back end, logins and data, so the app is a new front end, not a new product. Keep the web app: it is still how new customers find you.
Talk to Devtings
Devtings builds custom web apps and mobile apps for small and mid-size businesses in the US and the UK, so we can recommend the option that fits rather than the one we prefer to sell. See our mobile app development services or get in touch.