Editoria

Linea guida Apple 4.2: Apple rifiuterà un'app per siti Web? Come superare la revisione

Cosa dice effettivamente la regola di funzionalità minima di Apple, perché le app basate su sito Web vengono rifiutate e una pratica lista di controllo per inviarne una che sembri una vera app.

Un'app telefonica su un nastro trasportatore che passa attraverso due checkpoint di revisione del negozio con liste di controllo

Apple può rifiutare un'app basata su sito Web e la "funzionalità minima" è il motivo più comune. La linea guida 4.2 ne è la regola. Un'app per un sito Web non viene rifiutata automaticamente, ma un'app che non aggiunge altro oltre a un sito Web in un frame è a rischio reale.

Questa guida spiega cosa dice la linea guida, cosa i revisori tendono a cercare e come preparare una presentazione. Nessuno al di fuori di Apple può promettere l'approvazione, e questo articolo no. Quello che puoi fare è rimuovere le ragioni evitabili del rifiuto.

Cosa dice effettivamente la linea guida 4.2

Le Linee guida per la revisione delle app affermano al punto 4.2, Funzionalità minima:

La tua app dovrebbe includere funzionalità, contenuti e interfaccia utente che la elevano oltre un sito Web riconfezionato. Se la tua app non è particolarmente utile, unica o "simile a un'app", non appartiene all'App Store.

Le parole che contano sono "sito web riconfezionato". La regola non vieta le app costruite attorno ai contenuti web. Vieta le app che non offrono nulla che un sito Web non offra già.

Le linee guida correlate compaiono anche nelle recensioni delle app dei siti Web:

  • 4.2.2: Oltre ai cataloghi, le app non dovrebbero essere principalmente materiale di marketing, pubblicità, ritagli web, aggregatori di contenuti o una raccolta di collegamenti.
  • 4.2.3: L'app dovrebbe funzionare in modo autonomo senza richiedere l'installazione di un'altra app e dovrebbe indicare e richiedere eventuali download di grandi dimensioni necessari al primo avvio.
  • 2.1 (Completezza dell'app): Gli invii devono essere versioni finali con URL funzionanti, nessun contenuto segnaposto e dettagli dell'account demo se l'app dispone di un login.
  • 4.2.6: Le app create da un modello commercializzato o da un servizio di generazione di app vengono rifiutate a meno che non vengano inviate direttamente dal fornitore del contenuto dell'app.

Leggi sempre tu stesso il testo attuale, poiché Apple aggiorna le linee guida. La fonte ufficiale è la Linee guida per la revisione dell'App Store.

Apple rifiuterà l'app di un sito web?

Dipende da cosa fa l'app inviata. In pratica, i revisori reagiscono ad alcuni modelli:

  • L'app apre un singolo URL e sembra identica al sito Web mobile, inclusa la navigazione in stile Web.
  • Mostra solo un muro di accesso senza contenuto sfogliabile, quindi il revisore non può vedere cosa fa l'app.
  • Si rompe o mostra errori senza connessione.
  • I suoi collegamenti saltano costantemente al browser.
  • Sembra una brochure di marketing per un'azienda senza una funzione propria.

Un'app che racchiude un servizio reale, come un negozio, un sistema di prenotazione, un'area membri o una libreria di contenuti, e lo presenta con una navigazione simile a un'app, si trova in una posizione diversa. Puoi comunque essere rifiutato, poiché la revisione è un giudizio, ma hai qualcosa a cui puntare.

Perché un'app generata da servizi necessita del tuo account

La linea guida 4.2.6 afferma che le app realizzate con un servizio di generazione di app vengono rifiutate a meno che non vengano inviate direttamente dal fornitore del contenuto dell'app. Per il proprietario di un sito web, la lettura pratica è questa: pubblica con il tuo account Apple Developer, a nome tuo o della tua azienda, e assicurati che l'app rappresenti i tuoi contenuti.

Questo è anche il modo in cui funziona SiteTo.App. Le build vengono firmate con l'account sviluppatore Apple che colleghi e la build viene consegnata a TestFlight nel tuo account App Store Connect. Possiedi l'elenco e lo invii. Vedi il Guida all'account sviluppatore Apple per l'impostazione. Non consegnare i tuoi contenuti a un fornitore che invia la stessa shell a molti clienti con il proprio account.

Ciò che fa sembrare un'app del sito web un'app

L'obiettivo non è aggiungere funzionalità fine a se stessa. È per migliorare l'uso mobile. Le aggiunte forti e oneste includono:

  • Navigazione nativa. Una barra delle schede o un menu che corrisponde al modo in cui le persone si muovono nel tuo sito su un telefono, piuttosto che un'intestazione del desktop compressa in un piccolo schermo.
  • Notifiche push. Messaggi a cui gli utenti accedono, come aggiornamenti sugli ordini, promemoria di prenotazione o nuovi contenuti. In SiteTo.App questi vengono configurati tramite Firebase; vedere il Guida Firebase.
  • Collegamenti profondi. Collegamenti da notifiche o e-mail che aprono la schermata destra nell'app.
  • Un'esperienza di lancio progettata. Un'icona, una schermata iniziale e uno stato di caricamento e errore chiaro.
  • Trasferimenti nativi. Condivisione, caricamento di file, accesso alla fotocamera o download che funzionino correttamente sul dispositivo.

Non aggiungere espedienti come l'attivazione/disattivazione di una torcia. Non affronta la linea guida 4.2 e i revisori la esaminano.

Una lista di controllo pre-invio

Risolvilo prima di caricare:

  1. Prova l'intero viaggio su un vero iPhone. Installa tramite TestFlight, non solo un simulatore. Apri l'app a freddo, esegui l'accesso, naviga su diversi livelli in profondità e utilizza il gesto Indietro.
  2. Prova senza connessione. Attiva la modalità aereo e apri l'app. Dovresti vedere un messaggio chiaro, non una pagina vuota.
  3. Controlla ogni collegamento esterno. Decidi appositamente quali collegamenti rimangono all'interno dell'app e quali aprono il browser.
  4. Risolvi i problemi di layout del sito web. Problemi di reattività, target di tocco piccoli e popup solo desktop sono evidenti in un'app.
  5. Rimuovi il contenuto segnaposto. La linea guida 2.1 prevede un prodotto finito con supporto funzionante e URL per la privacy.
  6. Fornire credenziali dimostrative. Se è richiesto un accesso, includi un account che continui a funzionare durante la revisione.
  7. Rendi precise le risposte sulla privacy. Dovrebbero descrivere l'intera esperienza, inclusa l'analisi web e gli strumenti di pagamento caricati nell'app.
  8. Scrivi screenshot onesti e una descrizione. Mostra l'app reale e non rivendicare le funzionalità che mancano.
  9. Utilizza le note di revisione. Spiega cosa fa l'app, dove si trovano le funzionalità native ed eventuali requisiti regionali o dell'account.

Puoi controllare il tuo sito rispetto a molti di questi con il file lista di controllo della preparazione, e il nostro guida alla pubblicazione copre i gradini circostanti del negozio.

Come scrivere note di revisione che aiutano

I revisori vedono molti contributi. Una nota breve e specifica li aiuta a trovare rapidamente il valore. Copertina:

  • A cosa serve l'app, in una o due frasi.
  • Come accedere, con credenziali demo funzionanti.
  • Dove trovare le funzionalità native, ad esempio "Le notifiche possono essere abilitate dalla scheda dell'account".
  • Qualcosa di insolito, ad esempio una funzionalità che richiede una regione o un hardware particolare.

Mantienilo reale. Evitare discussioni sulle linee guida nella prima presentazione. Salvalo per una risposta se vieni rifiutato.

Se Apple rifiuta l'app

Un rifiuto è una conversazione, non un verdetto finale. Apple spiega le linee guida applicate nel Centro risoluzioni.

  1. Leggi attentamente il messaggio. Prendere nota del numero della linea guida e di eventuali schermate o comportamenti specifici menzionati.
  2. Risolvi il problema reale. Se il motivo è una funzionalità minima, migliora ciò che fa l'app invece di riformulare la descrizione.
  3. Rispondi con precisione. Descrivi cosa è cambiato e dove il revisore può vederlo.
  4. Invia nuovamente una nuova build, se necessario. Una modifica al file binario richiede un nuovo caricamento.
  5. Fare appello solo con un caso. Se ritieni che il rifiuto sia un errore, utilizza la procedura di ricorso per l'analisi dell'app e cita i fatti.

Poiché un'app basata su sito Web carica il tuo sito, molte correzioni si verificano sul sito Web stesso e vengono visualizzate nell'app senza una nuova versione dello store. Le modifiche alla configurazione nativa richiedono ancora una nuova build.

Domande comuni

L'app di un sito Web deve funzionare offline?

Non di regola, ma dovrebbe fallire con grazia. Una schermata vuota senza connessione sembra incompleta e ciò influisce sul modo in cui i revisori vedono l'app.

Una PWA viene trattata diversamente da qualsiasi altro sito web?

Una PWA in un'app iOS è ancora contenuto Web all'interno di una shell nativa, quindi si applica la stessa linea guida. Vedere come pubblicare una PWA su App Store e Google Play.

Posso inviare la stessa app per più marchi?

La linea guida 4.2.6 limita le app create da un modello o da un servizio di generazione e inviate per conto dei clienti. Ogni azienda dovrebbe pubblicare con il proprio account.

Devo pagare un convertitore per ottenere l'approvazione?

Nessuno strumento decide il risultato. Apple valuta l'app inviata. Il pagamento per una build non cambia la situazione, quindi il prezzo è separato dall'approvazione. Vedere prezzi.

Prossimi passi

Inizia testando il tuo sito come app. Visualizza l'anteprima del tuo sito web in SiteTo.App, provalo sul tuo telefono e nota come sembra un sito web invece che un'app. Correggi questi punti, quindi segui il creare e pubblicare la guida.

Visualizza il tuo sito web come un'app

Personalizza l'esperienza e visualizzala in anteprima prima di scegliere una piattaforma.

Costruisci la tua anteprima

Continua a leggere

Tutte le guide