Pubblicare sull'App Store: tutte le tue domande dal nostro AMA su Reddit

Gli screenshot hanno due compiti insieme: convincere qualcuno a scaricare la tua app e aiutare Apple a capire cosa fa durante la revisione. Metti in risalto le funzioni principali e il valore che offrono, invece di mostrare schermate a caso: se la tua app ha qualcosa che la rende diversa — un workflow unico, una funzione di community, un caso d'uso specifico — assicurati che sia visibile.

Un dettaglio che frega più persone di quanto si pensi: i tuoi screenshot devono corrispondere alla versione dell'app che stai effettivamente inviando. È sorprendentemente comune ridisegnare parte di un'app, inviare una nuova build e dimenticarsi di aggiornare gli screenshot dell'App Store — e un'evidente discrepanza tra ciò che viene mostrato e ciò che viene effettivamente revisionato può sollevare domande durante l'App Review. Apple mette a disposizione anche dei bezel di prodotto ufficiali per presentare i tuoi screenshot in modo pulito e coerente, utili da usare se non l'hai già fatto. Un'ultima cosa segnalata dai nostri ingegneri iOS: screenshot che mostrano il prodotto o il servizio di un concorrente hanno già causato problemi in revisione, quindi è meglio evitarli del tutto.

Ti serve un numero D-U-N-S solo se vuoi iscriverti all'Apple Developer Program come Organizzazione. Se pubblichi come singolo individuo, non ne hai bisogno.

Per ottenere un account Organizzazione, devi prima registrare la tua realtà presso Dun & Bradstreet (o un partner locale): ottenere il numero D-U-N-S richiede in genere circa due settimane, e Apple può chiedere informazioni aggiuntive durante l'iscrizione. In cambio, un account Organizzazione porta con sé alcuni veri vantaggi: la tua organizzazione compare come sviluppatore sull'App Store al posto del tuo nome personale, è generalmente più adatto ad aziende e team (soprattutto se la proprietà cambia nel tempo), rende più semplice dimostrare la proprietà del tuo brand e dei tuoi contenuti durante la revisione, e in alcuni paesi può renderti idoneo a un'esenzione dal costo dell'Apple Developer Program. Se invece sei uno sviluppatore indipendente che pubblica le proprie app, un account Individuale è perfettamente valido e ti evita del tutto il requisito del D-U-N-S.

Una fonte di confusione ricorrente: gli errori criptici di Transporter durante il caricamento di una build. Tre dei più comuni, spiegati:

• "No suitable application records were found" → probabilmente la scheda dell'app non esiste ancora in App Store Connect.
• "Potential loss of keychain" → di solito è solo un avviso, che compare quando l'app è stata trasferita tra account sviluppatore Apple.
• "Redundant binary upload" → probabilmente stai caricando una build con lo stesso numero di versione o di build di una già presente.

Una delle domande che ci vengono fatte più spesso. Da quello che vediamo aiutando i nostri clienti a pubblicare, la maggior parte delle revisioni si conclude in 24-48 ore, anche se può richiedere più tempo a seconda dell'app e del carico di lavoro di Apple.

Se hai una scadenza — un evento di lancio, una data di uscita — invia la tua app il prima possibile invece di aspettare l'ultimo momento. Così, se Apple chiede modifiche prima di approvarla, avrai ancora tempo per sistemarle. E se i tuoi tempi diventano davvero stretti, Apple offre una richiesta di revisione accelerata per le situazioni urgenti. Non è garantita, ma vale la pena provarci ogni volta che hai una data fissa da rispettare.

Il momento giusto per uscire dalla beta non è quando la tua app è perfetta, ma quando è pronta per utenti reali. In pratica: l'esperienza principale è solida, l'app ha già contenuti significativi, e i tuoi utenti beta continuano a tornare perché risolve davvero un problema per loro.

Anche la seconda parte conta allo stesso modo: non pubblicare senza un piano di lancio. Un errore comune è concentrare tutte le energie sull'ottenere l'approvazione, per poi accorgersi che nessuno sa che l'app esiste. Un pubblico target chiaro e una risposta chiara a "perché qualcuno dovrebbe scegliere questa app invece di un'altra" ha un impatto molto maggiore sulla trazione rispetto a lanciare qualche giorno prima. E quella risposta non aiuta solo il marketing: tende anche ad allinearsi con ciò che Apple cerca durante l'App Review. Le app che offrono qualcosa di davvero utile o distintivo hanno di solito un percorso più semplice rispetto a quelle che sembrano l'ennesima variante di qualcosa che esiste già.

Entrambe le piattaforme possono essere ostiche, ognuna a modo suo. Da quello che vediamo, le prime pubblicazioni vengono rifiutate più spesso da Apple che da Google Play — ma questo non significa che Google Play sia più semplice. Ha i suoi vincoli, che possono creare altrettanta frizione a seconda del tipo di account sviluppatore e della configurazione dell'app. Per gli aggiornamenti, il tasso di rifiuto è di solito molto più simile tra le due.

Un utente GoodBarber di lunga data ha riassunto bene questo compromesso nel thread: pubblicare su Apple è tutto un processo, e c'è sempre qualche motivo per cui un'app viene segnalata — ma avere la documentazione e il supporto di GoodBarber per orientarsi toglie gran parte dello stress, e garantisce che l'app resti conforme alle policy degli store nel tempo. Ha anche sottolineato che Google Play, un tempo la piattaforma più semplice, è diventato anch'esso più severo: le app ora devono essere aggiornate regolarmente, altrimenti l'account sviluppatore rischia di essere segnalato. Un supporto affidabile su entrambi i fronti, secondo lui, non ha prezzo.

C'è davvero molto da dire su Google Play in particolare — abbastanza da farci pensare a un AMA dedicato proprio a questo, invece di mescolare tutto qui.

Tutto quello di cui abbiamo parlato è esattamente ciò che il nostro team di supporto gestisce ogni giorno — ed è anche per questo che il servizio esiste come offerta dedicata: GoodBarber Takes Care (GBTC). Invece di gestire tu stesso l'App Review, il team GBTC invia l'app all'App Store e a Google Play per tuo conto, dall'inizio alla fine. Apple rifiuta in media circa il 42% delle prime pubblicazioni — spesso per motivi difficili da anticipare — ma negli ultimi 12 mesi il team GBTC è riuscito a far accettare il 91% di quelle prime pubblicazioni rifiutate. Sugli aggiornamenti, il lavoro di prevenzione fatto in anticipo riduce il tasso di rifiuto a solo il 5%. Se preferisci lasciare l'App Review a un team che ci vive dentro ogni giorno, è esattamente per questo che esiste GBTC.

Questo è il riepilogo, ma il thread originale vale comunque la lettura per il dettaglio completo di ogni risposta — e resta aperto, quindi se hai una domanda che non abbiamo trattato, puoi ancora pubblicarla lì: AMA sulla pubblicazione sull'App Store su r/GoodBarber.

Questo è stato il nostro secondo AMA dal vivo. Dicci nei commenti quale argomento vorresti che affrontassimo la prossima volta.