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/]

 

[AppMobile] iParcheggiatori

iparcheggiatoriApplicazione Mobile: iParcheggiatori

Pagina Store: Apple Store

Sito web: http://www.iparcheggiatori.it

Descrizione: App per la segnalazione dei “parcheggiatori abusivi”. L’idea è quella di sfruttare la tecnologia per “stanare” questi estorsori in piena regola. Nasce così iParcheggiatori, un’applicazione gratuita che permette di inviare segnalazioni “Anonime” da qualsiasi punto d’Italia in cui ci si trovi.
Il sistema, attraverso la geolocalizzazione, permette di indicare il punto esatto della città in cui sono presenti i parcheggiatori abusivi. E’ possibile, in aggiunta, indicare se il pagamento è “a piacere” (ossia una somma da contrattare con il “lavoratore” di turno) e se qualcuno abbia subito minacce o danni alla propria vettura.

Requisiti: Richiede l’iOS 5.1.1 o successive. Compatibile con iPhone, iPad e iPod touch. Questa app è ottimizzata per iPhone 5.

Categoria: Utility

Tecnologie: XCode 5; iPhone 3GS/4/4S/5/5S; MacOx 10.9 (Maverick) – Linguaggio: Objective-C; Framework e Librerie: MapKit; Integrazione con servizi REST-JSON.

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/2014/02/22/appmobile-iparcheggiatori/.

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] Come configurare, inviare e ricevere le notifiche push in una app iOs

Eccovi un tutorial su come configurare, inviare e ricevere le push notification di Apple in una app iOs. Tali notifiche sono molto utili nel caso in cui vogliate segnalare aggiornamento ed eventi agli utenti che hanno installato la vostra app e che hanno, ovviamente, dato il consenso per la loro ricezione. La configurazione non è molto immediata, specie la parte di creazione dei certificati, per cui vi descriverò i singoli passi nel dettaglio.

Prima di essere operativi, vediamo il modello di programmazione per capire quali sono le componenti in gioco e il flusso funzionale di registrazione, di accreditamento e di invio/ricezione delle notifiche push:

  1. Push-NotificationL’app, registrata sul Provisioning Portal con un AppID, deve essere configurata in modo da avere la funzionalità di push notification abilitata. Una volta abilitata, occorre generare un Provisioning Profile (sia per l’ambiente di sandbox – o development –   che per quello di production – o distribution) da associare all’app stessa. Lato app, quando l’utente dà il consenso alla ricezione delle notifiche push, si fa richiesta ad iOs per la registrazione e l’autorizzazione alle notifiche.
  2. iOs contatterà il server APNS (Apple Push Notification Service), il quale ricevuta la richiesta, genererà un device token da inoltrare direttamente all’app che ha chiesto la registrazione. Il device token è un “indirizzo” univoco che serve all’APNS per rintracciare il device e per inoltrare le notifiche push tramite l’app.
  3. Una volta ricevuto il device token, dall’app occorrerà richiamare un nostro servizio remoto (registerDevice) in cui registrare tale token, oltre ad una serie di altre info utili del device. L’idea è quella di registrare su un nostro database online, la lista di tutti i device, e relativi device token generati, in modo da inoltrare tutte le nostre notifiche a chi ne ha fatto espressamente richiesta.
  4. Un altro servizio remoto presente sul nostro server (sendPush) sarà responsabile dell’invio delle notifiche push (un semplice messaggio di testo). Tale servizio dovrà essere configurato in modo da avere l’autorizzazione dall’APNS server: occorrerà, dunque, generare e configurare un certificato SSL (e una relativa chiave privata) per poter inoltrare una richiesta di notifica push a ciascun device accreditato.
  5. Quando l’APNS server riceve una richiesta di invio di una notifica push per un determinato device token (dopo aver attestato la veridicità del certificato SSL del servizio remoto sendPush), inoltra la notifica. Dall’altra parte, sul device a cui è associato il device token, verrà visualizzato un alert dell’app (o una notifica nel Centro Notifiche) con il messaggio inviato. Oltre l’alert, si può decidere se riprodorre anche un suono e/o visualizzare un badge (il numeretto con il totale delle notifiche sull’icona dell’app). Cliccando sulla notifica o facendo lo “swipe” sull’alert, verrà aperta la vostra app.

 

NOTA. Non è possibile testare le push notification sul simulatore, ma soltanto direttamente su un iPhone/iPad.

 

Push Notification Payload.  Una richiesta di invio di una push notification (dal nostro server all’APNS server) è fatta da un breve messaggio costituito da un device token a cui indirizzare la notifica, un payload ed altre parti. Il payload contiene il messaggio vero e proprio (in formato JSON), compresi alcuni parametri. In totale non deve superare i 256 bytes. Per maggiori informazioni sui parametri, vedi Local and Push Notification Programming Guide.

Un esempio di messaggio è il seguente:

{"aps":{"alert":"Hello, world!","sound":"default"}}

Vi riporto i tutorial da cui sono partito per poter scrivere questa mini-guida:

 

Partiamo ora con la parte operativa:

 

[iOs] Far votare o recensire un’app su Apple Store con Appirater

Volete invitare l’utente a lasciare un voto o una recensione sulla vostra app su Apple Store? Sono diverse le librerie che permettono di fare il rating, ma tutte di terze parti.

La libreria che vi consiglio, che è anche quella più utilizzata per tale scopo, è Appirater, di cui trovate una presentazione sul sito ufficiale del creatore:

http://arashpayan.com/blog/2009/09/07/presenting-appirater/

Il codice è scaricabile direttamente da GitHubhttp://github.com/arashpayan/appirater/

AppiraterScreenshot

Cosa vi permette di fare Appirater:

  • chiedere all’utente se vuole recensire e votare la vostra app su Apple Store, visualizzando una popup con opzioni
  • permettere di impostare quando visualizzare la popup, se dopo N giorni dall’installazione dell’app (o sua nuova release) sul device oppure dopo N utilizzi (uses) dell’app stessa
  • permettere di posticipare la recensione da parte dell’utente, ricordandogli di farlo dopo N giorni
  • oppure, se l’utente non vuole recensire l’app, “ricordare” tale opzione e non visualizzare più il messaggio di popup
  • i messaggi della popup sono localizzabili in varie lingue (compreso italiano)

Le opzioni sono configurabili nel file Appirater.h e le vedremo in dettaglio dopo aver definito come installare la libreria.

Installazione

  1. Scaricare da GitHub la libreria ed importare tutti i suoi file (comprese le cartelle delle lingue .lproj che vi interessano) nel vostro progetto
  2. Se utilizzate l’ARC (Automatic Reference Counting), poiché la libreria è un pò vecchiotta e non utilizza l’ARC, dovete marcare il file Appirater.m con il flag -fobjc-arc (basta andare sulla root del progetto, selezionare il target e nella scheda Build Phases » Compile Sources, in corrispondenza della classe Appirater.m, inserire il flag su citato cliccando due volte su tale classe)
  3. Aggiungete al vostro progetto i seguenti framework (sempre nella scheda Build Phases, sezione Link Binary with Libraries): CFNetworkSystemConfiguration e StoreKit. Assicuratevi di cambiare da Required ad Optional il flag del framework StoreKit, sempre nella sezione Build Phases » Link Binary with Libraries del target.
  4. Infine, potete utilizzare Appirater direttamente nel vostro AppDelegate.m, in corrispondenza del metodo application:didFinishLaunchingWithOptions:

Utilizzo. Un esempio di utilizzo di Appirater è il seguente: 

    //call the Appirater class
    [Appirater setAppId:YOUR_APPID];
    [Appirater setDaysUntilPrompt:1];
    [Appirater setUsesUntilPrompt:10];
    [Appirater setSignificantEventsUntilPrompt:-1];
    [Appirater setTimeBeforeReminding:2];
    //[Appirater setDebug:YES];
    [Appirater appLaunched:YES];

Tale codice è stato inserito nel metodo dell’AppDelegate application:didFinishLaunchingWithOptions:

Potete settare una serie di opzioni o come fatto nell’esempio precedente o modificando i valori di default dell’interfaccia Appirater.h.

Importante è inserire l’AppID della vostra app, così come visualizzata nelle informazioni relative all’app stessa sull’account di iTunesConnect. Per farvi rilasciare un AppID dovete aver pubblicata una vostra app sullo store o almeno registrato tutte le sue informazioni lì prima dell’invio ad Apple per l’approvazione.

Tra le opzioni che possiamo settare abbiamo:

  • + (void) setAppId:(NSString*)appId; permette di settare l’AppID dell’app (da prelevare su iTunesConnect)
  • + (void) setDaysUntilPrompt:(double)value;  setta il numero di giorni da quando è installata l’app (o una sua nuova release) dopo i quali visualizzare la popup di rating
  • + (void) setUsesUntilPrompt:(NSInteger)value; setta il numero degli “usi” (uses) dopo i quali si chiede all’utente se vuole votare. Un uso potrebbe essere il fatto che l’app si apra in primo piano nel device.
  • + (void) setSignificantEventsUntilPrompt:(NSInteger)value; setta il numero di eventi significativi prima di chiedere all’utente se vuol fare il rating
  • + (void) setTimeBeforeReminding:(double)value; setta il numero di giorni prima di rivisualizzare la popup di rating (una sorta di promemoria)
  • + (void) setDebug:(BOOL)debug; questa opzione è comoda per gli sviluppatori, perché consente di visualizzare immediatamente la popup per poter fare test o sviluppo. Tale opzione è da disabilitare quando si rilascia l’app sullo store.

Eccovi un altro riferimento utile (stavolta in italiano): http://www.htmedia.it/2012/03/tip-ios-31-chiediamo-una-recensione-con-appirater/

Buon rating!

[iOs] Il Logging nelle nostre app con le Preprocessor Macros

Prima di un rilasciare una app iOS su Apple Store, è buona prassi fare un pò di pulizia dei log sparsi nel codice. Molti sviluppatori, infatti, sono restii all’utilizzo del debug e preferiscono utilizzare, man mano che sviluppano, la classe NSLog e farsi stampare gli output sulla console. Dunque, i nostri progetti rimangono pieni di NSLog che, tuttavia, è meglio non rilasciare sulle app in esercizio. Il motivo è dovuto al fatto che la scrittura dei log è onerosa e potrebbe ridurre le performance della nostra app. Inoltre, anche se la console del device è nascosta all’utente, potremmo dimenticare di loggare informazioni sensibili … e ciò è “no buono”.

Ho letto un pò di articoli a riguardo, tra cui i seguenti:

Ecco la procedura che ho seguito, utilizzando le Preprocessor Macros. L’idea è quella di inserire un flag (-DDEBUG) nella configurazione di DEBUG del nostro progetto e importare nelle nostre classi un log “custom” (DLog oppure ALog).

  • Per prima cosa, inserite un file Log.h nel vostro progetto con il seguente contenuto:
#ifdef DDEBUG

#   define DLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

#else

#   define DLog(...)

#endif

// ALog always displays output regardless of the DEBUG setting

#define ALog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
  •  Poi spostatevi nella configurazione del vostro progetto (click sulla root di progetto, selezionate Targets e poi spostatevi nella scheda Builds Settings). Qui, cercate la voce “Other C Flags” e inserite il flag -DDEBUG in corrispondenza della configurazione di DEBUG.

  • NOTA. Il punto precedente non è necessario se in Log.h si va a controllare il valore del flag nativo DEBUG (che è true se siamo in ambiente di debug, false quando si è in modalità Release/Ad Hoc), anzichè DDEBUG (che è una nostra variabile “custom”)
    #ifdef DEBUG
  • Importate l’interfaccia Log.h nel file di progetto <YourApp>_Prefix.pch, in modo da rendere visibile la macro in tutte le classi (senza importare esplicitamente la macro ogni volta). Nel mio caso, ecco il contenuto del .pch:
#import <Availability.h>
#import "Log.h"

#ifndef __IPHONE_5_0
#endif

#ifdef __OBJC__
	#import <UIKit/UIKit.h>
	#import <Foundation/Foundation.h>
#endif
  • Infine, potete utilizzare i log “custom” normalmente come fareste con NSLog, come segue:
 DLog(@"Logging %d con %@",1, @"DLog");
 ALog(@"Logging %d con %@",2, @"ALog");

Eccovi l’output di esempio delle precedenti righe di log:

2012-12-25 15:03:16.276 MyApp [4451:907] -[AppDelegate application:didFinishLaunchingWithOptions:] [Line 33] Logging 1 con DLog
2012-12-25 15:03:16.281 MyApp [4451:907] -[AppDelegate application:didFinishLaunchingWithOptions:] [Line 34] Logging 2 con ALog

DLog e ALog, per come sono stati configurati nel Log.h, stampano anche il nome della classe, il metodo e la riga di codice in cui si trovano. ALog stampa anche se non siamo in DEBUG (quindi, come NSLog, loggherebbe anche quando abbiamo rilasciato l’app su Apple Store o con una distribuzione “ad hoc”).

Quindi, lanciando la vostra app in DEBUG (sia sul Simulatore che sul device) vi troverete i log stampati sulla console. In Release (sia su App Store che su una distribuzione “ad hoc” dell’IPA) non verrà loggato nulla sul device dell’utente, se avete utilizzato DLog (e non ALog oppure NSLog).

[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 libreria Three20: navigazione “persistente” e galleria fotografica nelle vostre app

Three20 è una libreria open-source scritta in Objective-C e molto utilizzata e diffusa tra le maggiori app in Apple Store, come Facebook, Posterous, Pulse, Meetup.com e SCVNGR (vedi il seguente link con l’elenco delle app più famose che lo hanno utilizzato: http://three20.info/gallery).

La libreria mette a disposizione un ricco set di view controller come il Launcher, il popolare Photo Browser per la creazione di una gallery, e varie tables concepite per i contenuti Internet.

Altra funzionalità potentissima è quella che permette di accedere alle view delle vostra app tramite delle URL, come se la navigazione avvenisse su un sito web. Tale possibilità è davvero eccezionale, perché senza tale framework siamo costretti a programmare la navigazione con una gestione a stack delle view (grazie al navigation controller), dove il “salto” tra una vista e l’altra può avvenire solo tramite operazioni di push e pop delle stesse. Three20 introduce, quindi, il concetto di “persistenza“: permette di ricordare lo stato dell’app, ovvero ogni pagina (vista) viene “raggiunta” grazie ad una specifica URL. Quando un utente naviga attraverso le viste, Three20 memorizza una history di navigazione e la scrive su disco. Quando l’app viene ricaricata di nuovo, queste URLs vengono rieseguite istantaneamente così che la navigazione inizia dall’ultima vista visualizzata.

La libreria è modulare, ossia è possibile scegliere quali elementi includere nelle nostre app. Ciò fa di Three20 l’unico framework in Objective-C che incoraggia l’utilizzo di quelle che la comunità chiama “extensions“. Il Launcher è un’altra implementazione open-source disponibile in Three20 che emula l’app launcher standard dei dispositivi iOs (ossia il “desktop” con tutte le app installate, detto springboard). Il Launcher permette, dunque, di riordinare e cancellare gli elementi, personalizzare il numero di colonne e righe e di gestire pagine multiple.

Ecco il link al sito ufficiale con la demo delle funzionalità disponibili in Three20http://three20.info

Per una introduzione vi consiglio di leggere il post sul blog di Ray Wenderlich:

http://www.raywenderlich.com/656/introduction-to-three20

Per l’installazione del framework nelle vostre app vi invito a vedere il seguente video:

http://www.youtube.com/watch?v=-0-E-Z0fihg

Il progetto si trova su GitHub e prendi il nome di Facebook-Thre20, perché Facebook lo utilizzò per implementare la sua prima app mobile e lo ha fixato/customizzato nella versione attualmente (1.0.6) più stabile: https://github.com/facebook/three20/

L’installazione di Three20 nelle vostre app è molto semplice. Prima occorre scaricare la libreria a questo link: http://three20.info/roadmap/1.0.6.2 (o da riga di comando con GIT o decomprimendo il .tar). Vi consiglio di mettere la cartella decompressa di Three20 (rinominandola in three20) nella parent directory che contiene il progetto della vostra app. Basta poi digitare da terminale il seguente comando python per procedere all’installazione e configurazione automatica della libreria nella vostra app:

python three20/src/scripts/ttmodule.py -p path/to/myProject.xcodeproj Three20

Vi ritrovate comunque tutti i passi, anche quelli della procedura manuale di installazione, al seguente link: http://three20.info/article/2010-10-06-Adding-Three20-To-Your-Project Dopo l’installazione, nel progetto della vostra app, vi ritroverete (nella cartella Frameworks o Dependencies) i seguenti sottoprogetti (o moduli):

  • Three20Core
  • Three20Network
  • Three20Style
  • Three20UICommon
  • Three20UINavigator
  • Three20UI
  • Three20

Quando compilerete il vost ro progetto, XCode compilerà prima i precedenti sottoprogetti, rendendo disponibili i compilati alla vostra app.

Per realizzare una galleria di foto in una app iPhone/iPad, io ho seguito l’articolo sul blog di Ray Wenderlichhttp://www.raywenderlich.com/1430/how-to-use-the-three20-photo-viewer

Grazie al precedente articolo, ho potuto realizzare le gallery di foto delle mie app iVagabro e LuBannApp.

 

[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