If you opened App Store Connect this morning to find a Guideline 4.2 rejection on your AI-built habit tracker, you are reading the same letter hundreds of indie developers have received in 2026. The wording is brief, the reason is abstract, and the next step is unclear. The honest answer is that the rejection is not about the AI tooling. It is about what the reviewer sees in the binary after the AI tooling is done, and that surface has become very easy for App Review to recognize.
Short answer
Guideline 4.2 (Minimum Functionality) rejects apps that look like a repackaged website, a template clone, or an idea executed at the level of a tutorial. Apple writes in the App Review Guidelines that an app should include features, content, and UI that set it apart from a repackaged website, and that apps which are not particularly useful, unique, or app-like do not belong on the App Store. The reason vibe-coded habit trackers and medication reminders keep falling here is convergent design: ten thousand similar prompts produce ten thousand similar five-screen apps, and the reviewer recognizes the shape on sight. The fix is depth in one place, not polish across the whole app.
What you should know
- 4.2 is the catch-all minimum functionality clause. It covers apps that are too shallow, too generic, or too website-shaped. Apple has used this clause since the App Store launched and the wording has not changed materially.
- 4.2.6 is the template clause. Apps built from commercialized template or app generation services are rejected unless submitted by the content provider. AI-built apps with no original logic often land here as well.
- AI slop is not an Apple term. It is the developer community shorthand for indistinguishable AI-built apps. Apple does not name AI in the guidelines, but the pattern is what triggers the rejection.
- Reviewers spend roughly two minutes per first review. That is enough time to open the app, tap through three or four screens, and decide. Shallow apps reveal themselves quickly.
- The volume context matters. Apple reported reviewing around 7.77 million submissions and rejecting roughly a quarter, according to its 2024 App Store Transparency Report. Submissions grew in 2025 partly because of vibe-coding tools, and the rejection backlog grew with it.
What does Guideline 4.2 actually say?
The text is short. Section 4.2 of the App Review Guidelines reads that your app should include features, content, and UI that set it apart from a repackaged website, and that an app which is not particularly useful, unique, or app-like does not belong on the App Store. The phrase to focus on is app-like, because it is the criterion a reviewer applies in practice. An app-like experience uses iOS conventions, persists state between launches, integrates with native systems where it makes sense, and offers something the same content cannot offer in a browser tab.
Subclause 4.2.6 then covers the template case directly. Apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content. That clause was written for the era of cookie-cutter restaurant apps, but it transfers cleanly to AI-generated builds. If your project began with a one-line prompt to Lovable, Rork, or a Cursor template and the output is recognizable as a template, the reviewer can cite 4.2.6 in the same letter as 4.2.
Why are AI-built habit and medication trackers getting flagged?
Three factors compound. First, the prompt distribution is narrow. Most people asking an AI tool to build a tracker describe the same set of screens: a list of habits, a daily checklist, a streak counter, a reminder, a settings page. The model produces the shortest path to that brief, which is a five-screen scaffolded app. Second, the visual layer is bland by default. AI tools default to a clean sans-serif, a card layout, and a primary color, which means the average AI-built tracker looks like every other AI-built tracker. Third, the underlying logic is not differentiated, because the prompt did not ask for differentiation.
Medication trackers add a fourth complication. Guideline 1.4.1 requires medication dosage information and calculators to come from a regulated source: the drug manufacturer, a hospital, a university, a health insurer, a pharmacy, or another approved entity, per the App Review Guidelines. An AI-built medication app rarely surfaces that provenance, so the reviewer either rejects under 1.4.1 directly or pushes the case under 4.2 because the app reads as a generic list with reminders. Either way, the letter arrives.
How does the reviewer recognize an AI-built app in two minutes?
Reviewers do not have a magic AI detector. They have pattern recognition built on volume. The signals they pick up include an onboarding flow that asks three questions and then drops the user into a single empty list, a tab bar with three or four icons where only one tab has real content, default iOS form controls used without customization, a settings screen with placeholder rows (Account, About, Terms, Privacy) that lead nowhere meaningful, a web view inside one of the tabs that loads a marketing page or a help center hosted elsewhere, and no persistence past app reinstall because the AI-built backend was a local stub.
None of these is a violation on its own. Together they are the shape of 4.2. The Modall analysis of the March 2026 crackdown describes the same set of tells from a developer's perspective, and the 9to5Mac coverage of Apple pulling the Anything app shows the policy edge case where a vibe-coding platform itself crossed into 2.5.2 (downloaded code) territory.
What does an app that passes 4.2 actually look like?
The successful 4.2 appeals I have seen follow a pattern. The app does one thing the reviewer cannot match against a template, and the differentiator is visible inside the first thirty seconds of use. A habit tracker that reads from HealthKit step counts and writes back resistance training sessions, so the daily checklist is partially auto-filled from sensor data, will read differently to a reviewer. A medication tracker that imports a prescription label via VisionKit text recognition, parses the schedule, and registers a Live Activity so the next dose is on the Dynamic Island, signals depth on the first screen. A journaling app that uses on-device speech recognition with a Siri Shortcut to capture an entry hands-free, then summarizes the week with on-device foundation models rather than a server call, demonstrates an iOS-native primitive that a generic web wrapper cannot replicate.
The reviewer does not need to read the whole feature spec. The use of HealthKit, the appearance of a Live Activity, or the presence of a Siri Shortcut is itself the signal that the app is doing more than a template would.
How does 4.2 compare to the other rejection clauses AI apps hit?
| Clause | What it covers | Typical AI-built trigger | Practical fix |
|---|---|---|---|
| 4.2 | Minimum functionality, not app-like | Five-screen tracker with no native integration | Add one deep iOS-native feature |
| 4.2.6 | Commercialized template service | Output recognizable as a builder template | Customize layout, copy, and at least one screen flow |
| 4.3 | Spam, duplicate of existing app | Submitting the same scaffolded idea under two accounts | Submit one app, differentiate by feature |
| 2.5.2 | Executable code at runtime | Vibe-coding apps that load and run user code | Bundle features at build time |
| 1.4.1 | Medical dosage source | AI-built medication app with no regulated source | Cite a manufacturer or hospital partner |
| 5.1.1 | Privacy and data collection | Missing or weak privacy policy in generated app | Write a real policy, declare data collection accurately |
The table is not exhaustive. It is the bucket distribution I see among AI-built submissions that get rejected. The takeaway is that 4.2 is the most common landing zone but rarely the only clause cited; the rejection letter often combines two.
What to watch out for
The most common mistake is to treat the rejection as a UI problem. Developers respond by adding animations, an onboarding tutorial, a darker color palette, and a new icon. None of that changes the verdict. The reviewer is reading the app's depth, not its surface. Polish without depth makes the second rejection arrive faster.
The second mistake is to argue with the reviewer. Apple's App Review process page and Median's guide on appealing both point in the same direction: appeals work when you show a concrete feature the reviewer missed, not when you argue that the app deserves approval. Reviewers see the same arguments every day and have a short tolerance for them.
The third mistake is to assume that a security or privacy issue caused the rejection and to scramble the wrong fix. 4.2 is about depth and shape. Most AI-built apps also have privacy manifest or storage problems, but those surface under 5.1.x clauses, not 4.2. Fixing the wrong thing burns a review cycle. For builders who want an external automated read of their build before submission, PTKD.com (https://ptkd.com) is one of the platforms focused specifically on pre-submission scanning for no-code and vibe-coded apps, aligned with OWASP MASVS, so the team can separate the genuine security gaps from the 4.2 design verdict.
Key takeaways
- Treat 4.2 as a depth verdict, not a polish verdict. The reviewer is asking whether the app exists for a reason beyond AI generating something tappable.
- Add one iOS-native primitive (HealthKit, Live Activities, VisionKit, Shortcuts, foundation models) and use it in the first thirty seconds of the experience.
- Read 4.2 alongside 4.2.6 and 1.4.1 when you submit a tracker. The combined clauses are the realistic risk surface, not 4.2 alone.
- Appeals work when they show a missed feature on video, not when they argue effort or intent. Keep the appeal short and concrete.
- Some teams outsource the pre-submission read entirely to platforms like PTKD.com (https://ptkd.com), which scans compiled builds for OWASP MASVS gaps before they reach App Review, so the 4.2 verdict can be addressed on its own terms.
