app_apple

Il divertimento che molto spesso si prova nell’utilizzare un’app non è sempre paragonabile allo stato d’animo dello sviluppatore in attesa che il frutto del suo lavoro venga pubblicato.

A volte è solo l’attesa a rendere quest’ultimo nervoso in altri casi invece, in seguito ad un intervallo di tempo che può protrarsi più delle proprie aspettative, al nervosismo subentra l’apprensione che a sua volta lascia spazio al dispiacere (volendo usare un eufemismo!) di vedere respinta la propria proposta, frutto di ore di lavoro e dedizione.

L’iter che porta alla pubblicazione di un’applicazione nel Marketplace di designazione varia a seconda del destinatario scelto. Così, se si decide di pubblicare l’app nello store ufficiale Apple è necessario che, dopo l’invio, questa superi gli annosi processi di revisione e validazione.

L’approvazione dell’applicazione non è cosa scontata e, per non mettere gli sviluppatori nelle condizioni di dover rivedere in parte il proprio lavoro, Apple ha recentemente divulgato l’elenco aggiornato dei principali motivi che portano al rifiuto della pubblicazione.

Il problema più comune che la Casa di Cupertino ha riscontrato nelle applicazioni durante il processo di revisione (la top 10 stilata da Apple nell’immagine sottostante) è che il14% degli sviluppatori dimentica di inserire dati fondamentali per ottenere l’approvazione del proprio prodotto, non compilando quindi tutti gli appositi spazi richiesti dal form.

Inoltre, in un periodo di osservazione durato 7 giorni e terminato lo scorso 28 agosto, è stato constatato che il 6% delle applicazioni bocciate non presentava la firma per l’accettazione del regolamento da parte degli sviluppatori, l’8% dei software rifiutati da Apple si ritiene contenesse bug e il 5% che presentasse un nome, una descrizione ed uno screenshot non chiari a definire la funzione dell’app stessa.

Schermata-2014-09-03-alle-16.57.391

 

Non è la prima volta che Apple pubblica un documento in cui comunica agli interessati le motivazioni per cui le applicazioni vengono rifiutate o eliminate dall’Appstore.

Nel 2010 gli sviluppatori furono informati che tra le altre cose le applicazioni per essere approvate non dovevano avere la finalità di generare un senso di disgusto, non potevano richiedere di sparare a persone o animali troppo realistici e non potevano storpiare i nomi dei prodotti Apple come, ad esempio, iTunz o Iphone (che, volendo essere precisi, si scrive iPhone).

Tra i casi che si ricordano con maggior facilità, l’applicazione eliminata per eccellenza dall’Appstore è Google Maps.

Si vocifera che tale decisione sia stata presa da Steve Jobs che, alla fine della sua carriera, accusò Google di aver copiato le features dell’iPhone ostacolando l’integrazione della navigazione turn-by-turn in iOS. Dal momento che questa funzione risultava inclusa sul sistema Android, Jobs decise di rimuovere Google Maps in favore della soluzione interna Plans frutto di un progetto rimasto per diverso tempo segreto e rivelatosi poi un fallimento.

Non per forza però il rifiuto di un’app o l’eliminazione della stessa sono il risultato di una concorrenza spietata, anzi, alcune volte basta molto meno per far si che si interrompa l’iter che porta alla pubblicazione.

 

Volendo rendervi partecipi di qualche aneddoto che vede zero12 protagonista, quello che può essere definito come maggiormente esemplificativo delle difficoltà sopracitate risale al tentativo di pubblicazione della seconda versione di una specifica applicazione. Dopo aver pubblicato con successo una prima versione ci siamo accorti della presenza di alcuni errori mandando quindi in approvazione una seconda versione, formalmente identica alla prima. Questa nuova versione, diversamente però dalla prima, venne rifiutata per una violazione delle linee guida. Nello specifico il problema riscontrato era riconducibile alla presenza di un link che rimandava al contratto, in cui si specificava che esistevano anche dei profili a pagamento ( secondo le policy di Apple tutti gli acquisti vanno fatti In-App negando quindi la possibilità di mettere nelle app link che facciano riferimento ad acquisti esterni all’app stessa).

Vi chiederete a questo punto come abbiamo risolto il problema.

Semplice, togliendo definitivamente il link incriminato e accontentandoci di avere come spiegazione la convinzione che la stessa identica versione di un’app può essere approvata o meno, probabilmente a seconda del grado di precisione della persona che, in quel momento, si occupa delle review.


Memorabile anche l’episodio in cui abbiamo ottenuto un rifiuto alla pubblicazione di un’applicazione perché i dati scaricati all’avvio della stessa venivano salvati in una delle cartelle di cui iOS fa un backup su iCloud. Secondo le linee guida Apple solo i dati creati direttamente dall’utente possono essere salvati su iCloud, mentre quelli scaricati in automatico da un web service e quindi ricreabili, no.

Per risolvere la segnalazione è stato sufficiente sostituire la cartella in cui venivano salvati i dati in modo da utilizzarne un’altra esclusa dal backup su iCloud.


Non sempre però abbiamo potuto risolvere le segnalazioni ricevute con facilità.


Con la prima versione di un’altra applicazione l’approvazione si è rivelata molto più sofferta a causa di problemi legati all’In-App Purchase dell’abbonamento annuale. Avevamo deciso di usare un abbonamento con rinnovo automatico ma non ci è stato concesso perché quel tipo di abbonamento può essere usato solo dalle app che distribuiscono periodicamente dei contenuti, come ad esempio le applicazioni legate alle riviste. Abbiamo quindi dovuto creare una seconda versione dell’app in cui si prevedeva un abbonamento senza rinnovo automatico, rifiutata anche in questo caso perché avevamo utilizzato il servizio di recupero dei prodotti per permetterci di sapere se un utente aveva già un abbonamento attivo. Secondo le linee guida Apple questo servizio non può essere utilizzato se si usa un abbonamento senza rinnovo automatico, l’app deve quindi risultare autonoma nel capire se un utente è abbonato oppure non lo è.

I problemi che al tempo abbiamo riscontrato però sono che quest’informazione deve persistere anche nel caso in cui l’utente cancelli e reinstalli l’app e che, nel caso in cui un utente possieda più dispositivi Apple, troverà l’abbonamento su ognuno degli stessi.

Per risolvere tale questione e tener quindi traccia di un eventuale abbonamento, non avendo un web service a supporto dell’app, abbiamo aggiunto il salvataggio di alcuni dati su iCloud che, essendo legato all’utente che compie l’acquisto, trasferisce in automatico l’abbonamento a tutti i dispositivi dell’utente. Soluzione che ci è stata poi confermata come la più appropriata anche da un operatore Apple.


Siamo convinti che si potrebbe parlare di questo argomento per giorni interi e che ciascun sviluppatore che si è trovato ad aver a che fare con la famosa Casa di Cupertino ha qualche aneddoto da raccontare.

E allora perché non condividerlo qui!

Sia mai che la condivisione possa fare bene al karma e permetterci di scaricare lo stress e superare i brutti momenti passati!

 

Comments
  • Marco
    Reply

    A me hanno rifiutato la app perche’ era troppo semplice… una schermata di prenotazioni per un ospedale assurdo essendo un servizio di pubblica utilità e peraltro gratuita

Leave a Comment