Guideline 1.1: objectionable content
Most developers read this one and assume it is about apps unlike theirs. Four categories catch ordinary apps.
1. What your users can produce. The app displaying it is what matters, which is why Guideline 1.2 requires filtering, reporting and blocking. An app with no safeguards is responsible for whatever appears in it.
2. What your model can produce. Apple's guidance treats AI output as content the app is responsible for. If a reviewer can make your model say something objectionable, that is a finding about your app, not about the provider whose API you called.
3. False information and features. A feature that does not do what it claims, fabricated data presented as real, an ability the app does not have. The most serious version is a health or medical claim, because a claim about an outcome is checkable and consequential. Guideline 1.4.1, medical apps.
4. Content designed to upset, and realistic depictions of violence, which mainly affects games and media apps and occasionally catches an app whose sample content nobody reviewed.
Assume a reviewer will try what a hostile user would try. For an AI app that means asking it for something it should refuse. Knowing what happens then is the difference between a considered answer in your review notes and a guess.
The AI case, specifically
The most common way an ordinary app meets this guideline in 2026.
Have a refusal behaviour and know what it is. Not "the provider handles it." What does your app show when the model declines, and what happens if a user works around a refusal.
Run the obvious attempts yourself, before review. Ask it for the things it should not produce, in the ways a person actually would. Write down what happened.
Then say so in the review notes, in three lines:
Safety: prompts and responses pass [moderation] before display.
Refusals render as [behaviour]. We tested the categories in
Guideline 1.1 against the shipping system prompt on [date];
notes available on request.Three lines converts an unknown into a described control. Submitting an AI app. · Guideline 5.1.2, third-party AI.
The false-features case
Quieter and more common than it sounds:
- A feature in the screenshots that does not exist yet.
- Sample data presented as real results.
- A claim about accuracy, performance or outcomes with nothing behind it.
- Health, medical or safety claims, which is the version that turns a metadata problem into a serious one.
The rule that covers all of them: if you cannot substantiate it, do not display it. That is simultaneously a review requirement, an advertising-law requirement in most markets, and the only version that survives contact with a user. Writing store copy that does not get rejected. · Screenshots and app previews.
What a reviewer actually does
Not a systematic audit. The obvious hostile things, quickly.
Types something inflammatory into your text field. Asks your model for something it should refuse. Opens the community feed and looks at what is in it. Taps the feature your screenshot promised and sees whether it exists.
Every one of those is a thing you can do yourself in ten minutes, and almost nobody does, because the team tests the app doing what it is for. What reviewers actually test.
Where it sits
| Guideline | Concern |
|---|---|
| 1.1 | What may be in an app at all |
| 1.2 | Safeguards when users can see each other's content |
| 1.4.1 | Medical and health claims and accuracy |
| 2.3 | Metadata accuracy |
| 5.1.2 | Disclosure when data goes to an AI service |
| Age rating | What the app contains, declared |
An accurate age rating does not make prohibited content acceptable. The rating describes; 1.1 governs.
The pre-submission pass
# sample and seed content that ships in the bundle
grep -rniE 'lorem|test user|sample data|placeholder|dummy' src app assets 2>/dev/null | head
# claims that would need substantiating
grep -rniE 'clinically|proven|guaranteed|cures?|treats?|diagnos|100% accurate|risk.free' \
src app fastlane/metadata store 2>/dev/null | head
# whether a refusal path exists at all in an AI app
grep -rniE 'refus|cannot help|blocked|moderation|safety' src server 2>/dev/null | headThen do the ten-minute hostile pass by hand, because that is the part a grep cannot do and the part a reviewer will.
shipcheck flags unsubstantiated claim language in app and listing copy, and reports whether a moderation path exists between generated content and display. It cannot judge whether content is objectionable, which is a human question. What it checks. · After a rejection.
More in this section
About shipcheck
shipcheck is a pre-submission checker from Baker Ventures LLC that runs inside Claude Code. It reads your React Native or Expo project, finds the things that get apps rejected or blocked at upload, cites the exact App Store Review Guideline or Google Play policy clause, and names the file and line to fix.
It exists because React Native and Expo apps fail for reasons that are invisible in the code you wrote: capability arriving through a dependency, purpose strings added by a config plugin, a privacy manifest missing from an SDK you never chose directly, and a generated ios/ directory that discards your edits on the next prebuild. shipcheck checks what the binary and the config actually declare, not what you intended. The rejection references on this site are free, need no account, and link to the primary Apple or Google document for every claim.
Questions and answers
What does App Store Guideline 1.1 cover?
Objectionable content, including defamatory or discriminatory material, realistic depictions of violence, content that encourages illegal or reckless behaviour, false information and features, and content designed to upset or disgust. It applies to what your app can display, not only to what you wrote.
Does 1.1 apply to content my users create?
Yes. Your app displaying it is what matters, which is why 1.2 requires filtering, reporting and blocking. An app whose users can produce objectionable content is responsible for having safeguards, not only for its own material.
Does it apply to AI output?
Apple's guidance treats model output as content the app is responsible for. If a reviewer can make your model produce something objectionable, that is a finding about your app rather than about the model provider.
What counts as false information or features?
A feature that does not do what it claims, fabricated data presented as real, or an app claiming an ability it does not have. Health and medical claims are the most common serious version, because a claim about an outcome is checkable and consequential.
How do I know what a reviewer will try?
Assume they will try the obvious things a hostile user would. For an AI app that means asking it for something it should refuse, and knowing what happens then is the difference between a considered answer and a guess.
Is this the same as the age rating?
No. The age rating declares what the app contains; 1.1 governs what may be in an app at all. An accurate rating does not make prohibited content acceptable.
shipcheck. “Guideline 1.1: objectionable content.” Baker Ventures LLC, September 7, 2026. https://shipcheck.bakerventuresstudio.com/rejections/guideline-1-1-objectionable-content/