Apple e la norma 4.2.6 delle linee guida di App Store

Tutto ebbe inizio l'8 giugno 2017, quando Apple ha inserito la norma 4.2.6 nelle sue linee guida relative alla pubblicazione su App Store.

“4.2.6 – Apps created from a commercialized template or app generation service will be rejected.” Ovvero, le applicazioni create utilizzando dei template commerciali o un servizio di generazione di app saranno rifiutate.

Tale norma è stata inserita alla fine della sezione “4.2 Design > Minimum Functionality”. Noi abbiamo subito interpretato questa aggiunta come un modo per moderare le app "povere", equivalenti ad esempio al sito web di un'azienda, con poche informazioni e un utilizzo minimo da parte degli utenti. Il 21 giugno TechCrunch pubblicò un articolo che dava un'interpretazione della questione molto simile alla nostra. TechCrunch scriveva appunto che l'obiettivo di questa regola era quello di colpire le app clone all'interno di App Store, lo spam e tutte le applicazioni ingannevoli.

GoodBarber e i suoi clienti hanno continuato a lavorare come hanno sempre fatto.

Distribuzione pubblica delle app native

Ogni store ha un proprio sistema di revisione che ha come primo obiettivo quello di proteggere gli utenti da app malware, con contenuti per adulti o che incitano all'odio.

Per Android, per distribuire pubblicamente un'app, esistono alternative a Google Play (installazione diretta, store alternativo).

Per quanto riguarda iOS l'App Store è l'unico modo per distribuire un'app pubblicamente.
 

Il 21 luglio 2017, Apple ha rifiutato l'ultimo aggiornamento dell'applicazione My GoodBarber e ci ha contattato telefonicamente per dirci che, in accordo con la nuova norma, tutte le app create con GoodBarber sarebbero state rigettate. E questo è quello che è appunto accaduto da qui in avanti.

Siamo rimasti molto sorpresi da quanto ci è stato comunicato durante la telefonata. Una persona del Review Team ci ha spiegato che:
- Apple non avrebbe più permesso che un utente potesse utilizzare uno strumento online per recuperare un file binario (il file .ipa che ha al suo interno l'applicazione) e inviarlo al team di revisione;
- La produzione massiva di app era un problema;
- Le applicazioni create tramite app builder erano considerate spam, in quanto utilizzavano dei template simili.

Tuttavia, il Review Team ha concluso dicendo che Apple sarebbe stata felice se GoodBarber avesse continuato ad inviare app, ma solo se queste fossero state personalizzate al punto tale da renderle veramente uniche.

Per soddisfare i requisiti di Apple, GoodBarber ha introdotto i seguenti cambi:

- Non dare più accesso al cliente al file .ipa per la distribuzione su App Store (versione per iOS di GoodBarber);
- L'offerta illimitata (di app iOS) per reseller è stata tolta dal portale.

Allo stesso tempo abbiamo dovuto adottare delle rapide misure di precauzione. Questo per non mettere i nostri clienti in una situazione di difficoltà inutilmente:

- Abbiamo bloccato le migrazioni da V3 a V4, in quanto implicavano un invio dell'app ad App Store per un aggiornamento. In quel periodo non c'era alcuna garanzia che gli aggiornamenti di applicazioni venissero accettati da Apple.
- Abbiamo bloccato le compilazioni di app iOS. Gli utenti non potevano più recuperare il file .ipa per inviare una nuova app o per aggiornarne una esistente.
- Abbiamo creato una pagina dedicata alla questione iOS all'interno del back office, per informare i nostri clienti dell'accaduto. Questa pagina è stata aggiornata diverse volte.

A questo punto per provare ad avere maggiori informazioni relativamente a questa decisione, abbiamo contattato il Developer Relations Manager di Apple. Lui conosce GoodBarber molto bene. Negli ultimi 5 anni abbiamo raccolto suoi feedback, relativamente all'evoluzione del nostro prodotto, almeno una volta all'anno. Ha sempre pensato che avessimo tutte le carte in regola per trovare una soluzione al problema, considerandoci da sempre un partner molto affidabile. Ad ogni modo ci ha confermato che tali decisioni venivano prese esclusivamente dal Review Team di Apple.

Il 25 luglio abbiamo inviato la nostra prima documentazione per spiegare ad Apple come GoodBarber avrebbe funzionato d'ora in avanti, tenendo bene in mente tutti i requisiti richiesti dal Review Team. Da quel momento si è però rivelato difficile riuscire ad avere una loro opinione relativamente ai cambi che volevamo operare. Nonostante l'insistenza delle nostre richieste, è dovuto passare un bel po' di tempo prima di ottenere un certo impegno da parte loro.

Abbiamo effettuato dei controlli qualità su 15.00 app iOS create con GoodBarber. Il nostro obiettivo era quello di individuare dei possibili spammer. Non siamo riusciti a scovare niente del genere, al massimo qualche reseller ha potuto creare delle applicazioni simili tra loro.

Una parte dei nostri clienti è costituita da 800 reseller attivi. La maggior parte di questi sono agenzie specializzate nella creazione di app e siti web. 10 di loro hanno creato più di 100 applicazioni mobile con la nostra piattaforma. Tra queste agenzie solo due di loro hanno una percentuale di accettazione su App Store che va dall'80% al 90%, tutte le altre si attestando stabilmente sopra il 90%.

Abbiamo constatato poi che Apple spesso ha utilizzato la norma 4.3 - Spam per rigettare le app dei reseller che usavano spesso per le pubblicazioni il loro account da sviluppatore e non quello del cliente.
 

Durante il mese di agosto abbiamo provato a contattare Apple con cadenza regolare, ma la situazione non è avanzata di un millimetro. Nelle brevi contatti che siamo riusciti ad ottenere, notavamo che le nostre proposte non erano state ancora analizzate.
Il Review Team si è limitato a dirci nuovamente ciò che non andava bene:
- le piattaforme online che davano la possibilità agli utenti di recuperare un file .ipa
- la produzione massiva di applicazioni
- app fotocopia
- l'utilizzo di template

Apple ci ha così provato a dare delle possibili opzioni:
a / creare applicazioni personalizzate;
b / raggruppare app simili in una specie di app contenitore;
c / creare web app e distribuirle fuori dagli store.

a/ Ricalibrare il processo di invio, per una migliore qualità. App uniche.

In questa fase non sapevamo ancora se le applicazioni dei nostri clienti avrebbero potuto essere accettate o meno. Abbiamo dunque mantenuto la chiusura delle compilazioni per iOS, proponendo però ad alcuni clienti la possibilità di un intervento del nostro team sui loro progetti. Il nostro obiettivo era quello di provare il processo , pensato a luglio, per assicurare ad Apple la qualità delle applicazioni. I nostri tecnici hanno così lavorato sul design e sulle funzionalità di queste app, in modo da renderle uniche. Dopo di che abbiamo provveduto ad inviarle ad Apple.

Solo il 47% degli invii (e re-invii) effettuati durante il mese di agosto sono stati accettati. Abbiamo però avuto modo di raccogliere informazioni per provare a rispondere ad alcuni quesiti:
- Unicità delle app? La V4 di GoodBarber possiede un sistema modulare che permette 64 (!) combinazioni (fattoriale di 64: svariati miliardi) per la personalizzazione di un'app. Questo sistema permette di evitare che due applicazioni siano identiche.
- Uso dei template? I template sono creati per rispettare dei concetti ergonomici. Un'app di news dovrebbe mostrare i suoi articoli sotto forma di lista? Un'app e-commerce non dovrebbe avere la possibilità di mettere il carrello nella parte superiore della pagina?

b/ App contenitore

A Luglio Apple non ci ha menzionato la possibilità di optare per delle app contenitore. Siamo stati noi a parlarne con i nostri reseller. Coloro che si dedicavano alla creazione di app per mercati specifici ci avevano detto che questa soluzione poteva avere un suo perché. Alcuni reseller ci avevano inoltre comunicato che avevano avuto l'autorizzazione da Apple a continuare ad aggiornare le loro app che erano già state accettate su App Store, per tutto il tempo che sarebbe servito loro ad effettuare una transizione per questo tipo di soluzione.

c/ Web app

Ogni volta che un'app veniva rifiutata a causa della regola 4.2.6, Apple incoraggiava fondamentalmente alcuni progetti a virare verso una versione web della propria app. Ebbene, prima dell''avvento di questa norma, GoodBarber aveva già deciso di puntare sulle Progressive Web App, le quali hanno rappresentato  fin da subito un''interessantissima opportunità. È per questo motivo che abbiamo lavorato intensamente in questa direzione negli ultimi due anni. Nell''Aprile 2017 GoodBarber è diventato infatti il primo app builder al mondo a proporre le PWA nella sua offerta commerciale. Le PWA sono delle alternative reali alle app native, in quanto le tecnologie web negli ultimi tempo stanno avanzando molto rapidamente. Su Android, l''utilizzo del service worker con Chrome ti permette di consultare la web app offline, di ricevere notifiche push e di installare l''app facilmente sulla propria home screen. Tuttavia, su iOS, anche se le PWA vengono visualizzate perfettamente su Safari, i service worker non vengono supportati. Questo significa che al momento la consultazione offline e le notifiche push non sono possibili. Va però in questa direzione l''annuncio di Apple, fatto ai primi di agosto, in cui ha comunicato che stanno iniziando a lavorare sull''implementazione del service worker anche su Safari.

Anche se bisogna dire che i nostri interlocutori Apple non hanno ancora saputo darci informazioni riguardanti le notifiche push per web app, tanto meno se questa funzionalità coinciderebbe con il supporto dei service worker. L''unica certezza è che bisognerà disporre di un account sviluppatore Apple per avere notifiche push sulla web app, così come già succede con Safari su OSX.

Gli altri app builder e la comunicazione della crisi

Apple ha affermato fin dal primo momento che non ci sarebbe stata alcuna eccezione relativamente all''applicazione della norma 4.2.6.

Abbiamo letto un po' ovunque che i nostri diretti competitor non erano stati colpiti da questa norma. Abbiamo così realizzato dei test, scoprendo che non era appunto vero quanto si diceva. C'è da dire però che per Apple era più difficile identificare quegli app builder che utilizzano tecnologie non native (ad esempio Cordova). Abbiamo poi avuto modo di metterci in contatto con alcuni CEO di altri app builder e anche quelli più specializzati, con una produzione di 300 app all'anno, erano stati colpiti.

Dal canto nostro, abbiamo cercato in questo periodo di essere totalmente trasparenti. Non c'è stato alcun momento in cui abbiamo finto di non avere alcun problema. Nonostante questo in molti ci hanno accusato di non comunicare quanto stava accadendo in modo adeguato. Avremmo potuto condividere quotidianamente le nostre varie ipotesi e analisi della situazione, ma abbiamo preferito focalizzarci sul problema. Abbiamo per cui deciso di aggiornare il nostro comunicato solo in presenza di informazioni valide e affidabili.
 

A inizio mese avevamo già una visione più precisa dell'impatto della norma 4.2.6 sulla nostra azienda. Nel mese di agosto abbiamo potuto osservare il 30% in meno di nuove sottoscrizioni. La conseguenza del blocco dell'area iOS della piattaforma.

Abbiamo così continuato il lavoro di ridefinizione della Road Map, nonché della nostra offerta commerciale, iniziato ad agosto.

Il 7 settembre, durante uno degli ultimi scambi con il Review Team di Apple, la situazione si è sbloccata in positivo. Siamo infatti riusciti a trovare una soluzione adeguata per i nostri vecchi clienti: Apple ci autorizzava infatti l'invio di aggiornamenti di applicazioni già presenti su App Store. Questo ha significato che i clienti che avevano un'app iOS pubblicata sullo store, potevano tornare ad aggiornarla senza avere alcun problema relazionato con la 4.2.6. Fu così che il giorno seguente riuscimmo ad aggiornare diverse app, tra queste anche alcune che erano in attesa di essere validate da alcune settimane.

Abbiamo dunque aperto un po' alla volta i back office per permettere la compilazione e l'invio di aggiornamento di app iOS già esistenti. Anche la migrazione da V3 a V4 è stata gradualmente rimessa in moto.

Fatto questo, abbiamo terminato quindi la nuova versione del portale di GoodBarber, che è stato messo on line lo scorso 25 settembre. A partire da questa data anche la nostra offerta commerciale ha subito delle variazioni. Cambiamenti dovuti all'impatto che la norma 4.2.6 ha avuto sul nostro modello di business. Questi sono i 3 punti principali:

1/ I clienti esistenti che già avevano un'app pubblicata su App Store, possono continuare a mantenerla e aggiornarla. Apple ci ha garantito che queste app non verranno colpite dalla nuova norma. Il loro abbonamento di conseguenza non cambia.

2/ Per distribuire una nuova app su App Store (reseller compresi), GoodBarber effettuerà una revisione in modo da massimizzare le possibilità che questa venga accettata da Apple. Verrà applicato un costo di revisione se questa dovesse avere esito positivo.

3/ L'offerta di app illimitate per reseller non prevede alcun costo extra per ciò che riguarda Android e PWA. Per iOS invece questo sarà possibile solo per le app distribuite fuori da App Store, utilizzando un account sviluppatore enterprise (Apple Developer Enterprise Program).
 

Oggigiorno le applicazioni rappresentano il 90% del tempo passato su smartphone, anche se il web sembra aumentare la propria popolarità avendo un traffico 3 volte maggiore rispetto al passato.

C'è ormai una convergenza in atto tra applicazioni  mobile e siti web, tutto questo grazie alle Progressive Web App (PWA). Le PWA forniscono un'esperienza simile alle app native in numerosi casi, offrendo allo stesso tempo quella visibilità e facilità di utilizzo tipica del web. Sistemi operativi come Android e Windows trattano alla stessa maniera app native e PWA, facendo in modo che queste ultime possano beneficiare di tutta una serie di funzionalità che fin a poco tempo fa erano prerogativa delle prime (le notifiche push ad esempio).

Troviamo inoltre molto interessanti le Instant App di Android, che offrono la possibilità di utilizzare un'app prima di installarla.

Sono dunque numerose le vie tecnologiche aperte per il futuro delle app, resta però difficile prevedere quale di queste vincerà. Una cosa certa è che la democratizzazione delle applicazioni rappresenta un qualcosa di rivoluzionario. E app builder come GoodBarber hanno contribuito in modo importante, dividendo per 10 i costi di possesso di un'app.

A differenza di un sito web, la distribuzione di un'app nativa al pubblico non è libera e immediata, ma deve passare comunque dallo store. Se acquistando un nome dominio, ci fosse stato un controllo sistematico di ogni sito web associato, il Web sarebbe oggi migliore di quello che è? Non lo crediamo affatto. 
Gli store devono ovviamente proteggere gli utenti da malware e contenuti abusivi, ma hanno allo stesso tempo l'obbligo di garantire le importanti conquiste fatte dal Web e soprattutto la loro neutralità.