PWA vs Native App in India 2026: Do You Need the App Store?

Most Indian SMBs that ask for a mobile app should build a fast mobile website first. That answer costs an agency work, so take it as sincere.

The rule in one line: buy an app when repeat usage is already proven, when push is your retention mechanism, or when you need hardware access, background work or store billing. Otherwise ship mobile web, make it quick, and spend the saved budget on getting people to it.

A progressive web app is not a cheap imitation of a native app. It is your website with an install option, offline caching and, on Android, working push. A native app is not a better website either. It is a distribution and retention product with its own build cost, review queues and uninstall rate.

What a PWA actually is in 2026

Three pieces turn a website into a PWA: a manifest, a service worker and HTTPS. The manifest gives it an icon, a name and a full screen launch mode. The service worker caches routes and assets so it opens on a bad connection and syncs later. That is the whole trick.

On Android, Chrome offers an install prompt, the icon lands on the home screen, and web push works. On iOS, the user must open the Share sheet and tap Add to Home Screen, and push only works after that step. The capability exists. The funnel to reach it is poor.

One option people miss: a PWA can be wrapped in a Trusted Web Activity and listed on the Play Store. You get the Play presence, the search result and the install button while shipping web code. There is no App Store equivalent, where a thin wrapper around a website is a familiar rejection reason.

The cost gap is bigger than the quote suggests

A PWA is mostly work you were already paying for. If you are building a responsive site properly, the extra effort is icons, a manifest, a caching strategy and testing the offline states. One to two weeks on top of a site build, not a second project.

A cross-platform app is a second project. Our own published rates put a basic Flutter or React Native build at ₹1.5L to ₹3.5L over four to six weeks, with e-commerce and SaaS apps running ₹3.5L to ₹12L over eight to eighteen weeks. Our breakdown of mobile app development cost in India covers where that money goes.

Year two surprises people. Apple charges about ₹8,500 a year and Google charges about ₹2,000 once, which is trivial. The real cost is upkeep: Google raises the required target API level yearly, Apple deprecates APIs, SDKs break, and every fix waits in a review queue before a user sees it. A web fix ships in minutes. Budget an app as a running cost, not a one-time build.

Install friction is the line item nobody prices

Compare the funnels honestly. Web: click the ad or search result, the page loads, the user acts. App: click the ad, land on a store page, decide to spend storage and a download, wait, open, sign up, then act. Every step drops people, and paid installs are bought in an auction where finance and gaming set the floor price.

Then the second bill arrives. Check your own phone: most of what is installed on it has been opened once. You paid for the install and you still have to earn the second session. On the web you pay for the visit, and the visit is the session.

What a PWA genuinely cannot do well

• iOS push in practice. Web push works on iPhone only for a site added to the home screen, and walking a normal consumer through the Share sheet loses most of them.
• Continuous background work. Live location for delivery riders or field staff, geofencing, alarms. Chrome on Android will retry a queued sync for an installed PWA, but nothing on the web tracks a rider between screens, and Safari supports none of it. That rules out logistics tracking and attendance apps.
• Deep hardware. Bluetooth thermal printers at a billing counter, NFC on iOS, fast continuous barcode scanning, precise camera control. Some of it works in Android Chrome. None of it works consistently across both platforms.
• Durable offline storage on iPhone. Safari wipes script-written storage for a site left untouched in the browser for about a week. Add to Home Screen exempts a web app from that clock, which means offline durability on iOS depends on the install step most iPhone users never take.
• Store presence. No Play or App Store search result, no ratings block, no install button in the place many Indian users go to check whether a brand is real. In lending, insurance and health, that absence gets noticed.
• The small stuff, on iPhone. Widgets and calendar access anywhere, and on iOS the rest of the list too. OTP autoread, share sheet targets and contact picking all work in Chrome on Android through WebOTP, Web Share Target and the Contact Picker. None of them work in Safari. Minor individually, together most of the reason an app feels native to an iPhone user.

What native actually buys you

Retention hooks first. Reliable push on both platforms, badges, widgets, and an icon on the home screen working as a free daily reminder. For a business with real repeat usage, that icon is the cheapest marketing it owns.

Distribution and payment second. Store search, deep links from campaigns, ratings as social proof, and store billing where platform rules require digital goods to be sold through the store. Physical goods and services in India still take UPI and cards in-app, which is why commerce apps keep their margin.

Performance third, and narrower than assumed. The gap is real for heavy interaction: camera-first flows, live maps with continuous tracking, video editing, games, long offline data entry in the field. A catalogue and a checkout are not heavy interaction. A fast mobile site beats a mediocre app there every time.

You rarely need two codebases for any of this. Flutter and React Native cover most of it at one build cost, and our comparison of Flutter and React Native for Indian startups covers the trade-offs. Most work belongs in cross-platform development, and full native is for the hardware and graphics cases that demand it.

Indian device and data reality cuts both ways

The data argument has flipped. Mobile data in India is among the cheapest in the world, so a 40 MB download is not the barrier it was a decade ago. Do not sell a PWA on data savings alone.

Storage is the real constraint. A large part of the Android base here is still on 64 GB and 128 GB phones that fill with WhatsApp media and photos. When the phone asks for space, the app opened once a month is the one that goes. That is a frequency problem, not a design problem, and the reinstall almost never happens.

Connectivity argues for caching on both sides. In a metro basement, on a train, or in a tier-3 town, a cached web shell often behaves better than a native app that assumes a network call on every screen. Offline-first is an architecture choice, not a platform choice.

One more local reality. iOS is a small share of Indian handsets and a large share of high-spend customers. If your revenue concentrates in premium D2C, travel or SaaS, iOS matters more than its unit share, and iOS is where PWA capability is weakest. In practice that weighs more in the decision than any benchmark.

The decision rule

1. Mobile web only. Purchases or bookings happen monthly or less often, you acquire from search, ads or WhatsApp, and you need no hardware or background work. This covers most local services, clinics, restaurants taking direct orders and catalogue-led manufacturers.
2. Add PWA behaviour. Users return weekly, offline reading or resuming a form matters, and Android is the bulk of your base. Manifest, service worker, Android push. Cheap, additive, reversible.
3. Build cross-platform. Repeat usage is already proven on the web, or push is your retention mechanism, or you need background location, Bluetooth hardware, store billing, or a Play listing because your category expects one. Field workforce apps land here by default.
4. Build fully native. Heavy graphics, AR, custom camera pipelines, or a team large enough to run two platform codebases well. Small set, and it feels obviously true when you are in it.

The gate between step two and step three is measurable before you spend anything. Count how many of last month's mobile users came back this month without you paying to reach them again. Above about 20 percent, an app multiplies a habit you already have. Below about 10 percent, an app only adds a download step in front of the same silence. In between, add the PWA behaviour and measure again next quarter.

The mistake people make

The common failure is buying an app to create retention rather than to multiply it. An app is not an acquisition channel. It amplifies a habit that already exists. Teams that skip the proof step end up buying installs to stop a dashboard looking empty.

The second failure follows. Budget goes into the app, the mobile site is left slow and half maintained, and most traffic still arrives there from Google and from ads.

The third is the credibility app. A listing with a few hundred downloads, a 2.9 rating and a last update from eighteen months ago reads worse than no app at all. If store presence is the only goal, a Trusted Web Activity costs a fraction and stays current.

The middle path that usually wins

1. Ship a genuinely fast mobile site: real speed, an enquiry or checkout flow that works with one thumb, and search visibility. This is web application development work, and it compounds.
2. Layer PWA behaviour once the site is stable. Manifest, offline shell, Android push if you have something worth pushing.
3. Instrument return rate and watch it for two or three months.
4. If the numbers hold, start app development on the API, auth and design system you already have. That reuse cuts a large slice off the app budget.

The sequence protects you when the answer is no. You end up with a fast site either way. The reverse order leaves an app nobody opens and a website you stopped maintaining.