The rejections e-commerce apps actually get

Guideline 4.2 gets all the attention, and it deserves some of it. But most first submissions that come back are not architectural rejections — they are paperwork, and they are fixable the same day if you know what you are looking at.

Here are the eight, roughly in order of how often store apps hit them.

1. Incomplete information (Apple 2.1)

What it looks like: “We were unable to review your app as it requires a login” or a request for information you did not supply.

What causes it: no demo credentials, an unanswered privacy question, a missing support URL, or a feature the reviewer cannot reach.

The fix, same day: put demo credentials in App Review notes even if browsing does not require an account, so the reviewer can see order history. Add a note about what to buy for a test order. Answer every privacy question.

This is the most common rejection and the least serious. It is a form problem.

2. Minimum functionality (Apple 4.2)

What it looks like: “Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.”

What causes it: the app reads as a website in a frame. Page loads between screens, web-styled controls, thin functionality, or anything that reveals a URL.

The fix: architectural. Cosmetic additions rarely move it, which is why resubmitting the same app with a new splash screen wastes a fortnight. The full explanation.

3. Template and app-generation services (Apple 4.2.6)

What it looks like: a rejection citing 4.2.6, sometimes with a note about submitting under the content provider’s account.

What causes it: the app was submitted by a service rather than by you. Apps built from a commercialized template are rejected unless the content owner submits them.

The fix: your own developer account. Which means this is a vendor decision you make before the app exists, not a rejection you fix afterwards. Why this decides your vendor.

4. Data collection and storage (Apple 5.1.1)

What it looks like: a rejection about requiring registration, or requesting a permission without justification.

Two common causes for store apps:

• Forcing an account to browse. Apple requires that apps not force registration unless the core functionality needs it. Browsing a catalog does not. Let people shop, and ask them to sign in at checkout or to see their orders.
• Requesting a permission you do not need. Location, contacts, photo library. If a feature does not need it, do not ask.

The fix: allow guest browsing, and remove unnecessary permission requests. Usually a settings change.

5. Payments and in-app purchase (Apple 3.1.1)

What it looks like: a demand that purchases use in-app purchase.

When it is a genuine problem: if you sell digital content, subscriptions or anything consumed inside the app, Apple’s payment system generally applies.

When it is a misunderstanding: physical goods paid for through your own checkout are not in scope. If you get this rejection for a physical-goods store, respond with a clear explanation: the app sells physical goods shipped to the customer, and payment is processed on the merchant’s own website with the merchant’s existing gateways.

Prevention: one sentence in your review notes saying exactly that, before anyone asks. Why the payment step is on the web.

6. Misleading metadata (Apple 2.3)

What it looks like: a rejection about screenshots or description not representing the app.

What causes it: mocked-up screenshots showing screens or features the app does not have. A description promising something unbuilt. Promotional pricing in a screenshot that is no longer current.

The fix: real screenshots of the real app. Frames and captions are fine; fiction is not. Screenshot guidance.

7. Broken functionality (Apple 2.1 / Play policy)

What it looks like: “we found the following bugs,” with steps.

What causes it, for store apps, most often: something wrong with the store, not the app. An expired certificate, a payment gateway in test mode, a maintenance plugin, permalinks changed, the REST API blocked by a security plugin. The reviewer experiences your store misconfiguration as an app bug.

The fix: check the store before you submit. Our WordPress plugin’s 14 store-readiness checks exist for exactly this class of problem.

8. Google Play: data safety and policy declarations

What it looks like: a rejection or a warning about your Data safety section being incomplete or inconsistent with observed behavior.

What causes it: under-declaring. Most often, forgetting what a third-party SDK collects — analytics, push, crash reporting, or an ad network if you enabled one.

The fix: list every SDK, list what each collects, declare all of it. Also confirm your privacy policy describes the app and not only the website, and that an account-deletion route exists and works. The full pass.

The three that are same-day fixes

If you get 2.1 (incomplete information), 2.3 (metadata) or the Play data-safety rejection, you can usually respond within hours. Fix the specific item, reply in the same thread, and resubmit. Resubmission is not penalized.

How to reply to a reviewer

Four rules that make the second round go better:

1. Answer the specific guideline they cited, and say what you changed.
2. Be brief and factual. No arguing about whether the guideline should apply.
3. Reply the same day. Threads go stale, and a stale thread restarts the clock.
4. Include a screen recording if the reviewer described something you cannot reproduce. It is the fastest way to close a disagreement about behavior.

Preventing seven of the eight

A pre-submission pass, in order:

• Demo credentials and a test-purchase note in review notes
• One sentence explaining physical goods and your own gateway
• Guest browsing enabled; no unnecessary permissions requested
• Real screenshots, no baked-in promotions
• Store checked: HTTPS, permalinks, live gateway, REST API reachable, no maintenance plugin
• Privacy and data-safety forms complete, including third-party SDKs
• Account-deletion route present and tested
• Published under your own developer accounts

That leaves 4.2, which is not preventable by a checklist — it is decided by what the app is. Which is the whole reason architecture is a purchasing decision rather than a detail.

Related reading

• Will Apple reject my WooCommerce app? A merchant’s guide
• Why Apple rejects wrapper apps
• Filling in app privacy and data-safety forms
• Publishing your store app to the App Store and Play

Guideline numbers and policies are Apple’s and Google’s, and they change. Check the current guidelines before submitting.