App Store metadata rejections: fixing 2.3.x, 2.3.7, 4.3 and 5.2.1
You just got the email. Status flipped to Metadata Rejected, and the Resolution Center note cites a guideline number you had to go look up. The good news is that a metadata rejection is one of the faster ones to clear: you are not re-uploading a build, you are editing the version record and resubmitting.
The one thing to check first is the guideline number in your Resolution Center message, because that tells you exactly which field to fix. This post covers the four you are most likely to see on a listing rejection. Guideline numbers get renumbered over time, so the ones here reflect the current App Store Review Guidelines.
First, the mechanic: what "Metadata Rejected" actually means
A Metadata Rejected status points at your store listing — app name, subtitle, keywords, description, screenshots, previews, URLs — not at the compiled app. Because the flag is on the metadata, you do not need a new binary. You edit the cited field in App Store Connect, keep the existing build attached to the version, and resubmit.
Two caveats worth stating plainly. First, resubmitting still puts you back in the review queue, so it is build-free but not review-free — a human or automated pass looks at it again. Second, fixing the one field Apple cited does not immunize the rest of your listing. Reviewers can flag a different guideline on the next pass. Clean up the whole listing while you are in there, not just the sentence that got quoted back at you.
Guideline 2.3.3 — screenshots must show the app in use
What triggers it. Your screenshots do not show the app doing its job. The classic version is a first slot that is a splash screen, a login page, or title art with a tagline and no actual UI. It also fires when a screenshot shows a feature the app does not have, or references a device or interface from another platform.
Before: slot one is your logo centered on a gradient with the words "the smartest way to plan your week," and no app interface anywhere on it.
After: slot one is a real screen from a core flow — a week view with actual entries filled in — with a short caption naming the benefit above the device. Reviewers (and users) can see what the app does from the thumbnail. Keep marketing captions and device frames, but make sure the app UI underneath is genuine and current.
This one is a metadata change: swap the images in the version record, resubmit, no new build.
Guideline 2.3.7 — keywords must describe your app, not game search
What triggers it. This is the keyword-misuse guideline. It fires when your metadata is padded with terms that do not describe your app: trademarked terms you do not own, the names of bigger or more popular apps, pricing language in the wrong field, celebrity or public-figure names dropped in for reach, or generic phrases stuffed in to catch searches. The 100-character keyword field is the usual offender, but the subtitle and name get flagged too. App names are capped at 30 characters, and price or promotional language does not belong in the name, subtitle, or screenshots.
Before (keyword field): a list that includes the names of three larger apps in your category, a well-known creator's name, and a couple of unrelated trending words, none of which describe a feature you shipped.
After: keywords that map to what a user would actually search to find your function — the tasks it performs, the problem it solves, the nouns from your own screens. Every term should point at something the app genuinely does.
Before (subtitle): a comparison line positioning yourself against a named rival app.
After: a subtitle that states the outcome your app delivers in plain terms, no other brand's name in it. The subtitle is for context on your app, not a place to borrow someone else's traffic.
Guideline 4.3 — spam and near-duplicate apps
What triggers it. 4.3 is about sameness. It fires when you ship multiple near-identical apps under separate bundle IDs (a separate build per city, per team, per client, instead of one app with those variations inside), or when a submission is hard to tell apart from something already widely available. It is often a concept problem, but the listing is what makes duplication visible — identical descriptions and screenshots across your own apps are a strong tell.
Before: five apps in your account with the same layout, the same feature list, and copy that differs only by swapping one city or team name.
After: one app that carries those variations as in-app options or purchases, with a listing that describes the genuinely distinct thing it does. If you truly have separate products, make each listing show what is actually different about it in the screenshots and description, not just a find-and-replace on a proper noun.
4.3 can require more than a metadata edit if the underlying app really is a thin reskin. But where the issue is that your listings read as clones of each other, differentiating the copy and screenshots is a metadata fix.
Guideline 5.2.1 — someone else's intellectual property in your metadata
What triggers it. Using protected third-party material you do not have rights to — trademarks, copyrighted works, copycat names — anywhere in your bundle, developer name, or metadata. A common variant is a mismatch between the app or brand in the listing and the entity that actually submitted it, which makes Apple ask who owns the name.
Before: a brand or platform name you do not own sitting in your app title, subtitle, or keyword field to catch its search traffic.
After: your own product name in the title, subtitle, and keywords. If you genuinely integrate with a third-party platform and need to say so, keep any factual compatibility mention in the description where it is permitted, and out of the name and subtitle. If you built the app for a client who owns the mark, submit it from the account of the entity that owns it, or get added to their team, so the seller name and the brand line up.
The build-free part, restated
For all four, if the fix lives in the version record — text and images — you correct it in App Store Connect and resubmit the same binary. You do not bump a build number or wait on processing. That is the fast lane a metadata rejection buys you. The trade is that you go back through review, so it is worth reading the whole listing against these four before you hit resubmit rather than clearing them one rejection at a time.
Where Mokbi helps (and where it does not)
Most 2.3.7 trouble starts at the writing stage, when a keyword field or subtitle gets padded to chase reach. Mokbi's AI drafts your listing copy — name, subtitle, keywords, description — from what your app actually does, which steers you away from the padding and borrowed-brand habits that draw a keyword rejection in the first place. It then localizes that copy into 50 languages, so you are not hand-writing a fresh keyword field per market and reintroducing the same trap in each one.
Be clear-eyed about the limit. This lowers your odds of a 2.3.x or 5.2.1 flag on the wording; it cannot promise approval, and it does not decide what is inside your build. Review is Apple's call. What compliant, app-accurate copy does is remove the easy, self-inflicted reasons to get bounced. Mokbi does not auto-publish to your listing — it produces the copy and the screenshots; you review them and submit.