User-generated content has a reporting or flagging mechanism

Apple's App Store Review Guideline 1.2 explicitly requires apps with user-generated content to provide a mechanism for users to flag objectionable content. Missing a report button on posts, comments, or messages is one of the most common UGC-related rejection reasons. Without it, reviewers cannot verify that your platform has any safeguard against harassment, hate speech, or illegal content — and they will reject on that basis. A stub report button that calls console.log instead of hitting an API has the same outcome: the content has nowhere to go, and your platform has no moderation capability.

Add a "Report" action to every UGC surface — posts, comments, messages, and profiles.

// src/components/PostContextMenu.tsx
function PostContextMenu({ postId }: { postId: string }) {
  async function handleReport(reason: string) {
    await fetch('/api/reports', {
      method: 'POST',
      body: JSON.stringify({ content_id: postId, content_type: 'post', reason }),
    });
    Alert.alert('Thanks for your report', "We'll review it within 24 hours.");
  }

  return (
    <ActionSheet options={['Spam', 'Harassment', 'Inappropriate', 'Cancel']}
      onSelect={i => i < 3 && handleReport(['spam', 'harassment', 'inappropriate'][i])} />
  );
}

Route reports to a database table your team can act on. Show a confirmation after submission. The report flow must complete end-to-end — not log to console.

• ID: app-store-review-blockers.content-moderation.ugc-reporting-mechanism

• Severity: high

• What to look for: Count all relevant instances and enumerate each. If UGC was detected in Stack Detection, look for report/flag UI. Search for components with names containing report, flag, abuse, inappropriate in .tsx, .jsx, .dart, .swift, .kt files. Look for long-press context menus or three-dot menus on posts, comments, messages, or profiles that include a "Report" action. Check API routes or service calls for reportContent, flagPost, reportUser or equivalent. Also look for the post-report flow: a confirmation dialog or a "Thanks for your report" state.

• Pass criteria: Each piece of user-generated content (posts, comments, messages, profiles) has a visible, accessible way to report it. At least 1 implementation must be verified. The report flow completes (sends to a backend or logging system).

• Fail criteria: UGC screens exist with no visible report or flag mechanism. Report UI exists but does not complete (the API call is stubbed or missing).

• Skip (N/A) when: App has no user-generated content — no posts, comments, messages, reviews, or any content created by one user and shown to another.

• Detail on fail: "Post feed in src/screens/FeedScreen.tsx has no report option on posts" or "Report button exists but calls a stub function that logs to console rather than sending to API"

• Remediation: Apple's App Store Review Guideline 1.2 requires apps with UGC to have a mechanism for users to report objectionable content. Missing this is a common rejection cause.

  1. Add a "Report" option to every UGC surface (long-press menu, three-dot context menu, swipe action)
  2. The report should present categories (Spam, Harassment, Inappropriate Content, etc.)
  3. Send the report to your backend with: content_id, content_type, reporter_user_id, reason
  4. Show a thank-you confirmation ("Thanks for your report. We'll review it within 24 hours.")
  5. Store reports in a moderation queue that your team (or moderation system) can act on

  Review the configuration in src/ or app/ directory for implementation patterns.