You want a mobile app, but you do not know whether it is worth spending months on iOS and Android development,
or if a Progressive Web App will suffice. This is a question every business and solo developer faces.
Spoiler: for many projects, a PWA is faster, cheaper, and entirely sufficient, but there are scenarios
where a native app is indispensable.
⚡ In Short
- ✅ PWA is a website with app capabilities: home screen installation, offline mode, push notifications, without the requirement of a store.
- ✅ Native app means maximum performance: full device access, AR, Bluetooth, biometrics.
- ✅ PWA development cost is usually several times lower: one codebase instead of two or three.
- ⚠️ The main drawback of PWA is iOS and discoverability: no automatic installation, and users find the product through search and links rather than an app store. Read how to handle this in the article How to Promote a PWA: SEO, Indexing, and Installation.
- 🎯 What you will get: a comparison table, selection scenarios, an overview of iOS limitations, paths to app stores, cost breakdowns, and a real-world case study of Kazki AI.
📚 Table of Contents
🎯 Section 1. What is a PWA and a Native App: Briefly
These are two approaches to building a mobile application. A PWA is a website that behaves like an app, while a native app is built separately for iOS or Android with full device access.
A PWA is when a website becomes an app. Native is when an app is an app from the first line of code.
Progressive Web App (PWA)
A PWA is built on standard web technologies: HTML, CSS, JavaScript. Thanks to Service Workers and the Web App Manifest, it gains capabilities previously exclusive to native apps: home screen installation, offline mode, and push notifications. Once installed, a PWA opens in full-screen mode, without an address bar, and with its own icon. I covered the technology, architecture, and step-by-step creation in the article Progressive Web Apps (PWA): A Complete Guide for Business and Developers.
Native App
A native app is built separately for each platform: Swift or SwiftUI for iOS, Kotlin or Jetpack Compose for Android. It is downloaded from the App Store or Google Play and has full access to the camera, GPS, Bluetooth, biometrics, and file system. Cross-platform solutions (Flutter, React Native) also exist, but they still require separate compilation and publication in app stores.
🎯 Section 2. PWA vs Native: Comparison Across 12 Criteria
PWA wins in cost, time-to-market, updates, and accessibility. Native wins in performance, hardware access, and store presence. The choice depends not on which technology is "better," but on the needs of the product.
| Criterion | PWA | Native App |
|---|
| Development Cost | Low: one codebase for all platforms. If a website already exists, a PWA is added with a minimal budget | High: separate code for iOS and Android or cross-platform with its own limitations |
| MVP Development Time | From a few days (for an existing website) to a few weeks | Usually months, even with a cross-platform stack |
| Installation | From the browser, without an app store. On Android there is an install prompt, on iOS only manually via "Share → Add to Home Screen" | Via App Store or Google Play: account creation, moderation, guideline compliance |
| Updates | On the next open, without user action | Via app store: moderation and user update or auto-update |
| Offline Mode | Yes, via Service Worker. Storage on iOS can be cleared, so keep critical data on the server | Yes, full control over local databases |
| Push Notifications | Android: full support. iOS: since 16.4, only for PWAs added to the home screen | Full support on both platforms via APNs and FCM |
| Performance | Sufficient for content, e-commerce, SaaS, media | Maximum: direct GPU access, critical for games, video, AR |
| Device Access | Camera, microphone, GPS, vibration. No NFC, ARKit, HealthKit; Bluetooth only in Chromium | Full: Bluetooth, NFC, AR, biometrics, HealthKit, Siri |
| SEO and Discoverability | Public pages are indexed by Google, but only with proper rendering and URLs. Details in the article SEO for PWA: How Users Find Your App | Store search (ASO), Google does not index app store pages as a website |
| Size | Shell cache within a few megabytes, the rest loads as needed | Tens to hundreds of megabytes |
| Platform Commission | 0% from app stores: payments through your own gateway (Stripe, LiqPay, Mono) | 15–30% on in-app purchases depending on terms |
| Audience and Accessibility | Anyone with a browser: one link and the user is in the app | Only those who find the app in the store, download, and open it |
This table is a map, not a verdict. For one project, the absence of a 30% commission is decisive; for another, Bluetooth access matters more than any savings.
🎯 Section 3. When a PWA is the Right Choice
I recommend that clients consider PWAs for content, service, and commercial projects where the primary interaction happens through text, images, and audio. This approach can cut launch time and costs compared to developing separate native apps, while retaining browser access and the ability to install the app on a device.
If a user can perform all necessary actions through a browser, I recommend evaluating a PWA first—before investing in separate native apps.
Scenario 1. Startup or Solo Developer with a Limited Budget
The classic startup trap: spending half a year on native apps for two platforms, only to find out the idea does not work. A PWA delivers a mobile experience in days and weeks, giving you time to validate your idea. Added to this is the cost savings: you do not need a Mac to build for iOS or a separate CI/CD pipeline for mobile platforms, and a developer account is only required if you choose to publish in app stores.
Scenario 2. Content Apps (News, Blog, Media, Audio)
Every article or episode has its own URL that Google can display in search results, and Service Workers provide fast access and offline reading. This is a unique advantage over native apps, with one condition: pages must be served as ready HTML rather than rendered solely by client-side scripts. How to achieve this is outlined in the article How to Promote a PWA: SEO, Indexing, and Installation.
Scenario 3. E-commerce, Catalogs, and Marketplaces
Here, a PWA removes the "download → register → then view products" barrier: a user clicks through from an ad or social media and immediately sees the catalog. Payments go directly without app store commissions, which can be decisive for low-margin businesses.
Scenario 4. Enterprise Internal Tools
CRMs, dashboards, and task trackers do not need the App Store. A single app runs on phones, tablets, and desktops, updates instantly for everyone, and does not require IT to manage installations on each device.
🎯 Section 4. When a Native App is the Only Option
A native app is needed when the product relies on hardware, complex graphics, reliable background processing, or strict security requirements.
If an app cannot function without an AR camera, Bluetooth sensors, or 60 FPS graphics, that is native territory.
Scenario 1. Games and Heavy Real-Time Graphics
3D games, AR, and video editors require direct GPU access (Metal, Vulkan) and fine-grained memory management. WebGPU is narrowing the gap, but native remains the primary choice for production games with heavy graphics.
Scenario 2. IoT, Bluetooth, and External Devices
Fitness trackers, medical devices, and smart homes operate via BLE, NFC, or USB. Web Bluetooth only works in Chromium and is absent on iOS. Integration with HealthKit and Health Connect is exclusively possible through native APIs.
Scenario 3. Background Processes and Deep OS Integration
GPS navigation in the background, music players with lock screen controls, VoIP, and messengers with reliable message delivery. Service Workers are not designed for long-running background tasks, and the OS may terminate a PWA once minimized.
Scenario 4. Security and Compliance
Banking and payment apps, medical and government sector apps benefit from Keychains and Keystores, full biometric APIs, screenshot protection, and certificate pinning. For audits like PCI DSS or HIPAA, a native app is typically easier to justify.
Store presence as a strategic business requirement (trust, ratings, an audience that searches exclusively in app stores) is covered in Section 6.
🎯 Section 5. PWA Limitations on iOS in 2026
iOS remains the primary weakness of PWAs. There is no automatic install prompt, push notifications are available only for apps added to the home screen, and Apple does not promise full parity with Android.
Android treats PWAs as full citizens, while iOS treats them as guests with limited rights.
This is the most critical decision factor if your audience is predominantly on iPhone. The current situation:
- No automatic install prompt. On Android, Chrome suggests installing the PWA automatically, whereas on iOS the user must know to tap "Share → Add to Home Screen." Therefore, you need a custom UI prompt.
- Push notifications work starting with iOS 16.4, but only for installed PWAs. Permissions are requested following a user action (a button click) rather than upon page load. Step-by-step code and common pitfalls are covered in the article PWA Push Notifications on iOS in 2026: What Actually Works.
- Storage can be cleared. Safari enforces site data deletion policies if a user hasn't opened a site in a while. Keep critical data on the server and treat the cache as temporary.
- Engine. In most regions, all browsers on iPhone run on WebKit, meaning Safari's limitations apply to Chrome and Firefox as well. The situation in the EU is different due to the Digital Markets Act.
- EU. Apple initially announced that iOS 17.4 would remove home screen web apps in the EU, then reversed that decision and kept them. For a European audience, it is best to check the current status on Apple's page rather than relying on outdated news.
iOS limitations are only part of the challenge. Typical integration errors (caching, analytics, updates) along with code examples were broken down in the article 8 Critical Mistakes When Integrating a PWA.
🎯 Section 6. Hybrid Approach and Distribution: PWA, TWA, Wrappers, Search
I recommend a "launch → validate → scale" strategy to my clients. Launch a PWA first, test demand and user behavior, and only then decide whether separate native apps in the App Store and Google Play are necessary. At the same time, keep in mind that a PWA lacks automatic visibility via a store showcase, so user acquisition channels must be planned in advance.
I advise against spending months developing a native app until you have validated the demand for the product itself.
In the first phase, you build a web application with PWA capabilities, gather feedback, and collect analytics. Once the product proves its value, you have the data needed to decide: do you need capabilities that a PWA doesn't offer, do users demand store presence, or is there a budget for multiple codebases?
How a PWA Gets Into App Stores
| Path | How it Works | What to Keep in Mind |
|---|
| Web Only | Users find via search, links, catalogs, QR codes | Requires SEO and thoughtful installation prompts (see below) |
| Google Play via TWA | A PWA wrapped in Chrome, without native code. Built using Bubblewrap or PWABuilder | Requires domain verification; check current Play Console requirements for new accounts |
| App Store via Wrapper | A WebView wrapper such as Capacitor | Per Guideline 4.2, Apple may reject apps lacking native value beyond the website; native capabilities are required |
| Microsoft Store | Packaged via PWABuilder | Simpler than others, but the audience is smaller |
Why "Being in the Store" is Not the Same as "Being Found"
For a native app, the store acts as a search engine, storefront, and installation channel. A PWA lacks this built-in funnel: users find it via Google, links, catalogs, and social media, and perform the installation themselves. Therefore, a public product page, proper rendering, keyword-friendly naming, catalogs, install prompts, and push notifications for user retention become part of your core strategy rather than an afterthought. All of this is detailed step-by-step with code and checklists in the article How to Promote a PWA: SEO, Indexing, and Installation.
Publishing in stores adds a channel and builds trust, but introduces commissions, moderation processes, and a separate maintenance package. If your audience comes from Google with a specific intent, an app store might be redundant. Certain audiences (primarily iOS users in the US and Europe) search for apps exclusively in the App Store, and for them, its absence means the product does not exist.
🎯 Section 7. Real-World Case Study: What PWA Brought to Kazki AI
For Kazki AI, I chose a PWA, which allowed me to launch within a few weeks with a single codebase. The main advantages were iteration speed and SEO, while iOS was the main drawback.
When you are on your own, every week of development counts. A PWA gave me an app without the app-building overhead.
Kazki AI is a personalized audio fairy tale service for children: a child becomes the hero of a story, and AI generates text with their name and narrates it in Ukrainian. Tech stack: Spring Boot, Thymeleaf, Tailwind CSS, PostgreSQL, Redis, and ElevenLabs for voice generation. The project is closed, but the experience remains valuable.
When users began asking for a mobile app, I estimated the scope of work for native development. Even with a cross-platform approach, it would take at least 2–3 months of work, and a full-fledged project might require developers, QA engineers, and dedicated resources to support iOS and Android. Additionally, you must account for an Apple Developer account, a Mac for building the iOS app, and navigating app store moderation, which does not guarantee publication on the first try.
Instead, I added PWA support in 4–6 days: I created a manifest.json with app descriptions, configured sw.js for caching static assets, and registered the Service Worker in templates. On Android, users could add the site to their home screen, and once launched, the PWA opened in a window without the standard address bar. Caching also helped load assets faster if they were already saved on the device.
What Settled the Matter in Favor of PWA
- Content Type. Text and audio, with no Bluetooth, AR, or complex graphics. The browser plays audio wonderfully, and native capabilities wouldn't have added anything here.
- SEO. A significant portion of new users arrived from Google, particularly on pages featuring children's names ("a fairy tale for Sofia"). A native app would not have provided this channel.
- Iteration Speed. I deployed updates multiple times a week, and users received the new version instantly.
- Cost. No developer account, Mac, or separate mobile CI/CD pipeline required.
What Didn't Work Ideally
iOS. iPhones lack an automatic install prompt, so I added a custom prompt: "Tap Share → Add to Home Screen." It wasn't perfect, but it worked.
🎯 Section 8. Cost and Timeline: Specific Figures
A PWA is typically several times cheaper than native development, but the cost depends on complexity. Below are estimated ranges, not a fixed price list.
The question is not "how much does an app cost," but "how much does every month of launch delay cost."
| Parameter | PWA | Native (Cross-Platform) | Native (Separate iOS + Android) |
|---|
| MVP Development Time | Days (if a website exists) to a few weeks | 2–4 months | 4–8 months |
| Development Cost | $0 — $5K | $15K — $50K | $30K — $150K+ |
| Developer Accounts | Not required (unless publishing to stores) | Apple $99/year + Google $25 one-time | Apple $99/year + Google $25 one-time |
| Maintenance (per month) | $0 — $500 | $1K — $5K | $2K — $10K |
| Store Commission | 0% | 15–30% | 15–30% |
| Mac Required | No | Yes (for iOS) | Yes (for iOS) |
Hidden PWA Costs
A PWA is not free "out of the box." Allocate time for rendering public pages (SSG, SSR, or prerendering), configuring push notifications, and supporting iOS. Skipping these tasks will result in a lack of search traffic and installation issues that wipe out any savings. What belongs to the promotion strategy is detailed in the article How to Promote a PWA.
❓ Section 9. Frequently Asked Questions (FAQ)
Can a PWA completely replace a native app?
For many applications, yes: content, service, e-commerce, and SaaS. For games, IoT, AR, and complex graphics, no—native is required.
Can you publish a PWA on Google Play and the App Store?
On Google Play, yes, via Trusted Web Activity. In the App Store, technically yes via a WebView wrapper, but Apple may reject an app that does not provide native value beyond the website. Details are in Section 6 and the article How to Promote a PWA.
Will users find my PWA?
Through Google, yes, if public pages are crawlable and served as ready HTML. In the App Store, no, unless you published it there. Search, catalogs, links, and installation are covered in detail in the article How to Promote a PWA: SEO, Indexing, and Installation.
What is better for the Ukrainian market?
It depends on the audience. Android traditionally dominates in Ukraine, so most users will get a full PWA experience with an install prompt. Check the current platform share in your own analytics.
Does a PWA work on iPhones in the EU?
Yes: Apple initially planned to remove Home Screen web apps in the EU, but reversed that decision and kept them. Before publishing, check current status on Apple's DMA page, as EU rules change.
Is a PWA secure?
A PWA operates exclusively over HTTPS, and Service Workers lack DOM access and run in an isolated thread. A PWA does not gain extra permissions upon installation. However, for regulated industries (banking, healthcare), native apps offer more protective tooling.
✅ Section 10. Conclusions and Selection Formula
For many projects, a PWA is not a compromise but a deliberate choice, especially for a solo developer or small team. However, technology is only half the decision: the other half is distribution and discoverability.
Technology should serve the product, not the other way around.
Selection Formula: 6 Questions
| Question | If "Yes" | If "No" |
|---|
| Is primary interaction text, images, audio, or video? | PWA | Consider native |
| Do you need Bluetooth, NFC, AR, HealthKit, or reliable background tasks? | Native | PWA |
| Can your audience arrive from search or a link? | PWA | Consider stores |
| Are there strict compliance requirements (PCI DSS, HIPAA)? | Native | PWA |
| Is store presence critical for trust? | PWA + TWA/wrapper or native | PWA |
| Are budget and launch time limited? | PWA | Choose based on other criteria |
If most answers point to a PWA, start with it: it takes days, not months. If in six months you find that native is needed, you will already have a working product, an audience, and an understanding of what exactly to build. And if your product is a game, IoT controller, or AR app, go straight to native development.
After choosing your technology, the next question is how people will discover your PWA and install it. This is broken down in the article How to Promote a PWA: SEO, Indexing, and Installation.
🔗 Further Reading
📖 Sources and Useful Links
