Kotlin Multiplatform: From “Hello World” to the Real World
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 542 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/61871 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Form (programming)Moment of inertiaMultiplicationComputing platformTouch typingExpert systemMobile appSoftware developerProduct (business)Degree (graph theory)QuicksortCross-platformSheaf (mathematics)MereologySampling (statistics)BitMultiplication signComputer animation
01:47
MereologyDifferent (Kate Ryan album)Computing platformFamilyFormal languageDiagramDirectory serviceSource codeMultiplication signSoftware developerTerm (mathematics)Cross-platformLine (geometry)Mobile appNP-hardLibrary (computing)Universe (mathematics)QuicksortWordShared memoryoutputCASE <Informatik>Focus (optics)Control flowMathematicsCodeStability theoryBeta functionAndroid (robot)Graph coloringBitSubset
05:52
Computing platformMultiplicationLibrary (computing)Android (robot)Revision controlString (computer science)Computer virusBitTemplate (C++)Projective planeMobile appSoftware developerLibrary (computing)Plug-in (computing)Data structureMobile WebComputing platformInterface (computing)Cross-platformINTEGRALChainData managementoutputCodeSocial classImplementationDefault (computer science)Functional (mathematics)EmailFormal languageCartesian coordinate systemBuildingAndroid (robot)Computer fileSoftware frameworkSource codeCuboidMereologyDifferent (Kate Ryan album)MultiplicationComputer animation
10:07
Axiom of choiceComputer architectureStandard deviationBitSampling (statistics)Software development kitLibrary (computing)Computer animation
10:45
Sampling (statistics)Mobile appMultiplicationProjective planeModule (mathematics)outputMultiplication signBuildingShared memoryQuicksortProcess (computing)Computer animation
12:33
Real numberQuicksortComputer animation
13:01
Data structureRepository (publishing)Shared memoryCodeData structureNumerical taxonomyFlow separationQuicksortProcess (computing)Mobile appDiagramoutputLibrary (computing)Direction (geometry)CodeRepository (publishing)Software developerMereologyGroup actionExecution unitDimensional analysisDifferent (Kate Ryan album)Streaming mediaCore dumpComputer animation
16:09
Data managementComputer configurationMathematicsTask (computing)Different (Kate Ryan album)Software frameworkArithmetic progressionoutputDataflowCodePlug-in (computing)WritingBinary codeSoftware developerRevision controlComputer animation
17:20
Binary codeInterface (computing)Menu (computing)DebuggerMobile appProjective planeBitRoboticsNamespaceDeclarative programmingSoftware frameworkImplementationModul <Datentyp>CodeCrash (computing)Default (computer science)Data structureDifferent (Kate Ryan album)outputForcing (mathematics)Data storage deviceFlow separationModule (mathematics)MultiplicationScaling (geometry)DebuggerInterface (computing)Common Language InfrastructureSoftware developerIntegrated development environmentMultiplication signQuicksortDatabaseSystem callAnalytic setProgram flowchart
21:33
CodeComputing platformMobile appTranslation (relic)BitService (economics)Shape (magazine)Computer animation
22:18
Software developerAdaptive behaviorData structureMultiplication sign
22:55
Multiplication signComputer animation
23:18
Program flowchart
Transcript: English(auto-generated)
00:05
Hello, everyone. Hello, again. So we are going to resume. If you are in the back, please come in. We have seats in the front. And please make sure to make yourself comfortable for this next talk, where I have the pleasure to introduce Russell.
00:20
So Russell is coming all the way from the USA to be with us today. He works at Touch Labs, knows everything about Kotlin Multiplatform. And today, he will tell us about from hello world to the real world. Yeah. Thanks a lot. Yeah, I'm here from Boston, where it's actually like negative 24 degrees Celsius today.
00:41
So I'm all right with the rain. And yeah, my name is Russell Wolf. I'm a Google Developer Expert for Kotlin. And I work at Touch Lab, where we do all Kotlin Multiplatform all the time. So I'm going to talk a little bit about taking your Kotlin Multiplatform from the basic kind of hello world
01:03
sample that you might start out with to the sorts of things that you might need for a production Kyle app. And I've been part of the work at Touch Lab. I've been doing Kotlin Multiplatform things since pretty much day one. In a couple of weeks, it's going to be five years since I wrote my first Kotlin Multiplatform
01:21
code, which is kind of cool. I don't know. It hopefully means I know something about what I'm talking about. But you can let me know. So let's get started. So quick introduction to Kotlin Multiplatform. And I'm kind of breaking up the talk
01:43
by the sections of the title. So I started with Kotlin Multiplatform. So Kotlin grew up initially as a JVM language. But it also has back ends on JavaScript and native.
02:02
And all of these are actually kind of families of platforms where JVM includes Android, native includes all sorts of different targets. And Kotlin Multiplatform adds not just the targets themselves, but the ability to share code between them. So you have platform code that runs on a particular target.
02:22
And then you have common code that runs on all of them or runs on combinations of them. And what this enables is a really nice kind of flexible interop, where you can share the parts of your code that make sense to share,
02:44
but you have the ability to drop into platform-specific code for things that you don't want to share. And it lets you treat your shared code as basically just another library. So you can be writing an otherwise fully native app and share just a piece of it between your different
03:02
platforms. So a couple words on KMP versus KMM. So KMP is Kotlin Multiplatform is the kind of whole universe of all the different things that Kotlin can target. KMM is Kotlin Multiplatform Mobile, which is the mobile part of that story, which
03:21
is the first piece that JetBrains is stabilizing. So that's the thing that they announced is in beta. There's not really a hard technical line between them, because KMM in the end is just parts of KMP. It's just kind of working on the same technology stack.
03:41
But in terms of what they're focused on for the developer experience, KMM is kind of the piece that's coming first. And yeah, as I mentioned before, it's recently moved into beta. It's planned to go stable this year. So it's a really good time to get into it,
04:01
start using it if you haven't yet. And what beta means to JetBrains can be a little bit different than you might be used to from other projects. Like they're very slow about designating things as stable. They want to be absolutely sure of every little detail. But even by calling it beta, they're
04:22
very strongly committed to keeping things working. They're just saying there might be some breaking changes in the future. And to kind of break down how Kotlin Multiplatform Code works, I like to use this kind of Venn diagram and focus on the mobile use case.
04:40
So we're talking about Android and iOS. So if you're an Android developer, you're used to this sort of diagram. You have access to all the Kotlin APIs you're used to. You have access to JVM and Android APIs. And there's a subset of that, just the pure Kotlin stuff,
05:03
that in principle you can run on any platform, which then means you can take that over to the iOS side. You can also add some iOS platform-specific code. So you have kind of your shared bits and your platform bits.
05:24
And the K&P toolchain brings all of that together so that essentially each of these different colors on the diagram are just a different source directory. And the toolchain knows how to kind of put the right parts together so that you get the right code for your platform.
05:42
And again, there's more to K&P than just K&M. But the eight-way Venn diagram of everything is a lot more complicated to draw. So what does it look like when you're writing your first Hello Worlds in Kotlin Multiplatform?
06:02
And one way to get that is to start with the Kotlin Multiplatform mobile plugin for Android Studio. So you can do a lot of this stuff. I tend to use IntelliJ IDEA more than Android Studio when I'm doing my K&P development.
06:21
But the new project template in Android Studio is a little bit easier to get started with. They have these Kotlin Multiplatform application or Kotlin Multiplatform library. And what they give you is some code that looks kind of like this.
06:41
And don't worry about every little detail of it. But this is kind of like the Hello World template that it generates for you. So there is a platform interface in the common code. So the common code is in the center here. The Android is on the left. The iOS is on the right. So there's a platform interface that's
07:02
implemented on each platform as Android platform and iOS platform. There is a expect function. So expect an actual or two keywords that Kotlin Multiplatform adds to the language that essentially let you declare something in your common code but implement it in your platform code,
07:24
essentially almost like a header. Actually, they used the header keyword for it before Hello World was released in 2017, 2018-ish. And so there's an expect function
07:42
that lets you get a default platform that has actual implementations on each platform. And then there's a greeting class that just brings it all together and prints the name of the platform that you're on. And this gives you a little playground to start messing around with Kotlin Multiplatform code.
08:02
And I actually really like the way that they use expect actual in here. It's very easy when you have this new tool starting out with Kotlin Multiplatform to kind of overuse it. I mean, you start making all these expect classes and things like that. I tend to find it's really nice to hold on to interfaces
08:23
as well. So when you define an interface platform rather than an expect class platform, you can substitute other implementations a lot more easily. And so this is kind of like a rough sense of the code
08:40
structure that you get from this template. So the code that I showed you is kind of those bottom three boxes. So there's common code in the middle is the orange. There's Android sources in that that you then compile to an Android library. There's iOS sources that you then
09:00
compile to an iOS framework file. And then if you used one of the application templates, it'll look at you in app layer. That consumes that. There's multiple ways that you can configure the iOS app to consume it. So you can, essentially, there's different dependency managers
09:23
that you can use in iOS. There's a default that's just kind of manually include the framework. You add a custom build step into Xcode that will call into Kotlin and do that. There's also a plug-in that's part of the Kotlin tool
09:43
chain that uses CocoaPods. So CocoaPods has historically been a commonly used dependency manager on iOS. It's, these days, starting to be replaced by Swift package manager. But the Kotlin tool chain doesn't
10:01
have as good of integration into SPM yet. And then I'll also just call out, we at TouchLab have a sample called kit that can also be a nice place to start out if you're playing with stuff for the first time.
10:24
It's a somewhat more complicated sample than that Hello World. It has a bit more architecture to it and shows some of our standard architecture and library practices. And also has a bunch of documentation explaining
10:40
why we make some of the choices that we do. So check that out also if you're interested. So what are some common themes around these sorts of starter projects? And there's a lot more than just those two, I should say, also. There's lots of people out there that have put together interesting Kotlin multiple
11:03
from samples that you can use when you're first learning. And something that comes up often in a lot of them is they tend to aim at maximizing shared code, which like in an ideal world is really nice. In the real world, oftentimes you're
11:23
starting from two separate native apps and you want to incrementally move towards more shared. And you don't always get a good sense of what that looks like from any of the standard samples. Things also tend to be monorepos when you're looking at starter samples.
11:42
So what if I already have existing apps? They live in different places, but I want to start sharing code between them. What does that look like? A big piece of a lot of them is there will be some step in your build process in iOS where Xcode has to kind of exclusively call
12:03
into Gradle to build your Kotlin. But if you're on a larger team, you might not want to have to do that every time. Your iOS team might not even have a JDK set up if they're not used to using that. So what do you do in that case?
12:23
And they also tend to be single module when you're looking at sample projects. But what happens when things get bigger? So that brings us to, yeah, what does it look like when you take all these sorts of things
12:41
and start scaling it up to real world projects? And I'm going to talk about some of the ways that we tend to think about this at TouchLab, as well as some tools and things that we've put out into the community to help out with some of these things.
13:03
And the first thing I want to talk about is team structure. This is something we've been talking about a lot internally at TouchLab recently, and kind of building out this sort of taxonomy of different ways that different teams approach the way that they handle their shared code.
13:22
And a common kind of core piece of that is being thoughtful about the ways that the structure of your team impacts the way that you want to organize your code. Because lots of teams are very different. So the distinction I'll kind of highlight here,
13:45
and it kind of works across a couple of different dimensions. I tend to think of it as kind of small teams versus large teams. But it's also sometimes teams that work kind of as one unit versus teams that work as multiple units.
14:01
And a key piece of that is often is the group that is writing the shared code the same group as the people who are consuming the shared code. So when you're a smaller team, or if you're one unit, you tend to have kind of fewer worries about who's owning what parts of the code, you're more kind of unified
14:24
in what your developer setup looks like, and you're more likely to be in a situation where you're kind of sharing a higher percentage of things and just kind of wrapping a thin UI around it. And you're more likely to be doing all of your feature development kind of at once for both platforms.
14:42
On the other hand, when teams get larger, things get a little bit messier. You're more likely to have iOS specialists who don't want to kind of deal with the Kotlin directly. And your Kotlin code, you're more likely to have a larger iOS app than just what
15:03
the Kotlin is. And so your Kotlin is just kind of one more thing in a sea of other native libraries that your iOS is using. And you tend to want to minimize the impact of your Kotlin on the rest of the iOS code.
15:21
And what this often means in practice is you want to kind of, rather than linking your Xcode build to your Kotlin directly, you want to kind of publish it as an external library.
15:41
And so the diagram that's why I showed you that kind of diagram on the left earlier, the way it can look like in a larger team is rather than directly consuming things, your shared code is being published to some sort of artifact repository. And then your apps are pulling that artifact down. And there's kind of more of a two-step process
16:01
to making updates, but it lets you kind of work in separate streams more easily. And we put out a tool to help with this in the fall. We touched lab. It's called KMM Bridge, and it's
16:20
a Gradle plugin that can essentially manage the publishing of your iOS framework in a couple different ways. So it gives you a Gradle task to publish a new version when you've made changes. It has options around how you implement that version and things like that, options for where you want to host that binary and the ability to plug in your own.
16:42
And then some helpers, if you're using a package manager for making that local development flow a little bit easier. So sometimes you want to be able to toggle between using the binary that you pulled down versus building it directly when you're trying to write new code or debug it.
17:03
So we have some helpers to make that flow a little bit easier. There's a bunch of little things that are still kind of a work in progress on here. If you're a team that's interested in using it, we'd love to talk to you and get some feedback. So feel free to find me and let me know if you want to learn more about that.
17:23
Another problem that comes up at scale is modularization. So when you write a hello world, it tends to be one module. But when you're writing bigger things, you might want to have more than one. And Kotlin Native, it turns out, makes this a little bit complicated. So when you have multiple Kotlin Native modules
17:42
and you export them to iOS, they're essentially their own kind of separate worlds. And so each of these modules has its own copy of any internal dependencies, their own copy of the standard library, its own copy of any third module that you might have underneath them that you're trying to share between them.
18:01
And they can't kind of talk between each other very easily. And this can be okay if they're doing very distinct things. So maybe one of them is making analytics calls and one of them is running your database and they don't really need to interact with each other. And then having them separate can be okay.
18:23
But often you end up wanting to kind of write this umbrella module on top of them so that in your Kotlin layer, you can have them talk to each other more easily and then you have sort of a shared module on top that you export as your iOS framework. And that lets you more easily,
18:41
that lets you have that more typical kind of modular structure while working with the Kotlin native implementations. There's still some that's used to this because your umbrella framework will have, you have kind of namespace clashes where all of your declarations in here
19:03
are essentially in one giant global namespace. And there's robot tickets that will improve this, but right now it can be a little bit messy when you have a lot of code in there.
19:24
Another thing that comes up in real projects is your binary size. So hello world tends to be small, real apps tend to be larger. And real apps have consequences when things are too large where things like the app store will throttle
19:41
your downloading or force you to do it on wifi rather than on mobile if your app gets too big. And this can be a significant impact to the amount of downloads that you get. And it turns out one of the biggest contributors to this is the Objective-C interface that Kotlin native uses to export your code to iOS.
20:04
And the kind of trick to use here is you want to limit the amount of public declarations that you have in your Kotlin code. And that will shrink that Objective-C interface because it only needs to be generated for public declarations. And that hidden from Objective-C annotation
20:22
that Marco mentioned earlier can also be a way to do that. Or there's kind of different monetization structures you can sometimes use. So I'll mention quickly a couple other tools that Tossed that puts out that can be helpful
20:41
when you're writing larger apps. So by default the crash reporting that you get out of Kotlin native doesn't kind of export to Swift very well. So we have this tool called crash-chios that will essentially symbolicate your stack traces better. We've done some, we have some updates to that in flight
21:02
that will kind of clean up different pieces of that story, but I'm not gonna go into detail there because I'm getting kind of low on time. And we also have a code debugger that lets you debug your Kotlin code from Xcode, which can be a nicer environment for your iOS developers when you're kind of introducing that.
21:22
That recently to be a CLI based interface which makes it much easier to update and install. So if you've tried it out in the past, feel free to give it another look. One of the nice things I want to talk about is kind of the shape of your API service.
21:45
So hello world apps tend to be small, but as your app gets bigger, you start to care more and more about what sort of the, how idiomatic is your API? And Swift and Kotlin tend to want slightly different things with that.
22:01
So I just want to point out, don't be afraid to kind of need a bit of translation layer between your shared code and your platform code. And we have some tooling that we're working on to make some of that easier, but it's not in the open yet, so I'm not gonna go into detail there.
22:20
I'll skip the example because I'm running out of time. But kind of the overall lesson that I want to highlight is different teams and have different structures and want slightly different things. Kotlin is all about adaptability. And so if you're a team that wants to share
22:41
a lot of code, you can do that. If you're a team that wants to minimize the impact of the Kotlin on the rest of your development team, you can do that. And you have the flexibility to kind of choose the way that you want to approach all of that. So thanks, I think I'm probably out of time for questions.
23:00
But I'm definitely happy to answer stuff in person. Feel free to tap me on the shoulder, find me whatever later today. If I'm staring at my laptop, it's not important because it's Saturday. So I'd love to chat. Thanks.