In che modo Bet365 ha aggirato le modifiche alla politica dell’App Store iOS di Apple

Nel 2016, con l’imminente data di fine del supporto per Adobe Flash, Bet365 aveva bisogno di convertire il suo precedente sito basato su Flash in HTML 5. Ciò ha spinto l’azienda a consolidare le sue piattaforme e a concentrarsi sulla fornitura di app iOS e Android basate sul nuovo sito web.

Sono passati più di cinque anni e da allora l’azienda ha dovuto apportare altri cambiamenti radicali al di fuori del proprio controllo. Alla fine del 2019, Bet365 ha ricevuto un’istruzione da Apple che stabiliva che avrebbe sviluppato funzionalità, contenuti e miglioramenti dell’interfaccia utente che avrebbero elevato la sua esperienza con l’app iOS al di là di quella trovata sul sito Web dell’azienda.

Spiegando come i piani di sviluppo del sito web di scommesse fossero diretti dalla strategia di Apple, Alan Reed, capo dello sviluppo sportivo presso Tecnologia Hillside, il Il braccio tecnologico di Bet365, afferma: “Apple voleva differenziare le app iOS. Voleva un prodotto omogeneo. Ciò richiede un cambio di passo nel pensiero. Non c’è stata trattativa».

In passato, afferma Reed, le app di Bet365 normalmente clonavano il sito Web, il che significava che l’azienda doveva fare il minimo indispensabile per creare app per Google Play Store e Apple App Store. Ma poiché Apple stava ora cercando di creare un’esperienza cliente iOS coerente con un aspetto e una navigazione più simili ad Apple, Bet365 aveva bisogno di rielaborare completamente il suo approccio allo sviluppo di app iOS.

“La necessità è la madre dell’invenzione e abbiamo riunito un team di progettazione”, afferma Reed.

In precedenza, la logica nell’app client sarebbe stata sviluppata in TypeScript, ma la modifica dei criteri Apple significava che l’app iOS doveva usare il codice nativo per l’esplorazione dell’app. Ad esempio, mentre il sito Web utilizza il mouse per scorrere, lo scorrimento nell’app iOS comporta lo scorrimento dello schermo del dispositivo verso sinistra o verso destra.

Il team di sviluppo del software aveva bisogno di creare un’app iOS Bet365 nativa proof-of-concept, ma all’epoca l’azienda non aveva sviluppatori esperti nel modello di programmazione Swift utilizzato da Apple. Sebbene il framework SwiftUI introdotto da Apple nel 2019 semplifichi lo sviluppo di Swift e fornisca un framework per creare interfacce utente per i dispositivi Apple, come spiega Reed, Bet365 richiedeva anche funzionalità non disponibili nel framework per supportare l’alta disponibilità e la bassa latenza di cui aveva bisogno.

“SwiftUI ti consente di scrivere app sempre più velocemente per l’App Store”, afferma. “Ma abbiamo un sito Web pluripremiato al di fuori dell’App Store e avevamo bisogno di una gamma di funzionalità non bloccate sul dispositivo”.

Sebbene SwiftUI sia ricco di funzionalità e offra molte funzionalità per gli sviluppatori, “queste non sono sempre allineate ai problemi che volevamo risolvere”, afferma Reed.

“Il problema per noi riguardava il porting della ricca esperienza utente che già offrivamo su un’altra ricca interfaccia utente”. Il framework basato su SwiftUI aveva anche bisogno dell’accesso al ricco set di dati di Bet365, ha affermato.

Le sfide di design che il team ha dovuto risolvere ha comportato il trattamento della navigazione all’interno dell’app come nativa e l’utilizzo del sito Web come archivio dati. Reed afferma che il team doveva pensare a presentare un “mazzo di carte” che avesse un aspetto diverso su un sito Web rispetto all’app iOS.

Eseguendo le prove di concetto, il team è stato in grado di elaborare compromessi che avrebbero offerto una buona esperienza utente, afferma.

Portabilità dell’app

L’obiettivo ideale per qualsiasi organizzazione è la capacità di creare app mobili in modo che il codice venga sviluppato una sola volta e possa quindi essere distribuito su più canali. Ma le regole stabilite da Apple per l’App Store significano che gli sviluppatori di app devono creare un aspetto specifico per Apple per le loro app.

Discutendo su come bilanciare lo sviluppo di app portatili con i requisiti di Apple, Reed afferma che adottare un approccio Apple prima di sviluppare app e poi convertirlo ad altre piattaforme è complesso perché Swift è proprietario. Invece, dice, “abbiamo costruito i nostri modi per trasferire il codice”.

Questo si basa sull’utilizzo del framework di sviluppo di app Android Kotlin. “Abbiamo preso parte del vecchio codice Flash e l’abbiamo analizzato su Kotlin”, afferma Reed.

Sebbene le app Kotlin non abbiano funzionato la prima volta, l’analisi ha accelerato i tempi di sviluppo. “Sì, abbiamo dovuto perfezionare il codice”, dice, “ma l’analisi ci ha dato un passo nella giusta direzione”.

Reed crede sviluppo di app prima su Apple non è sostenibile. Ma Kotlin offre un modo per ridurre lo sforzo di sviluppo, in cui la logica di business back-end è separata dall’app e viene fatto un passo intermedio nello sviluppo del codice lato client per semplificare e accelerare lo sviluppo di app multipiattaforma.

“Abbiamo trovato una via di mezzo dove usiamo Golang per il codice lato server, che esegue Linux e Windows”, afferma. Tuttavia, l’app client iOS deve ancora essere codificata in Swift.

Secondo l’esperienza di Reed, è più facile andare da Kotlin a Swift che il contrario. “Ci sono molti elementi di differenziazione tra le piattaforme”, afferma.

Il problema che devono affrontare gli sviluppatori di app è come far dialogare la propria app con diversi smartphone in modo ottimale in modo da non limitare le prestazioni dell’app e sfruttare l’esperienza utente nativa nella piattaforma.

Oltre le specifiche della piattaforma

Come nota Reed, lo smartphone è diventato parte integrante della vita moderna. “La tua proprietà è sul telefono; è il tuo ID”, dice. “Mentre si passa a un passaporto Covid, diventa una necessità”.

Ma non tutti possono permettersi lo smartphone più recente e aggiornato, quindi gli sviluppatori di app devono riconoscere che le loro app dovranno essere eseguite su diverse generazioni di smartphone precedenti. Reed crede che arriverà il momento in cui sarà necessaria più legislazione per garantire a tutti coloro che possiedono uno smartphone l’accesso a una serie di app di base che rimangono compatibili tra le diverse generazioni di dispositivi.