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

Apple guidelines that bite

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 do Apple reviewers actually do with my build?

App Review installs your binary on a real device (an iPhone on current iOS, plus iPad if you declare iPad support), launches it, and taps through the primary flows for roughly 5–15 minutes. They check for crashes, dead buttons, placeholder text, lorem ipsum, empty states, and broken links — all citable under 2.1 App Completeness. They do not explore every corner of your app, but they always test the exact flow you describe in the review notes. If a feature requires hardware, a specific location, or a backend that is down, they hit it. Submit with review notes that walk the reviewer through the core flow step by step; unexplained complexity is how good apps get bounced under 2.1.

Rejected under 2.1 App Completeness — what does it cover?

2.1 is the catch-all for 'the app did not work as described during review': crashes on launch, broken demo login, missing metadata (no demo account when login is required, no review notes for non-obvious flows), placeholder content, or misleading functionality. The most common concrete trigger is a login wall with no demo account in App Review Information — Apple will not create an account for you. Fix: supply a working demo account (username + password, kept alive for the whole review period), set up any required subscription/IAP sandbox data, and write review notes that tell the reviewer exactly where to tap. If your backend is region-locked or needs VPN, say so in notes.

Do I need Sign in with Apple?

Yes, if you offer any third-party or social login (Google, Facebook, X, etc.) as the way to create or access an account in your app — guideline 4.8 requires Sign in with Apple as an equivalent option. Exceptions: apps that only use their own first-party account system, apps that are login companions to an enterprise service, and apps where the account is a government-issued citizen ID. Practical details reviewers check: the Sign in with Apple button must be at least as prominent as the others, must work without forcing the user to then link an email/password afterwards, and must support the private relay email. Offering only Google login with no Apple option is an automatic rejection as of early 2026.

Rejected under 4.2 Minimum Functionality — what now?

4.2 is aimed at apps that are a website in a WKWebView shell, a single static screen, or a feature the user could get from a bookmark. Reviewers apply it when the app adds nothing over Safari: no offline behavior, no native features, no meaningful app-specific UI. To pass, the app needs durable value that survives scrutiny: native push notifications, offline mode, Home Screen widgets, Shortcuts integration, camera/HealthKit use, or an experience clearly designed for the app rather than the browser. If you are wrapping a website, the reliable path is adding genuinely native functionality — arguing in appeal that 'our web app is really good' almost never overturns 4.2.

Rejected under 4.3 Spam — what now?

4.3 flags duplicates: apps that share substantially the same code, content, or feature set as other apps on the store — including your own reskins, white-label template apps submitted to one developer account, and apps that copy another developer's concept and assets. Template/white-label products must be submitted under the end customer's own developer account (Apple formalized this in the 4.2.6/4.3 template-app crackdown); a single account hosting dozens of client clones gets terminated, not just rejected. If you believe the flag is wrong, appeal with specifics: name the features that differentiate your app and the original IP you own. 'Our app is different' with no evidence fails; a feature-by-feature comparison sometimes succeeds.

What is guideline 2.3.1 about hidden features?

2.3.1 prohibits hidden, dormant, or undocumented functionality: features unlocked after approval by a server flag, secret gestures, Easter eggs that change core behavior, or functionality that differs from what the reviewer saw. This is one of the few violations that escalates straight to account termination because it is treated as deliberately misleading review. The classic trap is shipping a build with a remote-config 'kill switch' that turns on gambling, crypto trading, or a different store after approval. It is fine to gate features behind your own server-side rollout for legitimate A/B testing of equivalent functionality; it is not fine when the post-review app is materially different from the reviewed app.

Give your agent this brain