La pirateria – e forse dico una cosa scontata – è un grosso problema anche per iOS.

Nel mondo del Jailbreak esistono AppStore fittizi dove è possibile scaricare gratuitamente copie di app che normalmente si trovano a pagamento.

Il tipo di utenza che usufruisce di questo servizio è divisibile in due macro-categorie:

a. persone che non compreranno mai la tua app

b. persone intenzionate all’acquisto, ma che desiderano provarla prima di investire i loro soldi nel tuo prodotto 

Riguardo al successivo pagamento da parte degli utenti tipo b. non bisogna farsi molte illusioni: sono davvero pochi coloro che regolarizzano la loro posizione andando sullo store virtuale di Apple.

Lo scenario è, dunque, tutt’altro che roseo. Un’ulteriore complicazione viene anche dalla natura stessa delle applicazioni. Questo genere di prodotti ha, infatti, una vita brevissima di utilizzo-medio, con il tangibile rischio che la ”prova” gratuita coincida perfettamente con il termine di utilizzo. Detto questo le app hanno anche costi rappresentativi del loro effettivo utilizzo. Apple, inoltre, non fornisce alcun periodo di trial sui prodotti distribuiti attraverso l’AppStore.

Come accade per altri settori, anche le tecniche per evitare la pirateria sulle app sono molto complesse, facilmente aggirabili e dall’elevata possibilità di creare un danno anche a chi l’applicazione l’ha regolarmente acquistata. Questo a causa di falsi positivi che possono essere causati anche per una semplice sostituzione del device. Non dimentichiamoci, poi, che Apple non vincola l’applicazione al dispositivo sul quale è stata scaricata, ma all’account dell’utente che l’ha acquistata.

Esistono soluzioni al problema? Una tecnica ottimale sarebbe quella di verificare se effettivamente l’utente ha effettuato l’acquisto, richiedendo una sorta di ricevuta digitale. Con iOS7 è stato introdotto un set di nuove API che consentono di ottenerla (anche se – a dire il vero – il sistema era comunque disponibile già con Lion). La classe è in oggetto SKReceiptRefreshRequest , interessante vero? Peccato che la verifica dello scontrino digitale sia ancora una procedura particolarmente complessa.

La ricevuta digitale sarebbe anche utilizzabile nel passaggio da applicazione a pagamento ad applicazione con modello freemium, in questo modo sarebbe possibile fornire a chi ha già pagato un set superiore di risorse.

La speranza è che venga rilasciata una qualche utility che renda l’analisi più snella (esiste già una lib su GitHub, che comunque richiede diverse conoscenze nell’ambito di certificati etc). O il danno economico diventerà sempre meno gestibile.

IOS7 è uscito, lo sappiamo e molti di noi lo hanno già installato. Il nuovo sistema operativo rappresenta un cambiamento radicale rispetto al 6, un cambiamento necessario per svecchiare un prodotto che rischiava di essere visto come “datato”, specie se confrontato con quelli proposti da concorrenti che, con il trascorrere degli anni, hanno saputo produrre sistemi operativi molto accattivanti.

Non parlerò delle funzioni di iOS7, delle quali è stato detto già abbastanza. Voglio guardare “il dietro le quinte” e ripercorrere le trasformazioni che iOS7 ha subito negli ultimi mesi, dalla developer preview 1 fino al rilascio ufficiale odierno. Un’altra maniera per capire il modus operandi di Apple, fra tentativi, certezze e modifiche dell’ultima ora.

Per noi sviluppatori iOS7 rappresenta “un problema” anzi, due problemi. Il primo è il missmatch creativo che si è creato tra sistema operativo e applicazioni “vecchie” che per lo più utilizzavano lo scheumorfismo.

Il secondo sono le API e il nuovo modo di “vedere” le applicazioni.

La questione ha due risvolti, entrambi da considerare.

Senza dubbio per innovare, è necessario guardare avanti e, nel caso, prendere decisioni unilaterali, di forza, in maniera che tutti vi si adeguino senza negoziare. Lasciando troppa libertà si corre il rischio che ognuno continui sulla sua vecchia strada, implementando API vecchie. Una nota personale: è da tempo che mi riprometto di imparare bene il linguaggio “Ruby”, ma ad ogni rilascio di sistema operativo mi vedo costretto a ricominciare a studiare tutto daccapo.

Apple è decisamente coerente con quello che dice e fa; alcuni elementi dell’interfaccia grafica standard sono stati macellati da diversi sviluppatori (me compreso) per accontentare le richieste di clienti a cui non piaceva il pop up bluetto perché non in linea con i colori aziendali. Da Cupertino, infatti, non si smetteva di sconsigliare modifiche a tali componenti, avvertendo che release future avrebbero potuto generare cambiamenti, con il rischio di dare vita a comportamenti inaspettati con l’applicazione di questi hack… Insomma tutti ne erano consapevoli tanto ieri come oggi.

 

Tuttavia, se la filosofia che sta dietro a determinate scelte è comprensibile, le vie che propone per renderla operativa sono talvolta meno limpide.

Parliamo del minimalismo dell’interfaccia grafica di iOS7. È chiaro che questa scelta non è fine a sé stessa come su altri sistemi (una pura questione estetica, di gusto), ma propedeutica al contenuto e al contesto presentato, animazioni incluse.

Meno chiaro, invece, la maniera attraverso la quale trasformare il concetto in qualcosa di reale, attraverso la programmazione. Infatti, benché iOS7 preveda che tutte le app compilate debbano utilizzare come area lo schermo intero, ad oggi sembra non esistere un modo semplice per cambiare questa azione e renderla simile ad iOS6. Una scelta che ha fatto letteralmente impazzire un certo numero di sviluppatori. Capita che le “vecchie” applicazioni ricompilate vengano visualizzate con un layout diverso e con i contenuti che “scivolano” sotto la status bar. Un problema non da poco per chi come me sta lavorando per implementare animazioni di transizione diverse da quelle standard tra una sezione e un’altra senza usare gli strumenti forniti da Apple.

Non c’è dunque da stupirsi se il forum ufficiale della Mela morsicata è animato da discussioni visitate da migliaia di persone. In pratica, con questa scelta, si obbliga lo sviluppatore da una parte a “ridisegnare” gran parte del layout e dall’altra a tenere sempre presente la bicompatibilità con il vecchio sistema.

Gli stessi ingegneri Apple si sono dimostrati non esattamente all’altezza: le loro risposte ancora latitano e quando arrivano, non sono del tutto esaustive, soffermandosi su un solo modo di programmare , talvolta utilizzato da una percentuale minima dei programmatori. Intanto anch’io mi sono cimentato, proponendo una soluzione che riduca l’impatto sulle ore di lavoro e mantenga la retrocompatibilità con il 6. La speranza è che funzioni.

 

Il confronto con i programmatori ha portato Apple ha fare alcuni importanti correttivi. Dai primi giorni di settembre è possibile scaricare anche le versioni vecchie per quelle app che hanno interrotto la compatibilità con i precedenti sistemi operativi.

Nel nostro caso stiamo sviluppando un update per un nostro prodotto, iEtiquette che sarà compatibile solo con iOS7. Mentre per chi non avesse o potesse aggiornare sarà comunque possibile scaricare la versione precedente. Questa è una scelta di importanza enorme perché favorisce sia sviluppatori che utenti.

Il cambiamento, come dicevo all’inizio di questo post è radicale. Sicuramente qualcuno si lamenterà. Negli ultimi giorni ho letto di diverse polemiche riguardo ad aggiornamenti  di applicazioni a pagamento che – con il pretesto del passaggio al sistema 7 – dovranno essere pagate di nuovo dagli utenti che le avevano a suo tempo scaricate. Un caso eclatante – notizia di oggi – riguarda il task manager CLEAR che nella nuova versione iOS7 compatibile richiede ben 3 euro.

L’effort per rendere una app compatibile con iOS7 è molto elevato e per applicazioni complicate (CLEAR non è tra queste) è abbastanza normale che gli sviluppatori richiedano un pagamento. Il problema è che non è possibile fissare un prezzo di update, o gratis o tutto. D’altra parte ritengo che sia normale che un’applicazione supporti gratuitamente un solo sistema operativo. È una situazione che nel mondo desktop viviamo tutti i giorni (è probabile che qualcuno se ne approfitti, avvelenando il mercato).

 

Altre sorprese passate in sordina sono la possibilità di scaricare app in 3G fino a 100MB (prima il limite era di 50MB) e che un’applicazione per iPhone su iPad userà le risorse per retina display e verrà visualizzata a quasi tutto schermo, con un miglioramento sull’usabilità davvero notevole.