Will Apple reject my WooCommerce app? A merchant's guide

The developer forums are full of 4.2 rejections, and almost all of the advice there is written for people who write code. If you run a WooCommerce store and you are about to pay someone to turn it into an app, you need a different version of the same information: which parts of this risk are yours, which belong to the vendor you pick, and which are nobody’s to control.

What App Review is actually doing

A human reviewer installs your app and uses it for a few minutes. They are not auditing your code. They are forming an impression, and two guidelines convert that impression into a decision.

Guideline 4.2 — Minimum Functionality. The standard question: does this app include features, content and UI that elevate it beyond a repackaged website? The rejection letter usually arrives as some version of “your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience.”

Guideline 4.2.6 — Template and app-generation services. Apps created from a commercialized template or an app-generation service are rejected unless they are submitted by the content provider. Read that twice, because it is the rule most store owners have never heard and the one that decides which vendor you should hire.

The four things that trigger 4.2

From published rejections and vendor documentation, the pattern is consistent. Reviewers react to:

1. Page loads between screens. A flash of white, a thin progress bar, text arriving before images. This is the single strongest signal, because it is what browsing a website looks like.
2. Web-styled controls. Select dropdowns that open the OS picker in the wrong way, text fields that do not behave like native fields, a horizontal scrollbar.
3. Thin functionality. An app that only lists products and links out for everything else — no search, no account, no order history.
4. Anything that reveals a URL. A share sheet offering a web address, a long-press menu with “open in new tab,” an error page with a domain in it.

Notice that none of these are bugs. They are all consequences of an architecture, which is why resubmitting the same app with a new splash screen so rarely works.

The 4.2.6 question you should ask before you pay

If your app is going to be published under your own Apple Developer account, with your business as the seller, 4.2.6 is not aimed at you — you are the content provider submitting your own app.

If a vendor offers to “handle publishing” under their account, or bundles your app into a portfolio account they own, you have inherited a 4.2.6 exposure that has nothing to do with how good the app is. Ask the direct question: whose developer account will my app live under? If the answer is anything other than “yours,” ask them to explain 4.2.6 in writing.

This is why StoreToNative publishes under your own accounts and treats it as a design constraint rather than a preference. It also means you need the accounts — $99/year to Apple, $25 once to Google — and that you own the listing, the reviews, and the customer relationship afterwards.

What you control, what your vendor controls, what nobody does

You control: the store listing (name, subtitle, screenshots, description), the privacy answers, the support URL, whether your catalog is complete enough to be worth reviewing, and whether your store’s checkout works on mobile Safari. A reviewer who cannot complete a test purchase is a reviewer who rejects.

Your vendor controls: whether the browsing screens are native, whether the app has real functionality (search, filters, account, order history, wishlist), whether the submission is under your account, and whether the pre-flight checks catch the obvious problems before a human sees them.

Nobody controls: which reviewer you get and what mood they are in. Anyone who promises approval is telling you something they cannot know. What an honest vendor can tell you is that the structural reason converted stores get rejected does not apply to their architecture — that is a claim about design, and you can verify it in ninety seconds with airplane mode.

The pre-submission checklist that prevents most of it

Before you submit, in this order:

• Test a real purchase on a real device. Not the simulator. Card, address, shipping, confirmation email.
• Check your store’s basics. HTTPS everywhere, working permalinks, a live payment gateway, no maintenance-mode plugin. Our WordPress companion plugin runs 12 store-readiness checks for exactly this, because a store problem shows up as an app rejection.
• Fill the app privacy questions honestly and completely. Vague answers get bounced faster than bad ones.
• Give the reviewer a way in. If any part of the app needs an account, supply demo credentials in App Review notes. An app the reviewer cannot get into is rejected in minutes.
• Make the first screen do something. A home screen with real merchandising — collections, a banner, best-sellers — reads as an app. An empty grid reads as a placeholder.
• Screenshots that match the app. Marketing mockups that show screens the app does not have is its own rejection reason.

If you have already been rejected

Read the actual guideline number in the message, not the summary. Then:

• 4.2 is architectural. Adding a splash screen will not fix it; adding genuine native functionality might, and changing the rendering model definitely does.
• 4.2.6 is about who submitted it. The fix is your own developer account.
• 2.1 (incomplete information) is usually demo credentials or a missing privacy answer — a same-day fix.
• 5.1.1 (data collection) is usually asking for a permission the app does not need, or requiring an account to browse. Let people browse without signing in.

Resubmission is not penalized. Repeating the same submission with cosmetic changes wastes a week, so change the thing the guideline names.

The honest bottom line

App Review is a human process with a written rulebook, and most WooCommerce rejections come from one of two decisions made before a line of the app existed: a browser-based architecture, and someone else’s developer account. Both are choices you make when you pick a vendor, and both are cheap to get right at that moment and expensive to change later.

Related reading

• Why Apple rejects wrapper apps — and how a native storefront avoids Guideline 4.2
• Native, WebView or PWA: what a WooCommerce app really is
• WooCommerce app builders compared: 7 options, honestly
• 12 store-readiness checks before you launch

Apps built with StoreToNative are submitted under your own developer account, with the checklist and the privacy answers computed in the console. Start the 14-day trial and see the pre-flight run against your own store.