Most businesses that ask us for a mobile app need a good web app first. Not because apps are bad, but because the thing they actually want — customers who come back, a tool staff can open from their home screen, notifications that bring people back in — the web can now do on both major platforms, at roughly the cost of one codebase instead of three.
There is a real minority for whom native is the right answer from day one. This post is about telling the two apart, with the current platform rules rather than the ones from five years ago, because the rules have changed more than most people realise.
What changed, and why the old advice is stale
The standard objection to web apps was always the iPhone: no push notifications, no proper home-screen install, everything opened in a Safari tab. Two changes have largely removed that objection.
In iOS 16.4, Apple added Web Push to Home Screen web apps. Notifications appear on the Lock Screen and in Notification Center like any other app's, and the user manages them per app in Settings. The one condition worth knowing: a web app can only ask for permission in response to a direct tap, such as a subscribe button — no prompting on page load. That is a sensible rule, and it is the same discipline a good native app should follow anyway.
Then with iOS 26, WebKit made every website added to the Home Screen open as a web app by default, whether or not it has a web app manifest. Previously only sites that were explicitly configured opened full-screen; everything else behaved like a bookmark. The manifest still matters — it is how you control the icon, the name and the launch behaviour — but the baseline experience on an iPhone is now an app window, not a browser tab.
On Android, installable web apps have worked properly for years, and you can go further: Chrome's Trusted Web Activity wraps your web app in an Android package that, per Google's own quick-start guide, can be uploaded to the Play Store for release. Same code, a Play listing on top.
Why this matters more in India than elsewhere
StatCounter's figures for September 2026 put Android at roughly 94% of mobile use in India and iOS at about 6%. Two practical consequences follow.
First, "we need an iPhone app" is rarely the bottleneck it feels like in a boardroom where everyone carries one. Your customers are overwhelmingly on Android, often on mid-range phones with limited storage, where asking someone to download a 60 MB app to place one order or check one status is a real barrier. A web app that loads from a link in a WhatsApp message has no such barrier.
Second, the platform where the web is strongest is the platform most of your users are on. The iPhone limitations that remain matter less when they affect one user in sixteen — though if that one in sixteen is your highest-value segment, which it can be for premium D2C brands, weigh it accordingly.
What a web app still cannot do
This is the part agencies selling web apps tend to skip. The gaps are real, and if your product lives in one of them, go native.
Hardware access on iPhone. Bluetooth is the clearest example. The Web Bluetooth API is, in MDN's words, not Baseline "because it does not work in some of the most widely-used browsers". In practice it is a Chromium feature, and since every browser on iOS runs on WebKit, that means no Bluetooth from the web on an iPhone. WebKit has also publicly declined to implement Web NFC on security and privacy grounds. If your product talks to a glucose meter, a label printer, a POS terminal or a fitness band, that is usually the end of the web app conversation.
Heavy background work. Continuous location tracking for a delivery fleet, long uploads that must finish while the phone is locked, audio that keeps processing in the background — native apps get far more reliable access to these than a web app does on either platform.
Deep OS integration. Home-screen widgets, rich interaction with the share sheet as a destination, deep contact or calendar access, and the polish of platform-native gestures and animation. Some of this is partially available on the web; none of it is as good.
Discovery through the store. If your growth plan genuinely depends on people finding you by searching the App Store or Play Store, a web app is invisible there — except on Android via a Trusted Web Activity, which gets you a Play listing but no iOS one.
Notice what is not on that list: logins, payments, offline forms, camera capture for photos and documents, notifications, home-screen install, and fast repeat loads. Those are what most business apps actually consist of, and the web handles all of them.
What the stores actually cost and demand
People tend to price an app as the build. The stores add their own fees and their own gatekeeping, and both are worth knowing before you commit.
| Web app | Android (Play Store) | iPhone (App Store) | |
|---|---|---|---|
| Account fee | None | US$25, one-time | US$99 a year, or local currency where available |
| Commission on digital goods | None (your payment gateway's fee only) | 15% on the first US$1M a year, and 15% on auto-renewing subscriptions | 15% for small businesses under US$1M; standard rate above |
| Review before release | None — deploy when ready | Required; new personal accounts must first run a closed test with 12 testers for 14 days | Required for every release |
| Updates reach users | Immediately | After review, then when users update | After review, then when users update |
| Codebases to maintain | One | One per platform, or one cross-platform codebase | One per platform, or one cross-platform codebase |
Two caveats on that table. The commissions apply to digital goods and services sold in the app — subscriptions, in-app credits, unlocked content. Physical goods and real-world services, like an order from a D2C store or a booked appointment, generally go through your own payment gateway in either case. And Google's own support page notes these rates apply until its announced updated fees roll out globally, so check the live page before you model a subscription business on them.
The row people underestimate is the one about updates. On the web, a pricing error or a broken checkout is fixed in minutes and every user has the fix on their next load. In a store app, the fix waits for review and then for each user to update — and some never do, which means supporting old versions of your app, talking to your API, for years.
Apple adds one more constraint worth reading before anyone suggests "just wrap the website". Guideline 4.2 of the App Store Review Guidelines says an app should "elevate it beyond a repackaged website". A thin wrapper around your existing site is a fairly reliable way to get rejected. If you are going to the App Store, build something that earns its place there.
So when is native genuinely the right call?
In our experience, it comes down to four signals. One strong one is usually enough.
Your product depends on hardware or background access. Bluetooth devices, NFC, continuous location, background audio. This is the clearest case, and it is not a matter of preference — the web simply cannot do it reliably on iPhone.
People use it many times a day, for long sessions. A messaging tool, a field-service app that a technician lives in all shift, a trading or banking front end. When usage is that dense, the extra polish, offline robustness and platform integration of native earn back their cost.
Your audience skews to iPhone and expects native polish. Rare in India, but real for some premium segments. Check your own analytics rather than assuming.
The store itself is a channel you need. Some categories genuinely acquire users through store search, and some enterprise customers want an app they can push through device management.
If none of these apply, the honest answer is usually a web app — fast, installable, with notifications where they help — and revisiting native once you have usage data that shows a specific gap.
What not to do
Do not build three things at once. A website, an Android app and an iPhone app, launched together, is three products to keep consistent, three release processes, and roughly three times the bugs. Start with one thing that works well, then expand where the data points.
Do not build an app because a competitor has one. Look at their store reviews and download counts first. Many business apps are installed once, used twice and quietly deleted — and a deleted app sends no notifications.
Do not wrap your website and call it an app. On iPhone it risks rejection under guideline 4.2. On Android it passes review but gives users nothing the website did not, at the cost of a release process you now have to maintain.
Do not skip the web performance work and blame the platform. A slow, heavy web app is slow because of how it was built, not because it is on the web. If your current site takes eight seconds to load on a mid-range Android phone on mobile data, fix that before concluding you need native. Most of the "apps feel faster" argument disappears once the web build is done properly.
Do not forget the middle path. Cross-platform frameworks such as React Native and Flutter give you real native apps from one shared codebase. They do not remove the store fees or the review process, but they remove most of the "two codebases" cost. If the signals above say native, this is often how we would get there.
A sensible order of operations
For most businesses we work with, the order that wastes the least money looks like this:
- Build the web app properly. Fast on mid-range Android, installable, with a manifest, offline handling for the screens that need it, and notifications only where a user has asked for them.
- Measure how it is actually used. How many people install it to the home screen, how often they return, where they drop off, and what they ask for that the web cannot give them.
- Add a Play Store listing via a Trusted Web Activity if store presence on Android helps — same code, small extra effort.
- Go native, or cross-platform, for the specific gap the data shows. Bluetooth, background location, a daily-use workflow that needs more polish. At that point you are building something you know people want, not guessing.
This is the same reasoning we use for web development projects generally: build the smallest thing that genuinely solves the problem, then spend money where the evidence says it is needed. If you want a sense of what the web build costs before anything else, our website and web app development pricing is published and kept current.
The short answer
If your product needs hardware, heavy background work, dense daily use or the stores as a channel, build native — ideally cross-platform. Otherwise, a well-built web app does what most businesses actually want from "an app", reaches the 94% of Indian phones on Android without a download, works on iPhone with notifications and home-screen install, and can be fixed in minutes rather than after a review queue.
Tell us what you are trying to build and we will tell you honestly which side of that line you are on — including when the answer is a native app.
Bharat Vasireddy
Founder & Digital Marketing Strategist8+ years of experience in performance marketing and web development. I help businesses scale through data-driven SEO, Google Ads, and high-performance websites.