Comment Bet365 a contouré les changements de politique de l’App Store iOS d’Apple

En 2016, avec une date de fin de vie pour Adobe Flash imminente, Bet365 devait convertir son ancien site basé sur Flash en HTML 5. Cela a conduit l’entreprise à consolider ses plates-formes et à se concentrer sur la fourniture d’applications iOS et Android basées sur le nouveau site Web.

C’était il y a plus de cinq ans et depuis lors, l’entreprise a dû apporter d’autres changements radicaux en dehors de son propre contrôle. À la fin de 2019, Bet365 a reçu une instruction d’Apple qui stipulait qu’il développait des fonctionnalités, du contenu et des améliorations de l’interface utilisateur qui élèveraient son expérience d’application iOS au-delà de celle trouvée sur le site Web de l’entreprise.

Expliquant comment les plans de développement du site de paris étaient dirigés par la stratégie d’Apple, Alan Reed, responsable du développement sportif chez Hillside Technology, le La branche technologique de Bet365, déclare: « Apple voulait différencier les applications iOS. Elle voulait un produit homogène. Cela nécessite un changement radical de mentalité. Il n’y a pas eu de négociation.

Dans le passé, dit Reed, les applications Bet365 ont normalement cloné le site Web, ce qui signifiait que l’entreprise devait faire le strict minimum pour créer des applications pour le Google Play Store et l’App Store d’Apple. Mais parce qu’Apple cherchait maintenant à créer une expérience client iOS cohérente avec une apparence et une navigation plus appleées, Bet365 devait retravailler complètement son approche du développement d’applications iOS.

« La nécessité est la mère de l’invention et nous avons réuni une équipe de conception », explique Reed.

Auparavant, la logique de l’application cliente aurait été développée dans TypeScript, mais la modification de la stratégie Apple signifiait que l’application iOS devait utiliser du code natif pour la navigation dans l’application. Par exemple, alors que le site Web utilise la souris pour faire défiler, le défilement dans l’application iOS implique de faire glisser l’écran de l’appareil vers la gauche ou la droite.

L’équipe de développement logiciel devait créer une application iOS Bet365 native de preuve de concept, mais à l’époque, la société n’avait pas de développeurs qualifiés dans le modèle de programmation Swift utilisé par Apple. Bien que le framework SwiftUI introduit par Apple en 2019 simplifie le développement Swift et fournisse un framework pour créer des interfaces utilisateur pour les appareils Apple, comme l’explique Reed, Bet365 nécessitait également des fonctionnalités non disponibles dans le framework pour prendre en charge la haute disponibilité et la faible latence dont il avait besoin.

« SwiftUI vous permet d’écrire des applications plus rapidement et plus rapidement pour l’App Store », dit-il. « Mais nous avons un site Web primé en dehors de l’App Store et nous devions avoir une gamme de fonctionnalités non verrouillées sur l’appareil. »

Bien que SwiftUI soit riche en fonctionnalités et offre de nombreuses fonctionnalités de développement, « celles-ci ne sont pas toujours alignées sur les problèmes que nous voulions résoudre », déclare Reed.

« Le problème pour nous était de porter l’expérience utilisateur très riche que nous offions déjà vers une autre interface utilisateur riche. » Le framework basé sur SwiftUI avait également besoin d’accéder au riche ensemble de données de Bet365, a-t-il déclaré.

Les défis de conception que l’équipe devait résoudre impliquaient de traiter la navigation à l’intérieur de l’application comme native et d’utiliser le site Web comme un magasin de données. Reed dit que l’équipe devait penser à présenter un « jeu de cartes » qui semble différent sur un site Web par rapport à l’application iOS.

En exécutant des preuves de concept, l’équipe a pu trouver des compromis qui offriraient une bonne expérience utilisateur, dit-il.

Portabilité des applications

L’objectif idéal pour toute organisation est la possibilité de créer des applications mobiles afin que le code ne soit développé qu’une seule fois et puisse ensuite être déployé sur plusieurs canaux. Mais les règles stipulées par Apple pour l’App Store signifient que les développeurs d’applications doivent créer une apparence spécifique à Apple pour leurs applications.

Discutant de la façon d’équilibrer le développement d’applications portables avec les exigences d’Apple, Reed dit que l’adoption d’une approche Apple-first pour le développement d’applications, puis la conversion vers d’autres plates-formes est complexe car Swift est propriétaire. Au lieu de cela, dit-il, « nous avons construit nos propres moyens de transférer du code ».

Ceci est basé sur l’utilisation de l’infrastructure de développement d’applications Android Kotlin. « Nous avons pris une partie de l’ancien code Flash et l’avons analysé à Kotlin », explique Reed.

Bien que les applications Kotlin n’aient pas fonctionné pour la première fois, l’analyse a accéléré le temps de développement. « Oui, nous avons dû affiner le code, dit-il, mais l’analyse nous a donné un pas dans la bonne direction. »

Reed estime que développer d’abord des applications sur Apple n’est pas durable. Mais Kotlin offre un moyen de réduire l’effort de développement, où la logique métier back-end est séparée de l’application et une étape intermédiaire est prise dans le développement du code côté client pour simplifier et accélérer le développement d’applications multiplateformes.

« Nous avons trouvé un demi-chemin où nous utilisons Golang pour le code côté serveur, qui exécute Linux et Windows », dit-il. Cependant, le cOS iOSlient app doit encore être codé dans Swift.

Dans l’expérience de Reed, il est plus facile de se rendre de Kotlin à Swift que l’inverse. « Il y a beaucoup de facteurs de différenciation entre les plateformes », dit-il.

Le problème rencontré par les développeurs d’applications est de savoir comment faire en sorte que leur application parle de manière optimale aux différents smartphones d’une manière qui ne limite pas les performances de l’application et peut tirer parti de l’expérience utilisateur native dans la plate-forme.

Au-delà des spécificités de la plate-forme

Comme le note Reed, le smartphone est devenu partie intégrante de la vie moderne. « Votre propriété est au téléphone; c’est votre pièce d’identité », dit-il. « Alors que nous passons à un passeport Covid, cela devient une nécessité. »

Mais tout le monde ne peut pas se permettre le smartphone le plus récent et le plus récent, de sorte que les développeurs d’applications doivent reconnaître que leurs applications devront fonctionner sur plusieurs anciennes générations de smartphones. Reed croit qu’un moment viendra où plus de législation sera nécessaire pour s’assurer que tous ceux qui possèdent un smartphone ont accès à un ensemble d’applications de base qui restent compatibles entre les différentes générations d’appareils.