Over the past 10 years iOS and Android have not only grown and matured, but increasingly converged as well...

Early apps were spartan: a few screens built by a solo developer or a small team. Compare that to today’s apps, which offer surface-layer simplicity but implementation complexity that often goes deep. In these iceberg apps, each user sees what they need and nothing more.

Our programming languages have matured as well. Objective-C and Java are each needlessly verbose in their own unique way, but over the past few years Swift and Kotlin have emerged as popular languages because they are both concise and similar.

The devices and UIs have also converged. Five years ago I appreciated how our designers honored platform-specific UI conventions; today I struggle to identify any. Both iOS and Android have great notification features, permissions models, design systems, and much much more.

But despite the similarities across UIs, devices, and languages, we still build everything twice. For the app I work on we have two sync engines, two navigation patterns, and two reactive event frameworks. Worst of all, this redundancy harms our agility as some features are more difficult on iOS while others are harder on Android.

Working Together

With these challenges in mind, our primary solution is to bring our mobile teams together. We’re asking Android engineers to review iOS pull requests and vice-versa. Initially we’re focusing these reviews on business logic and view models. We don’t expect iOS developers to learn Android’s XML layout system or Androids to study Core Data.

However, we’re also trying out multiplatform Kotlin. I like it because it’s not an all-or-nothing endeavor like most cross-platform frameworks. Here’s how Kevin Galligan explained it on the Talking Kotlin podcast:

It compiles down with LLVM: it doesn’t have a surrogate memory model and it’s not running a VM. When your iOS app calls Kotlin from Swift, Swift doesn’t know that it’s not a native thing.
Most importantly Kotlin/Native gives you optional sharing. So you can start by putting one module in your app without any real overhead. You can do it incrementally.

Our first experiment is to replace some old Objective-C persistence code with Kotlin/Native and SQLDelight. This leverages code we already wrote for Android! If that works well we’ll continue to invest. Ultimately, I want our mobile developers to gain the superpower of shipping code on two platforms.

To implement this approach using multiplatform Kotlin, we’re working with Touchlab who have been pushing multiplatform development forward for years. We’re also happy to benefit from JetBrains’ and Google’s continuing investments in Kotlin.

We’ll continue to update the community with the results of our experiments and any progress we make on nurturing a truly multiplatform mobile team, so stay tuned!