Linea guida 4.3(a) Design Spam: come risolverlo, con 4.3(b) e 4.2.6 per app da template e AI (2026)

Un rifiuto per la linea guida 4.3(a) Design Spam è uno dei messaggi di App Review più difficili da gestire, perché raramente dice a quale app somiglia la tua. Colpisce app da template, clienti white-label e app generate con l'AI molto più spesso di altre. Questa guida distingue la 4.3(a) dalla 4.3(b) e dalla 4.2.6, analizza come altri sviluppatori hanno superato il rifiuto e ti fornisce un modello di risposta e una checklist da completare prima di inviare di nuovo l'app. Per altri tipi di rifiuto, consulta la guida ai rifiuti linea guida per linea guida.

Cosa significa la linea guida 4.3(a) Design Spam?

La linea guida 4.3(a) significa che Apple ritiene che il tuo invio sia sostanzialmente la stessa app di una già inviata: più bundle ID di un'unica app oppure una copia quasi identica di quella di qualcun altro. La soluzione è consolidare i duplicati o rendere l'esperienza di base chiaramente diversa.

A novembre 2026, le App Review Guidelines dicono: "Non creare più Bundle ID della stessa app (ad esempio, inviando un'app di mappe separata per ogni città del mondo invece di un'unica mappa mondiale che consenta agli utenti di cercare qualsiasi città)." L'alternativa suggerita da Apple è: "valuta di inviare un'unica app e di offrire le varianti tramite acquisto in-app." La 4.3(a) è contrassegnata dall'icona della chiave, quindi si applica anche alla notarizzazione delle app iOS e iPadOS distribuite al di fuori dell'App Store.

Il testo di rifiuto che gli sviluppatori ricevono di solito è: "Guideline 4.3(a) - Design - Spam. Abbiamo notato che la tua app condivide un binario, metadati e/o un concetto simili ad app inviate all'App Store da altri sviluppatori, con solo differenze minime." In questa frase ci sono tre fattori scatenanti (binario, metadati, concetto), e ciascuno di essi può causare il rifiuto.

In cosa la 4.3(a) è diversa dalla 4.3(b) e dalla 4.2.6?

La 4.3(a) riguarda i duplicati, la 4.3(b) le app che non aggiungono nulla di nuovo a una categoria già affollata e la 4.2.6 le app create da template e inviate dall'account sbagliato. Ognuna richiede una soluzione diversa, quindi controlla prima il numero esatto della linea guida indicato nel rifiuto.

Il testo attuale della 4.3(b) avverte inoltre che Apple "potrebbe rimuovere queste app dall'App Store in futuro se non vengono aggiornate, migliorate o non attirano clienti", e che categorie a basso impegno come i giochi alcolici e le app di peti possono portare all'esclusione dall'Apple Developer Program se inviate ripetutamente. Per le altre regole riviste di recente da Apple, consulta le nostre modifiche alle App Review Guidelines di ottobre 2026.

Perché le app da template e generate con l'AI vengono segnalate come spam?

Le app da template e generate con l'AI vengono segnalate perché molte condividono lo stesso codice di partenza, gli stessi layout delle schermate e testi simili nello store, il che corrisponde a tutti e tre i fattori: binario, metadati e concetto. Essere proprietari del codice non esenta un'app se il risultato somiglia a centinaia di altre.

Gli app builder basati sull'AI producono spesso lo stesso onboarding, la stessa tab bar e lo stesso insieme generico di funzionalità ("monitora le abitudini, ottieni insight con l'AI"), e anche la descrizione generata per l'App Store spesso è identica. Se hai pubblicato tramite un builder, controlla chi compare come venditore. La 4.2.6 dice che i servizi di template "non dovrebbero inviare app per conto dei propri clienti", quindi l'app deve essere pubblicata con l'account sviluppatore del proprietario dei contenuti. La nostra guida alla pubblicazione con Base44 e la guida alla pubblicazione con Lovable spiegano cosa resta a tuo carico dopo l'esportazione.

Cosa hanno fatto altri sviluppatori per risolvere un rifiuto 4.3(a)?

I casi riportati pubblicamente mostrano che le sole modifiche grafiche raramente funzionano. Consolidare le app duplicate e scrivere una risposta specifica su ciò che rende l'app diversa funziona meglio.

• Unione in un'app esistente (GitHub). Un team che pubblicava un'app VoIP basata su Linphone ha riferito nella issue #936 di linphone-iphone che un nuovo set di icone e una nuova combinazione di colori non avevano superato la 4.3(a). Hanno concluso che il conflitto era con un'altra app basata su Linphone sullo stesso account. Hanno inserito le modifiche in quell'app esistente come aggiornamento, ed è stata approvata "quasi subito".
• Spiegare l'unicità (Godot Forum). Uno sviluppatore di giochi sul Godot Forum sospettava che il binario condiviso del motore corrispondesse ad altri giochi Godot. Sia la riduzione della build sia la spiegazione che usava Godot sono state respinte. Una risposta che "elencava i punti chiave che secondo me rendevano il mio gioco divertente e unico rispetto ad altri giochi dello stesso genere" ha portato all'approvazione.
• Gli screenshot non bastavano (Apple Developer Forums). In una discussione sugli Apple Developer Forums, uno sviluppatore ha raccontato che un rappresentante di Apple aveva indicato gli screenshot, e che "metadati" può significare titolo, sottotitolo, parole chiave o screenshot. Anche con screenshot completamente nuovi ha ricevuto lo stesso rifiuto, per un aggiornamento di un'app che esisteva da 2–3 anni.

Il filo conduttore: le modifiche estetiche (icone, colori, screenshot) sono fallite in tutti e tre i casi. Ha funzionato eliminare il duplicato sull'account oppure fornire al revisore motivi concreti, a livello di funzionalità, per cui l'app è diversa.

Come si risolve un rifiuto 4.3(a) passo dopo passo?

Per risolvere un rifiuto 4.3(a), prima trova il duplicato, poi apporta modifiche reali al prodotto e infine rispondi ad App Review con dettagli specifici prima di inviare di nuovo. Reinviare la stessa build con una nuova icona è il modo più comune per essere rifiutati di nuovo.

1. Leggi il numero esatto della linea guida nella sezione App Review di App Store Connect. Se indica 4.2.6 o 4.3(b), segui invece la riga corrispondente della tabella qui sopra.
2. Elenca tutte le app del tuo account, pubblicate o rimosse, che condividono codice, template, concetto o design con quella rifiutata. Se ne trovi una, uniscile in un'unica app con varianti in-app, oppure pubblica le modifiche come aggiornamento dell'app già live.
3. Cerca nell'App Store le parole chiave della tua categoria e annota i primi risultati. Scrivi cosa fa la tua app che nessuna di queste fa.
4. Cambia almeno un flusso principale (fonte dei dati, funzionalità principale, modello di interazione), non solo il tema.
5. Riscrivi nome, sottotitolo, parole chiave, descrizione e screenshot in modo che descrivano le tue funzionalità specifiche e non rimanga alcun testo generico del template.
6. Rispondi in App Store Connect usando il modello qui sotto. La pagina App Review di Apple offre anche appuntamenti Webex di 30 minuti se vuoi fare domande direttamente a un revisore sulle linee guida.
7. Se ritieni che il revisore abbia frainteso l'app, presenta un solo ricorso all'App Review Board. Apple chiede di "inviare un solo ricorso per ogni invio che non ha superato la revisione" e di rispondere prima alle richieste di informazioni.

Cosa deve dire la risposta ad App Review?

Una buona risposta indica le funzionalità specifiche che rendono l'app diversa, conferma che sul tuo account non ci sono app duplicate e mostra al revisore dove si può vedere ciascuna differenza. Mantienila breve, concreta e cortese.

Hello App Review,

Thank you for the feedback on Guideline 4.3(a). We have reviewed our account
and confirm [App Name] is our only app in this category. [We removed /
merged "Old App" into this app in version X.Y.]

What [App Name] does that similar apps do not:
1. [Feature] - e.g. syncs with the user's school timetable via [API];
   see Home > Schedule.
2. [Feature] - e.g. offline lesson plans authored by our team, not
   generated or scraped; see Library.
3. [Feature] - e.g. teacher-to-parent messaging; see the demo account.

This version also changes [core flow] and replaces all metadata and
screenshots to reflect these features.

Demo account: [username] / [password]

We are happy to provide more detail or join a call.

Thank you,
[Name]

Se una funzionalità richiede l'accesso, fornisci al revisore credenziali funzionanti. La nostra guida all'account demo per la revisione dell'App Store spiega come configurarne uno.

Cosa deve includere una checklist di differenziazione prima del nuovo invio?

Una checklist di differenziazione deve coprire account, binario, metadati e concetto, i quattro ambiti che la 4.3 esamina. Spunta ogni voce prima di premere di nuovo Invia per la revisione.

• Account: nessun'altra app, pubblicata o rimossa, condivide lo stesso template, concetto o design.
• Account: l'app è inviata dall'account sviluppatore del proprietario dei contenuti (4.2.6).
• Binario: schermate di esempio del template, dati demo e branding segnaposto sono stati rimossi.
• Binario: esiste almeno una funzionalità principale che manca ai primi risultati della categoria.
• Metadati: nome, sottotitolo e parole chiave descrivono il tuo valore specifico, non la categoria in generale.
• Metadati: gli screenshot mostrano le tue funzionalità distintive nei primi due fotogrammi.
• Concetto: sai spiegare in una frase perché un utente dovrebbe scegliere questa app rispetto ai primi cinque risultati.
• Note per la revisione: le differenze e un account demo sono elencati, così il revisore non deve cercarli.

Se sei stato rifiutato per la 4.3 più di una volta e non sai cosa cambiare, il nostro servizio di pubblicazione sull'App Store prepara la revisione e gestisce con te il feedback dei rifiuti, a $599 per entrambi gli store (le quote degli account sviluppatore sono a parte).