Come evitare il rifiuto di un'applicazione per iPhone. Alcuni consigli pratici

Visti gli ultimi risultati raggiunti dell’App Store, sembra proprio che il mondo non viva senza iPhone e senza le sue applicazioni. Sviluppare per iPhone non solo è una necessità dettata dal mercato, bensì un nuovo modo di sviluppare prodotti software che possono raggiungere una diffusione spropositata. E’ davanti agli occhi di tutti il successo che un’applicazione, opportunamente promossa e certamente ben realizzata, potrebbe portare per il suo creatore in termini di notorietà e di fatturato.

Per questo motivo l’idea di mettersi a sviluppare una propria applicazione sarà certamente balenata nella testa di molti, addetti ai lavori e non. Anche se i tempi potranno essere diversi gli uni dagli altri, per entrambi si manifesterà la possibilità del rifiuto della propria applicazione da parte di Apple, proprio come è capitato già a tanti sviluppatori per motivazioni più o meno arbitrarie.

Brian Stormont, capo della (piccola) software house Stormy Productions, indica alcuni aspetti cui prestare attenzione per avere maggiori possibilità con la propria app. Alcuni di questi, non sono altro di quanto già scritto nei termini e condizioni per l’utilizzo dell’SDK, mentre altri sono aspetti che potrebbero essere lasciati in secondo piano da molti ma potrebbero risultare decisivi per l’approvazione.

Vediamoli in dettaglio:

1)Massima attenzione all’HIG: la violazione di almeno uno dei criteri indicati da Apple nelle proprie Human Interface Guidelines è uno dei principali motivi di rifiuto per un’applicazione. I fatto che alcune applicazioni presenti in App Store sembrano presentare tali violazioni, non deve trarre in inganno. Sembra che Apple chiuda un occhio per alcune di queste violazioni, come ad esempio per quanto riguarda gli splash screen, ma non per questo significa che è consigliabile violarle.

2)Matching delle icone: l’icona 57×57 che verrà visualizzata su iPhone, deve avere una controparte identica nell’immagine a 512×512 richiesta quando viene fatta la submission dell’applicazione. Anche se non è indicato tale aspetto nel documento HIG, Apple rifiuterà le icone non corrispondenti per una violazione di tale criterio. Le icone non devono essere identiche, bensì condividere almeno un elemento importante. La condivisione dello stesso tema non è sufficiente.

3)Simulazione di malfunzionamenti: per alcune applicazioni, simulare un malfunzionamento del dispositivo, come la rottura dello schermo, potrebbe essere divertente, ma Apple non lo accetterà e rifiuterà l’applicazione.

4)Utilizzare in maniera coerente le immagini per i bottoni fornite da Apple: se si opta per utilizzare le immagini che Apple fornisce per la creazione dei bottoni, occorre prestare attenzione alla funzione che sono chiamati a svolgere. Anche se nell’HIG è scritto che l’utilizzo di tali bottoni può essere anche non-standard, le probabilità di rifiuto aumentano a dismisura.

5)Controllo della banda utilizzata: se l’applicazione in questione scarica dati attraverso la connessione del dispositivo, occorre assicurarsi che tale quantità non ecceda indicativamente i 4.5 MB per 5 minuti di attività (Apple non indica precisamente tale numero, ma è quanto è emerso in una discussione con un responsabile Apple del tech support, n.d.r.).

6)Finestra pop-up per network non disponibile: se l’applicazione utilizza la connessione ad Internent, quando la connessione non è più disponibile, è necessario creare una finestra pop-up che informa l’utente sulla necessità della applicazione di una connessione Internet. L’apposita icona e un messaggio del tipo “trying to connect” non sono sufficienti.

7)Attenzione al bug “network is unavailable”: nell’SDK fornita da Apple è presente un bug relativo alle funzioni di modalità di connessione: quando si invocano le funzioni di reachability , se per prima cosa non viene eseguito un tentativo di connessione ad un network, si riceverà un falso messaggio di errore “network is unavailable”. Apple rifiuterà l’applicazione se si accorgerà che quest’ultima porta con sé un falso positivo.

8)Ridicolizzare pubblicamente personaggi politici: Apple rifiuterà applicazioni che si prendono gioco e ridicolizzano figure politiche (presenti o passate).

9)Fornire una descrizione accurata: la descrizione che verrà visualizzata su iTunes, deve essere chiara ed esaustiva e occorre assicurarsi di fornire frasi e descrizioni non ambigue.

10) Descrizione relativa alle novità: quando si sottopone una nuova versione della medesima applicazione, è richiesta una descrizione che verrà visualizzata nella sezione dedicata. Questa descrizione deve essere chiara e concisa.

11) Compatibilità con il sistema operativo: effettuare il test dell’applicazione con tutte le versioni del sistema operativo per il quale si dichiara il corretto funzionamento (sembra abbastanza ovvio ma ricordarlo non fa male, n.d.r.)

Questi elencati sono i consigli di chi ha già sottoposto 45 applicazioni ad Apple e, presumibilmente, ha esperienza in questo. Non per questo significa che l’esperienza di Stormont debba essere la sola ed unica possibile o che i suggerimenti forniti rappresentano i soli che si possono dare.

Personalmente aggiungerei il 12° punto che, più che un consiglio, potrebbe svolgere la funzione di un mantra: “Rimani calmo quando viene rifiutata la tua applicazione. Se ti arrabbi, sarai tu a passare le notti insonni a ripensare se è motivato o meno il rifiuto, non Apple.”