Can I Put My Pwa in the App Store and Google Play Store?

You can put a PWA in the app store. Google Play will take one with a thin native shell wrapped around it, and Apple will take one too, as long as the app does enough on its own to count as an app rather than a bookmark. That's the honest short answer, and the rest of this piece is about the gap between "you can" and "you should".

The stores are not neutral shop windows, they're gates run by companies with their own commercial interests.

The gap matters because the stores are not neutral shop windows. They're reviewed, gated, and run by two companies with their own commercial interests. We've had a client's product rejected by Apple so many times, on shifting grounds, that they ran out of money and walked away from the whole thing. That story's later on, and it changed how we talk to clients about store distribution.

So this is a practical guide. What each store actually accepts, what a Trusted Web Activity is and how it gets your PWA on Google Play, why Apple turns wrapped web apps away, what you give up inside a wrapper, and when the sensible choice is to stay on the open web and say so out loud.

The Short Answer for Each Store

Google and Apple sit in very different places on this. Google has spent years building tooling to help you publish a PWA to the app store it owns, because a web app that works well is still a web app running in Chrome, and Chrome is theirs. Apple has no equivalent tooling and no interest in making one.

On Google Play the route is documented and supported. You build a small Android project that opens your site full screen with no browser chrome, prove you own the domain, and submit it. Thousands of apps in Play work exactly this way.

On Apple's side there's no official PWA path at all. You wrap your web app in a native container and submit that, and the review team judges it on whether it behaves like an app. A thin wrapper that only loads a website gets refused. One that uses the camera, stores data properly, handles notifications and works when the signal drops has a real chance.

What Counts as a PWA to Apple and Google

Technically, a progressive web app is a website with three things bolted on. It's served over HTTPS, it ships a web app manifest that tells the device its name, icon and how it should open, and it registers a service worker that can cache files and respond when the network can't.

Google treats that definition as a first-class thing. Chrome will prompt people to install your PWA to their home screen, Play accepts it as the basis of a listing, and Play's own quality checks assume web content inside the shell.

Apple's quieter version

Safari supports the same standards. Add to Home Screen gives you a full-screen icon, and web push works for installed web apps. What Apple doesn't do is treat any of this as a route into its store. For review purposes your manifest and service worker count for nothing. The reviewer opens the app, uses it for a few minutes, and asks one question, which is whether this could just be a website.

That difference shapes everything that follows. On Android you're submitting a known pattern. On iOS you're submitting a native app that happens to be built mostly from web pages, and the burden of proof sits with you.

Publishing a PWA on Google Play with Trusted Web Activity

A Trusted Web Activity is an Android container that opens your site using the user's own Chrome engine, full screen, with no address bar. It isn't a web view bolted into an app. It's the real browser, so your PWA behaves identically to how it behaves on the open web, with the same storage and the same service worker.

Getting a PWA on Google Play through a TWA follows a clear order.

1. Host the PWA on HTTPS with a valid manifest and a working service worker.
2. Generate the Android project, usually with Bubblewrap or PWABuilder.
3. Publish a Digital Asset Links file on your domain so Android knows you own both sides.
4. Test the back button, deep links and the offline state on a real device.
5. Add Google Play Billing if you sell digital goods inside the app.
6. Submit with screenshots taken from the running app, not from your desktop site.

Miss the Digital Asset Links step and the app opens with a browser bar across the top, which looks exactly as unfinished as it sounds.

Forget the asset links file and your app opens with a browser bar across the top, which looks exactly as unfinished as it sounds.

Play's review is lighter than Apple's, though it isn't a rubber stamp. Crashes, broken back behaviour and listings that don't match the product all get picked up.

Getting a PWA into the Apple App Store

Apple's rule is guideline 4.2, minimum functionality. An app that repackages a website, with no device capability and nothing a mobile browser couldn't do, gets rejected. So the work isn't really about wrapping. It's about deciding which parts of your product deserve to be native, and building those properly.

Before you write a line of wrapper code, list every device capability your product genuinely uses. If the list is empty, you don't have an App Store app yet, you have a website with an icon.

What native capability looks like

On the performance coaching survey app we built, the presenter's iPhone generated the QR code for the audience to scan using iOS's own built-in libraries. Nothing was stored outside the app, so the code only ever existed live, in the room, while the session was running. When the presenter marked the survey finished, no further responses could be recorded.

That's a small thing, and it's exactly the sort of thing a reviewer recognises as app behaviour. The device is doing work. The camera, the local generation, the hard stop at the end of a session, all of it depends on being native.

Apply the same thinking to a wrapped PWA. Push notifications, camera, offline storage, biometric sign-in, share sheets, widgets. Pick the ones your product truly needs and build them natively around the web content.

Why Apple Rejects Wrapped Web Apps

Rejection is normal and you should plan for it. Apple's own figures show 1,931,400 rejections out of 7,771,599 submissions in 2024, which is close to a quarter of everything sent in, according to Apple, 2024. Wrapped web apps sit in a category that attracts more attention than most.

The reasons repeat. Guideline 4.2 catches apps with no native capability. Guideline 2.1 catches apps where the reviewer hits a broken state, a blank screen or a login they can't get past. Apps that send people out to a browser to pay, or to sign up, get flagged too. Anything that looks like a template, built from the same shell as fifty other listings, has a hard time.

Give the reviewer a path

Reviewers work fast and they test on real hardware in conditions you don't control. Give them a working demo account with real data in it. Write review notes that say plainly what the app does and which parts use the device. Make sure the first screen after launch shows something, even on a poor connection, because a spinner is the easiest rejection a reviewer can write.

Build the submission for a tired person with a queue of apps to get through, and most of these problems disappear before they start.

When Rejection Has Nothing to Do With Your Code

We worked on a peer-to-peer currency exchange product, where travellers could swap leftover foreign currency with each other at interbank rates and skip the commission. Apple rejected it. We fixed what they asked for. Apple rejected it again, on new grounds. That cycle repeated.

Eventually Apple said the product could be used for money laundering and criminal activity. We capped every transaction at €150, which should have ended the argument outright, and the app was rejected again. The client had already spent real money on legal counsel and compliance work by that point. They ran out of budget and the product died.

Apple Pay and other payment services launched a little while afterwards. We believe the two things were connected.

If your product competes with something the platform owner sells, build a web route that works on its own from day one. Don't let a single review queue hold your entire launch.

The part worth taking from that is structural. There's no effective way to challenge a reviewer who keeps inventing fresh objections, and no neutral referee. A well-funded incumbent can keep a compliant competitor off the store indefinitely, and the competitor pays for every round. A PWA on the open web doesn't remove that risk, and it does mean the risk can't kill you.

Compliance You Need Before You Submit, Not After

On that same currency exchange product, we built the transfer mechanism well and didn't factor in anti-money-laundering rules at all. Apple raised it first, which is a bad way to find out. We went back and retrofitted several layers, with more stringent Know Your Customer checks, tighter transfer security, and hard limits on how many transfers any two people could make between them.

Retrofitting compliance is slow and expensive, and it tends to land on parts of the product you've already designed around.

Finding out about your compliance obligations from a reviewer is the most expensive way to learn them.

The opposite case came up on a proof of concept we did for a company building an app for sharing memories with audio attached. We started with Spotify, which had no proper API for the short clips we needed, and which would have forced every user to hold a Spotify account. Working around that would have meant custom technical workarounds just to stay within Spotify's rules.

We moved to Deezer instead. Deezer had a full API, supported clips, and didn't require users to be logged in. Using an official API the way the provider wants it used left us fully compliant with no workarounds, and the architecture got simpler at the same time. Compliance and simplicity pulled in the same direction.

What You Lose in the Wrapper

A wrapper buys you a store listing. It costs you a few things that are easy to overlook until launch week.

• Instant updates. Web content still updates freely, but anything native in the shell goes through review.
• Full device access. You only get the capabilities you've specifically built bridges for.
• Clean analytics. Sessions split across web and store installs, and attribution gets messy.
• Simple releases. You now maintain a web build, an Android shell and an iOS shell.

Notifications are where wrappers earn their keep, and also where products most often get it wrong. Going native gives you the system permission prompt, and that prompt is a one-shot. Say no once and getting back in front of that user is painful.

Asking before you ask

The fix is framing, not engineering. Explain what the notifications are for, in your own words, on your own screen, and let the person say yes before the system prompt ever appears. Asking permission properly makes people feel they have control, and when they feel in control they're more bought in, more engaged and more likely to stay. The technical end result is identical. The response rate isn't.

Offline Functionality: What Reviewers Actually Look For

A reviewer will put your app in airplane mode. What they see next decides a lot. A blank screen with a spinner reads as an unfinished product. A screen that says what's happening, and still shows something useful, reads as a considered one.

Google Maps and Apple Maps handle this about as well as anyone. There's clear mode signposting, so you always know whether you're looking at live or saved data. They prompt you to download an area before you lose signal, and they quietly cache the places you visit often. Best of all, the detail degrades gracefully with zoom. Go right down to street level on data you never downloaded and the detail isn't there, and you're still never dumped on a blank map with no idea where you are.

Test your offline state by actually turning the signal off on a real phone, in the place your users will be. The simulator lies about how this feels.

The temptation is to add offline support because the technology allows it. Resist that unless it genuinely matters to the product. A bad experience costs you the return visit, and a half-built offline mode is a reliable source of bad experiences. Doing a small number of things extremely well beats cramming features in at lower quality.

Who Owns the Developer Account and Why It Matters

This is the least glamorous decision in the whole process and one of the ones that bites hardest. On a social football product we worked on, the client set up App Store Connect themselves, so the Account Holder role sat with them, registered in their name. They gave us admin access to most of the account.

We set up three internal testing groups. One for our team, one for the client, and one external QA beta group for the client's own testers. That structure let us control exactly which build went to which group through the deployment process, which matters when you're running fixes and new features in parallel.

As launch got closer, the client started going into the account and sending builds that had already been uploaded to whichever group they fancied. That caused problems. Because everything sat on their account, they had full access and there wasn't much we could do to stop it.

The ownership was right. The client should hold their own account, since the listing, the reviews and the revenue all belong to them. What we'd settle earlier now is who presses the buttons, which roles each person holds, and what the rule is for promoting a build between groups.

Store Fees, Payments and the Revenue Question

If you sell digital goods inside the app, the store takes a cut. In-app purchases through Apple or Google retain between 15% and 30% per transaction, according to SplitMetrics, with the lower rate applying to smaller developers and to subscription renewals after the first year.

Physical goods and services delivered in the real world are exempt, so a fashion retailer or a hotel booking app pays nothing on sales. A wellness brand selling a subscription programme inside the app pays. That single distinction decides whether a wrapper makes commercial sense, so work it out before you build anything.

Work out what the store takes before you build the wrapper, not after your first renewal cycle.

Revenue doesn't have to come from the sale itself. On the memory-sharing proof of concept, moving to Deezer gave us a search catalogue larger than Spotify's, and when someone wanted to hear a full track rather than a clip, there was a natural upsell to a Deezer subscription. That opened an affiliate referral line running alongside the product's own revenue.

It's worth asking that question of any product heading into a store. Where else does value flow, and can some of it flow back to you without going through the billing system?

Store Listings and the Users You Actually Want

We worked on a gifting and wishlist platform where the client was hesitant to spend anything on App Store Optimisation. Their thinking was that the product was social and group-based, so word of mouth would carry it. Referral does bring people in. What it doesn't do is tell them what they're getting.

Our view then and now is that the listing is the first screen of the product. The icon, the category, the first two lines of copy and the first screenshot all have to say plainly what this is, so someone can rule themselves in or out before they ever tap install. People who download after reading an accurate listing arrive already pre-sold.

Show your first screenshot and first two lines of copy to someone who's never seen the product, and ask them to describe what the app does. If they can't, the listing isn't ready.

The wrapper raises the bar

A wrapped PWA makes this harder, because a store listing sets an expectation of a native app. If the listing promises something slick and the first load is a slow web page, you've created a gap between the promise and the product, and that gap shows up as people deleting it within a day.

Staying Web-Only and Doing It Deliberately

Some products shouldn't be in a store at all, and choosing that on purpose is a strong position rather than a retreat.

We worked on a product aimed at African communities living abroad, built to help people stay connected with their home communities. It was technically viable and fairly straightforward to build. We ran a lot of focus groups with the target market and the result was clear, which was that the desire for that kind of product wasn't there. Separately, the devices commonly used in African countries at the time were limited enough that delivering half of the intended experience on them would have been very hard.

Both findings pointed the same way. The route to market follows from who the users are and what their phones can run, and no amount of store presence fixes a product people haven't asked for.

Web-only has real advantages. You ship when you want, you keep all your revenue, you work on any device with a browser, and nobody can remove you. For a lot of lifestyle products, a home-screen PWA with a well-handled install prompt does everything a store listing would, without the review queue or the cut.

Choosing Your Distribution Route

Four questions settle this for most teams, and they're worth answering honestly before anyone opens a code editor.

• Does the product use device capability that the web genuinely can't reach?
• Do your customers look for products like yours by searching a store?
• Are you selling digital goods, and can you live with the platform cut?
• Can you support three builds, or just one?

If the device answer is no and the search answer is no, stay on the web and put the saved budget into the product. If your buyers do search the stores, Google Play through a Trusted Web Activity is the cheapest way to find out whether that channel is worth anything, because the build is small and the review is manageable.

Treat iOS as a separate decision with its own budget. Getting a PWA in the app store on Apple's side means building genuine native capability, writing review notes, and having a plan for two or three rounds of rejection. That's a project, not a packaging exercise.

And sequence matters. Prove demand on the web, learn what people actually use, then wrap the version you know works rather than the version you hope will.

Conclusion

Both stores will take a PWA. Google Play makes it straightforward with a Trusted Web Activity, and Apple will accept a wrapped web app that does real work on the device, judged by a reviewer who's looking for a reason to say no.

The harder question is whether the store earns its place in your plan. The currency exchange product we worked on was compliant, capped at €150 a transaction, and still never shipped, because Apple kept finding new objections and the client ran out of money. That's a risk you carry the moment a single review queue sits between you and your customers.

So decide on purpose. If device capability and store search matter to your customers, build for the stores properly, with native work that justifies the listing, compliance sorted before submission, and a listing honest enough that the people who install are the people you want. If neither matters much, stay on the web, keep your revenue, ship when you like, and spend the difference on making fewer things work beautifully.

If you're weighing up a store listing against staying web-only, we're happy to think it through with you. Let's talk about your app distribution plan.

Frequently Asked Questions