Riccardo Mori

Daring Fireball: One App at a Time: Ancora una volta il bravissimo John Gruber spiega come stanno le cose con la chiarezza e la sintesi che lo contraddistinguono. Stavo scrivendo un post proprio per approfondire l’argomento (ossia che sull’iPhone Apple non permette agli sviluppatori di terze parti di scrivere applicazioni che possano eseguirsi in background), in quanto pare che vi sia un dibattito piuttosto animato su questa ‘limitazione’ imposta da Apple.

Gruber:

Esistono svariate ragioni per desiderare che un’applicazione continui a girare in background (o almeno che abbia un processo helper senza interfaccia grafica che continui a girare in background; ma anche questo non è consentito nell’attuale SDK di iPhone).

Alcune di queste ragioni sono evidenti osservando le applicazioni Apple che in effetti si eseguono in background: il telefono, Mail, Safari e iPod. In altre parole, le applicazioni presenti di default nel dock nella parte inferiore dello schermo. Pertanto un’applicazione di terze parti non potrà controllare periodicamente la presenza di nuovi messaggi in background come fa Mail. Né sarà in grado di continuare a riprodurre un file audio in background, come fa iPod.

Nessuna delle altre applicazioni Apple, tuttavia, può girare in background. 

No, nemmeno l’orologio e gli SMS.

Nell’interfaccia utente dell’iPhone non esistono i concetti di ‘lanciare’ un’applicazione e ‘uscire’ da essa, continua Gruber, esiste solo lo switching, il passare da una all’altra:

Questa illusione viene mantenuta riducendo il più possibile i tempi di lancio e di uscita dall’applicazione. Regola generale: quando un’applicazione iPhone esce, qualsiasi cosa si stia facendo con essa viene salvata; quando si rilancia l’applicazione, qualsiasi cosa si stesse facendo con essa viene ripristinato. 

Perché Apple ha imposto questa limitazione, che a molti (programmatori e utenti) sembra un po’ troppo drastica? Gruber:

Semplice: iPhone è estremamente limitato dalle risorse a disposizione. Batteria, RAM, cicli del processore sono estremamente limitati. Se le applicazioni di terze parti potessero eseguirsi in background, questi tre componenti di iPhone ne soffrirebbero senza alcun dubbio. Tutte le applicazioni in esecuzione consumano memoria. iPhone è provvisto di soli 128 MB di RAM, senza spazio di swap. Le prestazioni della CPU e la vita della batteria verrebbero compromesse quando le applicazioni in background eseguono qualche compito — e se non stanno facendo nulla, che senso ha mantenerle in esecuzione? Ho notato un deciso aumento dell’autonomia della batteria sul mio iPhone quando ho impostato Mail per controllare i messaggi ogni 60 minuti invece che 15. Ed è solo un’applicazione. 

Per quanto riguarda le poche applicazioni Apple che girano davvero in background, Gruber spiega che gli ingegneri Apple hanno fatto di tutto affinché queste consumino il meno possibile in termini di CPU, batteria, memoria. Una cosa che non sapevo:

(L’applicazione iPod, per esempio, si esegue in background soltanto se si passa a un’altra applicazione mentre un brano è in riproduzione. Altrimenti anch’essa si chiude premendo il tasto Home per passare ad altro).

E per finire, potrebbe Apple consentire alle applicazioni di terze parti di girare in background?

Naturalmente. Si tratta di un compromesso, in cui gli utenti tecnicamente più avanzati pagano a vantaggio dell’utenza media. Il vantaggio è semplicemente questo: gli utenti non si dovranno preoccupare che le applicazioni che compreranno e installeranno dall’App Store potranno rallentare il loro iPhone o compromettere l’autonomia della batteria. D’altronde quale potrebbe essere l’alternativa? L’avviso di ‘non installare o eseguire troppe schifezze’ sull’iPhone?

E ritorniamo al discorso di un paio di post fa. iPhone non è un Mac né va considerato tale, anche se l’idea piace a molti. Forse più avanti si potrà pretendere che iPhone faccia di più, ma dovrà avere specifiche tecniche più aggressive: un processore più veloce e molta più RAM, tanto per cominciare. Poi, davvero, questa mania di voler riempire iPhone con le applicazioni più disparate la capisco poco. Non ho ancora un iPhone, lo avrò appena potrò acquistarlo regolarmente, ma penso già a come lo userei nella vita di tutti i giorni. Comodo per ascoltare musica, comodo come telefono, comodo avere la possibilità di leggere e scrivere email come se stessi usando un vero client di posta, e stesso dicasi per il Web. Quando osservavo, durante l’evento del 6 marzo, il responsabile dello sviluppo del programma AIM per chattare con iPhone, da un lato applaudivo lo sforzo e i risultati: dopo due sole settimane di sviluppo, l’applicazione è già carina. Dall’altro pensavo: la userei? E francamente la risposta è no. Oltre che sembrarmi ridicolo chattare con un telefono, mi immagino quanta attenzione e concentrazione un’attività del genere possa rubare. Forse potrebbe avere senso, che so, per ammazzare una lunga attesa in una stazione o in aeroporto; per il resto, mah, preferisco la separazione dei lavori. Chattare con il Mac, inviare SMS con il telefono.

Ma al di là delle mie preferenze personali, è innegabile il delicato equilibrio di risorse che l’iPhone offre, e che qualsiasi uso/abuso di una di esse finisce con l’incidere pesantemente sulle altre: CPU, memoria, batteria, sono intrinsecamente legate; l’iPhone com’è oggi — con le sole applicazioni Apple — è un ecosistema chiuso e ben rodato. È comprensibile che l’apertura verso l’esterno sia graduale. Certamente, si può obiettare che Apple dovrebbe lasciar fare, e che poi sta all’utente decidere come gestire le applicazioni che egli stesso installa, e che se il suo iPhone comincia a rallentare e la durata della batteria viene decisamente ridotta sono affari suoi. Ma per quanto riguarda l’ambito Mac ho visto e sentito troppi utenti dare la colpa a Apple per problemi creati da loro stessi volendo installare un sacco di haxie e schifezze sui propri Mac.

Apple non sta decidendo imposizioni restrittive per il puro gusto di farlo, lo sta facendo per non incrinare la fluidità e la bellezza dell’esperienza utente, che è in fin dei conti quello che ha reso iPhone l’oggetto fenomenale che è, e la ragione primaria del suo enorme successo.

Rogue Amoeba » iPhone SDK Bug Filing: Gli sviluppatori di Rogue Amoeba (la software house che ha realizzato, fra l’altro, Audio Hijack Pro, Fission e Airfoil) hanno inviato una serie di bug report ad Apple in merito all’SDK di iPhone. Sono, in sostanza, delle richieste di revisione di alcune restrizioni intrinseche all’ecosistema del Software Development Kit di iPhone. Secondo Rogue Amoeba, alcune delle migliorie proposte (tutte piuttosto radicali, a parer mio) tornerebbero comode agli sviluppatori, altre andrebbero a beneficio di tutti, programmatori e utenza, ma l’obiettivo comune a tutte, scrivono, è quello di rendere la piattaforma iPhone più robusta e potente possibile.

Brevemente, le loro richieste sono:

• Permettere l’installazione delle applicazioni a discrezione dell’utente e non di Apple;
• Permettere l’esecuzione in background delle applicazioni;
• Consentire l’accesso come utente root su iPhone;
• Realizzare un API di tipo MediaPicker per consentire l’accesso ai file musicali di iPod;
• Aggiungere un’opzione che permetta alle applicazioni per iPhone di accedere all’intero filesystem;
• Permettere alle applicazioni per iPhone di accedere al computer quando iPhone è collegato fisicamente;
• Permettere il VoIP sulla rete cellulare;
• Consentire alle applicazioni per iPhone di accedere alla porta Dock.

La prima cosa che mi è venuta in mente leggendo questo elenco è Steve Jobs che, dandogli un’occhiata, borbotta a mezza voce: “Scordatevelo”. Anch’io in effetti ho pensato la stessa cosa. Non è che siano proposte troppo fuori dal mondo, ma considerando la politica conservatrice che Apple ha dimostrato finora in materia di iPhone, un’apertura a questo livello è impensabile per il momento. Fin da quando è uscito iPhone e si è cominciato a parlare di applicazioni di terze parti, l’impressione che mi hanno sempre fatto gli sviluppatori, con la loro veemente insistenza per un’apertura totale della piattaforma iPhone, è quella di pensare a se stessi più che agli utenti finali. Ovvero, pensare a se stessi come modello di utente finale. Non è affatto così e non deve essere così. Per fare un esempio, dal punto di vista di un programmatore può essere tremendamente utile sfruttare l’esecuzione in background delle applicazioni, ma possono benissimo sfuggire importanti considerazioni di interfaccia utente. A questo proposito è interessante l’intervento a firma David Rouse nei commenti al post in questione:

Sul permettere l’esecuzione in background delle applicazioni non sono d’accordo, ancora una volta parlando da utente. Se chiudo AIM, vuol dire che ho finito di chattare e di utilizzare l’applicazione. Non dovrebbe nemmeno esserci un interruttore “online/offline” nell’interfaccia grafica […]. Ora, se io spengo il display e arriva un nuovo messaggio, lo si può notificare con un beep (fra l’altro, se l’azione dovesse mandare in crash l’applicazione mentre lo schermo è spento sarebbe irritante). Ma se l’applicazione sta girando in background e si sente un suono d’avviso quando arriva un messaggio, come faccio a sapere da dove arriva e che cosa ha provocato l’avviso? E non voglio vedere né finestre di dialogo flottanti né sei minuscole icone di terze parti nella barra di stato. Secondo me la regola di Apple che stabilisce che nessuna applicazione debba eseguirsi in background è estremamente sensata da un punto di vista di interfaccia grafica e di generale semplicità, anche se tecnicamente iPhone ha tutta la potenza per gestire eventi in background.

Un altro punto interessante della conversazione fra i commentatori al post e gli sviluppatori di Rogue Amoeba ha a che vedere con un’altra annosa questione che esiste dall’introduzione di iPhone: l’iPhone va considerato come un ‘Mac tascabile’ oppure no? Molti sviluppatori e nerd assortiti propendono per l’idea del ‘Mac tascabile’; molti utenti, tuttavia, non sono d’accordo. Per quanto poco possa contare la mia opinione personale: no, secondo me iPhone non deve essere trattato come un ‘Mac tascabile’, secondo me occorre un aggiustamento di prospettiva. Per chiarirci, la posizione di molti sviluppatori (fra cui quelli di Rogue Amoeba) è che iPhone — essendo praticamente potente come un Mac (Mike di Rogue Amoeba lo paragona a uno dei primi iBook) — debba essere aperto né più né meno di un Mac, e che i programmatori abbiano per questo una grande libertà di movimento, così da creare per iPhone una quantità di software e soluzioni pari a quelle oggi disponibili per la piattaforma Mac. Ma iPhone è uno smartphone. Intelligente, ricco di tecnologia appetitosa finché si vuole, ma non è un Mac.

Riporto uno stralcio illuminante della conversazione fra Gareth, uno dei commentatori al post in questione, e Mike, uno del team di Rogue Amoeba:

Gareth: A essere onesti, non riesco a capire il senso di molti di questi cosiddetti ‘bug report’. L’iPhone non è un Mac. Ripeto, iPhone NON È un Mac.

Solo perché si basa (in gran parte) sulle medesime tecnologie non signfica che sia la stessa piattaforma, con gli stessi utilizzi, ecc.

Apple è il guardiano dell’iPhone al momento. L’iPhone è piuttosto limitato rispetto a qualunque Mac dello scorso decennio. Il sistema di visione delle informazioni a video è totalmente diverso, e le capacità del suo processore non permettono un multi-tasking puro. Certo, molti processi possono eseguirsi in parallelo, ma non tutto. Apple vuole avere il controllo di tutto questo, altrimenti l’esperienza dell’utente potrebbe essere rovinata da sviluppatori ‘nerd’ troppo zelanti che semplicemente non afferrano il concetto.

Ciò che stai descrivendo, quel che sembra tu voglia, non è ciò che è l’iPhone o quel che l’iPhone potrebbe essere attualmente. L’iPhone è un telefono. Non è un ‘Mac da taschino’ e non lo sarà mai. Sarà sempre una parte, una ‘sotto-specie’ di quel che è un ‘Mac’ vero e proprio.

Mike: Hai ragione, non è un ‘Mac tascabile’, ed è proprio questo il problema. Io voglio un ‘Mac tascabile’. Quelli che possiedono un iPhone sbloccato sono mesi che si godono il loro ‘Mac tascabile’, e in generale pare che tutto funzioni [sugli iPhone hackerati], a parte la mancanza di approvazione ufficiale da parte di Apple.

Voglio però chiarire una cosa sulle capacità hardware di iPhone. Tu dici che iPhone è molto limitato rispetto a qualunque Mac del decennio passato, e che questo limita necessariamente la possibilità di un vero multi-tasking e di molte altre soluzioni interessanti. Non sei l’unico a pensarla così. È un’affermazione molto diffusa. Ma non è vero.

Dieci anni fa significa tornare ai tempi del primo iMac, che aveva un disco rigido da 4 GB, 32 MB di RAM, nessun tipo di accelerazione hardware 3D e un processore G3 a 233 MHz.

Il mio nuovo iPod Touch (essenzialmente identico a un iPhone ma senza l’hardware specifico del telefono) è molto più potente di quell’iMac, in ogni ambito. Ha il doppio della capacità di immagazzinamento, e l’hardware di immagazzinamento è molto più veloce di un disco rigido. Ha il quadruplo della RAM e il suo processore è 2–3 volte più potente. Per non parlare di un’accelerazione 3D più che soddisfacente.

Da un punto di vista hardware, l’iPhone e l’iPod Touch sono, a grandi linee, l’equivalente di un iBook di fascia media, con uno schermo molto piccolo e senza tastiera. Gli iBook di fascia media possono far girare tranquillamente l’intero Mac OS X nonché gestire il multi-tasking e qualsiasi programma arbitrario. […] 

Gareth: Mike, non è così. Chi possiede un iPhone ‘jailbroken’ (Dio, quanto odio quel termine) non ha affatto un ‘Mac tascabile’ per le mani, ma un ammasso di applicazioni da nerd, scritte male e implementate peggio. Brutte da vedersi, terribili da usarsi.

L’iPhone, come l’iPod, non è una piattaforma per nerd.

Forzare l’iPhone a effettuare gli stessi compiti di un Mac solo perché potrebbe esserne in grado da un punto di vista tecnico, significa non capire affatto il senso di questo dispositivo e di questa piattaforma.

È una delle ragioni per cui Apple ha atteso un certo tempo prima di annunciare lo SDK. Apple voleva che le persone si abituassero all’iPhone come dispositivo, al multi-touch come tecnologia di input, e al modo in cui vengono visualizzate le informazioni sullo schermo.

Gli sviluppatori dovrebbero pensare a che cosa possono realizzare con questa nuova piattaforma, all’interno dei limiti imposti dal dispositivo. Non dovrebbero pensare a fare il porting di qualsiasi applicazione verso l’iPhone solo perché è possibile farlo pasticciando un po’ in Xcode.

Non voglio un ‘Mac in tasca’ — che sia potente come i primi iBook o meno — perché il mio Mac è a casa mia o nel mio zaino. Quel che faccio sul mio Mac è… beh, è quel che faccio sul mio Mac. Non vorrò mai mettermi a ritoccare foto sull’iPhone, o a comporre documenti per davvero, perché il sistema di visualizzazione delle informazioni a video di iPhone è totalmente inadeguato per questo genere di attività.

L’iPhone fa già il 90% di quel che voglio faccia. E credo sia così anche per la maggioranza degli utenti. Sicuro, vi saranno applicazioni e servizi particolari che la gente vorrà e utilizzerà, ma per molti saranno davvero una o due cose in più [di ciò che iPhone adesso può fare].

Mi piace ciò che Apple ha fatto e come si è comportata. Dovresti vedere quell’ammasso di schifezze che viene passato come ‘software’ su altre piattaforme mobili per capire che la posizione di Apple come guardiano è una buona cosa. L’iPhone non farà mai tutto quel che vuole un nerd — nessuna piattaforma lo farà.

iPhone non è un ‘Mac da tasca’ e non lo sarà mai. Perché non è lo scopo primario del dispositivo (o dell’intera piattaforma, se è per questo). E gli sviluppatori devono capire questa differenza, altrimenti la piattaforma iPhone diventerà un obbrobrio come Windows Mobile.

In sostanza, non si può avere l’uovo e la gallina. Se deve essere e rimanere un’esperienza di alta qualità, allora deve esserci qualcuno che giudichi quale software possa offrire tale esperienza, e quale no.