In late 2019, we received an instruction from Apple. It stipulated we develop features, content, and UI enhancements that would elevate our iOS app experience above and beyond that found on the Safari website.
What resulted was the radical redesign of our flagship sportsbook app, which would see us rewrite the rulebook of our mobile experience. However, the sophisticated new concept our design team had dreamt up would push the sports development team skills to the limit.
The challenge, on the one hand Apple’s new UI framework, Swift UI, was in its infancy and didn’t provide the flexibility or control we needed. On the other, there wasn’t time to create a new framework from scratch. Then something amazing happened.
It was during our search for solutions that the team saw something familiar in the design and raised the potential of utilising code that lay dormant in an old repository. This is the story of how the now defunct Flash became the foundation of our latest iOS app.
A Bit of Background
They say that life is circular and that is certainly true of software development. In the beginning we had 4 sites, a desktop site, a low-end and high-end mobile site, and a tablet site.
Requirements for mobile were driven by multiple factors. Screen size, mobile internet speeds and phone functionality. However, as mobile phone design and performance have unified, designing and developing our mobile experiences have been mostly about the size of the screen. Because of this, we came close to achieving one responsive site that would rule every platform.
But here we are diversifying again. We had been looking at ways in which we could refresh our mobile and desktop experiences when Apple’s ‘request’ came in and made it an imperative.
Navigating Innovation
Mobile is a critical channel, and we have a fairly even split between Android and Apple. Around 40% of our users access our services via the Apple ecosystem. That’s millions of users in total, and of those, 45% use our iOS mobile app.
We looked at the sportsbook and asked, if it could be freed from being a website, how could we think about it differently? What could we take advantage of? It occurred that when you’re looking to differentiate between channels the biggest impact you can make is with the navigation. Get it right and you change the fundamentals of look, feel and how you interact with the app.
When you consider our sportsbook, it’s fundamentally a database of fixtures and competitions the customer navigates up and down. Apps on the other hand have tabs so you can maintain state and simultaneously explore multiple places on the sportsbook.
We saw an opportunity to introduce a swipe mechanic, which would enable people to navigate different parts of our sportsbook at the same time. Crucial to the design was embracing interactions users of iOS are used to. We leveraged the capabilities and existing paradigms of iOS so users could enjoy a smooth and intuitive card and tab system. Something that’s equal parts iOS and bet365.
A good user interface does two things. It makes it easy for the consumer to find what they are looking for and to navigate to it quickly and efficiently. Our new design focused on removing any unnecessary friction from the experience.
With the deck of cards, users can swipe up and down to navigate the part of the site they are on and left to right to jump to different pages. The thumb never leaves the screen, and every element of the experience remains live until you decide to close it.
Design & Development
At bet365, design and development have a close working relationship that enjoys a healthy dose of competition. Dev says, we can build anything you can design, and design creates concepts they know will test dev. We are always trying to spur each other on.
In the past, we’ve tended towards a light touch framework for our apps to ensure we can keep up with the rapid rate of updates we have to implement and maintain parity in the user experience.
Traditionally, it’s involved delivering our existing site inside a lightweight wrapper. When we update the website, the app is updated as well. It’s the most practical and efficient way of doing things. This meant that before this latest project, around 5% of the code for the app was native and the new app would have to be developed from the ground up.
We built a demo very quickly that showed the design in action. That was the easy bit. The challenge was to transform an award-winning website that works at the speed of light into an app with a brand-new navigation.
Prioritising Flexibility and Control
We knew what we were trying to do was ambitious in terms of memory and performance. So, we had to make sure we could get it onto a phone quickly to test it.
We had a couple of options at our disposal, Swift and Swift UI. Swift UI was more modern but not backwards compatible to every version of iOS. We didn’t want to lose any of our coverage, so despite offering a framework that allows you do things quickly, Swift UI wasn’t right for us.
Instead, we went with Swift because of the control it gave us. However, we put the design in and quickly realised it was going to be extremely difficult, if not impossible, to get it working as we’d like.
Despite having many millions of users, our app is a niche product that demands high availability and low latency. We must do those things in real time to 100,000s of customers. We can’t just promise speed and availability. We must deliver it.
Consequently, we have to make sure we have systems that are highly maintainable, highly performant and can adapt to outside influences such as design, operational systems changes or device changes. Vendors typically design their software for a mass use case to ensure as many people as possible can use it and benefit from it.
But because we are niche product and have niche considerations, we find that vendor designed frameworks don’t give us the flexibility and control needed. This meant we were back at square one but didn’t have time to create our own framework from scratch.
Cache in the Attic
We were whiteboarding solutions when one of the team noticed there were commonalities between what we wanted to achieve now and a Flash site we had retired 3 years earlier.
Because they both attempt to solve the same problems, Apple’s UIKit holds some very strong parallels with Adobe Flash. As an organisation we are incumbent to our rate of change. We can do 100s of releases in a week. Therefore, our biggest issues have always been about speed of delivery and maintenance without compromise upon our quality standards.
As a result, we need software that is modular and allows our front end code to be released many times by a team of developers who work on different elements of the codebase. We must compartmentalise our code so that it can be released little and often. It’s why we’ve adopted a culture of iterative or delta releases.
The risk associated with trying to move code from one environment to another is often compounded by the speed at which you are trying to do things and the number of times you want to release it. Our Delta release programme ensures we can work on many different aspects of the application at the same time and give it to many different people to work on, without the need for them to collaborate on every change.
Even though you release an app in its entirety to Apple, for our Quality Assurance, we felt that we could mitigate our risk far more efficiently and effectively if we only had to test the changes rather than the entire app. It would mean that if there is an issue we could identify it far more quickly, while minimising the cost of development.
When you have to consistently release changes and updates in a fast moving environment like Sports betting, the accuracy and testability of them is far more important when working at scale. It was this exact process that Flash was so good at enabling us to do in the past and the advantage it would give us today.
We dug the old flash site out and very quickly realised that there was a huge repository of libraries that we could repurpose into Swift. While we had some new features and designs that we couldn’t simply port over, it gave us the frameworks and fundamentals that we’d need to create the shell of an App.
We had to make some tweaks, but it was a huge shortcut that allowed us to quickly get a working demo on phones. We wouldn’t have achieved it in time if they hadn’t found the libraries. The two teams then worked closely to put together PoCs they could trial on the phones. Essentially, they designed and developed as they went. In the end, the entire process took around 9-months.
This is not the first time that old tech has helped us to drive innovation at bet365. In the same way that Erlang enabled us to overcome the same challenges of scale it had for the Telecoms sector, we found the answer by focusing on the problem we needed to solve.
Perhaps the true insight here, is that code never truly becomes defunct. It just goes out of fashion for a time and should be kept in your armoury until it becomes useful again.
What’s Next
Now that we’ve got something proprietary on one OS, we are now looking at how we can create differentiation across the wider estate. The card-based navigation is now being developed for Android using a new codebase being written in the same spirit as the Swift. This time it’s not out of necessity. It’s an opportunity and one that we relish.
Authors
Alan Reed, Head of Sports Development and Matt Mitchell, Head of Design and UX