Mitigating the Risk of Siloed Native Code

Separate and risky

Engineering leaders have a choice to make:

• Continue building in siloes with separate platform teams (Android and iOS) OR
• Evolve from a 100% siloed native code → x% shared native code between Android and iOS

Here are the five areas of risk that come with managing two siloed native code bases: 

1. Development

Each time your Android and iOS devs work on business logic items like database, networking and error handling, it creates opportunities for unique platform errors. 

And you’ll know this from first-hand experience…when your platform teams are working on new features in parallel, the amount of feature work that lands in the finished product is far less than the amount of work you do to get there. That’s the cost of iteration and if you continue to do that in parallel with two teams, you’re multiplying that cost. 

Takeaway: Completely separate code bases are prone to platform-specific errors, which impact developer velocity and grow technical debt as architecture approaches diverge. The cost of feature iteration is also amplified when platform teams don’t share code. 

2. Feature fidelity

Platform-specific errors and development slowdown eventually cause Android and iOS features to drift apart.

Takeaway: Siloed native code bases with no sharing compromise feature fidelity.

3. Economic

We estimate 35-50% of developer time is spent on bug fixes and an estimated 15-50 errors per 1000 lines of delivered code.

Consider all the possibilities with a 25-40% increase in available developer time:

Note: How did we calculate these figures? If you have two teams and you reduce the workload of one of them by half you’ve increased capacity by 25%.

Now plug in your average developer salary and do some math.

Takeaway: Funding 100% siloed code bases is EXPENSIVE (and wasteful)!

Source 1, Source 2, Source 3

4. Political capital

A bad day for an engineering manager is when their CEO unexpectedly interrupts standup and tells the story of how her niece’s startup is coding their Android and iOS apps from a single codebase. The CEO turns to the engineering manager and asks “Why aren’t we doing that?” 😕

Takeaway: Completely siloed code bases in 2020 is a red flag to your management (unless you have complete data to defend your position).

5. Recruitment & retention

The teams at React Native, Flutter and JetBrains/ Kotlin Multiplatform are spending money to promote and evangelize multiplatform solutions to your developers. And your devs are paying attention. Forward looking orgs will cater to developers’ interest in multiplatform solutions at both the recruitment and retention level.

Takeaway: Siloed code bases cannibalize emerging developer interest in engineering efficiency plays.

Shared native code with Kotlin Multiplatform

Native mobile development for iOS and Android generally involves writing 2 separate code bases, picking an “all in” cross platform tool, or using some form of code sharing to bridge the gap.

For long-term mobile developers, there is a sense of dread around any form of “cross platform” due to generally negative experiences and outcomes.

• The tooling and ecosystems are generally bad. This can easily cut your efficiency gains to zero, or worse, not to mention crush team morale.
• Performance is often bad. This is poor UX, baked in, and users do care.
• There’s often a “perfect” native component that you just can’t use. so you have to create your own, and make big compromises.

Resistance from native developers is not simply being defensive. There are real reasons why most quality mobile is still native, a decade into “the iPhone Era”.

Native developers tend to talk about “cross-platform” as one concept, with all tech being rolled into “native” and “cross -platform”. In reality, all these options vary considerably and it’s important to define them appropriately so we can discuss which options are better for which circumstances.

The most concise definition of Kotlin Multiplatform I can give is as follows:

• optional
• natively integrated open source
• code sharing platform
• based on the popular, modern language Kotlin
• built by JetBrains, which makes the best fools on the market
• facilitates non-UI logic availability on many platforms

Optional means the tech is designed to be used along with the native tech. Most cross-platform frameworks allow you to integrate them into existing apps, but are generally not designed to make that easy. “Possible” is not the same as “actively designed for”.

The optional sharing nature means it is easy to evaluate KMP in your existing apps. You can add code incrementally, and critically, if some shared code isn’t performing as expected, you can “just code it natively” without any major issues. The optional sharing nature makes KMP low-risk.

Other code sharing solutions, such as C++, JS and Rust, generally involve a bridging layer. C++ is “native”, but from the JVM you need to talk to it through JNI. That will have extra code and performance implications. The same goes for other code-sharing frameworks. They run in their own runtimes, with their own memory quirks, restrictions, and rules.

Kotlin was designed to interop with the JVM directly. Kotlin is “native” to the JVM, and for Android, Kotlin is recommended over Java itself.

For iOS, the Kotlin compiler outputs an Xcode Framework that Objective-C and Swift can communicate with directly. It looks like any other Objective-C framework. To put it another way, Kotlin is also “native” in an Xcode and iOS context, and with Swift ABI stability in 5.1, we can expect there to be focus on Swift interop in the near future. 

Native integration dovetails with optional code sharing to reduce barriers to integration (easy to call, low-performance impact, etc) and reduce risk.

As a side note, Kotlin is the preferred language for Android. In the case of native mobile, this makes Kotlin unique for code sharing. C++, JS, Rust, Go, etc can all be used, but none of them is the “preferred” language for either platform. In the case of KMP, there’s no “3rd” ecosystem. Again, going back to risk, not adding a 3rd language is important. Also, because of how Android the Operating System is created and deployed to actual devices, there tends to be a much wider range of versions and issues. Being able to avoid adding any risk to the Android side is a huge benefit.

Introducing our latest initiative – #TouchlabShare!

We’d like to help you if you’re exploring shared native code.

Touchlab Share is a week-long series of daily Zoom webinars (20 mins each). Our Kotlin Multiplatform experts will present on a topic for 15 minutes and allow for 5 minutes of questions.

We’ll also link out to more in-depth resources and offer hour-long consultations for teams genuinely interested in Kotlin Multiplatform.

The inaugural Touchlab Share will flow as follows:

• **Framework for evaluating multiplatform solutions
  **Monday (April 6th, 1 PM EST)
  By: Justin Mancinelli (dir. project strategy)

• **Identify parts of your app that are good candidates for high-impact code sharing
  **Tuesday (April 7th, 1 PM EST)
  By: Kevin Galligan (partner), Sam Hill (engineering manager) and Russell Wolf (multiplatform engineer)

• **Building a POC with Kotlin Multiplatform – Touchlab KaMP Kit
  **Wednesday (April 8th, 1 PM EST)
  By: Kevin Galligan (partner), Sam Hill (engineering manager) and Russell Wolf (multiplatform engineer)

• **Building a business case for native code sharing
  **Thursday (April 9th, 1 PM EST)
  By: Jeff Namnum (partner) and Carmichael Caldwell (business development)

Register for #TouchlabShare