Goal

Your build made it all the way through the WPMAM publish pipeline and landed in Apple App Store Connect or Google Play Console — and then the review team turned it down. This article walks through the most common reasons that happens to MAM apps, and shows you exactly where in Mobile App Manager to fix each one before you re-submit.

Worth knowing up front: a store rejection isn’t the same thing as a build failure. If your build never actually reached the store — the Publish status panel shows a Fastlane error instead of “submitted to review” — that’s a build problem, not a rejection, and Recipe: Publish your app to iOS and Android is the article you want instead. Everything below assumes your build succeeded and Apple or Google sent you an actual rejection notice.

Prerequisites

• A rejection email or message from Apple App Store Connect or Google Play Console. Keep it open — it usually names the specific guideline you tripped (for example, Apple’s Guideline 5.1.1 for permissions, or 4.2 for “minimum functionality”).
• Admin access to Mobile App Manager on your WordPress site.
• Access to the Publish Your App page (Mobile App Manager → Publish Your App).

Steps

Work through the causes below in whatever order fits your situation. If your rejection notice names a guideline number, jump straight to the section that matches it; if the notice is vague, start at the top — permission and privacy issues cause the large majority of MAM app rejections.

1. Vague or empty permission strings (most common iOS rejection)

Apple rejects builds whose permission prompts don’t clearly explain why the app needs access — every privacy-sensitive permission you use needs its own user-facing explanation, and something as generic as “This app needs camera access” won’t satisfy a reviewer.

MAM collects this copy in the iOS Permission Descriptions panel on Publish Your App. Those strings ship into the iOS Info.plist as the NS*UsageDescription entries — the text the OS actually shows in its permission dialog:

Fix:

1. Open Publish Your App and find the iOS Permission Descriptions panel.
2. For every permission your app actually uses, replace the generic default text with a specific, benefit-oriented sentence. For example, for location: “We use your location to show events and offers near you.”
3. These fields are optional — you only need to fill in the ones for services your app actually uses. Put your effort into those, rather than leaving vague default text sitting in fields Apple might question.
4. Save, then re-submit (see Re-submitting after a fix below).

2. Missing rationale / privacy copy on the in-app prompt

For location specifically, MAM shows two prompts back to back: a custom rationale screen you control (the Enable Location content class) before the OS prompt, then the OS prompt itself. Apple reviewers look at both — so if your custom rationale is missing or generic, that alone can contribute to a 5.1.1 rejection, even when the permission string itself is fine.

Fix:

1. Find the Enable Location screen in your app’s configuration (the Enable Location content class — typically used as a gate before maps, geofilters, or nearby listings).
2. Fill in its prompt title and prompt body with a clear explanation of why you need location, in your own words.
3. Make sure the rationale body and the Info.plist GPS message tell the same story. They should agree, in plain language.

See Content class: Enable Location for the full settings list.

3. Web-wrapper / “minimum functionality” content

Apple Guideline 4.2, and Google’s equivalent policy, reject apps that amount to little more than a wrapper around a website. If most of your app is one full-screen web view of your existing site, review teams will treat it as not adding enough native value to stand on its own.

A MAM app is a native shell by design — but it can still end up looking like a thin wrapper if nearly every tab just points at web content.

Fix:

• Make sure the app uses native MAM content — listings, home-screen layouts, native forms, push notifications, geofilters — rather than relying almost entirely on full-screen web views.
• Keep web/embedded content as a supporting piece, not the whole app.
• If a core experience is web-based, add native features around it (a native home screen, push notifications, a contact form) so the app clearly does more than a browser bookmark would.

4. Login walls with no way in

Both stores reject apps that hide everything behind a login the reviewer has no way past — and the same goes for apps that force account creation for features that never actually needed one.

Fix:

• If your app gates content behind sign-in, provide the review team with working test credentials. On iOS this goes in App Store Connect → the app version → App Review Information → Sign-In Information. On Google Play it goes in the Play Console review notes / app-access section.
• Don’t require login for content that doesn’t need it. If browsing is possible without an account, let reviewers browse without one.
• If your app supports Sign in with Apple or social login, make sure the test path actually works in the submitted build.

5. App icon problems

A wrong-sized, low-resolution, or placeholder icon causes more rejections than you’d expect — it’s an easy thing to overlook. MAM’s Publish page enforces the basics before you can submit, but it’s still worth double-checking yourself.

MAM requires a square PNG of at least 1024×1024 pixels, used by both stores. The Publish-status checklist flags two specific problems:

• Icon missing — no icon uploaded.
• Icon too small — the uploaded image is under 1024×1024.

Fix:

1. On Publish Your App, check the publish checklist. If the App icon row isn’t marked done, follow its “Upload below” link.
2. Upload a square 1024×1024 (or larger) PNG. Avoid transparency on the iOS icon — Apple rejects icons with transparent or black backgrounds; set the icon background color if your art has transparency.
3. Make sure it isn’t a placeholder or default art. Stores reject obvious placeholders.

6. Re-submitting after a fix

Changing a setting in WordPress does not by itself send anything new to the store — you still need to trigger a fresh build. Once you’ve fixed the cause:

1. On Publish Your App, increment the build number — Apple and Google both reject a re-submission that reuses a build number already in the review train. (Version number can stay the same for a resubmission; the build number must go up.)
2. Click Save.
3. Click Submit Publish Request to send a fresh build through the WPMAM pipeline.
4. Wait for the new build to appear in App Store Connect (TestFlight) or Google Play Console — typically 30–60 minutes — then re-submit it for review there, replying to the rejection with a note describing what you changed.

Think of the submit as fire-and-forget: your build runs asynchronously on WPMAM’s CI while the Publish-status panel polls for progress in the background. Don’t expect an instant success or failure the moment you click Submit.

If none of these match

• Read the exact guideline number in the rejection notice — Apple and Google always cite a specific policy, and that citation is the fastest route to the real cause.
• Reply to the reviewer. For borderline cases — especially web-content and login questions — a short explanation of what your app does, plus a screen recording, often resolves things without needing a new build.
• Bundle id / package name mismatches are a publish-side guard, not a store rejection — if the Publish page flags an account-code or bundle-id mismatch, that’s support territory. See Recipe: Customer enrollment and account code.
• If you’re still stuck, contact MAM support with the rejection notice text and your account code.

Related

• Recipe: Publish your app to iOS and Android
• Content class: Enable Location
• Recipe: Customer enrollment and account code
• Recipe: Configure push notifications