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.”

L’ultima grande silurata dall’App Store è Google. Justin Williams, programmatore di VoiceCentral (un client che sfrutta Google Voice) si è visto rifiutare l’approvazione per i soliti imbarazzanti quanto assurdi motivi:

“Anzichè dirmi che la mia applicazione [Google Voice] duplicherebbe le funzionalità offerte dall’iPhone [il telefono stesso?] Apple dovrebbe essere più chiara a riguardo: mi dovrebbero dire che questa app compete con un prodotto Apple già esistente o comunque con qualcosa offerto dai suoi carrier esclusivi, AT&T in testa.
Preferirei una posizione più trasparente anzichè le solite spiegazioni senza senso”.

Nel suo blog Justin riporta una trascrizione per sommi capi della telefonata avuta con un certo Richard di Apple:

Richard: “La chiamo per dirle che VoiceCentral è stato rimosso dall’App Store poichè duplica features già presente su iPhone”

Justin: “Non capisco: TextFree, Skype, Fring o iCal non sono considerati duplicati?”

Richard: “Non posso discutere di altre applicazioni con lei”

Justin: “Non voglio discutere delle altre applicazioni ma di come le regole dello Store siano controverse e facilmente adattabili”

Richard: “Posso solo dirle che la sua applicazioni duplica funzionalità già esistenti e può confondere gli utenti. E’ contro la nostra policy.”

Justin: “Ma cosa è cambiato nella vostra policy? Il programma è nello store da quattro mesi senza nessun problema. Nell’ultimo mese e mezzo è tornato sotto review e senza che mi sia stata data la possibilità di aggiornarlo.”

Richard: “Non so che dirle se non che è in contrasto con la nostra policy”

Justin: “Può dirmi quale parti dell’applicazione duplicano queste funzionalità?”

Richard: “E’ inutile andare in dettagli insignificanti”

Justin: “Posso fare qualcosa per farlo approvare nuovamente sullo store?”

Richard: “Non saprei”

Justin: “Ma se non so come procedere non so neanche in che modo investire nello sviluppo di questa e di nuove applicazioni. Come posso sapere cosa si può o non si può avere sullo store?”

Richard: “Non so aiutarla in questo”

Justin: “Così dopo aver investito l’anima, tempo e denaro in un progetto questo viene rifiutato senza un motivo valido e soprattuto una spiegazione chiara. Come posso considerare Apple partner in questo senso?”

Richard: “Capisco quello che vuole dire ma non so come aiutarla”

Justin: “Sicuramente qualcuno in Apple le avrà chiesto di fare questa chiamata; posso parlare con questa persona?”

Richard: “No, sono l’unico con cui lei può parlare di questo problema”

Justin: “Ma ci sarà pure qualcuno che si occupa di questi affari e prenderà decisioni a riguardo…”

Richard: “Può parlare solo con me”

Justin: “Niente di personale ma questa non è una discussione. Lei mi ha detto che l’applicazione è stata rifiutata per un motivo poco chiaro e io non posso farle nessuna domanda perchè lei non può rispondere. Può almeno chiedere ai suoi superiori se è possibile avere una discussione più approfondita su questa situazione? Non mi interessa se devo firmare un altro NDA top-secret, ma devo capire come procedere e se ha ancora senso sviluppare in questo settore.”

Richard: “Lo farò sapere ai miei superiori”

La questione sembra quindi da ricercare nel timore delle compagnie telefoniche verso il sistema Google Voice perché potrebbe diventare uno standard di comunicazione VoIP portando con sé chiamate a basso costo ed SMS gratuiti. Lo zampino di AT&T in questo rifiuto è appoggiato anche dall’autorevole DaringFireball.

Che il processo di approvazione su App Store stia diventando soltanto un modo per escludere eventuali fastidi concorrenziali anzichè verificare la qualità dei prodotti da dare al grande pubblico sembra quasi una realtà di fatto. Nell’ultimo anno in cui mi sono occupato di programmazione per il melafonino ho avuto modo di vedere decine e decine di applicazioni con violazioni più o meno accentuate delle HIG Apple; ma non si tratta solo di dettagli tecnici a cui il grande pubblico può non far caso: spesso si tratta di errori macroscopici, di applicazioni che faticano a funzionare decentemente ma altre volte si tratta di applicazioni fondamentalmente inutili (e che non fanno altro che abbassare la qualità totale).
Qualsiasi sviluppatore che abbia avuto a che fare con la parte businness di App Store, l’iTunes Connect, potrà dirvi che spesso e volentieri si a che fare con un sistema lentissimo (tempi di approvazioni di almeno due settimane) che produce dei risultati davvero imbarazzanti (i controlli sono delle volte maniacali delle volte superficiali, spesso sembrano soltanto modi di verificare quanto una data applicazione sia pericolosa per Apple e i suoi partener).

Ma quello che sta accadendo non riguarda soltanto una questione di poca trasparenza. Un comportamento del genere da parte di Microsoft avrebbe alzato dei polveroni non solo mediatici ma anche a livello legale con il dipartimento di giustizia americano. Ma, sebbene in questo mercato Apple non rappresenti un monopolio (l’antitrust non misura lo share e neanche l’appeal di un prodotto), prima o poi arriverà il momento in cui dovrà fare i conti, volente o nolente, con un comportamento che prima di tutto innervosisce gli sviluppatori stessi.