Kotlin Multiplatform

Editor's Notes

• #3: Twitter lessons about intros. Also, a lot of bad people on twitter don’t credit sources.
• #5: For context, we also run Droidcon NYC and the big android dev meetup in nyc
• #6: I’m technically the President of Touchlab, but have largely stepped back from day-to-day so I can focus on research and traveling around and speaking. I caught the efficiency bug in 2015 researching cross platform for a project that really should’ve had it. Briefly, we got a tiny bit of money to produce the Android version of Apples ResearchKit, which is an open source medical research framework for building medical research apps, which is great if you’re OK self-selecting only iPhone owners. I won’t get into the demographic politics involved, but short version, there should be equal access for these things. We’re long off that project, but I’m still researching.
• #9: Plenty of other Kotlin talks
• #10: Largely designed for JVM, but also has JS and Native targets (not to scale, obviously)
• #11: Shared code is “common” code. That gets rendered to the various targets. JVM (what everybody knows), JS (functional but we’ll see), and Native. Native is iOS, but also linux, windows, various other platforms: basically anything LLVM reachable. Notably webassembly as well.
• #12: Take a little detour and talk about big picture.
• #13: First off, the discussion around “cross platform” is broken. Native developers who haven’t done much outside of native development, and at a “native conference” you’ll find a lot of that, tend to have a pretty binary worldview. Assume this is native. Then this
• #14: is what “not native”, aka “cross platform”, often looks like in discussions. It feels like this. I don’t do cross platform, I think cross platform has some appeal. Have you heard about flutter? After a few blog posts and a tutorial app, one tends to develop a more nuanced view…
• #15: There’s some more nuance, but its still kind of a surface understanding. In August 2018, that basically means you read the AirBNB post about React Native, and base your worldview on that.
• #16: I have been doing this for several years and have developed a much more nuanced view of things. The assortment of tech is wide and the technologies are super different. Talking about “cross platform vs native” kind of doesn’t make sense. There’s a lot of stuff out there, its becoming mature, and I think the days of 2 native code bases plus the web are numbered (to some degree). Useful to understand the ecosystem. Also, if there are any motorhead folks here, just for the record…
• #17: Direct quote. Anyway…
• #26: It’s a noisy space. TL;DR The debate is generally not well informed.
• #27: What we really need is something like this. Big tech taxonomy. React Native, Flutter, and Kotlin Multiplatform are vertebrates, but one’s a bird, one’s a dog, and one’s a fish. Speaking of flutter, though, if its done anything, its made it socially acceptable to talk about this stuff at Android conferences.
• #28: You can summarize the benefit as adding significant efficiency without really introducing risk. If you know my background, these are all also why we did doppl, and why these two piece of tech are very similar. All dogs aren’t the same, though
• #29: One tech has one kind of flavor,
• #30: The other has another, but if we’re going to completely kill the analogy, KMP is currently
• #31: KMP still a puppy and needs some training
• #32: Predicting the future is difficult. Flutter? PWA? Stay native? Next year? 2 years? 10 years? I have no idea. If somebody tells you they know, they don’t. There are too many really smart people with wildly different opinions to make any predictions.
• #33: Portable, sharable architecture, with a first class language, is great. I think saying you could build your stack with Kotlin, right up to the UI, and still have that be viable in a decade, is an easy bet. You’d still have great tools, be able to hire, have a community, etc.
• #34: Go watch Jack’s talk about blurring the lines between native and the web from Droidcon berlin. As a summary, chrome is increasingly able to deliver native integrations, and add in webassembly, the world is going to blur. With KMP, architecting this isn’t a big decision and binary. You can change UI without completely rethinking everything. Where UI goes in the next decade is a different discussion. Certainly not today. Anyway, my talk at berlin was highly related.
• #35: He also called me out because I’m the only person he knew who used to go around talking about J2objc at conferences. So I’m famous.
• #36: That’s it for the big picture detour. I can rant on that for hours, and I have several videos and blog posts if you’re curious.
• #37: So, back to Kotlin MP. Common code can be rendered to platform code by way of the Kotlin gradle plugin.
• #38: The end clients can consume this output and use it like any other library in their code.
• #39: We’re going to just focus on native mobile from this point on, though. The key to both of these is that they aren’t “everything” tools. They don’t require exceptional inclusion, by which I mean to use “native” features you have to jump through hoops.
• #40: Your Android app is just referencing another gradle dependency, and the iOS side is just calling into another Framework, from either Swift or Objecitve-C. The digram looks a little busy, but it’s a natural interaction. We’ll look at some code in a bit.
• #41: Common code by itself has a lot of logical classes, but is pretty unaware of the outside world otherwise. It lives in a world where there may or may not be threads, may be in a phone or an embedded device, a server, etc. Rather than making platform interactions an exception, KMP explicitly provides a mechanism to do this
• #42: Say you wanted to find out if you’re in the main thread. Kotlin went pretty lean out of the box, so you’ll need to add this yourself. To do this, you’ll use an expect/actual property
• #43: Write an ‘expect’ property. You can call this from common code, and provide the implementation in your platform specific code
• #44: For Android, check if your looper is “the” looper
• #45: For iOS, call isMainThread. And just for completeness, if in JS, it would look like this
• #46: JS has no threads :)
• #47: In the Droidcon app, as development progressed and we needed a new function, just added it
• #48: Can do classes with expect. Kotlin common has no ‘Date’ functionality, so we added bare minimum for Date and DateFormat.
• #49: On Java, Date delegates to a java.util.Date. Formatter to “SimpleDateFormat”. iOS has a similar equivalent.
• #50: If the type signatures match up exactly, you can do a typealias for the actual side. We wrote the sqlite database driver for K/N, and used typealias to cut out a lot of extra code
• #51: If the type signatures match up exactly, you can do a typealias for the actual side. We wrote the sqlite database driver for K/N, and used typealias to cut out a lot of extra code. On the iOS side…
• #52: The iOS sqlite driver is ported from AOSP, so we were able to do this on the iOS side as well
• #53: Obviously a lot more to the topic, but that’s how common/platform works. When the tooling is complete, its pretty smooth. Right click to add stuff…
• #54: One of the main reasons why KMP is going to be successful is Jetbrains and its tooling. The code comprehension is air tight, and the interop is super productive to code and performant.
• #55: Some things I find easier to pass in. An alternative to expect/actual is to define a lambda arg. Here we pass in a lambda to load a static file, for loading seed data.
• #56: On Android app startup, pass in a lambda to load a file string from assets
• #57: Swift is similar. You could shorten this to an anon function, but I’m not as nimble with Swift yet. In any case, this is easier than trying to do the bundle stuff in Kotlin
• #58: Gradle is similar to what you’re used to. This is from Droidcon. Kotlin has a common plugin.
• #59: Dependencies are standard ‘implementation’. This syntax is a little odd, but it’s all the 3-part strings you’re used to, defined in a central file.
• #60: Each “real” platform has a corresponding plugin.
• #61: Special note here. The “expectedBy” config points at a dependency that defines ‘expect’ artifacts, and this platform’s code will be expected to implement them. It’s pretty simple in practice.
• #62: There’s a whole bunch of odd config you’ll need to wrestle with for Native, but welcome to software development.
• #64: It’s not quite “1.0”, but is very stable. You could put this into production stuff now, but you’d need to know what you’re doing
• #65: There’s still quite a bit of confusion around tooling. Originally K/N was going to be CLion. Intellij doesn’t “see” kotlin in a native module, so that smooth expect/actual only works for JVM. Obviously they’ll address that, but in what form? Assuming Kotlinconf
• #66: Build speed isn’t great. Android side is pretty much normal android, but native can be slow. Expect optimization after release. Actual running speed is pretty great. Also, interop layer is not like JNI. It’s direct. That will be a major advantage over other options
• #67: This is the big thing now. There aren’t many
• #68: KNarch.db was mostly written by me, and is published and supported by Touchlab. It is a SQLite stack driver, an analog to Android’s sqlite stack for iOS, written in Kotlin native. It is…
• #69: A kotlin port of AOSP’s Sqlite Java stack,
• #70: A port of the C++ underneath that, but in K/N’s JNI analog, and
• #71: A port of the relevant CTS suite to verify functionality. There’s also the multiplatform layer, which I showed part of before in the typealias slide. This lib is going to have a review once coroutines are final, as I think there are some significant optimizations that can happen, but we’ll see.
• #72: Alec Strong from square rewrote all of their source gen to write out to Kotlin. This is a heavyweight ORM framework, and this new version is fully “common kotlin”. There is, however, no iOS driver, which is basically what we’re doing with KNarch.db. If you’re buliding an app in the near future with a database, this is almost certainly what you’re using
• #73: Rather than write classes that generate sql, sqldelight goes in the other direction. Write sql, which generates classes. It is capable of some pretty complex sql.
• #75: Russel Wolf wrote a multiplatform settings library, which we’re also using in Droidcon. It delegates to sharedpreferences on android and NSUserDefaults on ios.
• #76: The core library is very clean and clear about what it’s doing.
• #77: If you want to see all of this kind of come together in a unified whole, look at the Droidcon NYC app. It’s on github. We use all of this stuff to make an app on ios and android. Also
• #78: There’s some UI smoothing that could be done. For the most part, I wrote both, as everybody else is doing actual client work, and I’m not UI expert on either. However, all the data is sqlite, we using the json serialization pretty extensively. The threading and data plumbing all happen in kotlin in shared code.
• #79: I’m also making Droidcon NYC into my own little cross platform summit. This is certainly the most Kotlin multiplatfom talks in one place to date.
• #81: I’m especially curious about OKIO on multiplatform as they haven’t released anything yet, but see how it goes!
• #83: Jetbrains is providing the bulk of the libraries in the near future. JSON, networking is nice. The big, big thing is coroutines. Please do not let the lack of screenshots fool you. The stuff coming out of Jetbrains is going to be the bedrock of this ecosystem. All waiting on coroutines. Coroutines, if you aren’t super aware, is a lot more than async/await. Its really amazing, and will have a pretty big impact on how we code stuff. Anyway, lets talk about the elephant in the room.
• #84: Threads in Kotlin native are very, very different than what you’re used to. K/N was not designed as “Java on iOS” as opposed to, say, J2objc. To facilitate simpler memory management and thread safety, they made some decisions that are very different from what you’re used to in Java
• #85: It’s all about state. There are 2 types of state. Regular and Frozen. How do you know which is which?
• #86: We’ll provide a simple rule
• #88: It’s not just “immutable”. You’ll get runtime throws when you try to do anything to it. This can be difficult to debug in large object graphs, but they’re producing better debug output. Why do this?
• #89: This is a regular object graph. There’s no GC, so to manage memory, there’s a reference counter and a cycle checker. In a normal situation, when a parent changes, you need to rip through the graph and check everything.
• #90: Freezing applies to an object and it’s referenced graph. Once frozen, the runtime can make assumptions about the children (ie, it doesn’t have to walk the tree anymore). Why do you need to freeze for threads? Frozen reference counting is atomic. Regular is not
• #92: Reference counting is atomic for frozen, but not for normal.
• #93: Reference counting is atomic for frozen, but not for normal.
• #94: What does that mean? Leaks, crashes. I spent weeks trying to outsmart the system. Don’t do that.
• #95: You can’t use multithreaded coroutines. Everybody is waiting on that. Hopefully in the next few weeks. Certainly way before Kotlinconf, but we’ll see.
• #96: For droidcon ios we did a really simple expect/actual, and basically freeze everything. Works pretty good in practice
• #97: For reactive data queries, there’s a simple iOS implementation of LiveData. Can observe db on android and ios.
• #98: The threading in Droidcon works, but is definitely not at the level things will be when coroutines come out. Much, much better implementations coming. Very, very excited about coroutines!
• #100: KotlinConf! Probably v0.9x release, but could be “1.0”, just to make people comfortable. Hopefully fully baked threading. Expect several other libs from Jetbrains, and some community announcements. BTW, if you are working on anything, ping me because…
• #101: I’m talking about ios architecture and multiplatform at Kotlinconf! No pressure. One of those situations where the people who made the stuff you’re talking about will be watching you talk about it.
• #102: Expect significant tooling announcements, as well as some more future direction plans.
• #103: Post Kotlinconf, we’ll definitely see a v1, plus significant library work as threading and tooling issues should be largely resolved.
• #104: Expect major libs that we’re accustomed to in the mobile world. Reactive, date/locale stuff. Significantly improved tooling, and effort towards faster builds, CI integrations, etc.
• #105: Mainstream. Lots of tutorials, really great tooling, start of the serious wasm stuff (maybe). Maybe pushing more into the UI layer. I’m just guessing now, but you’ll absolutely be able to be productive building mobile and will see a lot of stuff published.
• #106: If you want to get involved in open source, this is a great time. Here’s what the Android db library ecosystem looked like in 2010.
• #108: I used to know all of them. I just google this. Bananas. How easy do you think it would be to have an impact on sqlite in Java/Android 2018? I wrote the original port of ormlite, not even ormlite, and it is definitely on multiple things on every one your phones, and I spent a few weeks total on that.
• #109: Now is the time to get involved. You can have a big, big impact.
• #110: Also need to do outreach to the ios community to work on libraries and the ecosystem together!
• #111: We are, of course, actively looking for orgs that want to start doing this soon. We are also hiring soonish for people really invested in multiplatform development. We as an org have fully turned in this direction. Follow me on twitter and check out my medium posts to get a better idea of what I’m talking about. I will tweet out much more info later today and/or over the weekend as a follow up. And come to Droidcon NYC!
• #112: Discount code AndroidSummit. Ticket prices go up Monday, so don’t wait!