The source of the code is not the only useful question. App Review can inspect what customers receive: the feature set, interaction quality, content, metadata, privacy behavior, purchase path, and how distinct the app is from other submissions. A repository can also carry template assets, placeholder copy, unused permissions, or fragile flows no matter who wrote it.
What Guidelines 4.2.6 and 4.3 cover
Apple’s current minimum functionality rules and spam rules address three different risks that are often collapsed into one AI rumor.
Guideline 4.2.6 addresses apps produced through a commercialized template or app generation service. It limits services submitting on a client’s behalf and expects tools to support customized, innovative apps with unique customer experiences. It does not say source code must be written by hand.
Guideline 4.3(a) targets portfolio duplication: multiple Bundle IDs for substantially the same app. A new theme, name, or content set may not solve that structural problem.
Guideline 4.3(b) addresses apps that are indistinguishable from what is already widely available. Established categories face a higher bar and need a meaningfully different or improved experience.
The practical test for an AI-built app
Treat the AI tool as part of your development process, not as the product argument. The submission should stand on evidence that a reviewer can see and reproduce.
- Name the specific customer and problem. A narrow, real use case is easier to distinguish than a generic utility with interchangeable copy.
- Remove template residue. Check icons, screenshots, sample data, bundle settings, privacy declarations, onboarding, empty states, and default microcopy.
- Show product depth. Make the useful path complete on a release build, including failure, loading, permission, purchase, restore, account, and deletion states where relevant.
- Document provenance. Keep licenses and creation records for code, assets, data, and third-party models. Do not imply ownership you cannot prove.
- Make metadata match the binary. Screenshots, descriptions, prices, subscriptions, privacy answers, and review notes should describe the submitted build precisely.
- Give App Review a usable path. Provide test credentials, setup details, hardware requirements, attachment evidence, and exact navigation for anything that is not obvious.
If Apple cites 4.2.6 or 4.3
Start with the complete rejection message. Do not guess which clause Apple meant, and do not lead with a broad argument that AI use is allowed. Compare the message with the submitted binary, the developer portfolio, reused assets, product depth, and the current product page.
A response should state what changed, where the reviewer can find it, which build contains it, and what evidence is attached. If the app is already distinct and Apple appears to have mistaken a framework or shared dependency for a template, explain that narrowly and ask for clarification. Appeal only when the record supports it.
Run an evidence-first review
The open-source App Store Review Skill checks Xcode, Expo, React Native, and Flutter projects for submission evidence, then separates confirmed blockers, warnings, and manual checks. Its first pass is read-only.
This guide summarizes public Apple documentation and does not guarantee approval. Apple makes each review decision and can change its guidelines. The skill is not affiliated with or endorsed by Apple Inc.