# Guideline 4.2 Minimum Functionality: app rifiutata da Apple

> Guideline 4.2: Apple rifiuta un'app che non offre più di un sito web. Metti una funzione nativa al centro dell'uso e mostrala al reviewer.

Pagina originale: [Guideline 4.2 Minimum Functionality: app rifiutata da Apple](https://devoria.fr/it/blog/guideline-4-2-minimum-functionality-app-rifiutata)
Autore: [Mehdi Azizi](https://devoria.fr/it/mehdi-azizi)
Pubblicazione: 2026-10-19
Ultima revisione dei contenuti: 2026-10-19


La guideline 4.2, "Minimum Functionality", rifiuta un'app che non offre niente di più di un sito web, o troppo poco perché valga la pena tenerla. **Il rimedio non è accumulare funzioni native: è metterne una al centro dell'uso, poi dire al reviewer dove trovarla.** La correzione passa quasi sempre da una nuova build.

Pubblico le mie app iOS: Solys, TradaZen e Nolera sono sull'App Store. Questa guida si basa sul testo ufficiale di Apple, letto il 15 ottobre 2026, e su rifiuti 4.2 pubblicati da sviluppatori sui forum di Apple. Le app rifiutate citate più sotto sono esempi. Per il quadro completo di tutti i motivi, leggi piuttosto [perché Apple rifiuta un'app](https://devoria.fr/it/blog/app-rifiutata-da-apple-perche-casi-reali).

## Cosa dice la guideline 4.2?

La 4.2 si trova nella sezione 4, "Design", delle [App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/#4.2). La prima frase fissa il criterio: "Your app should include features, content, and UI that elevate it beyond a repackaged website." In altre parole, la tua app deve offrire funzioni, contenuti e un'interfaccia che la mettano al di sopra di un sito web rimesso in una scatola.

Il testo aggiunge due idee. Un'app che non è davvero utile, unica o "app-like" non ha posto sull'App Store. E un'app che non offre né intrattenimento duraturo né un'utilità sufficiente può essere rifiutata. **La 4.2 giudica quindi due cose: la differenza rispetto al web e la quantità di valore.**

## Le sotto-regole che il messaggio può citare

| Sotto-regola | Cosa chiede Apple                              | Il rifiuto tipico                       |
| ------------ | ---------------------------------------------- | --------------------------------------- |
| 4.2          | Andare oltre un sito web                       | Sito mostrato in una WebView            |
| 4.2.1        | Una vera esperienza di realtà aumentata        | Un modello 3D appoggiato nella vista AR |
| 4.2.2        | Non solo marketing o link                      | App vetrina, aggregatore, link          |
| 4.2.3        | Un'app autonoma, download chiari               | App che richiede un'altra app           |
| 4.2.6        | Niente app ricavate da un template commerciale | Template inviato da un fornitore        |

Tre precisazioni. La 4.2.2 fa un'eccezione per i cataloghi: "Other than catalogs, apps shouldn't primarily be marketing materials, advertisements, web clippings, content aggregators, or a collection of links." Un catalogo di prodotti può quindi passare. Una brochure pubblicitaria, no.

La 4.2.3 ha due commi. Il (i) chiede che l'app funzioni da sola, senza installare un'altra app. Il (ii) chiede, se l'app deve scaricare risorse al primo avvio, di indicare la dimensione del download e di chiedere il consenso prima.

La 4.2.6, sui template commerciali e i servizi di generazione di app, è spiegata nella [guida alla guideline 4.3](https://devoria.fr/it/blog/guideline-4-3-design-spam-app-rifiutata), perché va di pari passo con la regola anti-spam.

## I due messaggi 4.2 più frequenti

Il messaggio di Apple si apre con l'intestazione "Guideline 4.2 - Design - Minimum Functionality". Il resto dice quale dei due problemi ha visto il reviewer. Ecco due formulazioni pubblicate da sviluppatori sui forum di Apple. Risalgono a qualche anno fa: il testo esatto può essere cambiato, le due famiglie no.

**L'app sembra un sito.** "Your app provides a limited user experience as it is not sufficiently different from a mobile browsing experience." Questo messaggio, [pubblicato sui forum di Apple](https://developer.apple.com/forums/thread/108931), contiene una frase decisiva: "Including iOS features such as push notifications, Core Location, and sharing do not provide a robust enough experience to be appropriate for the App Store."

**L'app è troppo scarna.** "We found that the usefulness of your app is limited by the minimal amount of content or features it includes." Questo [secondo messaggio](https://developer.apple.com/forums/thread/115230) chiede di rivedere il concept e riconosce che nessuna regola numerica definisce cosa sia utile o divertente.

> Aggiungere notifiche, localizzazione e un pulsante di condivisione a un sito incapsulato non basta: Apple l'ha scritto nei suoi stessi rifiuti.

## Quattro casi tipici di rifiuto 4.2

I quattro casi qui sotto sono esempi costruiti per illustrare la regola, non app reali.

### Il sito web incapsulato

Esempio: una palestra mostra il suo sito mobile in una WebView, con una barra a schede nativa sopra. Orari, prenotazione e account sono pagine web. Il reviewer ci ritrova quello che gli mostrerebbe Safari. Apple lo dice nella sua [pagina App Review](https://developer.apple.com/distribute/app-review/): un sito servito in un'app iOS, contenuti web non adattati a iOS o interazioni web limitate non fanno un'app di qualità.

Cosa farei io: ricostruire in nativo le schermate dell'azione principale, qui orari e prenotazione. Poi aggiungere quello che il sito non sa fare: un promemoria prima della lezione, gli orari consultabili senza rete, la prossima lezione in un widget.

### L'app troppo semplice

Esempio: un'app che mostra una citazione al giorno, e nient'altro. In dieci secondi l'hai vista tutta. La 4.2 parla di "lasting entertainment value or adequate utility": un valore che dura, o un'utilità sufficiente. **Per correggere, aggiungi profondità all'azione principale, non schermate intorno.** Qui: una cronologia, i preferiti, un promemoria all'ora scelta, un widget nella schermata Home.

### L'app generata con l'IA, senza niente di nativo

Esempio: un campo di testo, un pulsante, una risposta dell'IA mostrata come testo semplice. Apple non giudica lo strumento, ma quello che arriva sullo schermo del reviewer. Se l'esperienza sta in una pagina web, è molto probabile che arrivi la 4.2.

Spiego cosa l'IA fa bene e cosa sbaglia in [creare un'app con l'IA](https://devoria.fr/it/blog/creare-app-ios-con-ia-errori-verifiche). Il formato prodotto da ogni generatore, applicazione web o progetto mobile, è confrontato in [Lovable, Rork o FlutterFlow](https://devoria.fr/it/blog/lovable-rork-flutterflow-creare-app-mobile).

### Il guscio in attesa di contenuti

Esempio: un marketplace senza annunci, una directory vuota, un feed che mostra "Presto disponibile". Il reviewer apre un'app che non ha niente da mostrare. Questo caso tocca anche la 2.1, che rifiuta i contenuti provvisori: vedi la [guida alla guideline 2.1](https://devoria.fr/it/blog/guideline-2-1-app-store-rifiuto). Invia l'app quando ha contenuti reali, oppure fornisci un account demo già popolato.

## Il test che faccio: "E in Safari?"

Prima di inviare, mi chiedo se un sito web potrebbe offrire la stessa funzione principale. Se sì, l'app è esposta alla 4.2. Ecco la mia griglia per valutare una funzione nativa. **Una funzione conta quando serve l'azione principale, non quando decora.**

| Funzione            | Conta quando...                            | Non basta quando...                  |
| ------------------- | ------------------------------------------ | ------------------------------------ |
| Notifiche           | Portano un'informazione attesa             | Rilanciano i tuoi articoli           |
| Offline             | Il contenuto principale resta utilizzabile | Compare solo una schermata di errore |
| Widget              | Mostra un dato specifico della persona     | Mostra il tuo logo                   |
| Condivisione        | Si inviano contenuti verso la tua app      | Condivide solo un link               |
| Fotocamera, sensori | Fanno parte dell'azione principale         | Aprono il tuo sito                   |
| Dati locali         | L'app calcola, organizza e ricorda         | Tutto vive su una pagina web         |

Le raccomandazioni di Apple vanno nella stessa direzione. Un [widget](https://developer.apple.com/design/human-interface-guidelines/widgets) mostra contenuti attuali, leggibili a colpo d'occhio. Una [notifica](https://developer.apple.com/design/human-interface-guidelines/notifications) porta un'informazione utile, in poche parole, e non serve a spingere verso un'attività nell'app.

## Cosa fanno le mie app che un sito non fa

Progetto ogni app intorno a una funzione principale che non esiste in un browser, o a un valore che fa tornare.

- **Solys** è una sveglia. La suoneria passa da AlarmKit, il servizio di allarmi di iOS 26: supera la modalità silenziosa, come la sveglia di Apple. Per fermarla devi vincere un mini-gioco, e le app scelte restano in pausa dopo il risveglio. Nessuna pagina web fa suonare un iPhone in silenzioso.
- **TradaZen** è un simulatore di trading: un grafico vero a una data vera, una decisione, candele che si rivelano, sfide con classifica e un rango che sale. Qui non è una funzione nativa a reggere l'app. È il valore di intrattenimento duraturo di cui parla la 4.2.
- **Nolera** è un guardaroba: fotografi i tuoi vestiti, l'app li scontorna e li organizza, poi ti propone un outfit ogni mattina. La fotocamera fa parte dell'azione principale. Non è un extra.

**La 4.2 non chiede una lista di funzioni native: chiede un motivo per installare l'app invece di aprire un sito.**

## Correggere un rifiuto 4.2, passo dopo passo

1. **Identifica la famiglia.** Navigazione web: è il sito incapsulato. Contenuti o funzioni minime: è l'app troppo scarna. La 4.2.3: una dipendenza da un'altra app o un download non dichiarato.
2. **Cambia il prodotto, non la formulazione.** Una risposta che argomenta senza cambiare niente non ha motivo di convincere. Ricostruisci in nativo le schermate dell'azione principale, o aggiungi la profondità che manca.
3. **Prevedi una nuova build.** La causa è nell'app: un aggiornamento da remoto non basta. Ogni invio ripassa dalla coda, vedi i [tempi di revisione dell'App Store](https://devoria.fr/it/blog/tempi-revisione-app-store).
4. **Scrivi note per la revisione che guidino.** Apple chiede, nella sua pagina sulle [informazioni per una revisione completa](https://developer.apple.com/help/app-review/before-submitting-for-review/complete-review), di descrivere il concept, le funzioni e il pubblico. Per un aggiornamento: cosa è cambiato e dove trovarlo.
5. **Fai ricorso solo se il reviewer si è perso qualcosa.** Se la tua funzione nativa esisteva già ma non è stata vista, rispondi in App Store Connect con un breve video. Il ricorso all'App Review Board ha senso quando la tua app è stata fraintesa, non quando è scarna.

Il modello di note che userei, in inglese, da adattare:

```text
Hello App Review team,

Thank you for your feedback regarding Guideline 4.2.

What changed in build [X]:
- [Main feature] is now fully native: [what the user does].
- [Native feature]: [what it brings]. Where: [screen > button].
- [Second native feature]: [what it brings]. Where: [screen].
- Web content is limited to [legal pages, help].

How to test in two minutes:
1. Launch the app and [main action].
2. Turn on Airplane mode: [content] stays available.
3. Add the widget from the Home Screen: it shows [data].

Best regards,
[Your name]
```

Scrivi solo quello che esiste nella build inviata. Una funzione annunciata e introvabile ti costerebbe un nuovo rifiuto, stavolta per la 2.1.

## La checklist 4.2 prima dell'invio

- Sai dire in una frase cosa fa la tua app che un sito non fa.
- Le schermate dell'azione principale sono native, non pagine web.
- Ogni funzione nativa serve l'azione principale, e il reviewer la incontra in meno di due minuti.
- L'app ha contenuti reali fin dal primo avvio, o un account demo popolato.
- L'app funziona da sola, senza altre app da installare.
- Un download pesante al primo avvio indica la sua dimensione e chiede il consenso.
- Le note per la revisione descrivono il concept, il pubblico e dove si trova ogni funzione.
- Se la tua idea sfiora il limite, l'hai testata prima di scrivere codice, con un [MVP di app iOS](https://devoria.fr/it/expertise/mvp-app-ios) ben definito.

## Superare la 4.2 dal tuo prossimo invio

Se la tua app è appena stata rifiutata per la 4.2, l'[Apple Review Kit](https://devoria.fr/it/kits/review-apple) ti aiuta a ritrovare la regola citata e cosa chiede, con i modelli di note per il tester. Se stai ancora costruendo, il percorso dell'[iOS Kit](https://devoria.fr/it/kits/ios) parte dalla funzione principale prima della prima riga di codice. Per uno sguardo umano, [prenota un'ora con me](https://devoria.fr/it/coaching). Il metodo completo è nella pagina [app rifiutata da Apple](https://devoria.fr/it/expertise/app-rifiutata-da-apple).

Se stai preparando la tua prima uscita, [fai la tua diagnosi gratuita](https://devoria.fr/it/diagnostic): rimette in ordine i passaggi e ti invia la mia checklist anti-rifiuto Apple. La home mostra come [creare un'app mobile](https://devoria.fr/it) pensata per la review fin dall'inizio.

Nessuno può garantire che Apple accetterà la tua app. Io posso aiutarti a darle un motivo per esistere sull'App Store.

## Domande frequenti

### Cosa significa "Guideline 4.2 - Design - Minimum Functionality"?

È l'intestazione del rifiuto per funzionalità minima. Apple ritiene che la tua app somigli troppo a un sito web, o che offra troppo pochi contenuti o funzioni. La stessa intestazione può riferirsi a una sotto-regola: "Guideline 4.2.2" per un'app vetrina o una lista di link, 4.2.3 per un'app che dipende da un'altra app.

### Un'app in WebView viene sempre rifiutata?

No. La regola colpisce il sito web rimesso in un'app, non la tecnologia. Il reviewer giudica l'esperienza principale: se le sue schermate sono pagine web che fanno la stessa cosa di Safari, il rischio è alto. Una pagina di aiuto aperta nel browser non è il problema.

### Aggiungere le notifiche push basta per superare la 4.2?

No. In un messaggio di rifiuto pubblicato sui suoi forum, Apple scrive che notifiche, localizzazione e condivisione non bastano a rendere l'esperienza abbastanza ricca. Una notifica conta quando serve la funzione principale, come una sveglia o un promemoria scelto dalla persona.

### Che differenza c'è tra la guideline 4.2 e la 4.3?

La 4.2 giudica la tua app da sola: offre abbastanza rispetto a un sito web? La 4.3 la confronta con le altre: è una copia, una variante o l'ennesima app in una categoria satura? Una stessa app può prenderle entrambe, ma non si correggono allo stesso modo.

### Serve una nuova build dopo un rifiuto 4.2?

Quasi sempre, perché la causa è nell'app stessa. Unica eccezione: il reviewer non ha trovato una funzione che esisteva già. In quel caso, rispondi in App Store Connect con note precise e un breve video, senza cambiare la build.


## Il tuo progetto

[Apple Review Kit](https://devoria.fr/it/kits/review-apple): La checklist review App Store che uso, i miei rifiuti di Apple corretti, le note per il revisore e due skill Claude Code che rileggono la tua app. 29 €.

[iOS Kit](https://devoria.fr/it/kits/ios): Crea la tua app iPhone con Claude Code: lo Starter Code delle mie app, gli skill che verificano il suo lavoro, e l'Apple Review Kit, l'App Store Screenshots Kit e l'ASO Kit. 129,99 €.