Why Kotlin Multiplatform ?
Majority of developers will find themselves working with legacy code at one time or another, you don’t know the story behind the project and why the project is so become mess and complicated.
You need to think that “Nobody sets out to write bad code”. The problem is that nobody ever means to write bad code, but bad code or bad architecture always happens due to requirements changes or deadlines requires “quick and dirty” solutions that are never remedied, requirements turn out to be more complex than you originally thought. You can try to protect yourself with good architecture, create loosely coupled components and define clear responsibilities for each class. Whatever you do, another set of developers will still come along in a few years and they will think your code is another mess or the architecture is obsolete with current trends.
Now let’s say you have a legacy of Android and IOS code and there is so many discrepancy between those platforms when calling API, exception handling, UI/UX, and etc. Maintain those platforms will be challenging and you still need to add new features while minimize the discrepancy between those two.
It’s your jobs now to make both platforms look identical on architecture, business logic and UI/UX, maybe the simplest thing to do is build from scratch the whole project and using one code base in one project.
Refactor or Rewrite
If you think again build from scratch always looks more simpler and easy, but it’s have a risk that you can missing some logic and business rule that you need to apply on your new code also your team need to be distributed between maintain of legacy application, rewriting a new one and add new feature which causes a constant change of scope that will affect productivity. Maybe that problem could be fixed by hiring new developers to work on the rewrite only but probably they will lack experience on the business area, business logic and once again that will lead to poor productivity and a poorly designed system.
It doesn’t mean build from scratch is bad decision, rewrite your application from scratch also have some benefit. Uber’s post their story how they make decision to Rewrite their Uber’s Driver app here.
I think decision to build from scratch or refactor is strategic decision and that the right option will depend on your application size, your human resources, daily active user size and currently state of the code.
Hybrid Framework
When you read maybe you think about using hybrid framework such React Native, Flutter, Phone Gap or many other frameworks, with those framework you can migrate the code from native to hybrid partially, and you can build apps without touching native code, but those framework will always be behind, because it is not platform, it is just a “duct tape” that connect your code to native framework, when Apple or Google releases new version of OS or new features, that features will not be available immediately on those framework.
When new feature release to be able use you nee to write specific code for each platform to make it usable in the shared code, you would need to have your own abstraction with multiple wrappers for each platform. Also hybrid frameworks unify the UI development and it can be challenging due to platform specific UX patterns and user behavior when using your apps.
I’m not saying React Native, Flutter or any other hybrid framework is not good, I used to write apps using React Native and the final product using React Native is nice and running smoothly on both platform also I have no trouble to find example or library to solve my problem.
Using hybrid platform can save a lot of time and human resource,you only need to write once and you can compile iOS and Android apps using one code, but if you are one of believer that hybrid framework never replace native development maybe you will option out using hybrid way to build the apps. Maybe at least until Google and Apple officially come to agreement to use one of those framework as official way to build their apps.
Kotlin Multiplatform To Rescue
Now to make iOS and Android have same project structure, architecture and UI/UX but using native way sounds not so complicated, you can create every project using same architecture whatever it is MVP, MVVM, MVI or MVC, whatever the architecture is, I believe that there is “no silver bullet” pattern, so choosing architecture pattern is a matter of weighting trade-offs in your current situation, but even if you have same architecture on both project when you working as team miscommunication always happens, sometimes it’s just miss-perception when calling handling error exception, miss figured validation steps or mistaken when call API.
In this case it’s better to refactor/rewrite the current project and to make both platform use one library or one code to control all of the process on both platform. This code should responsible for all the business logic and tell both platform what to do.
Both platform IOS & Android is influence by C and can calling C or C++ library. Java can calling C++ code through Android NDK tool-set, likewise in IOS you can call C++ from Obj-C or Swift code. The main problem it’s not easy to create C library and it’s troublesome to setup and call C library.
On November 2017 Kotlin 1.2 released with Sharing Code between platforms. This is their major release and a big step towards enabling the use of Kotlin across all components of a modern application.
When Kotlin 1.3 released they reworked the model of Multiplatform projects in order to improve expressiveness and flexibility, and to make sharing common code easier along with first stable version of Coroutines.
IOS and Android have different standard user interface, Android have Material design and IOS have Human Interface, both standard is great and they have different way to show notification, alert dialog and navigation between page. User on iOS have different habits how they jump to other screen or how button and tabs looks alike. It’s better for apps following their guideline.
In this case UI code need to be different between iOS and Android and our multiplatform code will rules the business and UI logic, this way we not try to unify the UI and UX patterns for each platforms.
With Kotlin Multiplatform applications are native and we not depend on other library or bridges like hybrid framework. We can do everything we could do before, you can still using Crashlythics for your error track or you can still use ARKit on IOS without making React Native Bridge to make it can run on your code.
In Kotlin Multiplatform we make class that will will rules the business logic, define parameter to call API, control UI, and control when client need save the data to local storage and this class will be use by all client app at IOS, Android, Web, MacOS, or Windows Application.
Kotlin Multiplatform provide you with expect/actual mechanism. For example if you need tell client to save data to local storage from Kotlin Multiplatform code you can write specific code for each of platform.
In iOS to save data to local storage you need implement NSUserDefault, on the other hand in Android you need to use SharedPreference.
So on Kotlin Multiplatform code we need to declare expect class, and we need write actual class for iOS that implement NSUserDefault and actual class for Android that implement SharedPreference.
Conclusion
Kotlin multiplatform projects are a great way for truly cross-platform, even cross-tier development with all its benefits but please keep in mind that this feature still an experimental, maybe it’s better to wait until they have stable release if you want to try this on production.
Beside of that you can check j2ObjC by Google or Swift for Android to do something similar.
If you interested build Kotlin Multiplatform for iOS and Android you go to my next article, we gonna try to create one application for iOS and Android using one Kotlin module to control the logic.
Don’t forget to 👏
