In 2016, with an end-of-life support date for Adobe Flash looming, Bet365 needed to convert its previous Flash-based site to HTML 5. This drove the company to consolidate its platforms and focus on delivering iOS and Android apps based on the new website.
That was over five years ago and since then, the company has needed to make other radical changes outside of its own control. In late 2019, Bet365 received an instruction from Apple which stipulated that it develop features, content and UI enhancements that would elevate its iOS App experience above and beyond that found on the company’s website.
Explaining how the betting website’s development plans were being directed by Apple’s strategy, Alan Reed, head of sports development at Hillside Technology, the Bet365’s technology arm, says: “Apple wanted to differentiate iOS apps. It wanted a homogeneous product. This requires a step-change in thinking. There wasn’t a negotiation.”
In the past, says Reed, the Bet365 apps normally cloned the website, which meant the firm needed to do the bare minimum to create apps for the Google Play Store and Apple App Store. But because Apple was now looking to create a coherent iOS customer experience with a look and feel and navigation that was more Apple-like, Bet365 needed to completely rework its approach to iOS app development.
“Necessity is the mother of invention and we got a design team together,” says Reed.
Previously, the logic in the client app would have been developed in TypeScript, but the Apple policy change meant the iOS app needed to use native code for app navigation. For instance, while the website uses the mouse to scroll, scrolling in the iOS app involves swiping the device screen left or right.
The software development team needed to build a proof-of-concept native iOS Bet365 app, but at the time, the company did not have developers skilled in the Swift programming model used by Apple. Although the SwiftUI framework that Apple introduced in 2019 simplifies Swift development and provides a framework to build user interfaces for Apple devices, as Reed explains, Bet365 also required features not available in the framework to support the high availability and low latency that it needed.
“SwiftUI lets you write apps quicker and faster for the App Store,” he says. “But we have an award-winning website outside of the App Store and we needed to have a range of features not locked to the device.”
Although SwiftUI is feature-rich and offers a lot of developer functionality, “these are not always aligned to the problems we wanted to solve”, says Reed.
“The problem for us was about porting the very rich user experience we already offered to another rich user interface.” The SwiftUI-based framework also needed access to Bet365’s rich dataset, he said.
The design challenges the team needed to solve involved treating navigation inside the app as native and using the website as a data store. Reed says the team needed to think about presenting a “deck of cards” that looks different on a website compared with the iOS app.
By running proofs of concept, the team was able to work through compromises that would deliver a good user experience, he says.
App portability
The ideal goal for any organisation is the ability to build mobile apps so that the code is developed only once and can then be deployed across multiple channels. But the rules stipulated by Apple for the App Store means app developers need to create an Apple-specific look and feel for their apps.
Discussing how to balance portable app development with Apple’s requirements, Reed says that taking an Apple-first approach to app development and then converting to other platforms is complex because Swift is proprietary. Instead, he says, “we built our own ways to transfer code”.
This is based around using the Android app development framework Kotlin. “We took some of the old Flash code and parsed it to Kotlin,” says Reed.
Although the Kotlin apps did not work first time, parsing speeded up the development time. “Yes, we did have to refine the code,” he says, “but parsing gave us a step in the right direction.”
Reed believes developing apps first on Apple is not sustainable. But Kotlin offers a way to reduce the development effort, where back-end business logic is separated from the app and an interim step is taken in the development of the client-side code to simplify and speed up cross-platform app development.
“We have found a half way where we use Golang for server-side code, which runs Linux and Windows,” he says. However, the iOS client app still needs to be coded in Swift.
In Reed’s experience, it is easier to get from Kotlin to Swift than the other way round. “There are a lot of differentiators across platforms,” he says.
The issue that app developers face is how to make their app talk to different smartphones optimally in a way that does not limit app performance and can take advantage of the native user experience in the platform.
Beyond platform specifics
As Reed notes, the smartphone has become integral to modern life. “Your ownership is to the phone; it is your ID,” he says. “As we move to a Covid passport, it becomes a necessity.”
But not everyone can afford the latest, most up-to-date smartphone, so app developers need to recognise that their apps will need to run on several older generations of smartphone. Reed believes a time will come when more legislation will be needed to ensure everyone who owns a smartphone has access to a core set of apps which remain compatible across the different generations of device.
