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 guideline clauses

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

Rejected under 4.2 Minimum Functionality — what it means and the actual fix

4.2 targets apps that are little more than a website wrapper, a marketing brochure, or a thin utility the reviewer finishes in 30 seconds. The related 4.2.2 clause covers web-clipping reskins and 'app makers' output — templated containers around someone else's content. What does NOT fix a 4.2 rejection: adding a login wall, adding push notifications, or adding a settings screen — reviewers treat those as decoration on the same thin core. What does: native functionality that justifies the app existing — offline capability, device APIs the website can't touch (camera, sensors, widgets, CarPlay/watch), native navigation and performance, or content depth the reviewer can actually explore. In the appeal or resubmission notes, enumerate the native features explicitly; reviewers reject again when the reply argues policy instead of listing functionality.

What is guideline 2.3.1 and how do reviewers actually detect hidden features?

2.3.1 prohibits hidden, dormant, or undocumented features — including feature flags, remote-config toggles that change behavior after approval, and code paths not disclosed in review notes. Detection is not a human tapping around: Apple runs static analysis on the binary looking for undisclosed private API usage, unused-but-present capability strings, and symbols referencing functionality not in the review notes; dynamic analysis observes network calls and behavior differences between review conditions and normal use; and post-approval re-review sweeps re-check flagged apps. The practical rules: strip dead code and unused flags before submission (they read as hidden features), declare every remotely-toggleable behavior in review notes, and never ship a flag that materially changes what the reviewed app does.

My second app shares a codebase with the first and got 4.3 Spam — what are the remedies?

4.3(a)/(b) treats multiple substantially similar apps from one account as spam: duplicate binaries, reskins with swapped assets, and template output are either consolidated or removed, and repeat offense is an account risk. The two remedies Apple accepts: (1) MERGE — ship one app with in-app variants (white-label flavors become configurations or IAP unlocks of a single binary, not separate store entries); (2) DIFFERENTIATE — make each app substantially different in features AND content, not just branding: distinct feature sets, distinct content sources, distinct audience. A new icon, name, and color scheme is not differentiation. In the appeal, attach a feature-by-feature comparison table against your own first app — reviewers respond to evidence, and 'same engine, different game' arguments only pass when the gameplay/content genuinely differs.

What does 2.1 App Completeness actually cover, and what triggers it?

2.1 requires the app to be complete and functional at review time. The recurring triggers: no demo/test account provided for login-required apps (put working credentials in the App Review notes field — reviewers will not register); placeholder or broken content (dead buttons, 'TODO' screens, lorem ipsum, empty feeds); crashes on launch or on the primary flow — reviewers run on real current hardware; backend not live or pointing at staging/localhost during review; required hardware not available to the reviewer (if the app needs a Bluetooth accessory, say so and provide a video or demo mode); and IAP products not submitted together with the build. The pre-submission drill: fresh device, fresh install, airplane-mode-once, every button tapped, with the exact credentials you pasted into review notes.

Give your agent this brain