When I think about our journey into mobile development, I’m reminded of something the late great Douglas Adams wrote in The Restaurant at the End of the Universe: ‘There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.’

While we’re certainly not solving the mysteries of the universe, there are parallels with the world of mobile development. Just when you think you’re getting a handle on how things work and what you’ve got to do, everything changes.

A short history of bet365’s mobile development

bet365 brought its mobile development programme in-house in 2010. Five days before the start of the World Cup. Up until then, we had outsourced to a third party. It’s hard to imagine, but at that time the majority of the world was on Nokia devices and the iPhone was only just starting to make waves. Our mobile site was built in HTML4 and was basically a scaled down, menu-driven version of our desktop site.

>See also: Why Bet365 swapped Java for Erlang

We could serve people information on our full roster of sports and enable them to make a bet and that was pretty much that. Our development streams were split in two; one for the new high-end smartphones and one for everyone else. The primary differentiator being the larger real estate available to us on the new smartphones.

By 2012/13 smartphones had taken a hold of the market and triggered a huge shift in development. The iPhone et al gave us an opportunity to deliver a much richer experience to customers, which we could serve from the browser or through an app. Our first apps were basically light weight wrappers around our website. Providing apps supplied to the Apple and Android devices gave us a new route to market.

Then, the dawn of HTML5 brought another major shift. It gave us the opportunity to consolidate our code base. We moved from three development streams (one for tablet, one for low-end phones and one for high) to a single stream. This delivered exceptional efficiencies.

To app or not to app

The real benefit of HTML5 is you don’t have to worry about screen size. The code ensures your site automatically fits whatever user interface your customer is interacting with.

Undoubtedly, moving to a responsive strategy makes sense for a lot of companies because it’s a much more efficient way of working. However, it presented us with a number of challenges.

First, our service is all about speed of delivery, so you need your code to be as streamlined as possible. With a responsive approach you get a lot of redundant code that can slow down the experience.

Second, our experience shows that people use different devices in different ways – be it a tablet, a phone or now a wearable device, like the Apple Watch. We’ve found that, although responsive sites can shape shift to fit whatever UI the customer is using, they may not present he most optimised experience for the device.

Third, the app environment presented new feature opportunities that aren’t present with a responsive site. More importantly, these features would enable us to achieve strong differentiation in the market. Features like split-screen video streaming and notifications.

So, just as it looked as if we could move to a more homogenised approach to our development, it once again split into three streams: one for iOS, one for Android and a third for Windows.

Building apps for iOS, Android and Windows

The most obvious approach to mobile is to tailor your designs based on real estate. That’s how we started out. That is until we discovered how behaviour changes when users are on different devices. Today our strategy is driven by behaviour.

Although all tablets are Wi-Fi enabled, only a small percentage are 3G enabled. For this reason, people are more likely on tablets when sat at home and their sessions will be quite long.

Mobile phones users, however, are all about speed of action on the move – be it making a bet or closing one out early. So it’s important that we give our customers much quicker access to these immediate actions.

When it comes to design, we are always conscious of giving our customers a strong single brand feel. But we also understand that a customer has invested in a specific platform, whether it is iOS, Android or Windows. So we localise the look and feel, touch points, buttons and gestures to the platform.

Then of course there’s the smart watch. The biggest challenge you have is screen size. No matter how paired down, it’s going to be difficult to present any kind of experience on a screen that small. What smart watches do really well, however, is notifications.

Certainly this provides a channel for marketing but we saw an opportunity to deliver an information-rich experience. Smart watch users can set alerts on the sports and events they are most interested in and continue to keep up to date on the latest news, even if their phone is in their pocket.

>See also: 3 secrets every mobile UI/UX designer must know

Creating consistency in bet365’s code

All of this platform differentiation could have created a coding nightmare but we’ve found that we can use technology to create the consistency we need to develop at pace.

For example, moving from Javascript to Typescript has allowed us to bring intelligence into our development. We can standardise our code footprint and let the system iron out any OS nuances.

This has allowed us to hire new development staff and quickly bring them up to speed because they don’t need knowledge of the legacy code. They are not constricted by the rules we would have traditionally had to create to ensure our sites are working across each platform.

The result is that the vast majority (about 90%) of our code is now generic and the rest is tailored to make the most of the opportunities presented by the different OS App environments.