Your Progressive Web App already installs from the browser. Icons look right. Splash screen matches the brand. Then a client asks the question every WordPress agency hears: “Can people also find this in Google Play and the App Store?”
That request turns expensive if you treat it like a native rewrite. Two codebases, two signing pipelines, two review queues. Most sites do not need that. They need a third install path that still points at the same WordPress site: store listings built from the PWA they already run.
Progressify is the DaftPlug PWA plugin. This post is about App store builds: no-code bundles for Google Play and the App Store, an Android app bundle built and signed for you, an iOS build prepared for App Store submission, plus store screenshots and listing metadata generated from the same setup. Not install prompt rules, not push, not offline sync, not skeleton loaders or toast messages, not the bottom tab bar. For how installs perform once people already have the PWA, keep WordPress PWA install analytics by device, browser, and country nearby.
What Progressify actually ships here
Stay inside the real feature set:
- No-code bundles for Google Play and the App Store from the same WordPress site
- Android app bundle built and signed for you
- iOS build prepared for App Store submission
- Store screenshots and listing metadata generated so you are not starting store forms blank
Manifest, icons, splash, and browser install are prerequisites. Mention them only as the foundation. This post is not about prompt timing, push campaigns, background sync, skeleton/toast UI, or tab bar chrome. Those live elsewhere in Progressify. Here the job is packaging: take an installable site and produce store-ready Android and iOS builds without a second app team.
Why store builds matter when you already have a PWA
Browser install covers a lot. Android Chrome and modern iOS can put your PWA on the home screen. Plenty of content sites and shops stop there and win.
Store presence solves a different problem: discovery and trust for people who never open your URL first.
Search inside the stores. Someone looking for “your brand + app” searches Play Store or App Store before they search Google for your site. If you only have a PWA, that search returns nothing or a competitor.
“Install from store” habits. Some users and some IT policies still treat store listings as the only legitimate path. A signed package answers that habit without forcing a React Native rewrite.
One site, three install paths. Progressify’s product page is explicit: one site, three install paths. Browser install stays. The PWA stack stays. Store builds sit on top so you are not choosing between “web only” and “native forever.”
Cost reality. Native quotes start in five figures before review. A no-code path from the WordPress site you already operate is the difference between “maybe next year” and “ship a listing this quarter.” You still need Apple and Google developer accounts. You still pass their review. You do not need a second product codebase.
If the PWA is half finished (broken icons, missing HTTPS, no service worker), fix that first. A store wrapper around a broken install experience just ships the same broken experience through a different door.
How to generate store builds in wp-admin
Assume Progressify is installed, HTTPS works, and the PWA core (manifest, service worker, icons, name, theme colour) already installs cleanly from the browser.
1. Confirm the PWA is installable before packaging
In wp-admin, open Progressify and verify app name, icons, splash/theme colour, and a registered service worker. Smoke-test on a real phone:
- Android Chrome: confirm the install flow works.
- iOS Safari: confirm Add to Home Screen launches cleanly.
- Open from the home screen once and confirm standalone feels intentional.
If browser install fails, stop. Do not generate store packages yet.
2. Open Progressify App store builds
Find the App store builds section. This is the no-code path for Google Play and App Store packages. Keep display name and icons consistent with the PWA manifest so people do not install two differently branded things.
3. Generate the Android app bundle (built and signed for you)
Run the Android path. Progressify builds and signs the Android app bundle for you. Play submission expects an AAB, and signing is the step that usually stalls non-native teams.
When it finishes, download the package, store it somewhere durable, and note the application ID. Changing that ID after the listing exists is painful. Progressify does not replace Play Console registration or review. It replaces hiring a mobile shop to wrap the site.
4. Generate the iOS build prepared for App Store submission
Run the iOS path next. Progressify prepares an iOS build for App Store submission. You still need Apple Developer Program membership and App Store Connect work. You do not need to write Swift to get a first package out of the same WordPress site.
Confirm display name and icon match the PWA, download the prepared build, then move it through your normal Apple upload flow. Plan for Apple review to take longer than Android and to ask what the app is if it is clearly a store-wrapped site.
5. Use generated screenshots and listing metadata
Progressify also generates store screenshots and listing metadata. Treat that as a starting kit. Edit copy so it sounds like your brand. Replace any screenshot that looks outdated after a homepage redesign. A signed build with a one-line blurb and a blurry screenshot still fails the human test even if the upload succeeds.
6. Submit, then verify end to end
Upload Android to an internal testing track first. Upload iOS through your Apple pipeline. Install from each store on a clean device that never used the PWA. Confirm the listing opens your packaged app, login/cart/content still work, and branding matches the PWA name. Keep browser install live. Store builds are an extra path, not a replacement.
What good looks like
- Browser install still works for people who never open a store.
- Play Store has a signed Android app bundle you did not hand-roll.
- App Store Connect has an iOS build prepared for submission, not a blank Xcode project.
- Screenshots and listing metadata exist, then get edited for brand voice.
- App name, icon, and colours match across PWA, Play, and App Store.
- You can tell a client: same WordPress site, no second codebase, store presence included.
If a store install lands on a broken theme or HTTPS warning, that is a site problem. Fix the site, refresh assets if branding changed, resubmit.
Pitfalls (the ones that bite)
Skipping the PWA smoke test. Packaging a site that fails in Chrome wastes a review cycle.
Assuming Progressify replaces Apple/Google accounts. You still pay those fees and pass those reviews.
Inconsistent branding. Different names or icons across PWA and stores make people assume a clone.
Ignoring wrapped-site review expectations. Be honest in the listing. Have a support URL and privacy policy ready.
Skipping internal testing. Ship to yourself before production tracks.
Expecting store packaging to fix a half-configured PWA. Push, offline, and prompts are separate Progressify work.
One-and-done screenshots. Refresh listing media when the homepage redesign ships.
Practical checklist before you call it done
- Confirm HTTPS, manifest, icons, and service worker install cleanly on Android and iOS.
- Open App store builds only after browser install works.
- Generate the signed Android app bundle and archive it.
- Generate the iOS build prepared for submission and archive it.
- Edit generated screenshots and listing metadata for brand voice.
- Upload to Play internal testing and App Store Connect test tracks first.
- Install from each store on a clean device and click primary journeys.
- Keep browser install available so you still have three paths.
- Document package IDs and signing notes somewhere the next human can find.
- After approval, spot-check that store installs still hit the live site correctly.
Takeaway
A WordPress PWA that only installs from the browser is already ahead of most sites. Store builds answer the next request: put it in Google Play and the App Store too, without hiring a native team to rebuild what you already run.
Progressify generates no-code Android and iOS packages from that same site: an Android app bundle built and signed for you, an iOS build prepared for App Store submission, plus screenshots and listing metadata to start the store forms. Fix install in the browser first. Then package. Then submit.
One Pro membership unlocks Progressify plus Lightify, Generatify, Rankify, and Snapshotify. New Pro plugins join existing memberships. Plans differ by site count only (Pro $37.99 for 1 site, Pro Plus $74.99 for 5, Pro Max $138.99 for 100), with a 14-day money-back guarantee. See pricing when you are ready to add store doors next to the PWA you already ship.
Generate the builds. Upload to internal tracks. Install once from each store. When the listing opens the same WordPress product people already know, you closed the “do you have an app?” conversation without a second codebase.