--- title: What Are the Biggest Limitations of Progressive Web Apps? description: Progressive web apps promise simplicity, but PWA limitations run deep. Discover what they cannot do on iOS, offline, and in regulated products. image: https://weareaffective.com/hubfs/learning-centre-images/what-are-the-biggest-limitations-of-progressive-web-apps.webp --- [Skip to content](https://weareaffective.com/learning-centre/what-are-the-biggest-limitations-of-progressive-web-apps#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # What Are the Biggest Limitations of Progressive Web Apps? Table of Contents A progressive web app runs in the browser, sits on the home screen with its own icon, and behaves for the most part like any other app on the phone. The pitch is sound. One codebase, no store review, no store commission, and updates that go live the moment you push them. The trouble is that progressive web app limitations don't show up in a demo. They show up on a particular handset, in a particular moment, usually when the person using it is already under pressure. > A PWA's weak points show up on a real phone, with a poor signal and a user in a hurry. We build both native apps and PWAs, so there's no side to take here. What we've learned is that the decision is rarely about technology on its own. It's a decision about which moments in your product can afford to be slightly worse. This article walks through where PWAs run out of road, what that costs in practice, and how those costs tend to land on the product rather than the engineering team. Some of it is hardware. Some of it is Apple. And a good deal of it is the quiet way a platform limit reshapes what you end up shipping. ## What a PWA Actually Is, and What It Promises A progressive web app is a website with a few extra parts bolted on. There's a service worker, a small script the browser keeps around so pages can load from a cache. There's a manifest file, which tells the phone what icon to use and how the app should open. And the whole thing runs over HTTPS. Put those together and a site can live on the home screen, open full screen with no browser bar, and load fast on a patchy connection. The commercial promise is straightforward. You maintain one codebase across phones, tablets and desktop. You skip the review queue and the store's cut. You ship a fix on a Tuesday afternoon without waiting for anyone's approval. And the performance side holds up for the right kind of product. Debenhams rebuilt its mobile experience as a PWA and saw a 20% lift in conversions, with the journey from browsing to buying running two to four times faster than the experience it replaced, according to [Think with Google](https://www.thinkwithgoogle.com/intl/en-gb/success-stories/global-success-stories/debenhams-progressive-web-app-boosts-speed-conversions-and-revenue/). So for a catalogue-led or content-led product, a PWA does most of what people want from an app. The work is in being honest about what sits outside "most", because that's where the money and the goodwill go. ## Device and Hardware Features You Cannot Reach Browsers have been given access to more of the phone over the past few years. Camera, microphone, geolocation, orientation sensors and file pickers are all reachable now. The gap sits in the parts of the device that run while nobody's looking, and in the hardware that needs a long-lived connection. #### What PWAs cannot do on hardware Background processing is the big one. A native [app can wake up, fetch something](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need) and go back to sleep. A PWA mostly can't, so anything that depends on activity while the app is closed gets weaker. | Capability | PWA on Android | PWA on iOS | Native app | | --- | --- | --- | --- | | Push notifications | Yes | Home screen install only | Yes | | Bluetooth devices | Partial | No | Yes | | Background location | No | No | Yes | | NFC reading | Partial | No | Yes | | Background sync | Yes | No | Yes | | Widgets and watch apps | No | No | Yes | Write down every feature that has to run while the app is shut. If that list has more than two items on it, a PWA is fighting the platform rather than using it. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## The iOS Problem: Why Safari Changes the Calculation Outside the EU, every browser on an iPhone runs on Apple's engine underneath. Chrome on iOS is Safari wearing a different coat. So the capabilities of your PWA on iPhone are set by WebKit, whatever browser your user prefers. > Every browser on an iPhone runs Apple's engine, so your PWA lives by Safari's rules. That matters in a few practical ways. Push notifications work, but only after someone has added the app to their home screen, which is a step most people never take. There's no install prompt, so the user has to find the share sheet and choose the right option. And Safari is aggressive about clearing stored data for sites that haven't been opened in a while, which can quietly empty the cache you were relying on. #### Progressive web app limitations on Safari For a UK lifestyle brand with a heavily iPhone audience, this reshapes the business case. Your cheaper build is cheapest on the platform where fewer of your customers are. Your push channel depends on a manual install step. And the things you cached for offline use are subject to a housekeeping rule you don't control. None of that rules a PWA out. It does mean the iPhone experience needs designing as its own thing rather than assumed to match Android. ## Offline Behaviour: Where PWAs Break at the Worst Moment Simon was at an airport and couldn't get his boarding pass out of a flight app. The ticket data was already downloaded and sitting on the phone. The app put a no-connectivity error in front of it anyway, so he had to prove he'd paid, wait, and get a ticket written out by hand. Something that should have been a pleasant start to a trip turned into a stressful half hour at a desk. That failure had nothing to do with PWAs. It's a connectivity check wrapped around static information, and it's the single most damaging offline mistake a product can make. A PWA just makes it easier to repeat, because [the browser's storage is more fragile](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) and the default behaviour of a web page is to ask the network first. Developers rate this highly for good reason. Offline functionality is seen as very important by 78% of enterprise developers choosing a mobile platform, according to a [LinkedIn Pulse survey roundup](https://www.linkedin.com/pulse/survey-results-developers-weigh-ideal-rapid-mobile-groden-morrison#:~:text=Of%20primary%20importance%20by%20a,%20of%20all%20developers%20surveyed). The split we work to is simple. Passive things people read, like itineraries, saved tickets, maps and order history, should be offline first. Anything transactional should either queue for later or fail with a message that tells the truth. ## Storage Limits and Data That Disappears Without Warning A native app owns its slice of the device until someone deletes it. A PWA borrows space from the browser, and the browser hands that space back when it feels like it. Quotas vary by platform, by how much free space the phone has, and by how recently the person used your site. On iOS the clearing is more eager. On Android it's generally more generous, though the phone will still reclaim storage under pressure. So the data you cached is held on terms you don't set. The product has to behave sensibly when it's gone, which means knowing the difference between data that can be refetched quietly and data the user believes they saved. - Cached catalogue pages, which are cheap to rebuild and safe to lose. - Saved items and wishlists, which feel like the user's property and need a server copy. - Half-finished forms, which cause real annoyance when they vanish. - Tickets, codes and confirmations, which should never depend on local storage alone. Test the storage-cleared state deliberately. Wipe site data, reopen the app cold and watch what a returning customer sees. That screen is part of your product whether you designed it or not. ## Performance, Battery and the Feel of the Thing PWAs are small, and that's a genuine advantage. An app weighing close to 10MB as a native build can come down to roughly 500KB as a progressive web app, according to [pCloudy](https://www.pcloudy.com/blogs/types-of-mobile-apps/). On a cheap handset with a full photo library, that difference decides whether someone installs anything at all. The gap is in feel rather than speed. Native apps get the platform's own scrolling physics, gesture handling and animation timing for free. In a browser you rebuild those, and the rebuilt version is usually a little behind. Scroll momentum doesn't quite match. The keyboard pushes the layout around. A swipe gets caught by the browser's back gesture instead of your carousel. In the first three or four seconds of use, this is [what people are judging](https://weareaffective.com/learning-centre/why-do-some-apps-feel-easy-while-others-feel-hard). Simon calls that window immediate abandonment, and the triggers are sluggish interactions, slow loading and anything that freezes. Nobody writes a review about frame pacing. They just decide the thing feels cheap and go elsewhere. Heavy animation and constant background polling in a browser also drain the battery faster than the equivalent native work, which matters most for products people keep open for long stretches. ## Authentication, Security and Regulated Products We worked on an anonymous messaging app where we had to put authentication right at the front door. Messages were anonymous to users inside the product, but we needed to tie every message back to a real account on the back end in case of abuse or harassment. That ran against our usual preference for letting people in before asking them to sign up, and we did it because the legal position left no choice. > Some products need identity at the front door, and the browser gives you less to work with. Products with that kind of obligation sit awkwardly on the web. Passkeys and WebAuthn cover biometric sign-in well now, so Face ID and fingerprint login are fine. What you lose is everything below that layer, including device attestation, certificate pinning, tamper detection and secure storage inside the phone's own hardware. For a skincare brand selling moisturiser, none of that matters. For anything carrying age restrictions, health data, payments held on file or identity checks, your security team will ask questions a browser can't answer well. That's worth establishing before the build starts rather than during a compliance review. ## Discovery, Installation and Life Outside the App Stores Skipping the app store removes a gatekeeper and a 30% cut. It also removes a shop window. Nobody browses a store category and stumbles across your PWA, and you get no "install" button in a familiar place. Instead there's a share sheet and a menu item, and the drop-off at that step is steep. What you get in return is the open web. A PWA is a link, so it can be indexed, shared in a message, opened from an email and found through search. Flipkart drives half of its new customer acquisition through its PWA, and nearly 60% of its PWA visitors had previously uninstalled the native app to free up storage, according to the [Economic Times](https://tech.economictimes.indiatimes.com/news/internet/for-flipkart-this-app-makes-rural-connect/59676200). Reach of that kind is real. The ratings problem is subtler. Without a store listing you have no public score, so you have to collect sentiment yourself. A client of ours added a rating prompt that fired the second someone opened the app, before they'd done anything or seen any value. The scores it produced told them nothing. Ask for a rating after a good moment, like a delivery confirmed or a plan completed, and never on launch. ## The Hidden Cost of Working Around a Platform Constraint On an alcohol buying and selling platform we built, we were pushed into embedding web elements inside the product instead of building a proper API layer. It looked like the cheaper route at the point of decision. Across the length of the project it added roughly 20% more work, because every embedded piece needed its own handling, its own testing and its own set of fixes when something underneath changed. The budget stayed where it was, so the extra work came out of scope. We dropped features towards the end of the project to make the numbers hold. The client got the platform, and they got less of it than they'd planned for. Workarounds behave this way. A single one is manageable. Five of them compound, because each adds surface area to maintain and each makes the next change slower. By the time anyone totals it up, the saving that justified the choice has gone. That's the real shape of PWA limitations on a balance sheet. The browser can usually be made to do the thing. The cost appears in the months afterwards, spread across tickets nobody connects back to the original decision. ## Feature Parity Is Not the Same as Being Chosen A feature list is a poor predictor of adoption. Matching a competitor's capabilities, or beating them, does very little on its own. What decides things is how people [feel at the moment they use the product](https://weareaffective.com/learning-centre/what-are-the-best-examples-of-micro-interactions-in-popular-apps), what they're actually trying to do, and the context they're in while they do it. A feature that works beautifully in one setting fails when lifted into another. We saw this play out on a dating app. The client invested heavily in onboarding verification, because keeping fake accounts out was the whole proposition. They chose to skip discovery on the messaging side, so messaging got built in a generic way. The result was a [product that contradicted itself](https://weareaffective.com/learning-centre/why-80-percent-of-business-apps-fail-and-how-to-be-in-the-20-percent), because the messaging allowed exactly the automated, fake behaviour the verification existed to prevent. The connection to PWAs is this. Teams often frame the decision as a capability checklist, asking which boxes the browser can tick. That question skips the part that matters, which is whether the [app architecture design](https://weareaffective.com/app-architecture) holds together in the specific moments your customers care about. A PWA that does six things really well beats a PWA that does fourteen things in a lifeless way. Doing a limited set of features very well is almost always the better trade. ## When a Technical Limit Quietly Rewrites the Product We worked on a currency exchange product that started out as a remote transfer model. Platform and regulatory constraints forced a pivot to in-person, location-based exchange, where two people meet to make the swap. Some of what came out of that was good. Seeing pins on a map and watching movement gave the product a social feel it hadn't had before, and meeting someone face to face added something the remote version lacked. > A platform limit rarely stays technical, it changes the product and then changes who it's for. But requiring physical proximity took away the scale. People could only transact with others nearby, which shrank the pool of possible partners and undercut the original idea of wide, easy reach. The product that launched served a different, smaller need than the one that was planned. That's what a hard constraint does. It starts as an engineering note and ends up altering the market you're in. When a PWA can't support background location, or offline ticketing, or a connected device, the team doesn't usually abandon the feature. They redesign around it, and the redesign quietly moves the product somewhere else. ## Questions to Settle Before You Commit The choice gets much easier once a few things are written down. We'd work through these in order, because each answer narrows the next. 1. What does your audience actually use? If most of your customers are on iPhone, Safari's rules are your rules. 2. Which moments are the high-stress ones? Check-in, retrieving a ticket, finding an order, paying. Those need to work when the signal doesn't. 3. Does anything need to run while the app is closed? Background tracking, syncing or device connections push you towards native. 4. What are your security and legal obligations? Age checks, health data and stored payments all raise questions the browser answers poorly. 5. How many workarounds are you accepting on day one? Count them honestly, then add the maintenance. 6. Where does discovery come from? Search and sharing favour a PWA. Store presence favours native. Answer question two before anything else. The highest-stress moment in your product sets the technical floor, and everything else can flex around it. A [hybrid answer is often the sensible one](https://weareaffective.com/learning-centre/the-hidden-complexity-of-delivery-apps-what-every-business-owner-should-know). Catalogue, content and account management work well on the web, while a smaller native app handles the parts that need the device. That splits the cost along the same line the constraints already fall on. ## Conclusion Progressive web app limitations aren't reasons to avoid PWAs. They're the terms of the deal. You get a cheaper build, faster releases, a much smaller download and reach through plain links. You give up background work, deep hardware access, hardware-backed security, dependable local storage and a measure of control over how it all feels on an iPhone. The projects that go wrong are the ones where nobody priced the second list. We've watched workarounds eat 20% of a project's capacity on an alcohol platform and take features off the end of the plan. We've seen a location constraint turn a currency exchange product into something smaller than it set out to be. And standing in an airport with a boarding pass trapped behind a connectivity error is a decent reminder of what a technical shortcut feels like from the other side. Start with the moments that carry the most weight for your customers, work out what those moments need, and let the technology follow. That ordering costs nothing at the planning stage and saves a great deal later. If you're weighing up a PWA against a native build for a lifestyle brand, [let's talk through where your product's pressure points are](https://weareaffective.com/get-started). ## Frequently Asked Questions What exactly is a progressive web app? A progressive web app is a website with a few extra parts added, namely a service worker that caches pages, a manifest file that tells the phone which icon to use and how to open, and delivery over HTTPS. Together these let the site sit on the home screen, open full screen without a browser bar, and load quickly on a patchy connection. Why would a business choose a PWA over a native app? The main attractions are one codebase across phones, tablets and desktop, no app store review queue, and no store commission on sales. You can also push a fix out on a Tuesday afternoon without waiting for anyone's approval. Is there real evidence that PWAs perform well commercially? Yes, for the right kind of product. Debenhams rebuilt its mobile experience as a PWA and reported a 20% lift in conversions, with the journey from browsing to buying running two to four times faster than the experience it replaced. Which hardware features can a PWA actually reach? Browsers have opened up a fair amount of the device in recent years, including the camera, microphone, geolocation, orientation sensors and file pickers. The gaps tend to sit in the parts of the phone that run while nobody is looking and in hardware that needs a long-lived connection. What is the single biggest hardware limitation of a PWA? Background processing. A native app can wake up, fetch something and go back to sleep, whereas a PWA largely cannot, so any feature that depends on activity while the app is closed becomes weaker or stops working altogether. How do PWA capabilities differ between Android and iOS? Android is the more generous of the two, supporting push notifications and background sync, with partial support for Bluetooth and NFC. On iOS, push notifications only work once the app is installed to the home screen, and Bluetooth, NFC and background sync are not available at all. Are there features that no PWA can offer on either platform? Yes. Background location, widgets and watch apps are unavailable on both Android and iOS, so if any of those sit at the heart of your product, a PWA will not cover it. Native remains the only route for those capabilities. How should I decide between a PWA and a native app? Treat it as a product decision rather than a purely technical one. Work out which moments in your user journey can afford to be slightly worse, and if those moments involve background activity, connected hardware or a user under real pressure, native is likely to be the safer choice. ## Related Articles [![Real World Database Costs What Youll Actually Pay for Your App](https://weareaffective.com/hubfs/learning-centre-images/real-world-database-costs-what-youll-actually-pay-for-your-app.webp)](https://weareaffective.com/learning-centre/real-world-database-costs-what-youll-actually-pay-for-your-app) ### [Real World Database Costs: What Youll Actually Pay for Your App](https://weareaffective.com/learning-centre/real-world-database-costs-what-youll-actually-pay-for-your-app) Developers and product teams consistently underestimate what a database will actually cost to run.... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![Will My PWA Work Offline Like a Native App?](https://weareaffective.com/hubfs/learning-centre-images/will-my-pwa-work-offline-like-a-native-app.webp)](https://weareaffective.com/learning-centre/will-my-pwa-work-offline-like-a-native-app) ### [Will My PWA Work Offline Like a Native App?](https://weareaffective.com/learning-centre/will-my-pwa-work-offline-like-a-native-app) Simon was standing at an airport gate, boarding pass already downloaded, flight about to close, and... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![What Is Behavioural Debt? A Definition for Product Teams](https://weareaffective.com/hubfs/learning-centre-images/what-is-behavioural-debt-a-definition-for-product-teams.webp)](https://weareaffective.com/learning-centre/what-is-behavioural-debt-a-definition-for-product-teams) ### [What Is Behavioural Debt? A Definition for Product Teams](https://weareaffective.com/learning-centre/what-is-behavioural-debt-a-definition-for-product-teams) Product teams talk about technical debt constantly. They track it, budget for it, and schedule... by [Simon Lee](https://weareaffective.com/learning-centre/author/simon-lee) [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.