Indice dei Contenuti
Non c'è sistemista, sviluppatore o professionista IT degno di questo nome che non conservi un bel ricordo della Apple delle origini, quella che dominò la scena dei personal computer nei trent'anni che passarono dalla (ri)fondazione dell'azienda (1977) all'uscita sul mercato del primo iPhone (2007): quella che rivoluzionò più volte il mondo dell'informatica con l'introduzione del Macintosh e dell'iMac, del MacBook e del Mac Pro, nonché di molti altri piccoli e grandi capolavori estetico/funzionali come l'iPod; l'avversaria "buona" e amica del consumatore, da contrapporre allo strapotere della "perfida" Microsoft come racconta il suggestivo film TV I Pirati di Silicon Valley, uno dei testi sacri dei cultori della mela e della figura di Steve Jobs.
Al tempo stesso non c'è sistemista, sviluppatore o professionista IT degno di questo nome che non si senta percorrrere da un forte senso di fastidio all'idea di dover lavorare - sia pure saltuariamente - sulle recenti piattaforme Apple, e non a torto: il sistema operativo OSX è una sorta di versione caricaturale di FreeBSD; il framework di sviluppo XCode è sostanzialmente indifendibile; i portali e gli strumenti di pubblicazione e distribuzione a corredo (iTunes Connect, Apple Developers Portal, Application Loader et. al.) fanno acqua da tutte le parti.
Che il comparto software non sia mai stato il cavallo vincente di Apple è del resto cosa nota: l'ultimo prodotto degno di nota è probabilmente Final Cut Pro, limitatamente alle versioni che giravano su Carbon. Eppure, stupisce non poco vedere come una azienda da 580 miliardi di dollari non sia a tutt'oggi in grado di dotare i propri utenti di strumenti di lavoro e sviluppo adeguati. L'imbarazzo che si prova nell'utilizzarli è talmente forte che a tratti viene persino da pensare che possa essere una strategia voluta: un sistema così farraginoso, inefficiente e opaco da poter essere utilizzato con successo soltanto da quelle aziende che possono permettersi di affidare il compito di sbrogliare la matassa a un team di sviluppo dedicato, tagliando fuori il libero professionista, lo sviluppatore occasionale e qualsiasi altra piccola realtà. Una vera e propria contraddizione rispetto alle premesse alla base del primo Apple Store, il quale registrò una enorme affermazione poprio perché diede a chiunque la possibilità di pubblicare il frutto del proprio lavoro con poco sforzo e investimenti contenuti. E' ancora così? Purtroppo no. Cerchiamo di capire cosa è cambiato e perché.
App Store
Neppure il fanboy Apple più sfegatato è nella posizione di negare che il ruolo pioneristico dell'App Store di Apple nell'economia della diffusione delle mobile app a livello mondiale è oggi messo in forte crisi dal Play Store di Google, il quale consente di fare le stesse cose a costi estremamente più bassi, con revenue migliori e con una usabilità decisamente superiore. Il confronto tra i due store si può riassumere comparando il costo della subscription richiesta agli sviluppatori: gli anacronistici 99 dollari/euro chiesti da Apple contro i 25 di Google, una differenza che fa capire immediatamente che aria tira.
La faccenda non migliora (per Apple) da un punto di vista dell'usabilità: per navigare sull'App Store è ancora necessario installare sul proprio PC il client di iTunes, in quanto non c'è ancora altro modo (!) di vedere i dettagli di una app online. Google Play, al contrario, ha una web app estremamente evoluta che consente persino di effettuare gli acquisti di app e servizi tramite il browser.
I problemi non finiscono qui: l'aspetto più scandaloso è infatti rappresentato dalle piattaforme messe a disposizione degli sviluppatori per la gestione dei certificati e della pubblicazione/distribuzione delle app, ovvero dalla loro "integrazione" (se così si può chiamare) con gli strumenti di sviluppo, ovvero con il software XCode.
Apple Developer Portal
Partiamo dal cosiddetto Apple Developer Portal, il portale web mediante il quale gli sviluppatori hanno la possibilità di scaricare gli strumenti di sviluppo nonché gestire i certificati, profili e identità delle proprie applicazioni... ma non la loro pubblicazione: quest'ultima, infatti, avviene mediante un portale diverso chiamato iTunes Connect (vedi sotto). Questo, in parole povere, significa che per gestire le nostre app sarà necessario fare avanti e indietro tra due portali, in quanto ciascuna di esse necessiterà inevitabilmente sia della gestione di certificati, profili e identità che delle ovvie esigenze di pubblicazione.
Sull'usabilità del Developer Portal non mi dilungo, basti ricordare l'assurda e irrazionale gestione di certificati, identità e provisioning profile che sembra fatta apposta per complicare la vita allo sviluppatore: la necessità di generare un app ID e di creare un certificato per firmarla è senz'altro una necessità comprensibile, in quanto il sistema ha bisogno di essere sicuro che ciascuna applicazione sia effettivamente stata compilata dallo sviluppatore autorizzato. Ma perché imporre anche l'obbligo di generare un provisioning profile? La risposta è (purtroppo) molto semplice: il provisioning profile è l'incarnazione della volontà di Apple di controllare la distribuzione della app, impedendo agli sviluppatori di distribuirla autonomamente. A conti fatti, l'unico vero scopo del provisioning profile è quello di consentire alla Apple di determinare i dispositivi autorizzati all'installazione/esecuzione della app; come se non bastasse l'implementazione fa acqua da tutte le parti, complicando ulteriormente la vita dello sviluppatore.
iTunes Connect
Veniamo quindi al già menzionato iTunes Connect, il portale tramite il quale possiamo gestire tutti i prodotti che abbiamo intenzione di pubblicare su iTunes - fermo restando che tutte le app andranno comunque create, firmate e convaliate sul summenzionato Developer Portal. Qui la Apple si è a davvero superata, riuscendo a creare uno tra i meccanismi di upload più macchinosi, ridondanti e criptici mai visti nella storia dello sviluppo software.
La prima cosa che salta all'occhio è la necessità di doversi dotare - come spesso accade per Apple - di un client dedicato: è infatti possibile pubblicare una App soltanto tramite le applicazioni XCode o Application Loader, che funzionano peraltro in modo estremamente simile: l'unica differenza sostanziale è che XCode compila la app prima di inviarla a iTunes Connect, mentre Application Loader lavora con file .ipa compilati in precedenza. In entrambi i casi il file .ipa viene controllato sia dal client locale che dal web service di iTunes Connect, al quale spetta il compito di dare o meno l'OK a seconda che la build inviata rispetti o meno i requirement necessari per la pubblicazione.
E qui viene il bello: i requirement cambiano in continuazione, con una frequenza che ha dell'incredibile, a seconda di una serie di eventi che possono o meno essersi verificati nelle variegate realtà hardware e software che ruotano intorno all'universo Apple. Alcuni esempi:
- Ogni volta che viene rilasciato un nuovo dispositivo Apple (iPhone, iPad, iWatch et. al.), perché la app dev'essere dotata degli asset relativi (icone, screenshot et. al.)
- Ogni volta che viene rilasciata una nuova versione del sistema operativo iOS, perché potrebbe essere cambiato il modo di generare i certificati oppure perché potrebbero esserci nuove limitazioni a livello di privacy, sicurezza o gestione delle risorse/asset interni, per non parlare dei frequenti breaking changes.
- Ogni volta che viene rilasciata una nuova versione di XCode, perché potrebbero essere state aggiunte nuove voci di configurazione da inserire obbligatoriamente nel file .plist o nuove modalità di compilazione, archiviazione o code signing della app.
- Ogni volta che viene modificato il servizio Apple Push Notifications (APN), perché potrebbero esserci delle nuove regole da seguire, interfacce da implementare o altre operazioni da compiere per far funzionare correttamente le notifiche.
- Ogni volta che vengono effettuati cambiamenti alla grafica dell'App Store, che potrebbe necessitare di nuove immagini, icone, testi e/o altri asset da utilizzare nella vetrina della app.
Il tutto, ovviamente, in aggiunta alle fisiologiche scadenze dei certificati e dei provisioning profile, tutta roba per cui è prevista una rigorosa durata annuale, tassativamente non estendibile (vanno rifatti da capo ogni volta): non sia mai che lo sviluppatore possa privarsi per troppo tempo dal necessario svolgimento di tutte queste entusiasmanti attività.
Un caso di scuola
Concludo questa analisi tra gli incubi e deliri della piattaforma di pubblicazione Apple con un breve resoconto delle attività che ho dovuto svolgere durante la recente pubblicazione di una app. Premetto che non toccavo XCode da qualche mese, quindi la mia macchina virtuale (valida alternativa all'acquisto di un computer Apple, se si ha l'accortezza di seguire le avvertenze descritte in questo articolo) era ferma a OSX 10.11 El Capitan e XCode 7.
Gli aggiornamenti "consigliati"
La prima cosa che ho fatto è stata quindi un upgrade di tutto il sistema: da El Capitan a Sierra, da XCode 7 a XCode 8. Perché, direte voi? Se il sistema è così traballante, non è meglio "non toccare niente"? Lo sarebbe di certo, se non fosse che la Apple affianca alla pessima gestione della backward compatibility dei propri sistemi la cattiva abitudine di cessare piuttosto rapidamente il supporto alle vecchie versioni: in altre parole, restare indietro può portare problemi persino più grandi di quelli che arrivano in conseguenza di un upgrade.
Gli errori "noti"
Una volta aggiornato il sistema ed applicato le modifiche al codice sorgente della mia app, ho provato a pubblicarla alla vecchia maniera: archiviazione e pubblicazione diretta per distribuzione su App Store. Ha funzionato? Ovviamente no! Al momento di effettuare l'upload, iTunes Connect restituiva i seguenti errori:
- Errore ITMS-90022 e/o ITMS-990023, dovuto alla mancata presenza di una serie di icone relative alle ultime versioni di iPhone e iPad.
- Errore ITMS-90096, dovuto alla necessità di inserire una immagine di tipo "Default-568h@2x.png" nella root della app, obbligatoria a partire dall'uscita dell'iPhone 5.
Risolvere questi problemi non è stato difficile poiché, fortunatamente, erano entrambi presenti - e ampiamente documentati - nel popup di errore presentato da XCode al momento del tentato upload.
Per maggiori dettagli su ciascuno di essi consigliamo la lettura dei seguenti item presenti sul sito StackOverflow:
Una volta risolti lo strumento di pubblicazione su App Store non ha più avuto nulla da ridire, convalidando la build e restituendo un popup di avvenuta ricezione.
Gli errori "ignoti"
Un messaggio del genere non può che far pensare che l'invio del file .ipa sia avvenuto con successo. E' così? Ovviamente no! Nello specifico, nel tab Activities del sito iTunes Connect - nella sezione dedicata all'app in questione - non c'era alcuna traccia della nuova build, come se l'upload non fosse mai avvenuto. Inutile dire che, tentando nuovamente di effettuare nuovamente l'invio, XCode restituiva candidamente un messaggio di errore avvertendo che la build era già presente sul sistema. A quel punto, pensando che potesse trattarsi di un errore di upload, ho provato a cambiare numero di build ed effettuare nuovamente l'invio. Problema risolto? Neanche a parlarne! Ancora una volta la build è sparita nel nulla, fagocitata da iTunes Connect senza alcun tipo di feedback.
La spiegazione dell'arcano è arrivata qualche ora dopo tramite la seguente e-mail automatica:
Dear developer,
We have discovered one or more issues with your recent delivery. To process your delivery, the following issues must be corrected:
This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSPhotoLibraryUsageDescription key with a string value explaining to the user how the app uses this data.
Though you are not required to fix the following issues, we wanted to make you aware of them:
Missing Push Notification Entitlement - Your app includes an API for Apple's Push Notification service, but the aps-environment entitlement is missing from the app's signature. To resolve this, make sure your App ID is enabled for push notification in the Provisioning Portal. Then, sign your app with a distribution provisioning profile that includes the aps-environment entitlement. This will create the correct signature, and you can resubmit your app. See "Provisioning and Development" in the Local and Push Notification Programming Guide for more information. If your app does not use the Apple Push Notification service, no action is required. You may remove the API from future submissions to stop this warning. If you use a third-party framework, you may need to contact the developer for information on removing the API.
Once the required corrections have been made, you can then redeliver the corrected binary.
Regards,
The App Store team
La mail mette in evidenza altri due errori presenti nella app:
- Mancanza di una descrizione d'uso relativa ai (nuovi) parametri di sicurezza e gestione della privacy imposti da Apple in conseguenza dell'uscita di iOS 10.
- Mancanza dell'entitlement necessario per gestire correttamente il servizio di invio notifiche.
La domanda, a questo punto, nasce spontanea: perché mai questi errori non sono stati evidenziati al momento dell'upload come i precedenti? Come è possibile fare affidamento su un sistema che accetta una build dopo una serie lunga e accurata di controlli, con tanto di messaggio di OK, salvo poi invalidare il file ricevuto e comunicare via e-mail, per giunta con un ritardo di diverse ore, una serie di altri impedimenti che è necessario correggere pena l'impossibilità non solo di poterla utilizzare, ma addirittura di vederla caricata? Era davvero così difficile mettere in piedi uno strumento di pubblicazione in grado di gestire meglio queste dinamiche, risparmiando allo sviluppatore tutte queste perdite di tempo e oneri aggiuntivi? Evidentemente si. O forse, più semplicemente, alla Apple la qualità della vita dello sviluppatore medio interessa assai poco. Viene persino da pensare, come detto all'inizio dell'articolo, che vi sia una precisa volontà di complicare la vita al developer occasionale, lasciando così campo libero ai big hitters dell'App Store che hanno le risorse necessarie per poter dedicare una o più risorse alla risoluzione di queste "barriere architettoniche".
Sia come sia, per ottenere la comparsa della build all'interno del portale iTunes Connect è stato necessario correggere anche il primo di questi due errori, quello relativo alla descrizione privacy mancante. Anche in questo caso, anziché darvi la soluzione al problema, preferisco far riferimento al seguente intervento risolutivo presente sul sito StackOverflow. Particolarmente degni di nota alcuni commenti, con i quali mi sento pienamente solidale, che sottolineano l'assurdità di dover pubblicare una nuova build per aggiungere una informazione del genere che poteva essere tranquillamente gestita aggiungendo una voce alla scheda dell'app già presente su iTunes Connect: ma la Apple, ormai lo abbiamo capito, preferisce sempre optare per la scelta più scomoda e difficile per lo sviluppatore.
Gli errori "inesistenti"
Cosa dire del secondo errore, quello relativo alla mancanza dell'entitlement necessario per la gestione delle notifiche push? Di male in peggio: si trattava addirittura di un "falso positivo", in quanto la app conteneva regolarmente tutti gli entitlement e le signature necessarie. Del resto c'è poco di cui stupirsi, il minimo che ci si può aspettare da un sistema così complesso e irrazionale è la produzione di messaggi di errore errati: né può destare alcuna sorpresa il fatto che la Apple non si affretti a correggere questo tipo di problemi, visto che si tratta "solo" di altro tempo perso per lo sviluppatore.
Gli errori "post-pubblicazione"
Potevamo forse credere che dopo una ordalia del genere tutto si sarebbe risolto nel migliore dei modi? Ovviamente no! Neppure l'avvenuta pubblicazione sull'App Store ha messo la nuova versione dell'app al riparo da un altro, ennesimo bug di regressione: l'impossibilità di connettersi tramite HTTP a qualsiasi server web, gentilmente offerto dalla nuova funzionalità Apple Transport Security (ATS per gli amici), abilitata di default su tutte le applicazioni compilate con XCode 7 (o superiore) su piattaforme iOS 9.0 e OSX 10.11 (o superiore).
Per maggiori dettagli su questo ultimo problema - e sua risoluzione - rimandiamo a un apposito articolo che abbiamo scritto qualche tempo fa, in questa sede ci limiteremo a sottolineare come l'introduzione di questa funzionalità abbia avuto ancora una volta un impatto negativo per lo sviluppatore, il cui destino è evidentemente quello di essere perseguitato dal sadismo incompassionevole dei tecnici Apple.
Conclusioni
Non dubito che questo post provocherà lo sdegno e l'indignazione di qualche estimatore della Apple. Alcuni di loro cercheranno persino di produrre qualche argomentazione a difesa dell'irrazionalità del sistema sopra descritto: "questo è quello che succede quando si sviluppa in modo occasionale"; "basta tenersi informati e queste problematiche possono essere risolte"; e così via, in una spirale di giustificazioni volte a tenere alto lo stendardo sventolante della mela.
La cosa non deve stupire, il fenomeno è noto a tal punto da avere persino un nome scientifico: si chiama Sindrome di Stoccolma ed è particolarmente diffuso tra gli appassionati dei brand di tendenza, i quali si sperticano nella difesa del prestigio dell'azienda prediletta a dispetto dell'infima considerazione mostrata da quest'ultima nei loro riguardi: nel caso di Apple siamo alla difesa dell'indifendibile, almeno per quanto riguarda il comparto software, sviluppo e web. L'unica cosa che si può rispondere a queste persone è che imperfezioni macroscopiche come quelle sopra descritte non possono in alcun modo imputarsi alla mancanza della lettura di informative, TOS e release notes, men che meno a un approccio "occasionale" allo sviluppo: si tratta semplicemente di bad design e inefficienza funzionale, senza se e senza ma.
