Nel mercato delle app mobile, a non guadagnare saranno gli sviluppatori

In un post pubblicato a novembre scorso, esprimevo il mio parere circa le potenzialità/possibilità di guadagnare nel mercato delle app mobile:

l Freemium: Le app economiche potrebbero uccidere l’App Store

Stavolta riporto un pò di dati alla mano, citando un articolo pubblicato su Wired di Marzo 2014:

Con le app non si diventa ricchi

Sei un giovane smanettone in cerca di successo? Per fare soldi non ha senso pensare a una nuova app. Secondo un report di Gartner, una delle società leader nella consulenza e nell’analisi del mondo dell’Information Technology, nel 2018 solo lo 0,01% di questi software sarà anche un successo finanziario.

Nella guerra tra i marketplace che si sta consumando questa primavera, con l’offerta di Android Market che dovrebbe toccare quota 1 milione entro giugno superando iTunes Store, a non guadagnare un soldo saranno proprio gli sviluppatori. I download non significano successo finanziario: le previsioni indicano nel 94,5% la quota di applicazioni che nel 2017 saranno scaricabili gratis. Per avere probabilità di successo, sottolinea Gartner, bisogna puntare su grandi spese pubblicitarie o avere un brand già molto forte.

Per quanto riguarda le app a pagamento, già oggi il 90% è scaricato meno di 500 volte al giorno: una soglia che non permette di raggiungere la redditività finanziaria. Le previsioni indicano un ulteriore aumento dell’aggressività di un mercato già definito iperattivo. Le piattaforme per la produzione di app sono, da sole, oltre 200, in gran parte basate su strumenti open. E il loro numero
è destinato a crescere ancora.

[http://www.wired.it/economia/lavoro/2014/04/03/con-le-app-non-si-diventa-ricchi/]

 

Il Freemium: Le app economiche potrebbero uccidere l’App Store

Condivido la posizione di Lex Friedman (grande contributor su MacWorld) sulle app economiche pubblicate sui mobile store (non solo di Apple). Eccovi la traduzione e ringrazio il mio amico Marco per avermela segnalata:

freemium-vs-premium

Le applicazioni economiche potrebbero uccidere l’App Store (di Lex Friedman)

Più si abbassano i prezzi per il software dell’iPhone, più la situazione per noi consumatori potrebbe peggiorare. Lo smartphone è probabilmente una delle cose più costose che abbiamo in tasca quotidianamente. Eppure molte persone sono decisamente avare quando guardano gli scaffali virtuali dell’App Store. Come mai? Ironicamente le cose che sono economiche nel breve periodo tendono a diventare costose a lungo andare.

Non sorprende che le applicazioni gratuite siano decisamente più popolari delle applicazioni a pagamento: piace a tutti avere qualcosa senza spendere un centesimo. Ma la cosa strana è che la gente consideri un’applicazione da tre euro decisamente costosa, ed una da dieci euro dal prezzo addirittura esorbitante. Conosco gente che gioca allo stesso gioco gratuito ogni singolo giorno, sorbendosi tutti i banner pubblicitari, piuttosto che spendere cinque euro una volta sola ed andare avanti per sempre senza alcun banner pubblicitario.
Nel momento in cui scrivo, tra le prime venti applicazioni più vendute dell’App Store 15 costano un euro e la più costosa viene sette euro. Il prezzo medio delle top 100 app a pagamento è inferiore ai due euro.
Mi colpisce che così tanti possessori di dispositivi iOS non capiscano che non stanno agendo nel loro interesse né a breve né a lungo termine quando sorridono al pensiero di spendere soldi sull’App Store. I clienti che spendono un sacco di soldi per l’hardware di dispositivi iOS si puniscono poi risparmiando sulle app.

Ottieni ciò per cui paghi.

Le applicazioni a pagamento tendono ad essere migliori delle alternative gratuite. Sono in pochi gli utenti Twitter che pensano che l’applicazione ufficiale offra la miglior esperienza utente, ma molti rimangono su questa semplicemente per evitare di confron- tarsi con le alternative a pagamento come Tweetbot oppure Twitterrific.

Molte applicazioni gratuite sono buone. Ma quando paghi per un’applicazione premium, spesso paghi per una esperienza utente più profonda, una per la quale tu sei il cliente più importante e non sono gli inserzionisti i responsabili del supporto dietro le quinte alla app “gratuita”.

La ragione per cui gli sviluppatori fanno pagare per le proprie applicazioni è che sviluppare un’applicazione ha un costo. Con quello che lo sviluppatore guadagna dalla vendita della sua applicazione può rientrare nell’investimento iniziale di tempo e risorse ed investire nello sviluppo futuro dell’applicazione. I clienti beneficiano di questo ottenendo applicazioni migliorate o nuove applicazioni da questi sviluppatori, invece di applicazioni gratuite abbandonate e di qualità inferiore.

Per un’applicazione da un euro uno sviluppatore guadagna circa 70 centesimi. Di questo passo uno sviluppatore deve vendere più di 70 mila copie per guadagnare almeno 50 mila euro. Per uno sviluppatore indipendente questi servono a coprire le spese, il costo di sviluppo e di progettazione, e poi vivere di quello che resta. Ma se l’applicazione da un euro viene sviluppata da una piccola società di tre persone, è necessario venderne almeno 300 mila affinché il business sia sostenibile. Ovviamente se gli sviluppatori mettono in vendita la loro app per un euro non dobbiamo sentirci in colpa acquistandole. Ma gli sviluppatori mettono in vendita le loro applicazioni a costi così bassi perché sanno che è il prezzo massimo per cui i clienti pagherebbero. E se questo è vero le applicazioni a basso prezzo stanno avendo un impatto negativo su parecchie aziende reali e potenziali.

L’ascesa del Freemium

Gli sviluppatori, comunque, sono ricchi di risorse. Così, visto che molti utenti detestano dover pagare per le applicazioni, abbiamo visto l’ascesa del modello Freemium: puoi scaricare l’app o il gioco gratuitamente, ma per poter continuare a giocarci dovrai fare uno o più acquisti in-app. E questi micropagamenti non sono solamente fastidiosi, ma a lungo andare possono costare all’utente molto di più. Ad esempio: EA Real Racing 2 inizialmente costava poco meno di sette euro. Poi è uscito con il modello Freemium, che costa agli utenti decisamente di più sul lungo periodo, semplicemente per ottenere lo stesso diverti- mento che anche Real Racing 2 offriva.

Fino a quando i clienti dell’App Store non mostreranno volontà a spendere soldi per ottime applicazioni, gli sviluppatori dovranno continuare su questa strada semplicemente per rimanere a galla.

Non è poi così caro.

Un iPhone 5 senza contratto costa di listino 729 euro e se si sceglie un iPhone con contratto di due anni alla fine si arriva a pagare almeno la stessa cifra. A confronto, un’app di quelle “care” può arrivare a costare circa l’uno per cento del prezzo dell’iPhone. E lo vale.

Non si compra un Kindle solamente per leggere il dizionario ed il manuale di istruzioni precaricato. E così non si dovrebbe comprare un iPhone solamente per utilizzare le applicazioni gratuite. Equivale a mentire a se stessi, solamente perché ognuno è ormai condizionato pensando che spendere cinque euro per un app sia troppo. Non è sbagliato pagare per prodotti di qualità.

Spendere soldi per buone applicazioni significa anche investire in ottime applicazioni che verranno create in futuro. Sistemiamo l’economia dell’App Store e iniziamo a pagare per le applicazioni senza rabbrividire quando ne vediamo una per quattro euro.

Tanti possessori di dispositivi iOS non capiscono che non stanno agendo nel loro interesse né a breve né a lungo termine quando sorridono al pensiero di spendere soldi sull’App Store.

 

Un altro articolo interessante (più vecchiotto) sull’argomento: App Store: con i prezzi troppo bassi è la fine?

 

Ecco quello che penso:

Sono in parte d’accordo con l’articolo di Friedman, perché sono ancora piuttosto scettico sulla politica del business via app. La concorrenza è spietata ed è difficile essere all’altezza nello sviluppare un’app in grado di vendere tanto sullo store.
Secondo me, ci si guadagna quando c’è un progetto di marketing vincente e strutturato dietro. La politica del guadagno tramite advising stanca l’utente, ma può risultare vincente nel breve periodo. Il freemium è davvero una bella trovata e un’ancora di salvezza (Vedi: Freemium VS. Premium)
Nel piccolo si può guadagnare vendendo l’idea e l’app a clienti o investitori. Purtroppo, l’app business non fa girare molti soldi in Italia, perché i clienti non hanno la concezione dello sforzo che si fa nel realizzarle e non comprendono ancora le potenzialità e l’utilità che possono offrire agli utenti finali. In Italia facciamo ancora ben poco tramite mobile (vedi anche i pagamenti online o la disponibilità di servizi a distanza utili al cittadino…).

Guardate un po’ i guadagni che si traggono dal modello Freemium:
freemium-percent

[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] Apple dice addio al “compatibility mode” su iPhone 5

Apple dice addio al “compatibility mode” su iPhone 5 delle app che non hanno il layout ottimizzato su tali device.

Per chi non lo sapesse, gli sviluppatori potevano evitare di adattare la grafica delle app su iPhone 5, che è 176 px più lungo dei suoi precursori, permettendo alle app stesse di essere visualizzate in quella che viene definita “letterbox mode“, o appunto “compatibility mode“: iOs visualizza automaticamente delle bande nere sopra e sotto il layout delle app non ottimizzate, solo su iPhone 5.

iOs Letter Box Mode

Per predisporre l’app al “letterbox mode” bastava evitare di inserire la splash screen per i display da 4 pollici (Default-568h@2x.png), di 640×1136 px.

Ecco cosa si legge sulle iOs Human Interface Guidelines:

Note: If you don’t make any changes to your app, it runs in a compatibility mode on iPhone 5. When an app runs in compatibility mode, iOS automatically centers the app’s UI by adding slim black bars above and below it. For some developers, it might be reasonable to simply create a new launch image of the correct size and allow the unchanged app UI to be centered on the iPhone 5 display.

 

Tutte le app rilasciate sullo store prima dell’uscita sul mercato dell’iPhone 5 (seconda metà 2012) erano automaticamente adattate in “letterbox mode“. Tutte quelle, invece, rilasciate ed aggiornate dopo tale evento, dovevano esplicitamente “attestare” l’utilizzo della modalità di compatibilità, evitando di inserire nell’app la splash screen per display da 4″.

Oggi la triste notizia: Apple dal 1 Maggio 2013 impone agli sviluppatori iOs di rendere il layout delle app compatibile per il display dell’iPhone 5. Questo vuol dire che tutti i nuovi rilasci ed aggiornamenti, da tale data in poi, dovranno prevedere che la grafica sia ottimizzata.

Ecco la mail inviata da Apple agli sviluppatori che hanno sottomesso una app alla review, in cui dice “addio” al “letterbox mode” per le nuove app.

Dear developer,

We have discovered one or more issues with your recent delivery for “XXX_MyApp_XXX”. Your delivery was successful, but you may wish to correct the following issues in your next delivery:

iPhone 5 Optimization Requirement – Your binary is not optimized for iPhone 5. As of May 1, all new iPhone apps and app updates submitted must support the 4-inch display on iPhone 5. All apps must include a launch image of the appropriate size. Learn more about iPhone 5 support by reviewing the iOS Human Interface Guidelines.

If you would like to update your binary for this app, you can reject this binary from the Binary Details page in iTunes Connect. Note that rejecting your binary will remove your app from the review queue and the review process will start over from the beginning when you resubmit your binary.

Regards,

The App Store team

 

Pena la bocciatura dell’app all’atto della Apple Review. Ovviamente, le app già sullo store e non aggiornate dopo il 1 maggio continueranno a girare con la modalità di compatibilità.

A me la precedente mail è stata recapitata qualche giorno prima del 1 Maggio scorso, sottoponendo ad approvazione un aggiornamento dell’app LuBannApp. Questa non ha il layout ottimizzato per iPhone 5, ma me l’hanno approvata comunque e viene visualizzata ancora in “letterbox” mode, visto che la data di sottomissione ad Apple Review è antecedente al 1 Maggio.

Se a qualcuno di voi capita di scontrarsi, durante il processo di review, con questo famoso iPhone 5 Optimization Requirement (che oltretutto non vedo ancora sulle linea guida Apple), scrivetelo nei commenti. Grazie.

 

[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] La risoluzione delle icone nelle app iOS, con link utili da dove scaricarle

Eccovi un pò di riferimenti e di link utili per scaricare delle iconcine da inserire nelle vostre app iOS (e non solo). Innanzitutto, il riferimento per la risoluzione delle “custom icon“, da inserire nelle tabbar, toolbar, come badges o sulla springboard…e quant’altro, è quello ufficiale di Apple: Custom Icon and Image Creation Guidelines

Leggete anche questo articolo su DevApp.it (anche se non aggiornato): Linee guida per la creazione di icone e splashscreen per applicazioni iPhone e iPad

Alcuni siti utili da dove scaricare (sia gratuitamente che a pagamento) i set di icone per le vostre app sono i seguenti:

Se ne conoscete altri, segnalateli nei commenti. Grazie! 😉

[iOs] In-App Purchases: come far acquistare dalle nostre app

Volete inserire nelle apps per iOs la possibilità di far acquistare ai vostri utenti contenuti extra di qualsiasi genere (siano essi video, brani audio, ebook, …), ovviamente tutti non protetti da copyright o di cui voi siate proprietari?

Siete obbligatori a utilizzare e rispettare il programma In-App Purchase (IAP) della Apple, di cui vi linko la guida ufficiale: In-App Purchase Programming Guide.

Attenzione. Nelle guidelines di Apple, di cui ho scritto anche un post a questo link, si legge:

11.2 Le apps che utilizzano un sistema differente dalle In App Purchase API (IAP) per acquistare contenuti, funzionalità o servizi nell’app, non vengono accettate

Non potete, dunque, inserire altre modalità di pagamento per i contenuti delle vostre app, di nessun tipo (siano esse PayPal o sistemi esterni di pagamento), se questi contenuti vengono utilizzati direttamente nella vostra app (per esempio, brani audio scaricati, e-book da leggere attraverso l’app stessa, ecc.). Inoltre, questo stesso punto di applica a contenuti “virtuali”, come crediti, bonus, punti, ricariche, …

Quando si può acquistare tramite sistemi differenti per il pagamento (come PayPal) direttamente nelle nostre app ?

Ce lo dice il punto 11.3 delle linee guida:

11.3 Apps using IAP to purchase physical goods or goods and services used outside of the application will be rejected

Non possiamo usare In-App Purchases di Apple quando si tratta di far acquistare beni reali (physical goods) o beni e servizi che vengono usati esternamente all’app. Faccio un esempio: un catalogo di prodotti che vengono venduti da un negozio (sia esso fisico o online), oppure se volete far acquistare un servizio (spedizione di un prodotto comprato ad un cliente, …). Qui dovete utilizzare un sistema esterno per i pagamenti, come PayPal o bonifico.

 

Continuando, nelle linee guida sta anche scritto:

11.14 Le apps possono leggere o riprodurre contenuti (specificamente riviste, giornali, libri, audio, musica e video) ottenuti attraverso sottoscrizione o acquisto al di fuori dall’app, purché l’acquisto stesso non avvenga con un bottone o fornendo un link esterno nell’app per acquistare il contenuto approvato. Apple non chiede porzioni di “revenue“  (introiti) per gli acquisti approvati, acquistati o ottenuti con metodi esterni all’app

 

Apple obbliga gli sviluppatori ad iscriversi al programma IAP per ricavare il 30% degli introiti sulle vendite dei vostri contenuti fruibili attraverso l’app. La cosa assurda è che si vedono, comunque, apps sullo store che permettono anche altre modalità di pagamento (vedi Ebay e Amazon) per l’acquisto di prodotti di qualsiasi genere (siano essi reali o virtuali). Sarà che esistono degli accordi “sotto banco” tra Apple e queste grandi società? Oppure esistono degli “escamotage” per aggirare questo grosso vincolo di Apple? (sembrerebbe che Amazon abbia adottato un sistema di “workaround“, che onestamente non mi convince … Amazon ByPasses the iOs Commission Requirement).

Vi dirò che in un’app avevo inserito come modalità di pagamento PayPal, utilizzando le istruzioni presenti negli articoli scritti su questo blog su OsCommerce e PayPal Express. La Apple mi ha bocciato l’app per non aver rispettato il punto 11.2 suddetto, in quanto la mia app fa acquistare contenuti audio che poi vengono riprodotti nel player interno dell’app stessa.

A quel punto ho iniziato a studiare ed implementare il sistema di pagamento In-App Purchases di Apple, di cui vi allego un pò di articoli utili, alcuni dei quali mi sono serviti per risolvere non pochi problemi che mi hanno portato via un bel pò di settimane di lavoro.

RIFERIMENTI UTILI:

Di seguito vi riporto i passi da seguire per inserire gli In-App Purchases nelle vostre app.

Continua la lettura

[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