When leading a team of iOS and Android developers and creating the same application for both platforms, you are bound to face one (or all) of these issues:

1. PRODUCT: Tech debt and architecture issues are slowing development
Your team is having difficulty adding new features because too many parts of your codebase are tangled and interconnected. As a result, new bugs emerge whenever you add new features or fix existing bugs. Your team is constantly putting out fires when they could be innovating on the product.

2. PEOPLE: Your iOS and Android teams are siloed and lack collaboration
Android and iOS engineers should be able to deliver on both platforms. However, modern teams often lack a structure for leveling up engineers to deliver on both platforms. Furthermore, with little or no collaboration, this makes it particularly difficult to achieve feature parity between the two apps. It’s just too labor-intensive and requires too much management time.

3. **PROCESS: Your engineering approach could be better defined
**It could be that your iOS and Android engineers work at different speeds, making it tough to keep feature releases in sync. At the same time, independent backlogs can make some things slip between the cracks. And if some features are deliberately delivered on one platform before the other, it’s more difficult to predict when the second will be available because the code isn’t being shared. In effect, separate apps and separate teams result in divergent apps and user experiences.

…

The cause of these setbacks across people, product and process is a lack of common ground between developers and too much dependency and coupling with each platform. The solution, then, is to converge these development efforts and divorce it from the platforms.

Code sharing, specifically with a native framework like Kotlin Multiplatform, encourages better architecture by pushing the developer to decouple the view and approach the logic from a more modular perspective. By isolating the presentation layer from the business logic layer, you not only streamline the architecture, but also simplify bug testing, maintenance, and upgrades. All these gains come just from moving towards a Multiplatform friendly architecture, before even addressing the obvious benefit of only having to write the code once for both platforms.

(diagrams by Sam Hill, designed by Nelmer De La Cruz)

Compared to alternative multiplatform solutions like React Native or Flutter, KMP focuses on maximizing shared business logic. We believe this provides an advantage over the loathed “cross-platform” model by providing consistent platform experiences for users while sharing as much code as possible. For a deeper dive into why we prefer KMP over alternatives, you can view our webinar here.

How to get started

So where do you start with Kotlin Multiplatform (KMP) — In a word, small.

PRODUCT: Start small — and avoid big risks

Start by isolating a single layer or component or feature. For example, you can isolate the persistence layer, in effect creating a single database implementation for both platforms.

Isolating the persistence layer enables it to function for the entire app across both platforms. In other words, every time the app calls the database, it behaves the same; it’s not platform-specific. Rather than using CoreData for iOS or Room for Android, you can use a single implementation of SQLDelight for both.

As you start isolating layers such as persistence and improving the architecture in KMP it becomes easier to start refactoring other layers as well. For example, using KMP, a networking component can move from AlamoFire on iOS and likewise from Retrofit on Android to a shared layer, perhaps using KTOR.

PEOPLE: Create platform-agnostic teams

With KMP, your development teams no longer have to be siloed. By expanding the common ground and simplifying platform code, you gain an opportunity to easily level up your platform engineers — both iOS and Android — to become mobile engineers. A few low-risk ways to do this?

– Introduce flex time for Android engineers to learn iOS, and vice-versa.

– Insist the same platform-specific developer tackle the same user story on both platforms. (This is understandably a slower process but it has higher long-term ROI.)

– Perform shared code reviews. (For example, have an Android developer write a pull request, and get an iOS developer to review it.)

– As tasks start becoming more multiplatform, code reviews start giving developers opportunities to see complete stories and draw parallels between platforms

PROCESS: Promote D.R.Y. (Don’t. Repeat. Yourself)

Creating a platform-agnostic environment extends beyond just development. It’s equally important to consolidate the processes that drive development. Tracking a multiplatform feature in a single place makes it simple to maintain platform alignment. Having all of you multiplatform developers participating in the same planning processes improves communication. Consolidated defect tracking makes sure bugs don’t fall through the cracks on a platform.

…

So, if you are looking for opportunities to accelerate and optimize development, KMP is a great way to begin streamlining and future-proofing your product, people, and process:

– Product: KMP focuses on sharing code at the business logic layer (where most architecture issues occur) and enables you to address the issue in a piecemeal fashion — no big decisions. You start small at your own pace and see the results before continuing.

– People: Using KMP, your engineers will be better prepared for the future, increasing the value of your department to the wider organization because they can deliver on multiple platforms.

– Process: With KMP at the center, you introduce better engineering processes that promote code sharing and multiplatform development.

If you’re interested in learning how KMP can accelerate mobile innovation at your organization, please contact us.