[iOS] Apple Store Review Guidelines: la dura “strada” per l’approvazione delle nostre app

Per poter pubblicare la propria app su Apple Store, occorre affrontare il duro processo di approvazione Apple (review). Non è semplice superarlo, ma prima di iniziare a sviluppare un’app occorre prima capire se quello che si vuol realizzare è compatibile con le linee guida (App store Review Guidelines). Infatti, una app su iOs non sempre è realizzabile. Per esempio, non si possono pubblicare app che visualizzano semplicemente una pagina web o una lista di link. Oppure non potete pubblicare un catalogo di articoli o contenuti a pagamento, acquistandoli su un sito web esterno cliccando magari su un bottone “Compra” disponibile nell’app. Inoltre, devono essere considerate anche utili e seguire il “look and feel” di Apple.

Quindi, prima di iniziare a sviluppare un’app, leggete attentamente le linee guida di Apple, di cui riporto la traduzione di quelle disponibili adesso (al Luglio 2012), ma che subiscono continue modifiche, come dice Apple, in base alle app che vengono man mano approvate e alle situazioni che fanno evolvere anche il modo in cui validarle. Vi invito, dunque, a riferirvi alle linee guida aggiornate sul sito della Apple –>; App store Review Guidelines

NOTA. La traduzione è una mia interpretazione. Non corrisponde letteralmente alle frasi riportate nelle linee guida Apple, in quanto si è fatto un lavoro di trasposizione dai termini tecnici in lingua madre e l’italiano. Mi scuso per eventuali inesattezze.

Il processo di approvazione delle app assicura che le applicazioni possano essere distribuite funzionanti, performanti e libere da materiale esplicitamente offensivo o vietato. Le app vengono testate una per una dal team di Apple, dal punto di vista tecnico, di contenuto e di criteri di design. I vari punti che occorre rispettare vengono inseriti nelle App Store Review Guidelines.

In questo articolo, mi concentro solo sulle linee guide di approvazione delle app (su iOS). Esistono anche quelle da rispettare per la distribuzione dei programmi su sistema operativo MacOS (App Store Review Guidelines for Mac OS X apps), ma non sarà oggetto di questo post.

Consiglio. Quando sottoponete la vostra app, nel pannello di iTunesConnect e nelle informazioni relative alla versione che intendete pubblicare, compilate anche la sezione opzionale Review Notes, spiegando ad Apple del perché delle vostre scelte di progettazione o per evidenziare delle funzionalità presenti nella vostra app.

;

App store Review Guidelines (Luglio 2012)

Introduzione. Siamo lusingati che voi vogliate investire il vostro talento e tempo nello sviluppo di applicazioni per iOs. Questa esperienza è stata gratificante – sia professionalmente che economicamente – per decine di migliaia di sviluppatori e vogliamo aiutarvi a partecipare a questo gruppo di successo. Abbiamo pubblicato le nostre App Store Review Guidelines nella speranza di aiutarvi nello sviluppo della vostra applicazione e a velocizzare il processo di approvazione qualora sottomettete la vostra app alla nostra revisione.

Non vengono accettate nell’Apple Store, app con determinati contenuti per i seguenti motivi:

  • le app vengono scaricate da un pubblico non adulto e i “parental control” potrebbero non funzionare a meno che i genitori non istruiscano i loro figli (e molti non lo fanno), così teniamo d’occhio i contenuti affinché possano essere scaricati in modo sicuro da questo pubblico non adulto;
  • esistono oltre 350.000 applicazioni in App Store e, se la vostra app non fa qualcosa di utile o fornisce qualche forma di intrattenimento, non la accettiamo;
  • se la vostra app sembra che sia stata messa su in pochi giorni o riteniamo sia un primo esperimento per impressionare i vostri amici, preparatevi a vedervela rifiutata. Abbiamo un sacco di sviluppatori seri che non vogliono che le loro applicazioni di qualità vengano circondate da dilettanti;
  • verranno rifiutate app con qualsiasi contenuto o comportamento che crediamo siano oltre la linea. Quale linea, vi chiederete? Beh, come una Corte Suprema di Giustizia: “Lo saprò quando lo vedrò”. E pensiamo che anche voi lo saprete quando lo vedrete;
  • se la vostra applicazione viene rifiutata, abbiamo una Review Board a cui fare appello;
  • se si tenta di ingannare il sistema (per esempio, cercando di ingannare il processo di revisione, rubare dati degli utenti, copiare il lavoro di un altro sviluppatore o manipolare i voti), le applicazioni verranno rimosse dallo store e sarete espulsi dal programma di sviluppo
  • questo è un documento in continua revisione e nuove apps potrebbero dover rispondere a nuove domande in qualsiasi momento. La vostra app, per essere approvata, deve rispondere a questo documento.

Continua la lettura

[iOS] iOs Data Storage guidelines reject (2.23 – App Store Review Guidelines)

Brutta parola, “Apple reject“. La strada per farsi approvare un’app da Apple per il rilascio su Apple Store è assai tortuosa. Occorre seguire per filo e per segno ciascun punto delle App Store Review Guidelines. C’è un punto (il 2.23) che riguarda le iOS Data Storage Guidelines che onestamente non riesco a “disambiguare”, visto che su vari blog si danno suggerimenti e pareri assai discordi su come rispettarle. Il mio grosso quesito è capire dove è corretto salvare i contenuti che vengono scaricati tramite la mia app, considerando che questi vengono prima acquistati (con il sistema In-App Purchases di Apple) e poi sincronizzati manualmente dagli utenti.

Nell’ultima app che ho sottoposto al processo di approvazione di Apple, mi è stato risposto con un messaggio di rigetto riguardo il punto 2.23 e che vi incollo di seguito:

2.23
We also found that your app does not follow the iOS Data Storage Guidelines, which is required per the App Store Review Guidelines.

In particular, we found that after downloading one content, your app stores 13.8 MB. To check how much data your app is storing:

– Install and launch your app
– Go to Settings > iCloud > Storage & Backup > Manage Storage
– If necessary, tap “Show all apps”
– Check your app’s storage

The iOS Data Storage Guidelines indicate that only content that the user creates using your app, e.g., documents, new files, edits, etc., may be stored in the /Documents directory – and backed up by iCloud.

Temporary files used by your app should only be stored in the /tmp directory; please remember to delete the files stored in this location when the user exits the app.

Data that can be recreated but must persist for proper functioning of your app – or because customers expect it to be available for offline use – should be marked with the “do not back up” attribute. For NSURL objects, add the NSURLIsExcludedFromBackupKeyattribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCFURLIsExcludedFromBackupKeyattribute.

For more information, please see Technical Q&A 1719: How do I prevent files from being backed up to iCloud and iTunes?

In poche parole, Apple dice che quando l’app permette agli utenti di scaricare contenuti (downloadable contents), che siano essi immagini, video, audio, pdf, ecc., questo potrebbe far diminuire lo spazio sul dispositivo (e fin qui nessun problema); ma la cosa indesiderata è che il nuovo sistema iCloud potrebbe backuppare l’app con tutti i file scaricati e consumare lo spazio dell’account (che come si sa, è gratuito fino ai primi 5 giga, e a pagamento annuale in base alle soglie di spazio richiesto). A questo punto è iniziata la mia indagine e ho studiato un pò il caso per capire meglio come risolvere questo grosso dilemma e magari aiutarvi ad affrontarlo alla meglio.

Nel rispetto dei requisiti di storage dei dati sugli iDevice, Apple ha stilato le iOS Data Storage Guidelines in cui si legge questo (NOTA. La traduzione è ad interpretazione mia e mi scuso per eventuali errori):

iOS Data Storage Guidelines. iCloud include un sistema di backup che automaticamente effettua il salvataggio dei dati presenti sui device iOs degli utenti in modalità WI-FI. Tutto quello che si trova nella Home Directory della propria app viene backuppato, ad eccezione dell’application bundle, delle directory di cache e dei file temporanei.
Le musiche acquistate (su iTunes), le apps, le Camera Roll (le foto inserite nelle categorie, dette “rullini”), le impostazioni del telefono, la home screen e l’organizzazione delle app, i messaggi e le suonerie vengono automaticamente backuppate.

Poichè i backup vengono eseguiti in modalità wireless e memorizzati in iCloud per ciascun utente, occorre minimizzare la quantità di dati che le apps memorizzano. File grandi allungano i tempi di backup e consumano spazio di storage sull’account iCloud.

Affinchè i backup siano il più possibile efficienti, occorre assicurare che l’app memorizzi i dati in accordo con le seguenti linee guida:

  1. Solo i documenti o altri dati che vengono generati dall’utente (user-generated), o che non possono essere altrimenti ricreati dall’app, devono essere memorizzati nella directory /Documents e verranno automaticamente backuppati da iCloud.
  2. I dati che possono essere scaricati più volte o rigenerati dovrebbero essere memorizzati nella directory /Library/Caches. Esempi di file che potrebbero essere salvati nella directory Caches includono i file di cache del database e contenuto scaricabile (downloadable content), come magazine, newspaper e map applications.
  3. I dati che vengono usati soltanto temporaneamente dovrebbero essere memorizzati nella directory /tmp. Sebbene questi file non vengono backuppati da iCloud, occorre ricordare di cancellarli quando non servono più così da non consumare spazio sul dispositivo dell’utente.
  4. Usare l’attributo “do not back up per specificare i file che dovrebbero rimanere sul device, anche in situazioni di basso storage. Questo attributo si usa con i dati che possono essere ricreati ma che occorre siano persistenti, anche in situazioni di basso storage, per far funzionare propriamente l’app o perchè gli utenti si aspettano di averli disponibili anche durante l’uso offline. L’attributo funziona sui file marcati a prescindere dalla directory in cui si trovano, inclusa la directory Documents. Questi file non verranno eliminati o non verranno inclusi nell’iCloud dell’utente o di backup di iTunes. Poichè questi file utilizzano spazio di archiviazione sul device, la vostra app è responsabile del controllo e dell’eliminazione periodica di questi file.

Per maggiori dettagli vedi: Technical Q&A QA1719-How do I prevent files from being backed up to iCloud and iTunes?

Prima di entrare nel meglio della trattazione tecnica e del codice di programmazione, riporto quanto estratto dal documento di App Backup Best Practices.

Continua la lettura

[iOs] Distribuzione su Apple Store: errore “No architectures to compile for armv6”

Chi ha avuto esperienza di programmazione su XCode 3 e ha iniziato a sviluppare un progetto lì e poi ad importarlo su XCode 4, sicuramente è incappato nell’errore “No architectures to compile for (ARCHS=i386, VALID_ARCHS=armv6 armv7)“.

Questo errore non avviene a tempo di compilazione, ma all’atto della distribuzione su Apple Store.

Ho letto che capita anche sviluppando direttamente su XCode 4 e si verifica quando si crea un progetto che di default viene testato su una architettura armv7, che per intenderci è il processore che gira dagli iPhone 3GS a salire.

L’iPhone 3G monta un processore armv6, quindi, affinchè si possa deployare sui modelli da 3G a 4S, occorre settare la predisposizione a questa architettura sul compilatore. A partire dal firmware 4.3 apple ha tolto il supporto ai dispositivi basati su armv6 (iPod Touch/IPhone 1G, 2G, 3G), per cui se vi occorre rendere compatibile e scaricabile la vostra app anche su di essi, vi occorre compilarla su firmware 4.2 al massimo e dichiarare esplicitamente la compatibilità con l’architettura armv6.

Per prima cosa, occorre andare sulle proprietà del vostro progetto e settare una architettura valida (voce Valid Architecture):

  1. Navigare sul tab Build Settings e trovare le voci sotto il gruppo Architectures
  2. Per le voci presenti sotto tale gruppo settare i seguenti valori: Architectures: Standard (armv6 armv7); Base SDK: Latest iOS (iOS 4.3), Build Active Architecture Only: No, Supported Platforms: iphonesimulator, iphoneos e Valid Architectures: armv6 armv7 i386;
  3. Se nella voce Valid Architectures vi sono già i valori armv6 armv7, cancellarle, restartare XCode e reinserirle. Se vi è il valore $(ARCHS_STANDARD_32_BIT), vi consiglio di cancellarlo e inserire le due voci armv6 e armv7;
  4. Sempre in Valid Architectures, il valore i386 non è obbligatorio, ma permette di definire correttamente l’architettura utilizzata dal Simulatore che gira su un MacIntel.

Vi consiglio di fare anche il seguente passo, perchè mi è capitato che dopo essere riuscito ad uploadare la mia app su Apple Store, nonostante non mi abbia più dato l’errore “No architectures to compile for (ARCHS=i386, VALID_ARCHS=armv6 armv7)“, mi segnalava l’app compatibile anche per iPhone 3G, ma quando la si provava a scaricare ed installare, non succedeva nulla (ovvero nè la scaricava nè la installava sul device).

5. Nel vostro progetto vi è sicuramente un file che si chiama yourProjectName-Info.plist, che contiene tutte le info di configurazione della vostra app. Occorre che cancellate tutte i valori presenti sotto la voce Required device capabilities (se c’è).

enter image description here

Vi allego gli screenshot dei passi descritti e i due post che mi sono serviti per risolvere questo bel problema di compatibilità sui dispositivi con armv6: