: Sam is Engineering Manager at , a mobile innovation consultancy based in NYC with expertise in Kotlin Multiplatform. Disclosure Touchlab 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: 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. 1. PRODUCT: Tech debt and architecture issues are slowing development 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. 2. PEOPLE: Your iOS and Android teams are siloed and lack collaboration 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. 3. PROCESS: Your engineering approach could be better defined 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 and divorce it from the platforms. converge these development efforts Code sharing, specifically with a 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. native framework (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 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, . “cross-platform” 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 . A few low-risk ways to do this? mobile engineers 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 , , and : product people process 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. Product: 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. People: With KMP at the center, you introduce better engineering processes that promote code sharing and multiplatform development. Process: For engineering managers interested in starting small with Kotlin Multiplatform and reducing the risk of adoption, we’re happy to announce The Touchlab Refactory to Hacker Noon readers. deploys a dedicated code logistics team to perform an architectural review, refactor code, and provide a detailed roadmap for future development in Kotlin Multiplatform. What is it? The Touchlab Refactory How it helps mobile engineering leaders? Incremental refactoring Defined timeframe Separate work track, dedicated team More testing, less time Improved architecture Less duplication Kotlin Multiplatform expertise You can join the waitlist . here

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Accelerating Development with Kotlin Multiplatform

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

10 good rules for bad App

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps