Introduction to Kotlin Multiplatform

Introduction to Kotlin Multiplatform

by | Nov 8, 2019 | Future of mobile, Kotlin Multiplatform

Kevin Galligan — Intro to Kotlin Multiplatform | Øredev 2019 from Øredev Conference on Vimeo.

Introduction to Kotlin Multiplatform

Using the Kotlin language to program logic that can be used on all platforms of your app, it creates common logic that the native UI of any app can call upon.

KMP is really about pragmatic programming to help meet the growing demand to develop mobile applications on multiple platforms – a clean, clear way to avoid having to write the code twice.

The philosophy that has driven Kotlin since its inception is about enabling developers to code for all platforms. Kotlin is a modern language that allows you to develop applications more cohesively, and dovetails with native platforms on Java, iOS, and the web, so you can build on what’s already been coded. You focus on sharing code that is data, business, or presentation logic, and leave platform-specific components to be implemented natively.

It’s important to note that multiplatform does not mean compiling all code for all platforms. In mobile app programming, for example, you determine which modules are platform-specific and which are common to Android and iOS. Those which you identify as common to both can be programmed using KMP, writing in Kotlin Native.

KMP is a low-risk way to avoid repeating logic to develop applications for iOS and Android more expeditiously and effectively. Ultimately, KMP leads to better code overall. And it’s one of the many reasons why Touchlab is now fully committed to Kotlin as the most viable way forward for development teams today.

As a programming language, Kotlin keeps growing in popularity throughout the world, and with the introduction of Kotlin Multiplatform (KMP), there’s been more and more chatter among the mobile developer community about the possibilities it can bring.

Users’ needs are the same, whether they’re using an Android or an iOS device. Development teams, however, remain siloed by discipline, whether they’re programming for web or Android or iOS.

So, as a software development team, you have some challenging questions. Can you provide consistent quality on all devices when you have different development teams with varying skillsets developing the same apps for different devices? And can you ultimately justify the amount of time, budget, and resources it takes to produce viable solutions? We believe KMP is the best possible way to answer to these questions.

KMP: ready right now

It’s madness, really. An app is written for the web. Then for Android. Oh, and then it needs to be written for iOS, too. (At the same time.) Same app, different code. The question is, “Why?”

Development teams are essentially tripling their coding and testing efforts to ensure multiplatform coverage. It’s costly. It’s time-consuming. And – this might be the craziest part – it’s uncertain what the shelf-life of the code will be. As we know, the future is unwritten. As always, the goal is to be able to implement products more efficiently, and with better testing across platforms. And up to now, every multiplatform coding solution that has come along really hasn’t worked that well.

The good news is that there is now a better way.

And a proven way.

We at Touchlab have been writing code in Kotlin and deploying it to Android and iOS platforms, with no hiccups. That’s why we’ve gone all-in with Kotlin Multiplatform.

KMP is a true multiplatform language 

Kotlin enables you to write once, and test once. No siloed development teams. The same code can be used across Android, iOS and Web apps with no changes, eliminating the need for a translation layer. In essence, you’re reducing the amount of business logic coded by frontend developers by consolidating it efficiently with native code, but not oversimplifying abstractions. What’s not to love about that?

No wonder there’s a groundswell of enthusiastic support in developer communities around the world. There are 1.5 million developers currently using Kotlin, with 96,000 GitHub repositories containing 100 million lines of code. And the numbers keep growing. It’s one of the top two languages that developers are hungry to learn.

Kotlin was developed as a completely new language eight years ago, built from the ground up as a pragmatic approach to coding – a way to develop cleanly, clearly, and quickly.

Simply put, Kotlin is more readable, reusable, interoperable, and safer, offering a first-rate developer experience.

KMP for your complete tech stack 

It’s a low-risk way to code because it dovetails seamlessly with the native platforms on Java, iOS, and the web. It’s a modern language that enables you to build on what you’ve already coded, without re-working or re-inventing what you already have. Plus, because the code you share is optional, you can start small and increment as desired.

Kotlin is really an extension of Java, so it’s not a big leap for Java developers to start using Kotlin at all. In other words, you don’t have to make a big, potentially expensive decision to get started.

Kotlin is really an extension of Java, so it’s not a big leap for Java developers to start using Kotlin at all. In other words, you don’t have to make a big, potentially expensive decision to get started.

 

In fact, on Android, Kotlin was built for direct JVM interoperability. On iOS, Kotlin is ready for prime time, and the first half of 2020 will see rapid mainstream adoption. And Google officially recommends Kotlin as a language of choice.

The big considerations for any development team are cost, time, resources, and risk. And the big problem with the siloed approach is that organizations are often tripling them.

At the same time, the wrong teams are working on the wrong projects. Back-end developers should focus on architecture as well as APIs – but not UI. Enabling your back-end developers to code and test the client and server features as a unified whole enables more rapid development with safer, higher quality and identical implementation.

Our experience with Kotlin so far? No siloed teams. More streamlined workflows. Real cross-platform functionality.

Useful introduction to Kotlin Multiplatform resources 
7 ways to convince your engineering manager to pilot Kotlin Multiplatform

7 ways to convince your engineering manager to pilot Kotlin Multiplatform

by | Nov 5, 2019 | Future of mobile, Kotlin Multiplatform

We hear similar stories when we speak to mobile developers interested in a Kotlin Multiplatform pilot for their team. The story goes something like:

You’re a developer. You’ve seen the growing momentum that Kotlin Multiplatform (KMP) is gaining in the developer community – especially since Google announced it was officially supporting Kotlin as a development language in 2017.  And now you want to try it for yourself. (Or maybe you already have.) More important, you’d like to try it on a live project, with your colleagues at your workplace.

 

The question is, how do you convince your manager that it’s a viable framework to use? They already have enough to deal with, right? Hard deadlines, pressure to produce faster, test more thoroughly, improve architecture, deal with tech debt… the to-do’s for them go on and on and on.

 

If you’re convinced (like we are) that Kotlin Multiplatform is the best option for unified development of business logic across iOS and Android – but are not sure how to broach the subject with your manager — we’ve put together seven key talking points for you.

1. “One code base. One team.”

Using Kotlin Multiplatform, we can code business logic across both platforms. That means the team doesn’t have to do the same work twice — once for iOS and once for Android. No duplication. Saves time. Saves money. (And saves a lot of nerves, too.)

2. “Kotlin itself is skyrocketing.”

More development teams are using it, and more individual developers want to use it, whether they’re Android or iOS. It doubled in popularity each year since 2015, and after the Google announcement in 2017, it went stratospheric. It’s especially popular among programmers looking to grow their careers. 

3. “KMP plays nicely with both iOS and Android.”

One way to think about it: Lexus has the same engine as a Toyota — the only thing that’s different is the exterior. Same with iOS and Android. They’re essentially the same under the UI hood, so it’s very straightforward to deploy to either platform with few if any hiccups. 

4. “Using KMP is low-risk.”

It’s not an all-or-nothing proposition. We can do the programming incrementally, one feature or architectural layer at a time, so there’s no disruption to hard deadlines. It’s not a major commitment to pilot a project.”

5. Our team can focus on innovation as well as  production.

If we’re only writing the code once for both platforms, it gives us the potential to focus on fine-tuning the architecture, designing more features, or exploring other innovations because we’re not bogged down in production only. Focus on new stuff or focus on testing. Frees up resources to do more stuff…

6. “Keeping UI separate is a good thing. It ultimately will save us time.”

KMP doesn’t do UI at all, but that’s actually a real advantage for us. Sharing UI across platforms can be risky because it involves doing multiple reworks and workarounds to make the UI work natively on its respective platform. With KMP, we can focus on the business logic specifically, and leave the UI to be coded separately.

7.     “With KMP, we’re future-proofing our business logic.”

KMP doesn’t lock into one ecosystem like Flutter or React Native or Xamarin. It’s easy to take an Android library and make it work as a KMP library – even easier if the library is already written in Kotlin. And of course, Google’s endorsement of Kotlin is a big plus. 

Need help piloting KMP? Apply to KMP Hack Week!

What is Touchlab’s KMP Hack Week?

We’ve talked to teams who have done their own hack weeks, but they end up spending most of the time just getting set up. Our goal is to get you set up quickly with your KMP pilots. We’ll get the setup sorted on Day One, be available to talk KMP thinking, and help unblock for the rest of the week. We’ll also throw in some mini-lectures on topics that all KMP engineers should know.

Musings on the Current State of Kotlin Multiplatform (Q3 ’19)

Musings on the Current State of Kotlin Multiplatform (Q3 ’19)

by | Sep 11, 2019 | Future of mobile, Kotlin Multiplatform

I’ve spent a lot of time chatting in Slack and on Twitter about the state of Kotlin Multiplatform. These are usually piecemeal conversations but often center around common themes. To spread the word better and help streamline these conversations, I’m going to write periodic posts about the current state of the KMP ecosystem.

Catching Up

I think we can start by revisiting some predictions I had last year around KMP in 2019.

 

Mainstream Adoption

The overall prediction was that we’d be seeing recognizable names diving into KMP and releasing serious apps. Not exactly a wild guess. It is safe to say that was correct, although with a caveat. We’ve been having lots of conversations with teams evaluating and shipping KMP, but these are mostly private. Similarly, if you installed an app using KMP on iOS, you wouldn’t know it, which is the point. I expected tech companies to be a little more forward about the interesting tech they’re using, as I think it really helps with recruiting, but it turns out that not everybody thinks that way.

It is still early days, and you still need to know what you’re doing, but production code is certainly shipping with KMP in Q3.

Multithreaded Coroutines

Not yet. I was *way* off on that. Will discuss later.

Compiler Plugins

This is also “not yet”, although if you want something very specific you could persuade the Kotlin Native team to let you bake something in (if you’re looking for something serious to work on, mockk native). The Kotlin compiler in general is going through big changes. There’s a consolidation happening that will be good long term, but we’ll be waiting for official plugin support in the short.

Other Libraries 

I mean, sure.

Paid License Debugger 

This prediction is interesting, and meta for me. We released an Xcode pluginthat lets you debug Kotlin. Jetbrains has also released a version of App Code that can be used for debugging, and recently a native debugger for Intellij, although all of these tools will need some future polish.

Reactive Library

Yes, ish. I was thinking that would happen after Multithreaded coroutines. There is Reaktive. It is more of a “traditional” Rx-like library. I think most apps at this point use something built in-house.

Q3 2019

Rather than just a big rundown of where things are at, I’m going to create sort of a composite character and consolidate multiple conversations I’ve had recently.

Q: Is anybody currently using KMP in their apps? There have been a lot of blog posts from earlier in the year, but the situation seemed flakey. Has there been much progress since then?

A: Yes! People are using KMP in apps. KMP is relatively new, generating lots of excitement, and moving very fast. That means there’s been a lot of aging content. If getting started or looking for updated info, it’s best to check out the Kotlin Slack, check out some tutorials, and see more detailed docs. If you’re looking for a super quick intro, check out our getting started series. We should have a few more coming out soon. They’re quick, and we’re going to keep them updated with each release, so they don’t age too fast.

Q: We are exploring the possibility of using Kotlin MPP for business logic and architecture (storage, networking, etc). Is that feasible and how much logic can be shared?

A: That is really what KMP is designed to do, so it’s definitely feasible. It will not be easy to build UI’s, certainly not shared ones (although there will certainly be shared UI options in the future). What’s really missing at this point are some libraries you might want to use, like date/time support, or local file access. The good news is that 1) library work is accelerating as the community grows, and 2) Kotlin has an optional interop design, so it’s easy to plug in whatever you want from the native platform to implement a missing feature. If you can’t find a library for something you want to do, it’s easy to just code it “native”. Date formatting, for example.

Q: I’ve heard coroutines aren’t supported on iOS, and they’re needed for concurrency. How does that work?

A: Interesting topic. Coroutines in native (and JS) are single-threaded. That’s not the same as unsupported. You cannot, however, do all the stuff you would on JVM/Android. That has definitely put off some developers, but this is really multiple questions. Coroutines are not needed for concurrency. In the context of native mobile development, we usually want to do something off the main thread, then return to the main thread. You can do this, and it’s straightforward to write. We use suspend functions in the Droidcon app where the main thread suspends, a background task is run, then execution resumes in the main thread. Flow is more complex, but we’re using it in a Firestone SDK wrapper currently (not public yet). Ktor uses suspend functions instead of callbacks for network calls.

However, the whole community expects multithreaded coroutines will significantly increase adoption. There are no target dates, but there is ongoing work and I’d bet something to appear around Kotlinconf.

Understanding native concurrency helps the discussion. I have a couple of blog posts (and that’s what I’m talking about at Kotlinconf):

Q: What’s the Swift and general iOS interop situation like?

A: There are the mechanical interop details, then there’s what I’d call the Swift developer interop, which is related, but different. Swift interop with Kotlin is through an Objective-C interface generated by the Kotlin compiler. That means whatever issues a Swift developer will encounter with Swift to Objc interop will be present. On the other hand, Apple has spent considerable time trying to make that interop as painless as possible. That means Swift naming overrides, generics handling, etc. The Kotlin Objc output is constantly improving, and currently supports many of those features.

There are no details yet, but I have it on good authority that direct Swift interop may be a priority in the not-too-distant future.

The politics of shared code and Kotlin on iOS are a different story. The goal is to steadily improve the tooling experience for everybody, including iOS developers. That is certainly a huge goal of ours. That should help, but there’s going to need to be some selling on the idea too. Need to start seeing Kotlin talks as iOS meetups!

Q: Our iOS team is really excited about SwiftUI and said we should hold off on Kotlin until we figure that out.

A: Not in the form of a question, but I’ll rephrase: “Can you use Kotlin with SwiftUI?” Yes. Not the actual “UI” part, but the logic and architecture, which is what KMP is really for, sure. SwiftUI doesn’t change the equation much. We’re all pretty excited about it too.

You cannot have structs coming out of Kotlin. That is true. The data you use in SwiftUI does not need to be a struct. Struct support from Kotlin is an ongoing discussion, and we may implement something in the future that extends the interop, and/or down the road there may be formal support in Kotlin. For now, though, if the lack of structs is a show-stopper, then you’ll have an issue.

What’s Happening at Touchlab?

Touchlab is hiring full time and looking for contractors. Mostly Android, some multiplatform in the future: http://go.touchlab.co/trdw

We recently launched The Touchlab Refactory; an incremental refactoring service with KMP which focuses on a single feature at a time with no disruption to your current development workflow. Learn more here: http://go.touchlab.co/refactory

 
How does Kotlin Multiplatform stack up against other solutions? Our scorecard, explained.

How does Kotlin Multiplatform stack up against other solutions? Our scorecard, explained.

by | Aug 30, 2019 | Future of mobile, Kotlin Multiplatform

In my last article, I explained the reasons why you should try Kotlin Multiplatform — not because it can do everything, but precisely because it can’t.

It doesn’t do UI, or even attempt to. It does, however, do one thing really well: code business logic for iOs or Android. You code once, and deploy to either platform with virtually no hiccups because you keep the UI separate and native to its respective platform.

Naturally, introducing a relatively new way of coding immediately draws comparisons to other popular multiplatform solutions. The scorecard with which I concluded the article is meant to be a quick, point-by-point comparative glimpse at the three predominant solutions alongside KMP. Here, I wanted to provide some specifics on why we scored each the way we did.

 UI layer

 

 

KMP

Why rate KMP so high on UI when it doesn’t even have a UI layer? Because it doesn’t get in the way of the UI at all. Flutter, RN, and Xamarin all say sharing UI is a benefit to buying into their respective ecosystems — but each have gaps between expectations and reality. When using KMP, you code UI separately, in native, giving you greater control of the outcome for the best user experience possible. 

Flutter

Flutter doesn’t enable you to easily use native components to code UI. Instead, it takes control of all rendering, providing either a transparent view that shows the native Android code underneath, or uses PlatformViews which requires fairly clumsy native interop. Either way, it essentially co-opts the entire UI on its own canvas. And if there are bugs, you have to wait for the updates from Flutter. 

React Native

While you can create custom native UI widgets with React Native, Javascript performance is still an issue. Often, for example, developers will say it promises 60fps, but it gets in the way of doing good UI. It also hinders development efficiency because its UI widget libraries are not maintained by React Native. 

Xamarin

If you have a soft spot for .NET, Xamarin will be usable to you. But Xamarin.Forms has a lot of limitations, and Xamarin itself does not really create that ecosystem of great UIs. You’ll have to make separate UIs in Xamarin, Android as well as Xamarin.iOS, which is a lot more hassle than doing them natively. Similarly, this is why we don’t recommend writing UIKit code in Kotlin Native (even though you can).

Business logic

KMP

For Android, KMP is already as native as it can be. For iOS, it still has some issues with sharing business logic with idiomatic Swift code, but overall, it’s super-fast — and  the native interop means you don’t have bridge channels to deal with. 

Flutter

At present, Flutter does not share business logic with native code adequately. The Flutter team is working at integrating it into native apps, but at this point it is still experimental. When you need to integrate native code, you need to communicate across channels, otherwise you have to code it all in Dart — a language that is not widely used or supported. And while the Dart VM is fairly fast, it’s not as fast as a fully native solution. Basically, if you don’t want to deal with interoperability issues, it’s easier to work entirely within Flutter. 

React Native

To interop with native, it has to go through the JavaScript interpreter [update: Facebook knows this is a problem and recently released their own JS engine specifically for RN apps]:, so it’s always going to lag behind more native solutions. Also, it’s costly using JavaScript to bridge to native — more costly than Xamarin or Flutter.

Xamarin

Essentially, Xamarin presents the same problem as Flutter does: no direct interoperability with native code. You have to use C++, JNI, Java, Kotlin, or Objective-C Bindings. Currently not possible to interop with Swift, you can’t share business logic with non-Xamarin apps at all, and Microsoft has no plans to do this.

Developer efficiency

KMP

Debugging is straightforward with KMP because the debugging tools you’re already using are compatible. Android coders can debug in the Kotlin IDE, and iOS coders can debug in Xcode. In the meantime, as the libraries for KMP continue to grow, you’re not locked in — just use the tool that makes sense for that ecosystem. 

Flutter

With Flutter, you need a wrapper for its libraries to communicate with native code.You can’t use Xcode for iOS development. And while you can use Android Studio, you’re not really building an Android app with Flutter, you are building a Flutter app and using the Flutter plugins. Essentially, you’re in foreign territory.

React Native

Facebook has put a lot of effort into React Native, enabling you to choose from many great debugging tools and IDEs with good integration. It has a large and growing community that stems from the web development ecosystem. Even so, you’re unable to use the native libraries as easily as you can with KMP, so you still need to put work into libraries that haven’t yet been ported and integration with existing apps. And if you aren’t already a web shop, you need to learn the whole ecosystem.

Xamarin

To integrate existing native libraries, Xamarin.iOS only supports binding to ObjC Frameworks, and Xamarin.Android requires Java Bindings or the JNI. Sometimes, you can’t bring any new frameworks from native iOS or Android into Xamarin Projects. Additionally, you need to use LLDB or GDB for debugging native code.

Making the most of multiplatform

KMP

With KMP, Android is already fully native, so a bridge is not necessary. And, on iOS, KMP compiles a native framework with Objective-C headers, so, again, a bridge is not necessary. You can easily take a mostly business logic Android library and make it work as a KMP library (even easier if it’s already written in Kotlin). And while the UI has to be separate, it’s not a problem because the UI can then be a very thin layer that’s not dependent on the business logic layer. 

– Common architecture practices like MVP, MVVM, and CLEAN already encourage separating business logic and thinner UIs.  It’s only a slight modification to accommodate the shared module layer.

Flutter

Taking an existing Android library and making it a Flutter library is a whole lot harder than it is when using KMP. Flutter is really designed to be its own self-contained ecosystem. It’s difficult to share with non-Flutter apps. And while sharing the UI is better than it is in React Native or Xamarin, you have to build your own libraries, or write in Dart.

React Native

React Native is not ideal for larger apps or larger teams, and even though the developer community is large, it’s mostly made up of web developers, and therefore not necessarily attuned to mobile development fully. There are significant differences — screen sizes, UI expectations, variable device performance due to CPU, RAM, and graphics chips variability, offline and low or unreliable network connectivity, and platform-specific innovations that have been driven by significant engineering investment from Apple, Google, and Samsung.

Xamarin

Xamarin has its own ecosystem, with a relatively small developer community, and very limited sharing with other ecosystems. You have to build the UIs in Xamarin.Forms, or you have to build them separately using C# in Xamarin.Android and Xamarin.iOS.

Potential for code sharing

KMP

Even though KMP does not share the UI, which limits how much you can share, you are able to architect the app so that the UI layer is as thin as possible, which in fact is good architecture practice anyway. And it’s also good practice to make the best UI for users, which requires UI divergence between platforms anyway. Using KMP, you won’t run into obstacles when the UIs do need to diverge. And you will more easily be able to share non-UI code with less of a performance cost.

Flutter

Flutter provides everything except platform-specific features, which require a channel to native code. So if a library you need already exists in the Flutter ecosystem, great. But if not, you need to create it yourself which essentially requires writing code for three platforms — Android, iOS, and the Flutter Package API to communicate with the platform-specific implementations.

React Native

React Native provides everything but platform-specific features or high-performance logic (making it less desirable than Flutter), each of which requires a bridge to native code. If a library you need already exists in its ecosystem, you’re set. If not, like Flutter, you need to create it yourself, which requires writing code for three platforms — Android, iOS, and the React Native Bridge Module.

Xamarin

For simple apps, Xamarin.Forms allows you to share close to 100%. But it’s not ideal for more complex apps, where a lot of UI and any platform-specific features need to be separated into Xamarin.iOS and Xamarin.Android projects.

Maximum app quality 

KMP

When coding with KMP, you get fully native UI and business logic, with the same app quality as fully native apps in iOS or Android. 

Flutter

While the UI is performant (“buttery smooth” as the Flutter dev-rel people like to say), it’s easy to end up with something that’s perceived as lower quality to seasoned users. Also, Dart VM is fairly fast — much faster than Javascript — but there are still channel overhead issues you must deal with. As well, support for older devices is not robust. For Flutter in particular, the UIs may look modern on older devices, but the performance may be worse than native UI and implementation.

React Native

On the positive side, React Native architecture encourages native views and widgets, so you don’t fall behind platform UX updates. (Users expect these; otherwise, apps start to look old to them.) There is, however, a higher risk of lower performance because of Javascript (especially true on Android devices where standard Javascript is about as performance as an iPhone 6s and Facebook recently releases their own engine specifically for RN apps on Android).

Xamarin

For Xamarin, UI is really an afterthought. Xamarin.Forms has been getting more attention recently, but even when incorporating native widgets, you end up writing a full app in Xamarin.iOS and Xamarin.Android before getting something that modern users would generally accept as good quality.As for performance, it is true, the MonoVM is fairly fast, but there are still bridging overhead issues.

Kotlin Multiplatform Tutorial: Two Apps in Less than Five Minutes with KMP

Kotlin Multiplatform Tutorial: Two Apps in Less than Five Minutes with KMP

by | Aug 15, 2019 | Future of mobile, Kotlin Multiplatform

If you’re reading this you’ve probably heard a lot about Kotlin Multiplatform, but aren’t sure where to start.

The platform is evolving fast, which means a lot of the docs are out of date, and most of the tutorials seem to walk you through setting up projects and tools from scratch. But nobody likes reading the directions! We’re going to walk you through setting up some shared code in less than five minutes.

Prerequisite: We’ll cheat and not start the clock until you have Xcode 10.3+ and Android Studio 3.4.2 installed, and have an emulator installed and running for Android.

For Xcode, find it on the Mac App Store here and install it. Not on a Mac? Well, none of this will work (you need a Mac).

For Android Studio, go here to get the app, follow instructions here to set it up, and the instructions to setup an Android emulator here. Ready? OK, now start the clock.

Let’s get started.

Clone this repository and open it in Android Studio. The project currently contains two separate Hello World applications: one for Android and iOS each. Run the Android app to see it display “Hello, Android world!”

Now, open /iosApp/iosApp.xcworkspace and run iosApp in the iOS simulator to see it display “Hello, iOS world!” Although they share a folder structure, these iOS and Android apps are separate from one another. Now we’ll join them together with Kotlin Multiplatform.

First, open /app/src/commonMain/kotlin/sample/Sample.kt, which contains the following common code:

package sample

class Greeting {
    fun hello(): String =  "Hello, Android and iOS worlds!"
} 

Next, open /app/src/main/java/sample/SampleAndroid.kt in Android Studio. It contains the Android version of the Hello World app. To make it into a KMP app, replace the value being assigned to textView.text — which is currently “Hello, Android world!” — and replace it with Greeting().hello().

Finally, go back to Xcode and open ViewController.swift. Underneath import UIKit, add import app, which is the name of the KMP library. Then, just like in the Android app, change the value being assigned to label.textfrom “Hello, iOS world!” to Greeting().hello(). Rerun both applications, and see them both displaying the same string!

“Hello, Android and iOS worlds!”

All done! Stop the clock! You’re a Kotlin Multiplatform developer now!

What are some good next steps? Try calling out to some native code with expect/actual statements, then add an existing multiplatform library like Ktor and do some networking.

If you come from an iOS background and want a deeper explanation of how to use Kotlin Multiplatform to make a more involved app, then you might want to check out this article I wrote.

As you can see, it’s all about starting small with Kotlin Multiplatform. We recently launched The Touchlab Refactory; an incremental refactoring service with KMP which focuses on a single feature at a time with no disruption to your current development workflow. Learn more here. 

Kotlin Multiplatform Can’t Do It All. Which is Exactly Why You Should Try It!

Kotlin Multiplatform Can’t Do It All. Which is Exactly Why You Should Try It!

by | Aug 15, 2019 | Future of mobile, Kotlin Multiplatform

Before I begin, I want to be clear that all tools are created to solve problems, but none of them solve all problems. If your development team is in a hurry, or high-quality UI is not a major priority, go ahead and choose an ‘end-to-end’ development platform like Xamarin or Flutter or React Native to code your app for Android and iOS. You’ll get the job done 🎉!

Now, if you already have UIs for your apps, or if you want optimized UI for each platform, you’ll want to use Kotlin Multiplatform. The reason? It doesn’t do UI at all (not yet, anyway). But what it does do — and really well — is business logic for Android and iOS apps. 

Though the other multiplatform solutions aspire to support all application layers, they can’t adequately cover them all.

And sharing UI code across platforms is not necessarily desirable anyway. Very often when this is done, there will need to be multiple iterations to make the UI look and behave more natively. This will burn through development cycles, putting more pressure on your dev teams to deliver on time. And normally, the business is pushing for more features over UI quality. Sharing UI is risky, and it’s rarely good for morale, or for business.

 

Unlike Xamarin, Flutter or React Native, Kotlin Multiplatform does not live within its own ecosystem. Instead, it is very much like a “choose your own adventure” book, which is what makes it so powerful.

While KMP currently has limited libraries (though the number is growing), it does enable you to use all existing libraries and tools on iOS and Android, so there’s no need to wait for libraries or implement hacks and workarounds. You can’t do that with Flutter or React Native without running into sizable obstacles.

The output from Kotlin Multiplatform is just another package on Android and framework on iOS. That can save a significant amount of time and headaches because there is far less time spent writing bridge code or fully re-writing the things that are missing from other solutions. 

To code business logic in Flutter, your team first has to code shared logic in a language that is not widely used – Dart – in a new ecosystem, with a smaller community, and difficulty bridging it with existing code. In React Native, your mobile team would need to immerse themselves in the web ecosystem of JavaScript’s new IDEs and other tools . And in Xamarin, they’d have to code in C# , use Visual Studio, and a smaller, less active community. To make matters worse, whichever of these platforms your team uses, they’ll need a communication bridge between native and non-native code. 

In Kotlin Multiplatform, however, your team can code the platform-specific business logic, with direct communication with the native platform, with no need to wait for libraries or implement hacks or workarounds.

(You can if you want, that’s part of the adventure you choose.) And even if there are any issues, optional sharing with Kotlin Multiplatform means you only need to revert the code directly related to the issue — no ripping out the whole engine because of a bad spark plug. So, you always have choices. 

This is important of course, because it’s the business logic that determines how all features within an app will work. Because you’re writing the native code once for this layer, you accelerate development time and help ensure a solid code base. Plus, writing one set of native code is a highly effective way of future-proofing the code for later releases.

Kotlin Multiplatform, in other words, provides your dev teams with greater flexibility.

The other multiplatform solutions are essentially proprietary, resulting in vendor lock-in. It also results in the need to manage, in effect, a third platform because the ecosystems are too different from the native platforms and, because they try to solve everything but they can’t solve everything, you will need to write more platform specific code than advertised.

Unlike Xamarin and React Native, Kotlin Multiplatform doesn’t require a VM. Flutter doesn’t require a VM in production, but it does put you in a non-native ecosystem writing in a non-native language unlike Kotlin Multiplatform which respects the native languages and ecosystems of each platform. Kotlin Multiplatform is the most native multiplatform solution your team can use today. 

KMP doesn’t hide the fact that you’re dealing with multiple platforms because it already compiles to a native library for iOS or Android.

There are no intermediate layers to deal with, virtually eliminating any interop bottlenecks. And since Kotlin Multiplatform works with the native platform ecosystems rather than becoming its own, devs can use the tools and libraries they’ve always used including new platform innovations like SwiftUI and Jetpack Compose. Limitations you do encounter are not dead ends because you can always code around them with Kotlin, Swift, or whatever language lets you solve the issue with the least risk.

In sum, here’s how we measure the world of multiplatform solutions. Next week, we’ll share more details about the specifics of our rankings. In the meantime, if you’re interested in speaking to us about Kotlin Multiplatform, please contact us.

 

Measure multiple cross-platform development solutions