Users can block or mute other users
Why it matters
Apple's guideline 1.2 explicitly requires apps with user interaction features to offer users the ability to block abusive users. A direct messaging app, a commenting feature, or a following system without a block mechanism leaves users with no recourse against harassment. The reviewer will look for it, not find it, and reject. Beyond review compliance, a missing block feature has real safety consequences: users who cannot escape harassment churn immediately and leave negative reviews. The block relationship must be server-side — client-only blocks that reset on reinstall or across devices are not acceptable.
Severity rationale
Medium because Apple guideline 1.2 mandates block/mute capability for any app with user-to-user interaction, with rejection as the direct consequence of omission.
Remediation
Add a block action to user profiles and message threads, enforced server-side.
// src/screens/UserProfileScreen.tsx
async function handleBlockUser(targetUserId: string) {
await fetch('/api/users/block', {
method: 'POST',
body: JSON.stringify({ blocked_user_id: targetUserId }),
});
Alert.alert('User blocked', 'You will no longer see their content.');
navigation.goBack();
}
In your API, filter blocked users from feed queries, message threads, and comment lists. Add a "Blocked Users" screen in Settings so users can review and unblock. Store the block relationship in a blocked_users table — never only in client state.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the App Store Review Blockers Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- external · apple-guideline-1.2-ugc-block — Apple App Store Review Guideline 1.2 — User-Generated Content (block/mute abusive users)
Taxons
History
- 2026-04-18·v1.0.0·Initial import from app-store-review-blockers·automated