Last week, I spoke to an audience about evaluating multiplatform solutions. Spoiler: you need a rubric, and the criteria you pick will be heavily context-dependent.
Coincidentally, I got a comment on my Lead Dev NYC 2019 talk a few days later, bringing up 5 criteria that leads him to choose React Native.
My response became more of an article, so here we are: his comment, and my response
Kotlin multiplatform is promising, but when comparing stacks, these key factors rarely get mentioned:
- does it allow for a shared end to end testing and continuous integration setup between platforms?
- does it have feature parity by design?
- can code be shared between web and mobile?
- availability of experienced developers?
- shared pull requests between ios, android, and web (and thus converging knowledge and coding standards)?
Kotlin MP will likely never check these boxes, which people should be aware of before deciding. E.g. React Native is quite powerful when looking at the overall benefits and teams like shopify seem to agree.
Thanks for raising these questions.
Before anyone asks questions, they need to know if it is relevant to their business. And, when they ask questions, they need to know how important each one is to their business. There are world-class engineers at Nubank, Shopify, and Square and each of them made different code sharing decisions (Flutter, React Native, and Kotlin Multiplatform respectively). And let’s not forget the recent examples of Airbnb and Udacity abandoning React Native after years of investment in using it. Since every business is different, there is no one-size-fits-all evaluation criteria.
To answer your questions:
- Depends, because the focus is on sharing business logic, not UI, the shared testing is focused on the business logic. If you are building an SDK without UI concerns, then yes, you can E2E test the product under test. If you are building apps that share business logic with KMP, then no, but you can share common tests.
- No, it has optional sharing by design. This allows for greater feature alignment while reducing re-write risk in existing code, and easier, purposeful platform specific integration if the product calls for it. (See my thoughts related to feature-alignment as a goal)
- Yes, Quizlet is doing exactly that. KotlinJS came before Kotlin/Native and they are now both under the Kotlin Multiplatform umbrella.
- Depends what experience you are looking for. Since React Native has been out longer, there is a larger pool of people with React Native experience. However, React Native is different enough from both React Web and Native Mobile, that both experienced react web devs and native mobile devs have issues with it. And people who have a few years experience with React Native often build within the confines of React Native and libraries available which gives them trouble when the product requires more native platform integration or platform specific look and feel. As for KMP, Kotlin experience is easy to come by and the experience needed to integrate the generated framework into an iOS project is easy to come by as well. The difficulties are in the details which is more about good software development, rather than experience with each technology.
- Yes, Touchlab and other companies adopting KMP recommend shared PRs and ways to enable that like monorepos, bringing together Android and iOS teams into Mobile teams, building tools like our Kotlin Xcode plugin, and shared coding standards, especially around architecture and API style, to ease the transition to all platforms working together.
I wouldn’t say “likely never check these boxes”. For 1, the open source community is growing and there are already several concepts around sharing UI with KMP as well. For 2, similar answer as 1, you can already build full react web apps in Kotlin and the community is looking at ways to share everything for feature parity across all supported platforms.
Again, not everyone’s questions/criteria will be the same and the weight given to each will be different too. The people choosing KMP put more weight on its optionality, native interop, use of Kotlin, and deference to the platform UI and ecosystems. (See my recent webinar on this subject)
Lastly, since my talk, React Native has continued down the path of becoming “more native” with the introduction of JSI and Turbo Modules. Though, so far, those are more native in the C++ sense, rather than the Kotlin/Swift sense and that will bring issues related to what DropBox encountered. But again, there’s no one-size-fits-all criteria.
For more of my thoughts on this topic, please watch my 20 minute webinar
This post originally written for Touchlab