Guideline 1.2: the four UGC requirements, and why AI apps trip it

What each requirement means in practice

Filtering. Something that runs before content becomes visible. A moderation API, a blocklist, a model check, a human queue for a small enough volume. What fails review is nothing at all, or a filter that only exists in the marketing copy.

Reporting. A control the user can reach from the content itself, that reaches a destination you actually monitor. "Timely" is not defined numerically in the guideline. What is checkable is whether the control exists, whether it goes anywhere, and whether you can describe your process. Put that description in the review notes rather than making a reviewer guess. Review notes that work.

Blocking. In the app, at the point of contact, and it must actually stop the contact. This is where it gets structural: blocking means your content queries need a block relationship to filter against, in both directions, in every place content is fetched. Retrofitting it after launch is a data-layer change touching every feed query, which is exactly why it should be built with the feature rather than after the rejection.

Contact information. Discoverable, and functional. Reviewers check.

Why AI apps get caught

Three ways.

A model can produce content. If your app displays text a user did not write, Apple's position is that you are responsible for it, and the safeguards it expects for user content are the safeguards it expects here.

One user's input becomes another's content. Shared prompts, community galleries, exported conversations, a leaderboard of results. This is unambiguous UGC and it usually gets added as a growth feature by someone who has not read 1.2.

Screenshots and uploads. An app that accepts an image and returns a response is processing content the user supplied. If any of that becomes visible to anyone else, 1.2 applies.

Related and separate: Guideline 5.1.2 covers what you may do with data sent to a third-party AI service, and 4.3 covers apps that are one of many near-identical wrappers. An AI app with a social feature can be evaluated under all three in a single review.

The React Native specifics

Nothing here is RN-specific in policy. Two things are, in practice:

A moderation call needs a server. Doing it in the client means shipping an API key in an app bundle, which is both a security failure and, when found, a separate problem. Route moderation through your backend. Why RN apps fail differently.

Blocking needs to survive offline sync. Apps with an offline queue can locally re-render content from a blocked user after a reconnect, because the block was applied to the fetch and not to the cache. A reviewer will not find this. Your users will.

The pre-submission check

# do the four controls exist in the UI at all
grep -rniE 'report|block|flag' src app --include=*.tsx --include=*.ts | grep -iE 'user|content|post|message' | head

# is a moderation step actually called before content is shown
grep -rniE 'moderat|toxicity|classif' src server 2>/dev/null | head

# is contact information reachable in-app and in the listing
grep -rniE 'support@|contact|mailto:' src app fastlane/metadata 2>/dev/null | head

Then answer honestly: can a user, inside the app, stop seeing a specific other person? If the answer involves email, the answer is no.

Where it sits with the other content guidelines

shipcheck reports whether report, block and contact affordances exist in the shipped UI, and cites the guideline text alongside each gap. It cannot judge whether your moderation is good, and it says so rather than implying otherwise. What it checks. · The first-submission checklist.

Questions and answers