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.