# Guideline 1.2 User-Generated Content: cosa chiede Apple

> Guideline 1.2: se i tuoi utenti pubblicano contenuti, servono filtro, segnalazione, blocco, contatto e termini accettati. Check-list per Expo e Supabase.

Pagina originale: [Guideline 1.2 User-Generated Content: cosa chiede Apple](https://devoria.fr/it/blog/guideline-1-2-user-generated-content-apple)
Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi)
Pubblicazione: 2026-11-04
Ultima revisione dei contenuti: 2026-11-04


La guideline 1.2 si applica appena degli utenti pubblicano qualcosa che altri vedono: un messaggio, una foto, una recensione e, secondo me, anche un semplice nickname in una classifica. In quel caso il testo di Apple richiede un filtro, una segnalazione seguita da una risposta rapida, un blocco e un contatto pubblicato. **I messaggi di rifiuto aggiungono un quinto requisito: termini d'uso accettati, che non tollerano né contenuti offensivi né utenti molesti.**

Questa guida non racconta un rifiuto. Mostra cosa ho messo in piedi in TradaZen, la mia app per allenarsi al trading, quando le sue classifiche hanno iniziato a mostrare nickname scelti dai giocatori. Per una panoramica dei motivi di rifiuto, leggi piuttosto [perché Apple rifiuta un'app](https://devoria.fr/it/blog/app-rifiutata-da-apple-perche-casi-reali).

## Cosa dice la guideline 1.2?

La 1.2, "User-Generated Content", si trova nella sezione 1, "Safety", delle [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#user-generated-content). Riguarda le app con contenuti degli utenti o un servizio di social network. Per evitare abusi, queste app "must include" quattro protezioni:

- "A method for filtering objectionable material from being posted to the app": **un filtro che blocca i contenuti offensivi prima che vengano pubblicati**.
- "A mechanism to report offensive content and timely responses to concerns": un modo per segnalare un contenuto, e una risposta rapida alle segnalazioni.
- "The ability to block abusive users from the service": la possibilità di bloccare un utente molesto.
- "Published contact information so users can easily reach you": un contatto pubblicato, facile da trovare.

La versione attuale del testo, aggiornata l'8 giugno 2026, va oltre. Ricorda che è tua responsabilità rimuovere i contenuti che violano la regola, i tuoi termini d'uso o le tue regole della community. Se Apple ne trova, ti chiede di rimuoverli e di fornire un piano di miglioramento, e nel frattempo può togliere l'app dallo store.

Il testo elenca anche le app che non hanno posto sull'App Store: quelle che servono soprattutto alla pornografia, alla chat casuale o anonima stile Chatroulette, a valutare l'aspetto fisico di persone reali, alle minacce o alle molestie. **Per questi usi, le quattro protezioni non bastano.** La 1.2.1 aggiunge regole per le app di creator, in particolare un controllo dell'età per i contenuti che superano la classificazione dell'app.

## La tua app è interessata?

Il questionario sulla classificazione per età di App Store Connect dà una buona definizione. Parla di [contenuti generati dagli utenti](https://developer.apple.com/help/app-store-connect/reference/app-information/age-ratings-values-and-definitions) quando contenuti creati dagli utenti vengono ampiamente diffusi nell'app: video, foto, testi o audio. La messaggistica tra utenti la tratta a parte.

| Cosa vedono gli altri       | Interessata?   |
| --------------------------- | -------------- |
| Messaggi tra membri         | Sì             |
| Foto o recensioni pubbliche | Sì             |
| Nickname in una classifica  | Sì, secondo me |
| Note private                | No             |
| Contenuti scritti da te     | No             |

Apple non cita i nickname. Io però li tratto come contenuti degli utenti: chiunque può sceglierne uno offensivo, e altri giocatori lo vedono. È la scelta che ho fatto per le classifiche di TradaZen.

## I 5 meccanismi da programmare, con Expo e Supabase

Il messaggio di rifiuto 1.2, così come uno sviluppatore l'ha pubblicato sui [forum di Apple](https://developer.apple.com/forums/thread/807358) a fine 2025, elenca le misure richieste. Inizia con "Require that users agree to terms (EULA)" e finisce con un requisito di tempo: agire sulle segnalazioni "within 24 hours", rimuovendo il contenuto ed escludendo il suo autore.

| Meccanismo          | Dove programmarlo                   |
| ------------------- | ----------------------------------- |
| Termini accettati   | Schermata e profilo                 |
| Filtro              | Server, prima della visualizzazione |
| Segnalazione        | Pulsante e tabella                  |
| Blocco              | Tabella e regola di accesso         |
| Contatto pubblicato | App e scheda App Store              |

Gli esempi SQL qui sotto vanno adattati al tuo schema. Si basano sulle [regole di accesso per riga di Supabase](https://supabase.com/docs/guides/database/postgres/row-level-security), che valgono anche se qualcuno aggira la tua app.

### 1. Termini accettati, senza tolleranza per gli abusi

I tuoi termini d'uso devono dire nero su bianco che nessun contenuto offensivo e nessun utente molesto sono tollerati. Esempio di clausola, da far rileggere, non è una consulenza legale: "Nessun contenuto offensivo, d'odio, sessuale o molesto è tollerato. Un contenuto segnalato può essere rimosso e il suo autore escluso, senza preavviso."

**Una frase passiva sotto un pulsante di registrazione non prova il consenso: chiedi un gesto esplicito.** Una schermata con un link ai termini e un pulsante "Accetto", prima della prima pubblicazione. Salva nel profilo la data e la versione accettate, poi vieta la pubblicazione finché mancano:

```sql
create policy "pubblicare dopo i termini" on public.posts
for insert to authenticated
with check (
  auth.uid() = author_id
  and exists (
    select 1 from public.profiles p
    where p.id = auth.uid() and p.cgu_acceptees_le is not null
  )
);
```

### 2. Un filtro prima che gli altri vedano il contenuto

Il filtro sta sul server, perché il codice dell'app può essere aggirato. Una copia nell'app serve solo ad avvisare subito l'utente.

In TradaZen, una funzione nel database controlla ogni nickname, e l'app applica la stessa lista per avvisare il giocatore. Le tengo identiche. Lato server, un nickname offensivo non viene rifiutato in scrittura: **viene sostituito con un nickname neutro in visualizzazione, così non blocchi qualcuno per un falso positivo**.

I falsi positivi arrivano in fretta. In TradaZen, una prima versione del filtro censurava nomi come Dominique, Monique o Véronique, perché contengono un pezzo di parolaccia. La correzione: cercare parole intere, non pezzi di parole. E siccome l'app è venduta in giapponese e in cinese, il filtro copre anche queste lingue.

### 3. Una segnalazione, gestita entro 24 ore

Ogni contenuto pubblicato ha un pulsante "Segnala". In TradaZen, un nickname segnalato nella classifica della lega viene subito mostrato con un'etichetta neutra sul telefono di chi segnala. La segnalazione parte poi verso il server, e viene reinviata più tardi se il telefono è offline.

Lato database, una tabella delle segnalazioni, una sola per persona e per contenuto:

```sql
create table public.reports (
  id uuid primary key default gen_random_uuid(),
  reporter_id uuid not null references auth.users (id) on delete cascade,
  target_id uuid not null,
  reason text,
  created_at timestamptz not null default now(),
  unique (reporter_id, target_id)
);
alter table public.reports enable row level security;
create policy "le mie segnalazioni" on public.reports
for insert to authenticated
with check (auth.uid() = reporter_id);
```

In TradaZen, **un nickname segnalato da più giocatori viene sostituito con un nickname neutro**, e le segnalazioni non vengono mai mostrate alla persona segnalata. Una precauzione generale: l'identificativo usato per la segnalazione non deve poter essere modificato dall'autore del contenuto, altrimenti può sfuggire all'oscuramento.

L'oscuramento automatico non sostituisce la tua decisione. Per rispettare le 24 ore, fatti avvisare a ogni segnalazione: un [webhook di database Supabase](https://supabase.com/docs/guides/database/webhooks) può chiamare una funzione server che ti manda un messaggio. La chiave che permette di rimuovere il contenuto resta sul server, come spiego in [chiave API segreta in un'app Expo](https://devoria.fr/it/blog/chiave-api-segreta-app-expo).

### 4. Un blocco che agisce subito

Una tabella dei blocchi, poi una regola di accesso che toglie i contenuti delle persone bloccate dal feed di chi blocca:

```sql
create policy "senza i bloccati" on public.posts
for select to authenticated
using (
  not exists (
    select 1 from public.blocks b
    where b.blocker_id = auth.uid() and b.blocked_id = posts.author_id
  )
);
```

In TradaZen, aggiungi un amico tramite un codice, e puoi rimuoverlo e bloccarlo. **Un amico bloccato sparisce dalla lista, anche se manda di nuovo una richiesta.**

### 5. Un contatto pubblicato, facile da trovare

Metti un indirizzo di contatto nelle impostazioni dell'app, e in App Store Connect un URL di supporto che risponde davvero. In TradaZen, l'indirizzo di supporto compare nella privacy policy e nei termini d'uso. Cosa devono contenere queste pagine lo trovi in [privacy policy di un'app](https://devoria.fr/it/blog/privacy-policy-app-ios-apple).

Ultimo punto: decidi cosa succede ai contenuti di una persona che elimina il suo account. Il `on delete cascade` qui sopra cancella le sue segnalazioni insieme all'account. La ricetta completa è in [eliminazione dell'account su iOS](https://devoria.fr/it/blog/eliminazione-account-ios-flusso-test-apple).

## Cosa mostra TradaZen nella sua privacy policy

Questi meccanismi sono descritti pubblicamente nella privacy policy di TradaZen, completata a settembre 2026 con l'arrivo delle leghe e degli amici: "I nickname passano attraverso un filtro automatico; puoi segnalare un nickname inappropriato nella classifica, e rimuovere e bloccare un amico." La stessa policy precisa che l'e-mail e il diario non vengono mai mostrati agli altri giocatori. Il contesto dell'app è nel [caso di studio TradaZen](https://devoria.fr/it/blog/caso-studio-tradazen-lanciare-app-iphone).

## Cosa rispondere ad Apple dopo un rifiuto 1.2

Di' al reviewer dove trovare ogni meccanismo, nella tua risposta e nelle note per la revisione. Queste funzioni vivono nell'app: il reviewer testa il codice incluso nella build, quindi prevedi una nuova build. La procedura per [rispondere ad App Review](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/reply-to-app-review-messages/) è la stessa delle altre regole. Ecco un modello in inglese, da adattare, tenendo solo ciò che è vero nella tua app:

```text
Hello,

Thank you for your review. Build X includes the precautions
listed in Guideline 1.2:

- Terms: users accept our terms, with zero tolerance for
  objectionable content and abusive users, before posting.
- Filter: posts and usernames are checked on our server
  before other users can see them.
- Report: tap "..." on any post, then "Report".
- Block: tap "..." on any post, then "Block user". Their
  content disappears immediately.
- Reports notify us instantly; we act on them within 24 hours.
- Contact: Settings > Contact us, and our support URL.

Best regards,
```

Se un meccanismo manca nella build, una risposta non basterà. Come per la [guideline 2.1](https://devoria.fr/it/blog/guideline-2-1-app-store-rifiuto), Apple giudica la build che ha in mano.

## La check-list 1.2 prima dell'invio

- Hai elencato tutto ciò che un utente pubblica e che altri vedono, nickname compresi.
- I tuoi termini vietano i contenuti offensivi e gli abusi, e l'app chiede un "Accetto" esplicito.
- Il filtro gira sul server, cerca parole intere e copre le lingue della tua scheda.
- Ogni contenuto ha un pulsante "Segnala", e ogni segnalazione ti avvisa subito.
- Sai rimuovere un contenuto ed escludere il suo autore in meno di 24 ore.
- Bloccare un utente toglie subito i suoi contenuti.
- Un indirizzo di contatto è visibile nell'app, e l'URL di supporto risponde.
- Il questionario sulla classificazione per età dichiara i contenuti degli utenti, e la messaggistica se la tua app ce l'ha.
- Le note per la revisione dicono dove trovare ogni meccanismo, con un account demo.

## Correggere il rifiuto prima di inviare di nuovo l'app

Se la tua app è appena stata rifiutata per la 1.2, il [Review Kit](https://devoria.fr/it/kits/app-review) raccoglie quello che controllo prima di ogni invio, con due skill che rileggono il tuo progetto in Claude Code e preparano la tua risposta se Apple rifiuta. Per uno sguardo umano, [prenota un'ora con me](https://devoria.fr/it/coaching): leggiamo il messaggio insieme e guardiamo il tuo flusso di moderazione. Il percorso completo dopo un rifiuto è nella pagina [app rifiutata da Apple](https://devoria.fr/it/expertise/app-rifiutata-da-apple).

Se stai preparando la tua prima uscita, [fai il tuo diagnostic gratuito](https://devoria.fr/it/diagnostic): ti dice da quale tappa partire e ti manda la mia checklist anti-rifiuto Apple.

Nessuno può garantire che Apple accetterà la tua app. Questi cinque meccanismi, ben visibili, tolgono almeno questo motivo dalla lista.

## Domande frequenti

### Cosa significa "Guideline 1.2 - Safety - User-Generated Content"?

È il titolo del rifiuto nel messaggio di Apple. Significa che la tua app mostra contenuti creati dagli utenti senza tutte le protezioni richieste: filtro, segnalazione gestita in fretta, blocco, contatto pubblicato e termini d'uso accettati.

### Un nickname in una classifica conta come contenuto degli utenti?

Il testo di Apple non lo dice. Io lo tratto come tale, perché un nickname è scelto liberamente e visto da altri giocatori. In TradaZen, i nickname delle classifiche passano attraverso un filtro, possono essere segnalati e vengono sostituiti con un nickname neutro se creano problemi.

### Bisogna davvero gestire le segnalazioni entro 24 ore?

È quello che chiede il messaggio di rifiuto di Apple. Il testo della regola parla di risposte rapide. Un filtro automatico quindi non basta: serve qualcuno che rimuova il contenuto ed escluda il suo autore. L'oscuramento automatico dopo più segnalazioni ti aiuta a reggere nel frattempo.

### I termini d'uso vanno accettati nell'app?

È il modo più sicuro. Il messaggio di rifiuto chiede che gli utenti accettino termini che non tollerano né contenuti offensivi né utenti molesti. Un link in fondo a una pagina non prova il consenso. Una schermata con un pulsante "Accetto", prima della prima pubblicazione, non lascia dubbi.

### Un'app di chat anonima può superare la guideline 1.2?

Il testo attuale cita la chat casuale o anonima tra gli usi che non hanno posto sull'App Store. Un'app che serve soprattutto a questo può essere rimossa senza preavviso, anche con un filtro, una segnalazione e un blocco.


## Il tuo progetto

[Review Kit](https://devoria.fr/it/kits/app-review): La mia checklist per la review dell'App Store, i rifiuti di Apple che ho risolto, quella di Google Play e tre skill per Claude Code. 49 €.

[iOS & Android Kit](https://devoria.fr/it/kits/ios): Crea la tua app iPhone e Android con Claude Code: il codice di partenza delle mie app, il percorso fino agli store e tutti i kit. 99 €.

[Diagnosi: cosa ti separa dalla tua app per iPhone](https://devoria.fr/it/diagnostic): 7 domande, 60 secondi: scopri cosa ti blocca davvero nel pubblicare la tua app per iPhone, il tuo percorso in 4 tappe e il kit giusto per te.