En 2016, ante la inminente fecha de finalización de la vida útil de Adobe Flash, Bet365 necesitaba convertir su sitio anterior basado en Flash a HTML 5. Esto llevó a la empresa a consolidar sus plataformas y centrarse en ofrecer aplicaciones iOS y Android basadas en nuevo sitio web.
Eso fue hace más de cinco años y, desde entonces, la empresa ha necesitado realizar otros cambios radicales fuera de su propio control. A fines de 2019, Bet365 recibió una instrucción de Apple que estipulaba que desarrollaría funciones, contenido y mejoras de la interfaz de usuario que elevarían su experiencia con la aplicación iOS más allá de la que se encuentra en el sitio web de la compañía.
Al explicar cómo los planes de desarrollo del sitio web de apuestas estaban siendo dirigidos por la estrategia de Apple, Alan Reed, jefe de desarrollo deportivo de Hillside Technology, la El brazo de tecnología de Bet365 dice: “Apple quería diferenciar las aplicaciones de iOS. Quería un producto homogéneo. Esto requiere un cambio radical en la forma de pensar. No hubo negociación “.
En el pasado, dice Reed, las aplicaciones de Bet365 normalmente clonaban el sitio web, lo que significaba que la empresa necesitaba hacer lo mínimo para crear aplicaciones para Google Play Store y Apple App Store. Pero debido a que Apple ahora buscaba crear una experiencia de cliente de iOS coherente con una apariencia y una navegación más parecidas a las de Apple, Bet365 necesitaba reelaborar completamente su enfoque para el desarrollo de aplicaciones de iOS.
“La necesidad es la madre de la invención y reunimos un equipo de diseño”, dice Reed.
Anteriormente, la lógica en la aplicación cliente se habría desarrollado en TypeScript, pero el cambio de política de Apple significaba que la aplicación iOS necesitaba usar código nativo para la navegación de la aplicación. Por ejemplo, mientras que el sitio web usa el mouse para desplazarse, desplazarse en la aplicación de iOS implica deslizar la pantalla del dispositivo hacia la izquierda o hacia la derecha.
El equipo de desarrollo de software necesitaba crear una aplicación nativa de prueba de concepto para iOS Bet365, pero en ese momento, la compañía no tenía desarrolladores capacitados en el modelo de programación Swift utilizado por Apple. Aunque el marco SwiftUI que Apple introdujo en 2019 simplifica el desarrollo de Swift y proporciona un marco para crear interfaces de usuario para dispositivos Apple, como explica Reed, Bet365 también requería características no disponibles en el marco para admitir la alta disponibilidad y baja latencia que necesitaba.
“SwiftUI te permite escribir aplicaciones cada vez más rápido para la App Store”, dice. “Pero tenemos un sitio web galardonado fuera de la App Store y necesitábamos tener una variedad de funciones que no estén bloqueadas en el dispositivo”.
Aunque SwiftUI es rico en funciones y ofrece una gran cantidad de funciones para desarrolladores, “estas no siempre están alineadas con los problemas que queríamos resolver”, dice Reed.
“El problema para nosotros era trasladar la experiencia de usuario muy rica que ya ofrecíamos a otra interfaz de usuario enriquecida”. El marco basado en SwiftUI también necesitaba acceso al rico conjunto de datos de Bet365, dijo.
Los desafíos de diseño que el equipo necesitaba resolver implicaban tratar la navegación dentro de la aplicación como nativa y usar el sitio web como un almacén de datos. Reed dice que el equipo necesitaba pensar en presentar una “baraja de cartas” que se vea diferente en un sitio web en comparación con la aplicación de iOS.
Al ejecutar pruebas de concepto, el equipo pudo trabajar a través de compromisos que brindarían una buena experiencia de usuario, dice.
Portabilidad de la aplicación
El objetivo ideal para cualquier organización es la capacidad de crear aplicaciones móviles para que el código se desarrolle solo una vez y luego se pueda implementar en múltiples canales. Pero las reglas estipuladas por Apple para la App Store significan que los desarrolladores de aplicaciones deben crear una apariencia específica de Apple para sus aplicaciones.
Al discutir cómo equilibrar el desarrollo de aplicaciones portátiles con los requisitos de Apple, Reed dice que adoptar un enfoque de Apple para el desarrollo de aplicaciones y luego convertir a otras plataformas es complejo porque Swift es propietario. En cambio, dice, “creamos nuestras propias formas de transferir código”.
Esto se basa en el uso del marco de desarrollo de aplicaciones de Android Kotlin. “Tomamos parte del código Flash antiguo y lo analizamos en Kotlin”, dice Reed.
Aunque las aplicaciones de Kotlin no funcionaron la primera vez, el análisis aceleró el tiempo de desarrollo. “Sí, tuvimos que refinar el código”, dice, “pero el análisis nos dio un paso en la dirección correcta”.
Reed cree que desarrollar aplicaciones primero en Apple no es sostenible. Pero Kotlin ofrece una forma de reducir el esfuerzo de desarrollo, donde la lógica empresarial de back-end se separa de la aplicación y se da un paso intermedio en el desarrollo del código del lado del cliente para simplificar y acelerar el desarrollo de aplicaciones multiplataforma.
“Hemos encontrado un medio camino en el que usamos Golang para el código del lado del servidor, que ejecuta Linux y Windows”, dice. Sin embargo, la aplicación cliente de iOS aún debe codificarse en Swift.
Según la experiencia de Reed, es más fácil ir de Kotlin a Swift que al revés. “Hay muchos diferenciadores entre plataformas”, dice.
El problema que enfrentan los desarrolladores de aplicaciones es cómo hacer que su aplicación se comunique con diferentes teléfonos inteligentes de manera óptima de una manera que no limite el rendimiento de la aplicación y pueda aprovechar la experiencia del usuario nativo en la plataforma.
Más allá de las especificaciones de la plataforma
Como señala Reed, el teléfono inteligente se ha convertido en parte integral de la vida moderna. “Su propiedad es el teléfono; es su identificación ”, dice. “A medida que pasamos a un pasaporte Covid, se convierte en una necesidad”.
Pero no todo el mundo puede permitirse el último y más actualizado teléfono inteligente, por lo que los desarrolladores de aplicaciones deben reconocer que sus aplicaciones deberán ejecutarse en varias generaciones anteriores de teléfonos inteligentes. Reed cree que llegará un momento en el que se necesitará más legislación para garantizar que todos los propietarios de un teléfono inteligente tengan acceso a un conjunto básico de aplicaciones que siguen siendo compatibles en las diferentes generaciones de dispositivos.