Your AI-coded app shipped to App Store Connect, the build processed cleanly, and a few hours later Resolution Center returned Guideline 4.2 Minimum Functionality. Apple says the app does not provide enough features, content, or utility to deserve a place on the store. The build looks fine to you. The question is what 4.2 actually catches, why AI-coded habit trackers and meditation timers keep landing here, and what changes get the next submission through.
Short answer
Guideline 4.2 is the Minimum Functionality clause, and Apple uses it when an app reads as thin: a single-screen utility, a wrapped website, or a feature already shipped inside iOS. AI-coded apps trigger it disproportionately because the same prompts in Cursor, Claude Code, or Rork produce the same minimal scaffolds: a habit tracker with one list, a meditation timer with a circle and a start button, a horoscope reader with a date picker. The clause itself, in Apple's App Review Guidelines section 4.2, asks the app to do something real, useful, and native. The fix is rarely a longer feature list. It is depth in one direction.
What you should know
- Guideline 4.2 covers Minimum Functionality, with four sub-clauses (4.2.1, 4.2.2, 4.2.3, and 4.2.6). Each names a specific failure mode, from thin AR experiences to template-generated submissions.
- AI Slop is not a separate guideline. It is the visible result of 4.2 and 4.3 being applied to a higher volume of AI-coded submissions that share scaffolds.
- The clause is appealable inside Resolution Center. Developers who name the native iOS capabilities used, the target audience, and the on-device data tend to resolve the rejection on the second or third reply.
- Adding features rarely fixes 4.2. Apple is judging whether the app reads as native and useful as a whole, not whether it has more buttons than the previous build.
- Guideline 4.2.6 covers template providers and commercialized app generators. If your build came out of a service that ships the same shell to many developers, 4.2.6 is the structural rule, and a Resolution Center reply alone will not resolve it.
Why does Apple keep flagging AI-coded habit trackers under 4.2?
The short answer is that the scaffold is the problem, not the topic.
Most AI coding tools, asked to build a habit tracker or a meditation timer, produce the same skeleton: one tab, one list of items, a plus button, a paywall on screen two, and a settings screen. The flow runs almost entirely in React Native or Expo with a thin native shell. There is no widget, no Live Activity, no Shortcuts intent, no HealthKit read, no on-device complication, no notification logic that knows about local time zones. From Apple's side, the build reads as a feature already shipped inside iOS Reminders, the Health app, or Mindfulness.
The pattern the developer community calls AI Slop is the visible result. The Apple Developer Forums thread on 4.2 rejections shows how reviewers describe the issue: the app is similar to others in the category, does not deliver the functionality required for inclusion, and should be reconsidered with more depth. The wording is standard. The cluster behind it is not.
This matters because the fix you reach for matters. If you treat 4.2 as a metadata problem, you rewrite the description and the rejection comes back. If you treat it as a missing-native-feature problem, you add one widget and a notification and the rejection still comes back. The clause is asking for an app that does one specific thing, in a way iOS could not do without it.
What does 4.2 actually say, clause by clause?
The short answer is that 4.2 has four real sub-clauses, and they catch different failure modes.
Apple's App Review Guideline 4.2 is short on paper but wide in practice. Each sub-clause carries its own rejection pattern.
| Sub-clause | What it covers | Common AI-coded trigger |
|---|---|---|
| 4.2 (root) | Useful, unique, app-like behavior beyond a wrapped website | Single-screen utility, a webview wrapper, a feature already in iOS |
| 4.2.1 | ARKit experiences must be rich and integrated | A model dropped into an AR view with no interaction logic |
| 4.2.2 | Apps should not be marketing material, web clippings, or link lists | An AI-built directory that scrapes pages and shows them in cards |
| 4.2.3(i) | The app must work without another companion app | A controller that only functions when paired with a desktop tool |
| 4.2.3(ii) | Disclose download sizes when fetching resources at first launch | An AI-coded reader that fetches a large content pack silently |
| 4.2.6 | Apps from commercialized template services must be submitted by the content provider | Submissions from a multi-tenant AI builder under the developer's own account |
The AI Slop pattern most often falls under 4.2 root and 4.2.6. The root clause is the harder fix because it judges the whole app. The 4.2.6 case is sometimes harder still because the structural answer is a picker model or a rebuild that takes the template out of the loop.
What does a 4.2 fix look like in practice?
The short answer is depth in one direction, signaled through native iOS capabilities.
A habit tracker that ships with a Lock Screen widget, a Shortcuts action so the user can log a habit by voice, HealthKit read access to bring in workout data, and a notification that adjusts for the user's local sleep window reads as a real iOS app. The same habit tracker without those signals reads as a wrapped to-do list. Apple's reviewers do not write that comparison in the rejection message, but the pattern in the Apple Developer Forums thread on 4.2 fixes is consistent: resubmissions that pass include at least one capability that ties the app to the platform.
The meditation case is similar. A meditation timer with a circular progress view does not pass. A meditation timer with a complication for Apple Watch, an Audio session that ducks other audio, background playback support, and a Focus mode filter that turns on Do Not Disturb during a session reads as native. The capability list is not long. It just has to point in one clear direction.
For the horoscope or calorie-scanner case, the depth has to come from data instead of capability. A horoscope reader that pulls from a real astronomy data source and explains the calculation passes more often than one that calls a generic LLM. A calorie scanner that ships with a curated database, on-device classification, and an export to Health passes more often than one that posts an image to an API and shows a number.
How do you write the Resolution Center reply for a 4.2 rejection?
The short answer is one paragraph, four facts, and one offer.
The four facts are who the app is for, what the app does that iOS does not already do, which native capabilities the app uses, and what the on-device or proprietary data is. The one offer is a short demo: a live link, a video, or a test account that lands inside the differentiated flow on first login. Apple's reviewers see hundreds of these replies a week, and the ones that resolve fastest read like a calm engineering ticket, not an argument.
For builders who want an external automated read of the compiled IPA before resubmission, against OWASP MASVS coverage and the surrounding gates that often surface alongside 4.2, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scanning of AI-coded builds. A separate scan of the binary will not by itself satisfy 4.2 (the clause is about app depth, not vulnerabilities), but it does cover the related gates that tend to repeat in 4.2 resubmissions: Privacy Manifest, App Transport Security, permission usage strings, and undeclared SDKs. Apple's reviewers often touch those points on the same return trip.
What to watch out for
The first trap is treating 4.2 as a content problem. Adding three more screens to a thin habit tracker rarely changes the verdict. The reviewer is judging whether the app reads as native, not whether it has more screens.
The second trap is resubmitting the same build under a slightly different name or bundle ID. Apple ties 4.2 findings to the developer account and the binary fingerprint. A wave of similar resubmissions trips 4.3 spam findings on top of the 4.2 problem, and the second rejection is harder to appeal than the first.
The third trap is leaning on a webview to fill the depth gap. A webview pointed at a content site invites 4.2.2 (marketing material) and sometimes 4.2.3 (the app needs another product to function). The clause that catches webview-heavy apps is documented in Apple's note on web view apps and developer reports place this pattern at the top of repeat-rejection lists for AI-built submissions.
The fourth trap, specific to template providers, is mistaking 4.2.6 for a cosmetic fix. A multi-tenant AI builder that ships the same shell to many developers under different accounts has to consolidate to a picker model or rebuild each app as a genuinely separate product. Resolution Center cannot resolve a structural 4.2.6 case.
Key takeaways
- A 4.2 rejection is a depth signal, not a feature-count signal. Apple is reading the app as a whole and judging whether it deserves a place beside iOS Reminders, Health, or Mindfulness.
- The fastest fix is one clear native capability that points in the same direction as the app's promise. A widget, a Shortcuts action, a HealthKit read, an Apple Watch complication, or a Live Activity will do more than a feature list.
- Guideline 4.2.6 (commercialized templates) is structural. If the build came out of a multi-tenant AI service, the fix is consolidation or a separate rebuild, not a Resolution Center reply.
- The Resolution Center reply that works names the audience, the on-device data, the native capabilities, and a demo. Arguments without evidence almost never pass.
- Some teams pair an AI-coded build with an external pre-submission scanner. PTKD.com (https://ptkd.com) is one of the platforms focused on automated scanning of compiled mobile builds against OWASP MASVS before they reach App Store Connect or Google Play.
