Cross-platform development explained

First of all, if that previous sentence short-circuited your brain, here's what I mean:

• A company can have multiple channels, or digital experiences, through which it conducts its business. For example, a website or web-based app, and a native app.
• Traditionally, both of these experiences will require a separate codebase. A native app doesn't run on straight HTML code and vice versa.

Now, in comes cross-platform development, a way of working that's becoming increasingly popular ánd potent. In this case, you'd only need a single codebase to run both native and web applications. From a technical standpoint, one fundamental strategy for cross-platform development includes compiling different versions of the same program for different operating systems. Another route would be to make the program itself abstract at a higher level in order to accommodate different software environments.

Advantages of a unified codebase

The advantages of cross-platform development speak for themselves:

• Wider market reach: You don't have to choose between Android, iOS, or web anymore.‍
• Faster development: You code once and simply deploy it everywhere, in an ideal case.‍
• Lower cost: You no longer need separate team with separate skill sets to develop each app.‍
• More consistency: People want a consistent experience across channels, this is how to do it.‍
• Lower maintenance: Updating and maintaining a single codebase obviously takes less work.‍
• Faster prototyping: Cross-platform apps can easily be built as MVPs, reducing overall risk.

While that sounds very enticing, it doesn't contain any real clues as to what you should do with the legacy architecture that's present in your company currently. Not to mention overhauling an entire back end or migrating to a different service will sound incredibly scary to most stakeholders.

Stakeholder objections

Adapting your current architecture map to enable a headless or omnichannel approach will make things look more complicated when you'd initially expect the opposite; you might need to add a shell to compile your app into a native mobile app, or an additional API layer to abstract the different data sources.

To anyone less technically-inclined, this could cause some red flags to pop up and the hard questions will come rolling in:

• Will this solution be stable enough?
• Will it be scalable enough?
• Will it be customizable enough?

To that I'd answer: It's not that black-and-white.

• Choosing to start from a unified codebase doesn't mean you're boxing yourself in entirely. Whether you're going with Expo, Flutter, or Kotlin for your cross-development needs, injecting custom code is always an option. Which is something we usually end up doing at Bothrs, to take the customer experience to the highest possible level.
• People also underestimate how much these popular SaaS businesses have grown in terms of features and support. Take Shopify for instance, a now very feasible option for headless commerce. The platform can handle product databases of over 30.000 without problems, and the marketplace boasts currently boasts over 7,000 apps and integrations.
• But at this point we're hyper-focusing on the technical challenge, and losing sight of the actual business challenge. In reality, you want to provide value to more potential customers as soon as possible, while also providing a convenient and consistent user experience across channels. A very common objective for digital-first companies nowadays. Also, when's the last time you heard a customer complain about the inherent complexities of your back end architecture?

To clarify, though, the decision to create a unified codebase for your business' digital experiences shouldn't be made on a whim, and neither is it the right answer in every scenario. But people seem reluctant to give this approach the credit it deserves, especially when you're dealing with more than one channel.

Case study: Spotify

So let's take a look at a concrete use case: why Spotify decided to bring their desktop client and web player together as one single application. This project started back in 2018. You can read the full article, published by the company itself, here. Basically, there were a couple reasons why the idea of building a unified codebase came around:

1. The web player was built using React, and Spotify had just onboarded new engineers to the code. But those same engineers weren't equipped to work the desktop app as well, which used a range of web technologies.
2. Shopify was unable to ship new features at the pace they would have liked, because they had to be developed twice at different levels of complexity by the same engineers, with constant context switching as a result.
3. Additionally, there were accessibility issues with both clients. Spotify deemed it would be a challenge to do for the web player, but nigh impossible for the desktop application.

You'd think a company with over 400 million users would be hesitant to rebuild both applications from a single codebase, out of a few UX concerns, right? Well, you thought wrong. However, a project of this magnitude requires hefty technical validation before even considering it as a strategy.

So to avoid reinventing the wheel, Spotify decided to use the web player's codebase as a starting point, and rework it until it reached a feature set resembling the desktop app. Mainly because of its inherent robustness and tight coupling with Spotify's servers. From a technical standpoint, this meant creating a single UI for the entire app, but with multiple containers.

Long story short, here's what this project yielded:

• Spotify no longer needed to hire separate teams of engineers to work separate codebases; one single team would be in charge of the entire application.
• Since the web player gets deployed continuously, shipping and testing new features could be tested almost on the fly as well.
• Reusing the same code in multiple clients allowed Spotify to write the code once and reap the benefits in multiple places, faster.
• Needing just one set of design components that service multiple clients ensures that Spotify can implement designs more thoroughly, thereby improving its UX overall.

Conclusion

Instead of saying you should always attempt to create a unified codebase, I'll just say this. Similar to what Spotify did, I'd recommend you cater your technical decisions towards the needs and wants of your users first, and then your business. For instance, will inertia make you lose customers quickly? Does the challenge largely relate to the overall user experience? Is your team of engineers lacking bandwidth to maintain multiple channels? If you answered 'yes' to most of those questions, I urge you to consider cross-platform development.