Almost every founder building a customer-facing product hears the same voice in their head at some point: "We need a mobile app." Sometimes that voice is right. Most of the time it is a habit picked up from investor decks, competitor apps sitting on the home screen, and users saying "is there an app for it?" without meaning anything specific by it. A native mobile app is the most expensive path to a working product, the slowest to release changes to, and the hardest to keep alive as a team. It is also, sometimes, exactly the right call. The problem is that most founders make the pick before they have looked at the two cheaper options that would have covered what their product actually needs.
So how do you tell whether you actually need one? That is the point of this piece. You will see what a progressive web app really is in plain English, the 3 fronts your product can pick between, the 5 reasons that genuinely justify a native mobile app (not just the ones that feel like they do), the 3 things a progressive web app cannot do yet and whether you care, a simple shape that lets you serve web plus progressive web app plus mobile without ending up with 3 codebases, and the 3 signs it is smarter to stop at a progressive web app instead of building native. All of it is written for the buyer making the call, not the mobile engineer wiring it up, because the buyer is the person who signs the estimate.
Why does this decision matter more now than a few years back? Because browsers on phones have caught up to the point where most of what people think they need a native mobile app for is now doable in a well-built web app. Push notifications work. Installation to the home screen works. Camera access works. Offline mode works. The gap between "app you download from the store" and "app you save to your home screen from a browser" has narrowed sharply, and most founders have not updated their mental model. Meanwhile, native app builds have gotten more expensive to release and maintain because app-store review, platform version support, and mobile engineer salaries all moved the wrong way.
3
Fronts your product can pick between: responsive web, progressive web app, and native mobile app. Most founders only consider the third.
5
Real reasons that actually justify a native mobile app. If none of them apply to your product, a progressive web app almost always covers you.
3
Things a progressive web app still cannot do cleanly. Whether you care about them decides which side of the line your product sits on.
1
Shared design system, one shared API layer. That is what keeps 3 fronts from turning into 3 codebases you cannot afford to maintain.
The rest of the piece walks the answer in the order the questions show up during a real product conversation. What is a progressive web app? Which front does your product actually need? What justifies going native? What are you giving up if you do not? How do you build so all 3 fronts share the work underneath? When should you stop before native? Nothing exotic; boring on purpose, because boring is the version that ships on time and holds up as the product grows.
So What Is a Progressive Web App?
A progressive web app is a website that behaves like a mobile app. Your customer opens it in a browser once, taps "add to home screen", and from that moment onwards it lives as an icon on their phone just like any other app. When they tap it, it opens in its own window without the browser controls, works offline once loaded, can send push notifications, and can use the camera, the microphone, and the phone's location. Behind the scenes, it is still a website; on the outside, your customer cannot tell the difference from an app they downloaded from the store.
Why do people build them instead of native mobile apps? Because they cost a fraction of what a native app costs, they get released the moment you deploy them (no app-store review, no platform-version handling, no "please update the app" popup), they run on every device from one codebase, and they are indexed by search engines so people can find them without an install. The trade is that they cannot do everything a native app can do: deep hardware access, some advanced background behaviour, and the "sits in the app store" marketing surface are all weaker or unavailable. Whether that trade fits your product is the whole question.
What is the difference between a progressive web app and a responsive website? A responsive website resizes cleanly to fit any screen. That is where it stops. A progressive web app is a responsive website plus the pieces that make it feel like an app: installable to the home screen, works offline, sends push notifications, opens in its own window. So every progressive web app is a responsive website, but most responsive websites are not progressive web apps. The upgrade from one to the other is real engineering work, but far less than building a native mobile app from zero.
The First Filter
If your product would be fine as "a website your customers can save to their phone and use like an app", you are looking at a progressive web app, not a native mobile app. Most B2B products, most content products, most internal tools, and a majority of consumer products fit that description. Ask that question first, every time. It is cheaper to build, cheaper to run, and easier to change.
Which Front Does Your Product Actually Need?
Which of the 3 fronts fits your product? Almost every "we need a mobile app" conversation resolves into one of these once you push on it a little. Knowing which front you are actually in changes the cost, the timeline of releases, the size of the team, and whether you end up maintaining one codebase or 3.
3 Fronts
What "We Need a Mobile App" Almost Always Turns Out to Mean
Front 1
Responsive Web Is Enough
Your customers visit occasionally. They do not need an icon on their phone. They do not need to work offline. Notifications are nice-to-have, not essential. A well-built responsive website covers everything they will actually do. About a third of "we need a mobile app" requests belong here; the founder just needed the site to feel less painful on a phone screen.
Front 2
A Progressive Web App Fits
Your customers use the product regularly. You want an icon on their home screen. You want notifications, offline mode, and the camera or microphone occasionally. A progressive web app delivers all of that from one codebase, released the moment you deploy, indexed by search, and dramatically cheaper than native. Roughly half of "we need a mobile app" requests belong here.
Front 3
You Actually Need Native Mobile
You need deep hardware access, aggressive background behaviour, complex gesture experiences, or the app store as a marketing channel where your competitors already live. This is real native mobile territory. It is a smaller share of requests than most founders assume, but when the product genuinely needs it, no progressive web app will close the gap.
How to Sort Yourself
Ask: do your customers need the product on their home screen, do they need it to work offline, do you rely on the app store for discovery, and do you need hardware capabilities beyond camera and location. Two or three yeses push you toward native; one push you toward a progressive web app; zero and responsive web is usually enough.
Why does the front matter so much before you start building? Because a responsive-web request built as a native app is a native app you will pay to maintain forever for no reason. A native-app request built as a progressive web app will hit a wall the moment the product tries to do the thing that needed native in the first place. And a progressive-web-app request built as a plain responsive website will leave adoption on the table because your users never had the home-screen icon they would have kept opening. The front decision, made honestly, is worth more than any framework or design pick that comes after it.
5 Real Reasons You Actually Need a Native Mobile App
Assuming you have honestly asked the question and you still think native is the answer, which reasons hold up? The 5 below are the ones that keep showing up in native mobile builds that were the right call. If none of them apply to your product, a progressive web app is almost certainly going to give you what you actually wanted, at a fraction of the cost.
01
Deep Hardware Access the Browser Cannot Give You
Your product needs the accelerometer running constantly, needs Bluetooth to talk to a specific paired device, needs the fingerprint sensor for authentication in a way the browser does not expose, or needs to control the flashlight, the compass, or NFC. The browser has closed most of these gaps, but not all of them. If your product genuinely depends on hardware the browser cannot reach cleanly, native is not a preference; it is a requirement.
02
The App Store Is Where Your Competitors Already Live
If your category is one where every serious competitor sits on the app store and users find products by searching there (fitness, meditation, banking, dating, mainstream consumer apps), being absent from the store is a real distribution disadvantage. A progressive web app cannot be listed in the app store. If the store is where your customers look, you have to be there, even if the technical requirements do not force native.
03
Aggressive Background Behaviour and Reliable Background Sync
Your product needs to sync data on a strict schedule while the phone is locked, needs to track location continuously in the background, needs to run scheduled jobs that the operating system will not aggressively kill, or needs to keep a persistent connection open for messaging or voice. Browsers have relaxed these limits a lot, but not to native-app levels. If your product depends on background work that survives the operating system trying to save battery, native gives you the tools; the browser mostly does not.
04
Complex Gesture and Animation Experiences at 60 Frames Per Second
Games, drawing apps, immersive video experiences, augmented reality, and anything with a rich gesture language (pinch-rotate-zoom on custom canvases, multi-finger drawing, physics-driven interfaces) hits the ceiling of what a browser can do smoothly. Most products do not need this. A few genuinely do, and for those, native is where the performance headroom lives. If your product is a form, a list, and some charts, this reason does not apply to you.
05
A Fully Offline-First Experience With Local Encryption
Your users spend real time in places without connectivity (field workers, medical staff in rural clinics, airline crews, defence, offshore work) and the product has to keep working, keep collecting data securely, and sync cleanly when connectivity returns. Progressive web apps have offline mode, and it is good, but native gives you a stricter offline model, better local encryption tooling, and more predictable behaviour in low-power situations. If your product's core use is offline, native has real advantages that mostly do not show up in day-to-day online reviews.
The Honest Count
Read the 5 reasons above and count how many actually describe your product. Zero or one, and a progressive web app almost always covers you at a fraction of the cost. Two or more, and native starts earning its price tag. This is the single most useful filter to run before your team writes the first line of mobile code.
3 Things a Progressive Web App Cannot Do (And Whether You Care)
What do you give up if you choose a progressive web app over a native one? The 3 gaps below are the ones that still matter. They have narrowed a lot; most products can absorb them, but you should know what you are trading before you make the pick.
01
App Store Discovery and Ratings
Progressive web apps are not listed in the app store, so all the discovery, ratings, reviews, and social proof that live inside the store are unavailable to you. You have to bring your own distribution through search, ads, referrals, and word of mouth. For most B2B products, internal tools, and content products, this is not a loss because your customers were not going to search the store anyway. For consumer products in categories where the store is the discovery channel, this is a real gap and is often the deciding factor.
02
Some iOS Push and Background Limits Still Apply
Push notifications from progressive web apps work on modern iOS, but with more restrictions than a native app. Background sync and scheduled background work are also more limited on iOS than on Android. If your product's value depends heavily on the phone waking up on its own, buzzing your user with something time-sensitive, or running work while the user is not looking, iOS is where the progressive web app path shows its edges. Android is much closer to native for these use cases.
03
Perception, in Categories Where Perception Matters
In some categories, users still expect an app in the app store because "real" apps live there. Banking, insurance, high-trust financial products, and healthcare products are the clearest examples. A perfectly capable progressive web app in these categories can feel less legitimate to users than a native app, even when the actual features are the same. This is a perception gap, not a technical one. It matters when it matters, and it does not matter when it does not.
The Trade
None of these 3 gaps are absolute anymore. All 3 have narrowed. Each of them still matters for a specific kind of product. Ask honestly whether your product hits any of them; if it does not, the progressive web app trade is almost always in your favour.
A Simple Shape for a Product That Serves Web, PWA, and Mobile Without Three Codebases
So what does a product that serves all 3 fronts without falling into 3 codebases actually look like? Not fancy. The shape below is the arrangement that lets your team share the design system, share the business logic, share the payment layer, and share the data layer across the web, the progressive web app, and (when it is genuinely needed) the native mobile app. The layers underneath are one codebase. The layers on top are thin, platform-specific shells that render the shared work in the right way for each front.
Architecture
A Shape That Serves 3 Fronts Without Ending Up With 3 Codebases
Front 1
Responsive Web Shell
Renders the shared design system in a browser tab. No installation, no home-screen icon. Indexed by search engines.
Front 2
Progressive Web App Shell
Same shared design system, plus the pieces that make it feel like an app: installable, offline mode, push notifications, camera access.
Front 3
Native Mobile Shell
A thin native app that renders the shared design system through the platform-native chrome, plus the native-only features your product actually needs.
↓
Shared Underneath
One Design System, One API Layer, One Business Logic Layer
Design System
Shared components, typography, spacing, colors. Written once, rendered by every shell.
API Layer
The endpoints every shell calls. Predictable shapes. One auth story. Covered in our API design piece.
Business Logic
The rules of your product live once, behind the API. Every shell just renders the state.
Why This Shape Survives
Feature work happens once, at the shared layer. New shells plug in without touching the underlying product. When one shell needs a platform-specific feature (Face ID on iOS, a specific Android intent, an app-store listing), it lives in that shell only, and does not leak into the shared work.
Why go to this trouble instead of just building one native app and being done? Because 3 codebases is what happens when you skip the shared layer. Your web team makes a change; your progressive-web-app team makes it separately; your native team makes it a third time, differently, later. Within a year you have 3 versions of the same product that behave subtly differently, and every feature costs 3 times as much to build. The shared shape is what keeps that from happening, and it is what makes serving multiple fronts an option instead of a punishment.
3 Signs You Should Stop at a Progressive Web App Instead of Building Native
When is it safe to stop at a progressive web app and skip the native build? The 3 signals below are the ones that keep pointing that way. If you see more than one, the progressive-web-app answer is almost certainly the honest one, no matter how loud the "we need a mobile app" voice in the room is.
01
Your Users Live Inside a Browser Anyway
Your customer's day is spent in a browser tab. They flip between tabs, they have your product open next to their email and their spreadsheet, and adding a native app to the mix is just one more thing to install. Most B2B products, internal tools, and productivity software look exactly like this. Push these users toward a downloadable native app and adoption drops; give them a progressive web app they can pin to the home screen or leave in a tab and adoption stays.
02
You Ship Product Changes Faster Than the App-Store Review Cycle
Your team pushes changes to production regularly. Every app-store review waiting on approval is a delay you did not have as a web team. If shipping fast is part of how the product wins, a progressive web app keeps that speed; native adds a queue between "we are ready to release" and "customers can use the release". For most products that iterate rapidly, this is the single biggest reason to stay on the progressive-web-app path.
03
Nothing Your Product Does Actually Requires Native
Run through the 5 real reasons above. If none of them describe your product, native is a want, not a need. Building native anyway means paying the native tax (larger team, longer release cycles, app-store overhead, dual platform maintenance) for a benefit your product does not use. In most such cases the honest answer is: launch as a progressive web app, watch adoption, and revisit native only if a real reason emerges from usage data, not from opinion.
The Simplest Test
If more than one of the 3 signs above is true and none of the 5 real reasons for native apply, stop at a progressive web app. You can always add a native shell later if the product genuinely earns it. You cannot as easily undo the cost and complexity of a native build that turned out not to need to be native.
Frequently Asked Questions
Can a progressive web app really replace a native mobile app?
For most product categories, yes. Home-screen installation, offline mode, push notifications, camera access, and location are all available. The exceptions are products that genuinely need deep hardware access, aggressive background behaviour, complex 60-frames-per-second experiences, or the app store as a distribution channel. Outside those cases, a progressive web app gives you the same felt experience as a native app at a fraction of the build cost and with none of the app-store release friction. Most founders who tested both discover that their users cannot tell the difference on the surface, and their teams can absolutely tell the difference on the maintenance side.
What about React Native or Flutter? Are those a middle path?
React Native and Flutter are cross-platform native frameworks: one codebase that produces real iOS and Android apps. They are a real middle path when you need to be in the app stores but do not want to maintain two separate native codebases. They are not, however, cheaper than a progressive web app; they are cheaper than two parallel native codebases. Pick React Native or Flutter when native is genuinely required (app-store presence, hardware access, background behaviour) but you want to run one team across both platforms. Pick a progressive web app when the app store is not a requirement.
Does search engine indexing still work for progressive web apps?
Yes, and this is one of their quiet advantages over native. A native app cannot appear in a Google search result the way a web page can; a progressive web app can, because it is still a website underneath. If organic search is a real source of customers for your product, a progressive web app keeps that channel open while native cuts it off. This is one of the reasons most B2B products with real content marketing programs choose the progressive-web-app path.
Is iOS still worse than Android for progressive web apps?
The gap has narrowed a lot. Push notifications, home-screen installation, and offline mode all work on modern iOS. The remaining differences are around background behaviour and some smaller platform capabilities. For most product use cases the gap does not matter; for products that depend heavily on the phone waking itself up to run work while the user is not looking, iOS still favours native. Check your product's actual dependencies against the current iOS capability list before deciding; the answer is usually "the gap does not matter for what you are building".
Should you build the responsive web version first or the progressive web app first?
Build them together, from day one, as one project. The extra work to make a responsive website into a progressive web app is small if you plan for it up front, and painful if you retrofit it later. Treating "responsive web" and "progressive web app" as separate phases usually leads to the second phase never happening. The right default for almost every product is: build a progressive web app from day one, and treat responsive web as the fallback experience for the small number of users who never install it.
When you do build native, should you go single-platform first or both?
Depends on where your customers are. If your product's user base skews heavily toward iOS (typical for consumer products in high-income markets), start with iOS and add Android when the volume justifies it. If it skews toward Android (typical for products in India, Southeast Asia, and much of Africa), the reverse. Building both from day one is only the right call when your customer base is genuinely split and you cannot afford to be missing from either platform for the first release. Otherwise, pick the one your customers live on and add the second when the numbers say so.
Can Entexis help you pick and build the right front for your product?
Yes. Entexis designs and builds all 3 fronts (responsive web, progressive web app, and native mobile) and, more importantly, starts by helping you sort out which one your product actually needs. The work begins with the honest conversation about your users, your competitors, your distribution channels, and the specific things your product does with the phone, then moves into the design of the shared layer (design system, API layer, business logic) that keeps every front cheap to maintain, and delivers whichever shells your product actually needs. Reach out with what your product does, who it is for, and where your customers live, and we can walk through what the right front looks like for your specific product.
So where does that leave you? Most "we need a mobile app" conversations end with a different answer than the one the founder walked in with. Sometimes the answer is a well-built responsive web app. Most of the time it is a progressive web app that costs a fraction of native and delivers what the users actually wanted. Sometimes it really is native, and when it is, the 5 real reasons above are usually why. Get the front right first, share the design system and the API layer underneath, and add native only when the product genuinely earns it. Teams that do this end up with a product that reaches every device from one shared foundation. Teams that default to native regardless usually rediscover, a year in, that the app they built is doing 30 percent of what a progressive web app would have done at a tenth of the cost.
Want to Pick the Right Front for Your Product Before You Spend on the Wrong One?
At Entexis, we design and build products that serve web, progressive web app, and native mobile from a shared foundation. We start with the sorting conversation to make sure you are picking the right front for your users, your distribution channels, and the specific things your product does with the phone, then design the shared design system plus the shared API layer that keeps every front cheap to maintain, and deliver the shells your product actually needs. Your users get the product on the surface they were going to use anyway, your team stops maintaining 3 versions of the same feature, and your build cost matches what the product actually requires. Start the conversation with Entexis.
Need Custom Software Built?
From web apps to enterprise platforms, we build software that fits your workflow, not the other way around. Tell us what you need.
We'll get back within one business day.
Thank You!
We've received your message and will get back to you within one business day.
