Publishing your store app to the App Store and Play

By Abdalla Kamesh · Updated September 25, 2026 · Published September 8, 2026 · 5 min read

Building the app is the part people worry about. Submitting it is the part that actually delays launches, because most of the work is administrative, some of it has waiting periods you cannot shorten, and the order you do it in decides whether you launch in a week or a month.

This is the whole path, in the order that avoids blocking.

Do this first: the accounts

Start today, before the app exists, because these two items contain the only unbuyable delays in the process.

Apple Developer Program — $99/year. An individual enrollment is usually quick. An organization enrollment requires a D-U-N-S number that matches your legal entity name exactly, and that typically takes about a week to obtain and verify. Mismatched names are the classic stall: “Smith Trading LLC” and “Smith Trading, LLC” can be treated as different entities.

Google Play Developer account — $25, one time. Two paths with very different timelines:

Personal account created after 13 November 2023: Google requires you to run a closed test with at least 12 testers opted in for 14 continuous days before you may apply for production access. Fourteen continuous days — a tester dropping out resets your progress. This is the single longest fixed delay in the entire process, and it starts only once you have a build to test.
Organization account: needs a D-U-N-S number, which Google notes can take up to 30 days.

Read that again and note the implication: if you want to be live in two weeks, you needed to start the account paperwork three weeks ago. If you cannot, Android has an escape hatch — a signed direct APK your customers install from a link, which needs no Play account at all and is how most StoreToNative merchants test with real customers while the store paperwork runs.

Then: get your store submission-ready

A reviewer’s experience of your app is mostly an experience of your store. Before you submit:

HTTPS everywhere, with no mixed-content warnings.
A live payment gateway in production mode. A reviewer who cannot complete a purchase rejects.
Working permalinks and a reachable REST API.
No maintenance-mode or coming-soon plugin intercepting requests.
A real privacy policy URL and a support URL that resolves.

Our WordPress companion plugin runs 14 store-readiness checks covering exactly this class of problem, because every one of them surfaces as an app rejection rather than as a store error.

The listing assets, per platform

Gather these once and reuse them. Both stores want variations of the same things:

Asset	Apple	Google Play
App name	30 characters	30 characters
Subtitle / short description	30 characters	80 characters
Description	4,000 characters	4,000 characters
Keywords	100-character field	none (indexed from description)
Screenshots	Required per device size	Phone required, tablet recommended
Icon	1024×1024, no transparency, no rounded corners	512×512
Feature graphic	—	1024×500
Privacy policy URL	Required	Required
Support URL	Required	Required
Age rating	Questionnaire	Content rating questionnaire

Two things worth knowing. Apple’s keywords field is not visible to users — it is a comma-separated 100-character list, and repeating words from your app name wastes it. Google has no keyword field; it indexes your description, so the description has to read well and contain the words people search.

The privacy and data questions

Both platforms require a declaration of what data your app collects, and both make you answer per data type: identifiers, contact info, purchases, location, usage. Getting this wrong is a rejection and, at worse, a policy problem later.

For a WooCommerce store app, the honest answers are usually: contact information and purchase history (you have customers and orders), identifiers for push notifications, and usage analytics. What matters is that the answer matches reality — including anything your analytics or push provider collects on your behalf.

StoreToNative computes the data-safety answers for you from what your app actually has enabled, which removes the guessing but does not remove your responsibility to read them. Read them.

Review notes: the free win

App Review notes is a plain text box and the highest-leverage 200 words in the whole submission. Include:

Demo credentials, if any part of the app needs an account. Even if browsing is open, give them a test login so they can see order history.
A test product that can be bought cheaply, and confirmation that a real card will be charged (or that your gateway is in a mode where it will not).
A one-line explanation of the checkout architecture: the storefront is native, and the payment step runs on the store’s own secure checkout with the merchant’s existing gateways, because these are physical goods.
Anything region-locked, with a way around it.

That third bullet preempts the most common reviewer question about store apps.

Submission day, in order

Build and upload. In StoreToNative, a signed Android build takes about seven minutes; iOS builds are produced and uploaded to your own App Store Connect record.
Fill the store listing from the assets you gathered.
Answer the privacy questionnaires. Both platforms.
Set pricing and availability. Free app, all territories you actually ship to.
Attach review notes. With demo credentials.
Submit — Apple first if you are doing both, since its review is the less predictable one.
Watch the email, and answer any reviewer question the same day. Threads go stale fast.

What to expect

Review times move, and anybody quoting you a number is quoting an average that may not apply. Plan for days, not hours, on both platforms, and plan for one round of questions on a first submission. That is normal, not a failure.

Two failure modes worth preparing for. A Guideline 4.2 rejection on a first submission means the reviewer read the app as a repackaged website — architectural, and covered in will Apple reject my WooCommerce app. A 2.1 incomplete information rejection is almost always missing demo credentials or an unanswered privacy question, and is usually a same-day fix.

We cannot promise you an approval; nobody honestly can. What a guided submission does is remove the class of rejection that comes from a form filled in wrong.

After you are live

Turn on order-status notifications before you promote the app, so early adopters get the good version.
Put the install path everywhere: a smart banner on your mobile site, a QR code on packing slips, an app-only coupon.
Wait for reviews before you chase them. Ratings from customers who have actually received an order are worth more than ratings from people you nagged on day one.

Related reading

Guided publishing to both stores is on every StoreToNative plan, including the checklist and the computed data-safety answers. See how it works.

Help page: Publish to the App Store, the step-by-step guide.