[iOs] Your app contains non-public API usage…UIDevice methods deprecati

Da 1 Maggio scorso, sono cambiate un bel pò di cose per quanto riguarda il processo di approvazione su Apple Store. Ci si sta preparando all’uscita del iOs 7? Sembra proprio di si, perché alcuni metodi deprecati nelle attuali versioni di iOs, vengono definitivamente vietati.

A me è capitato con gli UIDevice methods, ossia con il metodo uniqueIdentifier, che consente di recuperare la stringa alfanumerica identificativa di ciascun device Apple (UDID). All’atto della sottomissione su Apple Store, ecco l’errore di validazione che mi è stato restituito:

 Your app contains non-public API usage. Please review the errors, correct them and resubmit your application.

Apps are not permitted to access the UDID and must not use the uniqueIdentifier method of UIDevice. Please update your apps and servers to associate users with the Vendor or Advertising identifiers introduced in iOS 6.

If you think this message was sent in error and that you have only used Apple-published APIs in accordance with the guidelines, send the app’s nine-digit Apple ID, along with detailed information about why you believe the above API’s were incorrectly flagged, to appreview@apple.com. For further information, visit the Technical Support page at http://developer.apple.com/support/technical/.

 

La correzione è alquanto semplice, visto che basta sostituire il metodo uniqueIdentifier con il nuovo identifierForVendor. In particolare, ecco una funzione utile che permette di recuperare l’UDID, mantenendo la compatibilità anche per le versioni di iOs precedenti la versione 6:

- (NSString *) idForDevice;
{
  NSString *result = @"";

  UIDevice *thisDevice = [UIDevice currentDevice];
  if ([thisDevice respondsToSelector: @selector(identifierForVendor)])
  {
    NSUUID *myID = [[UIDevice currentDevice] identifierForVendor];
    result = [myID UUIDString];
  }
  else
  {
    NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
    result = [defaults objectForKey: @"appID"];
    if (!result)
    {
      CFUUIDRef myCFUUID = CFUUIDCreate(kCFAllocatorDefault);
      result = (__bridge_transfer NSString *) CFUUIDCreateString(kCFAllocatorDefault, myCFUUID);
      [defaults setObject: result forKey: @"appID"];
      [defaults synchronize];
      CFRelease(myCFUUID);
    }
  }
  return result;
}

Se vi si ripresenta di nuovo lo stesso errore di validazione, nonostante la correzione con la funzione precedente, allora vuol dire che nel vostro progetto state utilizzando qualche libreria che internamente fa uso di metodi deprecati. A me è, infatti, capitato con il framework BugSense, che al momento non ha ancora rilasciato un aggiornamento per correggere tale problema. In tal caso, occorrerà rimuovere la libreria “incriminata” (che tuttavia non vi segnala direttamente xCode) per poter sottoporre l’app ad approvazione.

 

[iOS] Apps that are not very useful – Guidelines reject (2.12 – App Store Review)

Il più frustrante punto di violazione delle Apple Store Review Guidelines (tradotte anche su questo blog al Luglio 2012) è il seguente:

2.12. Apps that are not very useful, unique, are simply web sites bundled as Apps, or do not provide any lasting entertainment value may be rejected

Solitamente la motivazione che viene riportata, dal team di review di Apple nella mail di risposta, è la seguente:

2.12

We found that your app only provides a very limited set of features. While we value simplicity, we consider simplicity to be uncomplicated – not limited in features and functionality

We understand that there are no hard and fast rules to define useful or entertaining, but Apple and Apple customers expect apps to provide a really great user experience. Apps should provide valuable utility or entertainment, draw people in by offering compelling capabilities or content, or enable people to do something they couldn’t do before or in a way they couldn’t do it before.

We encourage you to review your app concept and evaluate whether you can incorporate additional content and features to be in compliance with the Guidelines. For information on the basics of creating great apps, watch the video The Ingredients of Great Apps. If you feel we didn’t understand the features of your app, or that we missed key functionality, and your app was incorrectly rejected, you may appeal to the  App Review Board.

 

Definire questo punto “frustrante” è dir poco, visto che non è una “bocciatura” a cui si può mettere una “pezza” (tecnicamente parlando). Apple ci fa semplicemente capire che la nostra app non serve a nulla o è troppo semplice, dove la linea di “confine” per definire il concetto di semplicità – spiega Apple – non è definibile con regole rigide.

Come si risolve?

Potrei scrivere qui dei suggerimenti, ma dipende dalla vostra app e dall’utilità che offre, visto che ad Apple “sta a cuore” che sia utile e trasmetta agli utenti una “grandiosa esperienza”. La vostra app deve dimostrare che ci sia un lavoro “complesso” dietro: in poche parole, una app con poche funzionalità e con una grafica poco curata, ha bassa probabilità di superare la review.

Arricchitela con maggiori funzionalità: magari una galleria fotografica e video (vedi Three20), più tabelle con contenuti magari scaricati da un server (vedi chiamate asincrone su iOS). Per la parte grafica, rispettate le risoluzioni delle immagini per ciascun device (vedi Custom Icon & Image Creation Guidelines) e le iOS Human Interface Guidelines.

Ecco altro materiale, suggerito da Apple, e che vi consiglio di vedere:

 

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/12/03/apple-review/.

[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