How to fix an App Store Guideline 1.2 user-generated content rejection

Apple rejects an app under Guideline 1.2 when people can post content in it and any of four safeguards is missing. The four are a way to filter objectionable material before it is posted, a way to report offensive content with timely responses, a way to block abusive users, and published contact information. Build all four, then tell App Review (the Apple team that reviews each app) where each one is. A moderation API can do the filtering; the other three are features you build.

What Guideline 1.2 requires

Guideline 1.2 covers "apps with user-generated content or social networking services". User-generated content (UGC) is anything one user posts that other users can see: posts, comments, reviews, chat messages, usernames, bios and photos. Apple's text, as read on 16 Oct 2026:

To prevent abuse, apps with user-generated content or social networking services must include:

• A method for filtering objectionable material from being posted to the app
• A mechanism to report offensive content and timely responses to concerns
• The ability to block abusive users from the service
• Published contact information so users can easily reach you

The guideline adds: "It is your responsibility to remove content that violates this guideline, your terms of service, or your community standards." Two related rules reach further:

• Creator content (1.2.1). Content that a community of "creators" makes in your app, such as video, articles, audio or casual games, is treated as user-generated content. Creator apps must also let users identify content that exceeds the app's age rating, and use "an age restriction mechanism based on verified or declared age" (1.2.1(a)).
• Mini apps, chatbots and plug-ins (4.7.1). Software your app offers that is not embedded in its binary (Apple lists HTML5 and JavaScript mini apps and mini games, streaming games, chatbots and plug-ins) must "include a method for filtering objectionable material, a mechanism to report content and timely responses to concerns, and the ability to block abusive users".

What reviewers asked for in recent rejections

Recent rejections are headed "Guideline 1.2 - Safety - User-Generated Content" and list what the reviewer found missing. Developers have posted these messages on Apple's Developer Forums. The lines below are App Review's words as those developers quoted them, not the published guideline, and they ask for more than its four points. The 2017 message and the first November 2025 message start with an EULA (end-user licence agreement: the terms each user accepts) that rules out objectionable content and abusive users.

Two things follow:

• The 24-hour line is not in Guideline 1.2, which asks for "timely responses to concerns". Reviewers have used it since at least 2017, so plan to act on every report within a day.
• A rejection names only what the reviewer found missing. The October 2025 message asked for blocking alone, and the second rejection in thread 807358 added three points the first did not list. Fix every listed point, then check that the other safeguards work too.

How the pieces fit together

The flow below uses the Detectivision API for the checks. The call and event names are the ones in its docs.

The fix, step by step

1. Filter text and images before they are posted

Run the check on your server, between "the user pressed Post" and "other users can see it". This is pre-moderation; types of content moderation compares it with the other approaches. Keep the API key on the server: a key inside an app can be read by anyone, who can then spend your credits (quickstart).

• Text. Send it as the user wrote it: posts, comments, chat messages, usernames and bios.
• Images. Upload to private storage first, send the API a signed URL (it works while it is valid), and make the image public only after the check (image moderation).
• Mode. Use "mode": "detect". It returns the flags raised and their confidence, and it never costs more than the other modes. Today's flags judge the whole text or image: the answer says that something was found, not where. So the filter rejects or holds the whole post; it cannot hide one word or one part of a picture.

On 16 Oct 2026 the public status endpoint listed these text flags: bad_habits, hate, insult, profanity, racism, self_harm, sexism and sexual; and these image flags: hate, scam, sexual and violence. Your own account's list comes from GET /api/v1/flags (flags). Toxicity detection and NSFW detection show how the text flags and the sexual flag are used.

Example response (format from the API reference; values illustrative):

curl https://api.detectivision.ai/api/v1/moderation \
  -H "Api-Key: $DETECTIVISION_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "type": "text_moderation",
    "input": "Nobody wants you here. Delete your account, idiot.",
    "mode": "detect",
    "metadata": { "postId": "p_20931", "userId": "u_4417" }
  }'

{
  "id": 58213,
  "type": "text_moderation",
  "mode": "detect",
  "status": "completed",
  "flagged": true,
  "flags": [{ "flag": "insult", "confidence": 0.94 }],
  "checked": [
    "bad_habits",
    "hate",
    "insult",
    "profanity",
    "racism",
    "self_harm",
    "sexism",
    "sexual"
  ],
  "unchecked": [],
  "tookMs": 640,
  "usage": { "charged": 2, "remaining": 8731 },
  "metadata": { "postId": "p_20931", "userId": "u_4417" }
}

flagged is the verdict. checked lists every flag that was looked for; status is completed when all of them were. metadata comes back unchanged, so the result names the post it belongs to. tookMs and the other numbers are illustrative, not measurements.

The same check as a pre-post filter for a whole post, with its text and photos. Each request matches the API reference:

// On your server: the app sends the new post here, and the API key stays here.
const API = "https://api.detectivision.ai/api/v1/moderation";

// Your rules. This is an example: decide your own, flag by flag.
const REJECT = new Set(["hate", "racism", "sexism", "sexual", "violence"]);
const HOLD = new Set(["insult", "profanity", "bad_habits", "self_harm", "scam"]);

async function check(type, input, metadata) {
  try {
    const res = await fetch(API, {
      method: "POST",
      headers: { "Api-Key": process.env.DETECTIVISION_API_KEY, "Content-Type": "application/json" },
      body: JSON.stringify({ type, input, mode: "detect", metadata }),
      signal: AbortSignal.timeout(30_000),
    });
    return res.ok ? await res.json() : null; // errors are never charged
  } catch {
    return null; // network error or timeout
  }
}

// Returns "publish", "hold" (a moderator decides) or "reject".
export async function screenPost(post) {
  const metadata = { postId: post.id, userId: post.userId };
  const checks = post.imageUrls.map((url) => check("image_moderation", url, metadata));
  if (post.text.trim()) checks.push(check("text_moderation", post.text, metadata));
  let verdict = "publish";
  for (const result of await Promise.all(checks)) {
    if (!result || result.status !== "completed") {
      verdict = "hold"; // not fully checked: never publish it unseen
      continue;
    }
    for (const { flag } of result.flags) {
      if (REJECT.has(flag)) return "reject";
      if (HOLD.has(flag)) verdict = "hold";
    }
  }
  return verdict;
}

import os
import requests

API = "https://api.detectivision.ai/api/v1/moderation"

# Your rules. This is an example: decide your own, flag by flag.
REJECT = {"hate", "racism", "sexism", "sexual", "violence"}
HOLD = {"insult", "profanity", "bad_habits", "self_harm", "scam"}


def check(type_, input_, metadata):
    try:
        r = requests.post(
            API,
            headers={"Api-Key": os.environ["DETECTIVISION_API_KEY"]},
            json={"type": type_, "input": input_, "mode": "detect", "metadata": metadata},
            timeout=30,
        )
    except requests.RequestException:
        return None  # network error or timeout
    return r.json() if r.ok else None  # errors are never charged


def screen_post(post):
    """Return "publish", "hold" (a moderator decides) or "reject"."""
    metadata = {"postId": post["id"], "userId": post["user_id"]}
    checks = [("image_moderation", url) for url in post["image_urls"]]
    if post["text"].strip():
        checks.append(("text_moderation", post["text"]))
    verdict = "publish"
    for type_, input_ in checks:
        result = check(type_, input_, metadata)
        if result is None or result["status"] != "completed":
            verdict = "hold"  # not fully checked: never publish it unseen
            continue
        raised = {f["flag"] for f in result["flags"]}
        if raised & REJECT:
            return "reject"
        if raised & HOLD:
            verdict = "hold"
    return verdict

• The two sets are your policy. Which flags reject a post and which hold it is your decision; the code shows one choice. self_harm is held, not rejected, so a person can reach out to the user.
• Never publish unseen. An error, a timeout or a partial result (a flag that could not be checked right now) holds the post. Errors and partial results cost nothing (errors).
• Act above your own line. A flag is raised from a confidence of 0.5, and findings below that never come back. What you can choose is what each confidence leads to: for example, hold flags under 0.7 for a person and reject above it.
• Languages. Text checks are reliable in English, Spanish, Portuguese, French, German, Italian, Turkish, Arabic, Russian and Hindi. Text in other languages is checked, but the results are not reliable (text moderation). If your users write in other languages, reports and human review carry more of the load.
• Posts that can wait. Save the post as pending, send the check with "async": true, and decide when the result arrives by webhook; keep image URLs valid until then. It costs half of an answer your app waits for (async requests).
• Video, audio and live streams. These checks are coming soon. Until then, hold uploaded videos for a person.

For the flags that fit each kind of app, see online communities, dating apps and marketplaces.

2. Add a report button and a review queue

Put a Report option on every post, comment, message and profile. Save who reported what and when. Let users hide any post from their own feed at once, and hide what they report: the second rejection in thread 807358 listed "a mechanism for users to immediately remove posts from the feed".

Then a person has to act on reports, quickly. With Detectivision:

• Logs. A moderator can open a check in the dashboard's Logs and see its flags, your metadata and your actions. Store the check's id with the post, so a report leads straight to it.
• Your actions. Define your own actions in Logs, such as Remove post and Ban user; an account can have up to 20. A moderator takes one in Logs, or your admin tool calls POST /api/v1/moderation/{id}/actions.
• The webhook. Each action sends a moderation.action webhook to your endpoint (subscribe it to that event on the dashboard's Webhooks page), and your server carries the action out. Detectivision never removes content or bans anyone itself (metadata and actions).
• Alerts. Subscribe to moderation.flagged to tell a moderator when a check raised a flag (webhooks).

The receiving end in Node.js, with the Standard Webhooks library the docs point to (npm install standardwebhooks express). remove and ban stand for the action keys you set up in Logs:

import express from "express";
import { Webhook } from "standardwebhooks";

const app = express();
const webhook = new Webhook(process.env.DETECTIVISION_WEBHOOK_SECRET); // whsec_...
const done = new Set(); // in production, keep these ids in your database

app.post("/webhooks/detectivision", express.raw({ type: "application/json" }), (req, res) => {
  let event;
  try {
    event = webhook.verify(req.body, req.headers); // signature and timestamp
  } catch {
    return res.status(400).end();
  }
  res.status(204).end(); // answer at once, then do the work

  const id = req.headers["webhook-id"]; // the same on every retry
  if (done.has(id) || event.type !== "moderation.action") return;
  done.add(id);

  const { action, item } = event.data;
  const { postId, userId } = item.metadata ?? {};
  if (action.key === "remove" && postId) removePost(postId); // your own functions
  if (action.key === "ban" && userId) ejectUser(userId);
});

The handler checks the signature on the raw body before it trusts the message. It answers well within the 10 seconds the docs allow, and it skips retries of a message it has already handled. Taking actions and sending their webhooks costs no credits.

3. Let users block each other

Add Block to every profile and every chat. Once a user blocks someone, hide that person's posts, comments and messages from them at once, and stop new messages between the two. Enforce it on your server, so it holds on every device, and let users undo it in their settings. A moderation API plays no part here: blocking is your feature.

4. Publish contact details and make users accept your terms

• Contact. Put a support email address or a contact form inside the app, for example under Settings, and on the page your Support URL points to. Guideline 1.5 asks that "your app and its Support URL include an easy way to contact you", and the second rejection in thread 807358 listed contact information "in the app itself".
• Terms. Show your terms before a user can post, and require acceptance. Reviewers' messages ask that the terms "make it clear that there is no tolerance for objectionable content or abusive users". Say what happens to people who break them: their content is removed and their account is closed.
• Age rating. Set an age rating that matches what users can post. The second rejection in thread 807358 listed "Age rating must reflect 18+". Creator apps also need the age restriction that 1.2.1(a) describes.

What to write to App Review

Reply in App Store Connect. Apple's guidelines say that if your app was rejected and you "would like to provide additional information", you should "use App Store Connect to communicate directly with the App Review team". Describe each safeguard and where the reviewer can find it. Give the reviewer a demo account too. Guideline 2.1 asks you to "include demo account info (and turn on your back-end service!) if your app includes a login", and the rejection quoted in thread 807358 said that a demo video "is not sufficient".

Write only what the build does today. Fill in the brackets with what is true for your app:

Hello,

Thank you for the review. Version [1.4.0] (build [58]) adds the safeguards
that Guideline 1.2 asks for. Each one can be tried with the demo account
below.

1. Filtering: every [post, comment, profile and photo] is checked on our
   server before other users can see it. Flagged content is [rejected /
   held until a moderator reviews it]. To try it: [steps].
2. Reporting: every [post, comment, message and profile] has a Report
   option ([where to find it]). Reports go to our moderation queue, which
   [who] reviews [how often]. [What happens next, for example: content
   that breaks our terms is removed, and the account that posted it is
   closed.]
3. Blocking: every [profile and chat] has a Block option ([where to find
   it]). The blocked user's posts and messages disappear at once for the
   user who blocked them.
4. Contact: [Settings > Contact us] in the app, and [support URL].
5. Terms: new users must accept our Terms of Use before they can post.
   The terms say there is no tolerance for objectionable content or
   abusive users.

Demo account: [user name] / [password]

[Your name]

If you disagree with the outcome, Apple's guidelines point to an appeal.

Google Play asks for the same, and a little more

Google Play's User Generated Content policy covers apps that contain or feature UGC, including specialized browsers or clients that direct users to a UGC platform. It defines UGC as "content that users contribute to an app, and which is visible to or accessible by at least a subset of the app's users". Google asks those apps for moderation that is effective and ongoing, and spells out what that means:

Apps "whose primary purpose is featuring objectionable UGC" are removed from Google Play, and so are apps that end up used mainly for it. The filtering in step 1 serves both stores; the other rows are features you build once.

Kids Category apps: ask App Review first

The Kids Category is the App Store category for apps designed for children. Guideline 1.3 says: "Kids Category apps may not send personally identifiable information or device information to third parties." Guideline 5.1.4 counts "photos, videos, drawings, the ability to chat" as personal information: an app that collects, transmits or can share it from a minor must have a privacy policy and follow children's privacy laws (both as read on 16 Oct 2026).

A moderation API is a third party: checking a child's message or photo means sending it to an outside service. If your app is in the Kids Category, ask App Review before you send children's content to any outside service, ours included. We cannot tell you how App Review will answer.

What this does not do

What a moderation API, ours included, will not do for you:

• Get your app through review. App Review decides. The API covers one safeguard out of four.
• Build the rest. Report and block buttons, contact details and terms are your features.
• Review reports. Detectivision gives you Logs, your own actions and webhooks, not moderators. A person on your side works the queue.
• Act on your platform. It never removes a post or closes an account. Your server does, when the moderation.action webhook arrives.
• Mark or mask part of a post. Today's flags judge the whole text or image. There are no word positions, no boxes, and no masked or blurred copies.
• Check every language equally. Text checks are reliable in English, Spanish, Portuguese, French, German, Italian, Turkish, Arabic, Russian and Hindi only.
• Check video, audio or live streams. Those checks are coming soon.
• Report what scores below 0.5. Findings under a flag's threshold never come back.
• Verify ages or match known abuse images. Detectivision does no age verification and no hash matching.
• Make any kind of app acceptable. Apple says apps used primarily for "pornographic content, Chatroulette-style experiences, random or anonymous chat, objectification of real people (e.g. 'hot-or-not' voting), making physical threats, or bullying" do not belong on the App Store. A filter does not change that.

Plans and the free trial are on the pricing page.

Start the free trial

Or read the quickstart first: an API key and your first check, in a few steps.