PWA vs native app: does your startup actually need an app store?

Most startups do not need an app store for their first product. Start with a progressive web app, a website that installs, works offline, and sends push notifications, and go to the stores only when you need something the stores uniquely provide. That is the short answer, and it is the advice we give most founders who walk into Novek Labs asking for "an app."

The longer answer has real nuance. There are categories where a store listing is table stakes, device features a browser still cannot touch, and users who will never trust a product outside the App Store. This post covers what a PWA can actually do in 2026, what the stores really cost, and a decision framework to apply before you spend a dollar on development.

Key takeaways

• A PWA (progressive web app, a website that behaves like an installed app) gives you instant distribution: one link, no download, no review queue, and you can ship fixes daily.
• App stores charge a real tax: review delays on every release, a commission on digital goods, and platform rules that can change under you.
• The app store is not a marketing channel. Nobody discovers an unknown startup by browsing the store. You still have to drive every install yourself.
• Native makes sense when you need deep device APIs, habitual home-screen presence, reliable push on iOS at large scale, or credibility in a category where users search the store first.
• The paths are not mutually exclusive. Ship a PWA now, validate demand, then wrap the same codebase for the stores later.

What can a PWA actually do in 2026?

A progressive web app is a normal web application with three additions: a service worker (a background script that handles caching and offline behavior), a manifest file that lets users install it to their home screen, and push notification support. To a user, a well-built PWA looks and feels like any other app icon on their phone.

Does a PWA work offline?

Yes, if you build for it. Service workers let you cache the application shell and data so the product opens and functions without a connection, then syncs when the network returns. We built HealthTrack Pro, a wellness PWA, to log workouts fully offline because people train in basement gyms with no signal, and that offline experience is what users mention most. Offline is an architecture decision, not a platform decision.

Can users install a PWA to their home screen?

Yes, on both platforms. On Android, Chrome actively prompts users to install PWAs, and the installed app gets its own icon, splash screen, and standalone window with no browser chrome. On iOS, Safari supports adding a PWA to the home screen as a standalone app, though the flow is buried: users tap the share button, then "Add to Home Screen." That friction is real, so design your onboarding to walk iOS users through it if installation matters.

Can a PWA send push notifications on iOS?

This was the historical dealbreaker, and it has partially fallen. Safari supports web push for PWAs that users have added to their home screen. The caveats matter, though: the user must complete the home-screen install first, permission prompts behave differently than native, and in our experience delivery is less predictable than native push at scale. If your product lives or dies on iOS notifications, that is a genuine reason to consider native. If notifications are a nice-to-have, web push is now good enough for a first version.

What can a PWA still not do?

Be honest with yourself about this list, because if your core feature is on it, the PWA conversation is over:

• Deep Bluetooth and hardware integrations, especially on iOS, where browser support for device APIs lags well behind Android
• Background processing beyond what service workers allow, such as continuous location tracking or always-on sensors
• HealthKit, Apple Wallet, Siri, widgets, watch apps, and other OS-level integrations
• High-end 3D games and anything needing maximum GPU performance
• App store presence itself, which for some audiences is the credibility signal

Full disclosure: Novek Labs is a web-first studio, so we carry a bias here. We think that bias is earned by watching what happens to first-time founders on each path, but weigh it accordingly.

How much does the app store really cost a startup?

Founders usually think of the store fee as the annual developer account cost. That is the smallest line item. The real costs are structural.

The review tax on every release

Every native release goes through store review. Most reviews clear quickly, but "quickly" is measured in hours or days, not minutes, and a rejection can stall you longer while you appeal or rework. On the web, deploying a fix takes as long as your build pipeline runs. When your MVP is wrong in ways you have not discovered yet, and it will be, iteration speed is survival. We covered this in why most MVPs die before launch, and the review queue works directly against it.

Commission on digital goods

If you sell digital products, subscriptions, or in-app content through a store app, the platform takes a commission and has historically required its own payment system. Rules around external payment links have loosened in some regions after regulatory pressure, but they shift constantly and vary by country. On the web, you pay your payment processor a small percentage and keep the rest, with no one dictating your checkout flow.

Platform risk you do not control

Store policies change, categories get restricted, and apps get pulled for reasons that arrive as a form email. None of this is common, but when it happens to you it is existential, and there is no equivalent risk on the open web, where you control your domain and your distribution.

Is the app store a good marketing channel?

This is the most persistent myth we hear: "once we are in the store, people will find us." They will not. Store search is dominated by established brands and paid placement, and browsing favors apps with thousands of ratings. An unknown startup gets effectively zero organic discovery from a listing.

Think about how every app you use actually reached you: a friend's link, a social post, an ad, a web search. The store was the last step in the funnel, not the top of it. A store page adds a step where users must stop, download, and wait, and every added step loses people. A PWA turns that funnel into one tap: the link is the product. For a first product trying to prove demand, that difference compounds daily.

The exception is categories where users genuinely start their search inside the store, which we cover in the decision framework below.

PWA vs native app: side by side

Factor	PWA	Store-distributed native app
Distribution	Instant, via any link	Download after store review
Release cycle	Deploy anytime, same day	Every release passes review
Digital goods commission	Payment processor fees only	Platform commission applies
Offline support	Yes, via service workers	Yes
Push notifications	Solid on Android, workable on iOS with caveats	Reliable on both platforms
Install friction	One tap on Android, share-menu flow on iOS	Store page, download, wait
Deep device APIs	Limited, especially on iOS	Full access
Home screen presence	Yes, after install prompt	Yes
Perceived credibility	Depends on audience	Store listing signals legitimacy in some categories
Cost to build	One codebase, web team	One to two codebases, or a cross-platform framework

When does a native app actually make sense?

We are not anti-native. We shipped Roundup, a micro-investing app, as a native build because finance users expect the store, biometric login, and OS-level trust signals, and the product depends on habitual daily opens. Native earns its cost when at least one of these is true:

• Your core loop needs device APIs the browser cannot reach. Continuous background location, Bluetooth hardware, HealthKit, widgets, watch integration.
• Your retention model is habitual, notification-driven engagement on iOS at scale. Web push on iOS exists, but if push is your lifeblood, native delivery is more dependable.
• Your category carries store-first trust expectations. Banking, dating, and kids' apps are examples where "it's not in the App Store" reads as a red flag to mainstream users.
• You are competing on polish in a gesture-heavy interface. High-end animation and native scrolling feel are still easier to perfect natively.

If none of those describe your first product, you are paying the store tax for nothing.

The hybrid path: ship a PWA now, wrap it later

The best part of starting on the web is that it is not a dead end. A well-structured web codebase can be wrapped for the stores later using Capacitor-style wrappers (which package your web app inside a native shell) or rebuilt with React Native, which shares your team's JavaScript skills and often big chunks of your logic. We compared those options in React Native vs native development.

The sequence we recommend, and the one we follow in our own mobile process, looks like this: ship the PWA first, use it to validate that anyone wants the product at all, and let real usage tell you whether store-only features are blocking growth. If they are, wrap or port with most of your code and all of your learning intact. Founders who start native pay the slowest iteration loop during exactly the phase when they know the least, which is also why native-first builds blow up timelines, as we broke down in how long it takes to build an MVP.

The decision framework

Answer these six questions honestly before you commit to a platform:

1. Does your core feature require a device API that browsers cannot access? If yes, native. If you are unsure, list your features and check each one, because "we might need it someday" is not yes.
2. Will your product die without reliable iOS push notifications from day one? If re-engagement push is the product, lean native. If push is helpful but not vital, the web is fine.
3. Do users in your category search the store first? Finance, dating, kids' content: probably. B2B tools, marketplaces, content products, internal tools: almost never.
4. How fast do you need to iterate? If you expect to change the product weekly based on user feedback, and every early-stage product should, the web's instant deploys are worth more than any native feature.
5. Are you selling digital goods or subscriptions? On the web you keep what your payment processor leaves you. In the store, model the commission into your unit economics before deciding.
6. What can you afford to maintain? One web codebase is cheaper than a web presence plus one or two native apps. If the honest answer is "we can barely fund one," that is your answer.

Score it simply: if questions 1 through 3 all come back "no," start with a PWA and revisit in six months with real data.

Frequently asked questions

Is a PWA cheaper to build than a native app? Generally yes, because you build and maintain one codebase that serves every device, and you likely need a website anyway. A native strategy means the website plus at least one app, and often separate iOS and Android considerations. The bigger saving is iteration cost: every future change ships once, instantly.

Can a PWA be listed in the app stores? Partially. Google Play accepts packaged PWAs through trusted web activity tooling, so you can get a Play listing from your web codebase. Apple expects apps to offer more than a wrapped website, so a bare wrapper risks rejection. If store presence becomes essential, a Capacitor or React Native build with some native touches is the safer route.

Do users actually install PWAs? Installation depends heavily on prompt design and platform. Android users install readily when prompted at the right moment, such as after a good first session, while iOS requires a guided share-menu flow, so fewer complete it. The good news is a PWA works fully in the browser either way, so an uninstalled user is still a user.

Will investors take a web-only product less seriously? In our experience, no. Investors care about retention, growth, and revenue, and none of those metrics know what platform they run on. A web product that ships weekly and shows real traction beats a native app that took twice as long to reach its first users.

When should we switch from PWA to native? When real usage data shows a store-only capability blocking growth: push-driven retention you cannot achieve with web push, a device feature users keep requesting, or clear evidence that store credibility is costing you conversions. Switching from a position of traction is cheap. Guessing native up front from a position of zero users is expensive.

Ready to pick a path?

If you are weighing this decision, we run this evaluation with founders every week. Send us what you are building through our contact page and we will give you a straight answer on whether your first version belongs on the web, in the stores, or on the hybrid path, even if that answer is not the one that earns us the bigger project.