new·The score now tells you which way it movedA brain's exam only ever grows: its own material writes questions, and so does every question a real caller asked and did not get answered. The score is a percentage over that growing set, so a brain that learned more could post a smaller number — and this week three did. One of them answered two MORE questions than the week before and showed eighteen points less. Printed as a single percentage, that reads as decline to a reader and as punishment to anyone who contributes material.all news →
mozg.beta
Sign in

App Store & Google Play Review · all subjects

Metadata and screenshots

6 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

What metadata mistakes trigger 2.3 Accurate Metadata?

2.3 covers everything in the store listing: screenshots, preview videos, description, keywords, and the app name must reflect the app as it actually works. Concrete triggers: screenshots showing UI that does not exist in the build (reviewers compare your screenshots against the live app — mismatched screens are a real rejection, not a myth); screenshots or descriptions referencing other platforms ('our Android users', Google Play badges, Android device frames or status bars); descriptions mentioning features locked behind a roadmap ('coming soon' for core features); and keyword fields stuffed with competitor names or irrelevant trending terms, which also feeds 4.3/2.3 spam flags. Keep one version's metadata truthful for the build it ships with; update screenshots whenever UI changes materially.

Are there hard rules for screenshot format and content?

Technically: screenshots must be the correct pixel dimensions for each declared device class (6.9"/6.7" iPhone, 13" iPad, etc.) — App Store Connect rejects wrong sizes at upload. Content-wise: device frames are allowed if they depict Apple devices accurately, but they must not obscure the app UI; screenshots must be captured from or faithfully represent the actual app; and no imagery suggesting other platforms. App preview videos follow stricter rules: only captured in-app footage plus simple titles — no hands holding phones, no people, no behind-the-scenes material. For Google Play: feature graphic and screenshots must not contain store badges, 'editor's choice' claims, or pricing. Overproduced marketing frames with UI that is not real is a recurring 2.3 trigger.

Can I get rejected for my app name or keywords?

Yes. Names and subtitle are limited (30 characters each on Apple) and must not include prices, 'free' claims, other app names, or unrelated popular terms — that is both 2.3 and the metadata-spam clause of 4.3. The 100-character keyword field is the classic stuffing vector: competitor names, celebrity names, and trending-but-irrelevant terms get flagged, sometimes weeks after approval by automated sweeps, and repeated keyword abuse feeds into account-level spam review. On Google Play, the short/full description is policed under the Store Listing policy for keyword stuffing and unattributed testimonials ('#1 app', fake quotes). Use only terms a user searching for your actual functionality would type.

What are the rules for the 'What's New' text and review notes?

Release notes are reviewed metadata too: they must describe the actual changes in the build (2.3), and they are a terrible place for marketing, upsells, or re-engagement copy directed at lapsed users — Apple rejects 'What's New' text that does not match the diff. Separately, the App Review Information notes field (not user-visible) is your highest-leverage review asset: state the demo account credentials, the exact tap path to any non-obvious feature, any hardware/server dependencies, and — if relevant — a short justification quoting the guideline you believe applies (e.g., 'digital goods are consumed outside the app per 3.1.1'). Reviewers read these first; a build with clear notes survives scrutiny that sinks unexplained builds.

What are the hard rules for App Store screenshot format and content?

Format: screenshots are required for the current 6.7"/6.9" iPhone class and, if the app supports iPad, the 12.9"/13" iPad class — App Store Connect scales down from these, so upload the largest sizes. You may attach up to 10 screenshots per localization, and the first two do the selling in search results. Content: they must show the actual app UI in use, on the correct device frame if frames are used; no pricing, promo badges, or 'award-winning' overlays; no UI from another platform (an Android status bar is an instant bounce); no placeholder or lorem-ipsum screens. Updates: for years screenshots were locked until a new binary; App Store Connect now lets you update screenshots for a live app without a new version — verify the current behavior, as this policy has moved. Localization note: each locale needs its own set or it inherits the default.

Are there hard rules for the 'What's New' text in App Store updates?

Yes. App Store Connect gives 'What's New' a 4,000-character field (same ceiling as the description), but the effective limit is attention — reviewers and users read the first two lines. It IS reviewed with each version: misleading changelog content (describing features not in the build), marketing or sales language ('50% off this week!'), external links or contact solicitations, and references to other platforms are all rejection triggers under 2.3 metadata rules. The pattern that passes: terse, factual, user-facing changes ('Fixes a crash when exporting large files; adds dark mode to the settings screen'). The pattern that fails: 'Bug fixes and improvements' copy-pasted for 20 versions while the app visibly changes — reviewers read that as concealing changes, which feeds 2.3.1 suspicion. Google Play's release notes follow the same practical rules under the Store Listing policy.

Give your agent this brain