malcom

Il coro di voci contrarie alle politiche dell’AppStore si è arricchito in questi giorni di un altro nome di ‘prestigio’: Joe Hewitt che hacurato la realizzazione dell’applicazione Facebook per iPhone ha deciso di abbandonare la piattaforma per tornare a lavorare sul web. A lui si è aggiunto anche Justin Williams di Rogue Amoeba (team specializzato nell’audio, conosciuto di più in ambito mac che non su iPhone).
Così se in valore assoluto la piattaforma non ne risentirà troppo (questo almeno nel medio periodo), c’è anche da dire che proprio da questo genere di persone sono nati i programmi di maggior successo che cavalcano ancora oggi le classifiche dello Store… nonchè quelli più curati sia dal punto di vista grafico che tecnologico (cosa che gli utenti Mac sanno molto bene).

Per Joe si tratta di una questione che trascende un pò la gestione tecnico/politica dello store, sconfinando più in un discorso generico sulla libertà di sviluppo: pur sottolineando la possibilità di Apple di poter scegliere come far girare gli ingranaggi di AppStore senza doverne rendere conto a nessuno, ritiene che questo insieme di regole (che spesso non hanno contorni ben definiti -ndr.) venute dall’alto e non create dalla comunità, non facciano altro che danneggiare sviluppatori da una parte e utenti dall’altra.

Nel frattempo un’altra notizia sta facendo il giro della rete: sembra dato per certo che Apple abbia introdotto nella stanza dei bottoni dello Store un tool in grado di verificare automaticamente la presenza di chiamate ad API private da parte di un programma.
La cosa deve aver scosso parecchi (ignoranti) tanto che perfino Gizmondo ieri pubblicava un articolo dai contorni davvero sinistri e apocalittici… per un momento ho creduto di aprire Repubblica (poi mi sono accorto che mancava la petizione della settimana):

“iPhone Apps Have to Be Approved by Robots Now, Too”

che suona più o meno come “Le applicazioni sullo store saranno approvate da ‘Robot’”. L’articolo apre con un

“Sounds sinister, right? That’s probably because I replaced the word “computers” with “robots!” For effect! But no, still, this is at least insteresting [...]“

Messo così certamente può suonare un attimino sinistro. Soprattuto per tutti coloro che di sviluppo software sanno poco o niente.
Queste persone avranno immaginato che Zio Steve avesse licenziato la (poca) manovalanza addetta alle verifiche per rimpiazzarla con tutti HAL 9000 d’alluminio satinato.
L’articolo in questione deve aver talmente intrigato i lettori che nel giro di qualche ora le testate nostrane erano già pronte con la traduzione italiana opportunamente amplificata (con mia grande sopresa questo articolo manca ancora su Melablog…ma li capisco vista la bufera di queste settimane).

In realtà la notizia non ha niente di sconvolgente (men che meno di apocalittico); ad ogni modo prima di spiegarvela è necessario fare una breve premessa sulla dicitura “API Private” (cosa che evidentemente in pochi sanno).

Le Application Programming Interface, o API appunto, sono un insieme di funzioni disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per un determinato compito: ad esempio potrebbero essere tutte le funzioni offerte per gestire la fotocamera o la connesione di rete.
Le API vengono rese pubbliche quando la loro implementazione risulta completa e non soggetta a cambi profondi (freezed); questa procedura si rende necessaria affinchè gli sviluppatori possano essere tutelati in caso di aggiornamenti dell’OS. Ovviamente nulla vieta alla società di poterle in futuro aggiornare; in questo caso però sarà tenuta a fornire retrocompatibilità per un certo lasso di tempo (si parla quindi di funzioni deprecate).

Il fatto che delle API siano private non è quindi un modo per fare dispetti ai poveri programmatori ma soltanto per dire “occhio, quel set di funzioni è ancora soggetto a grandi cambiamenti, non è documentato etc etc”.
Tecnicamente è possibile quindi utilizzare delle API private, a patto di comprenderne il loro modo d’uso e di accettare il fatto che il proprio software potrebbe non funzionare correttamente in futuro.

Siccome nel caso in questione non si parla di un computer, ma di un device mobile, mi pare piuttosto naturale che Apple cerchi di tutelare gli utenti dalla possibilità di avere un software che potrebbe un giorno piantarsi senza nessun apparente motivo (ovviamente Apple ha anche tutta l’intenzione di tutelare la propria immagine e quella del dispositivo evitando che questo sia possibile; in questo senso è rimasta coerente con i principi iniziali).

In questa ottica la necessità di controllare se un programma faccia chiamate a funzioni non ancora pubblicamente stabili/disponibili pare allora la cosa più naturale del mondo. E se è automatizzato (mi sorprende in effetti che prima non lo fosse) non ha niente di così trascendentale (con un debugger e un pò di esperienza si può fare lo stesso su qualunque computer).
Anzi mi pare un modo per accellerare un iter burocratico davvero troppo lento.

Questo sembra averlo capito anche l’articolista che verso metà articolo prova a spiegare la stessa cosa smorzando un pò i gli animi allarmisti (purtroppo per coerenza con il titolo il finale torna ad essere piuttosto stupido ” Congratulations, developers! Your next appeal against app rejection will be to a piece of software, which has no capacity to feel your pain”).
Così se almeno a Gizmondo lo hanno capito sembra che nel bel paese sia passato, al solito, solo la parte distruttiva: iPhoneItalia parte lanciata con un:

“Il tool automatico che rifiuta le applicazioni su AppStore”

Il resto dell’articolo viaggi su binari molto più generici (probabilmente il ‘giornalista’ si era stufato già di tradurre) ma conclude con una bella frase ad effetto:

“[...] Questo significa che da oggi in poi gli sviluppatori dovranno usare solo le API consentite da Apple, pena il rifiuto automatico!”

(sui commenti stendo un velo pietoso, non è mia abitudine “sparare sulla croce rossa”).

Tornando alla situazione dell’AppStore concordo in linea di massima con quanto detto da Luca De Biase sul suo blog; i problemi centrali dell’AppStore sono fondamentalmente due:

Il processo di approvazione. Dovrebbe far parte delle doc ufficiali....

• l’estrema lentezza nell’approvazione delle applicazioni: i tempi si sono certamente ridotti ma in un contesto così dinamico come quello mobile due settimane di wait and stop sono veramente tante; questo è tanto più vero nel caso in cui si tratti di aggiornamenti volti a correggere errori gravi. Sarebbe molto più accettabile un canale privilegiato per gli aggiornamenti (dove magari il check è fatto a posteriori) e tempi medi nell’ordine di 5-7 giorni.
• - le regole poco chiare: il fatto che si bocci per un non nulla è davvero inquietante. Si vedono centinaia di applicazioni dall’user experience a dir poco allarmante e se ne boccia una perchè magari non da errore in caso di mancanza di rete. Ci sono almeno 80 applicazioni per chiamare velocemente un numero cliccando l’icona (fatevi di conto che si tratta di un poche decine di righe di codice) e ci si preoccupa di errori grossolani.

E’ indubbio che questo stato di cose dovrà cambiare; è sopratutto necessario che questo avvenga prima che l’emorragia di persone importanti (di quelle che tengono veramente alla piattaforma, non di tutte quelle aziende che spremono dove si può finchè si può) sia troppo evidente. E lo si deve fare in vista di una concorrenza, quella di Android, che presto farà sentire il proprio peso.
Rubo la conclusione migliore a Luca:

“[...] Troppa segretezza e troppo autoritarismo, generano sospetti e malumori: per sconfiggerli, talvolta, basta spiegare meglio i fatti.”