Upgrade to Pro — share decks privately, control downloads, hide ads and more …

KotlinConf 2023: Kotlin Mobile Multiplatform for Teams

KotlinConf 2023: Kotlin Mobile Multiplatform for Teams

Touchlab has spent the past few years integrating KMM into various apps. The most simple observation we've taken away from that experience is that different teams approach KMM in different ways. What works well for small teams may be different than for larger teams. What works well for greenfield apps may be different than for existing app projects. In this session, we'll cover these different integration approaches. We'll also discuss tooling options, iOS-side API design tips, developer workflows with shared code, and some thoughts on how to present KMM to a team that may not know it needs it (yet!)

Kevin Galligan

April 14, 2023
Tweet

More Decks by Kevin Galligan

Other Decks in Programming

Transcript

  1. Kotlin Mobile for Teams
    Kevin Galligan 4/8/2023
    ready for production

    View full-size slide

  2. Welcome to Kotlin Church

    View full-size slide

  3. Introduction

    View full-size slide

  4. Kevin Galligan
    Founder/Technical Partner


    Touchlab


    Kotlin GDE

    View full-size slide

  5. Touchlab & Kotlin Mobile
    • iOS Native in 2017


    • First production apps in 2018


    • Fully dedicated to KMP in 2018


    • Directly built several apps


    • (Commercially) advised several
    more


    • (Community) advised 101
    our background

    View full-size slide

  6. Different Teams
    di
    ff
    erent approaches

    View full-size slide

  7. Shared code “modes”

    View full-size slide

  8. (Sort of) Complexity/
    Sophistication models
    don’t think of them too linearly

    View full-size slide

  9. Mode 1 - Shared Module

    View full-size slide

  10. Mode 1 - Shared Module
    AKA SDK-
    f
    low

    View full-size slide

  11. Android
    Shared
    Kotlin
    Xcode
    Framework

    View full-size slide

  12. Rather Complex
    need production Android, iOS, and Kotlin con
    f
    iguration
    experience

    View full-size slide

  13. Why KMMBridge Exists

    View full-size slide

  14. Mode 2 - Shared Architecture

    View full-size slide

  15. Individuals and smaller teams
    “Everybody builds Kotlin”

    View full-size slide

  16. Stock Kotlin

    View full-size slide

  17. Pros
    • Everybody gets exposed to
    Kotlin


    • Can more easily edit, debug,
    etc


    • More code shared, up to the
    screen
    Cons
    • Many iOS teams do not want to
    experiment this way


    • Can have a signi
    f
    icant,
    negative impact on iOS tooling


    • Feature dev harder to
    coordinate as teams grow

    View full-size slide

  18. Mode 3


    OPTIONALLY SHARED UI ™

    View full-size slide

  19. Shared UI == Failure!

    View full-size slide

  20. Shared Logic == Computers

    View full-size slide

  21. People remember this

    View full-size slide

  22. Not UI
    well, not necessarily UI

    View full-size slide

  23. Nothing is prime time (yet)

    View full-size slide

  24. Nothing is prime time (yet)

    View full-size slide

  25. Photo @antonarhipov

    View full-size slide

  26. Compose UI on iOS
    did Droidcon last year

    View full-size slide

  27. Other Examples

    View full-size slide

  28. Redwood/Treehouse
    See Jake’s talk a bit later

    View full-size slide

  29. SwiftUI run by Compose
    we’re experimenting

    View full-size slide

  30. OK. What’s “optionally”?

    View full-size slide

  31. 80/20
    mostly native UX, mostly shared code

    View full-size slide

  32. Apple Health
    Main Feed Settings

    View full-size slide

  33. Android - 100
    Everything is Kotlin. Everything is “native”.

    View full-size slide

  34. iOS - 80/20
    Shared architecture and some UI

    View full-size slide

  35. Possible with “other” tech?
    Yes, but “possible” and “designed for” are not the same.

    View full-size slide

  36. We’re excited about this
    Lot’s to
    f
    igure out

    View full-size slide

  37. Shared UI is Hard
    but done well?

    View full-size slide

  38. Optionally Shared UI is a better
    cross-platform
    (if successful) this will be a default option in a year

    View full-size slide

  39. Photo @sebi_io

    View full-size slide

  40. (More on the future later…)

    View full-size slide

  41. Mode 4 - Shared Everything

    View full-size slide

  42. Not discussed
    basically Flutter

    View full-size slide

  43. Compose UI and tooling will
    make this possible
    but, to me, the “optional” potential, even if not used, is
    important

    View full-size slide

  44. Zero Sum?
    (not scienti
    f
    ic, obv)

    View full-size slide

  45. UX Complexity/Sensitivity
    2014 Not-Native
    Native

    View full-size slide

  46. UX Complexity/Sensitivity
    2018 Not-Native
    Native

    View full-size slide

  47. UX Complexity/Sensitivity
    2022 Not-Native
    Native

    View full-size slide

  48. UX Complexity/Sensitivity
    The boring middle Not-Native
    Native

    View full-size slide

  49. UX Complexity/Sensitivity
    2026? Not-Native
    Native

    View full-size slide

  50. Zero Sum?
    Kotlin vs Flutter?

    View full-size slide

  51. Kotlin, Flutter, RN, etc vs Native

    View full-size slide

  52. Integration Approaches

    View full-size slide

  53. How to integrate Kotlin iOS?
    of course…

    View full-size slide

  54. Depends on what?
    ๏ Team Size


    ๏ Repo Organization


    ๏ KMP Experience


    ๏ iOS team “acceptance”


    ๏ Tooling


    ๏ Time (next year di
    ff
    erent than last year, 5 years from now, etc…)

    View full-size slide

  55. Smaller Teams
    • Generally more
    f
    lexible


    • Can “rip o
    ff
    the band aid” more
    easily


    • Less institutional inertia


    • Work through “interface”
    issues


    • Modes 1+ (possible)

    View full-size slide

  56. Larger Teams
    • More coordination issues


    • More inertia/risk averse


    • Specialized dev focus


    • More politically “entrenched”


    • Mode 1 to start (and maybe
    forever)

    View full-size slide

  57. New Apps
    • Fresh start


    • Pick architecture, CI, etc


    • Monorepo (if you want)


    • More
    f
    lexibility with options

    View full-size slide

  58. Existing Apps
    • Lots of existing code


    • Maybe multiple repos


    • CI is “robust” (AKA complex to
    change)


    • Existing procedures


    • Existing test coverage (or lack
    thereof)

    View full-size slide

  59. Everybody can do Mode 1

    View full-size slide

  60. Versioned SDK - Pros
    ๏ Minimally disruptive to the iOS team


    ๏ No extra tooling


    ๏ Don’t need to learn Kotlin


    ๏ Start small and “prove” the technology


    ๏ Versioned SDK unlikely to break builds

    View full-size slide

  61. Versioned SDK - Cons
    ๏ Limiting to shared e
    ff
    iciency


    ๏ iOS never gets “ownership”


    ๏ Slow feature and bug-
    f
    ix cycle


    ๏ “Unwelcome Guest”

    View full-size slide

  62. Everybody* starts with Mode 1
    Many stay there (and that’s OK)

    View full-size slide

  63. KMMBridge
    https://kmmbridge.touchlab.co/

    View full-size slide

  64. Stock tools for local dev
    What do teams do?

    View full-size slide

  65. (I’ve seen this movie)

    View full-size slide

  66. https://www.droidcon.com/2022/09/29/adopting-kotlin-multiplatform-in-brown
    f
    ield-applications/

    View full-size slide

  67. All that before you “start”
    Many points of failure (or, really, scuttle)

    View full-size slide

  68. KMMBridge was part of
    something more “ambitious”…

    View full-size slide

  69. Wide adoption needs publishing
    (and SPM)

    View full-size slide

  70. KMMBridge Publishes
    XCFrameworks
    SPM and Cocoapods, public or private, to GitHub
    Packages, JetBrains Space, Artifactory, etc

    View full-size slide

  71. But… Also local dev!

    View full-size slide

  72. Close the


    PLATFORM GAP ™

    f
    lip a switch”

    View full-size slide

  73. From Platform Engineers to
    Mobile Engineers

    View full-size slide

  74. Consume remote frameworks
    *(With Kotlin tools installed, of course)
    Easily build/debug local builds*

    View full-size slide

  75. Also local SPM dev
    SPM is *critical* for Kotlin on iOS

    View full-size slide

  76. After Mode 1?

    View full-size slide

  77. “Hey, how do you solve this
    problem?”
    “Oh, damn. I was going to ask you…”

    View full-size slide

  78. Everybody builds local
    Shared code actually “shared”

    View full-size slide

  79. Pros
    • Less rigid


    • Closer to feature dev


    • Can share much more code
    Cons
    • Breaking the “other platform”


    • Feature implementation *must*
    be in lockstep


    • All engineers *must* be
    “mobile engineers”
    • Breaking the “other platform”


    • Feature implementation *must*
    be in lockstep!!!


    • All engineers *must* be
    “mobile engineers”

    View full-size slide

  80. “Hey, how do you solve this
    problem?”
    “Oh, damn. I was going to ask you…”

    View full-size slide

  81. Possible Solutions
    (shout out to Marc Reichelt)
    ๏ Embrace breaking changes (good tests,
    f
    ix things)


    ๏ All engineers must at least test/avoid breaking on both platforms


    ๏ Tag-team feature PR’s


    ๏ Just pull versions and deal


    ๏ Something more complicated…

    View full-size slide

  82. After that?
    (these are broad generalizations)

    View full-size slide

  83. However…
    “Flutter doesn’t have that problem”

    View full-size slide

  84. SCHRODINGER’S CODE ™

    View full-size slide

  85. Another win with OSUI
    (need another acronym)

    View full-size slide

  86. kot·lin mul·ti·plat·form


    /ˌkätˈlin məltiˈplatfôrm,ˌkätˈlin məltīˈplatfôrm/


    noun


    noun: kotlin multiplatform


    1.optional, natively-integrated, open-source, code sharing platform, based on the popular,
    modern language kotlin. facilitates non-ui logic availability on many platforms.
    Oh, and JetBrains!

    View full-size slide

  87. https://www.droidcon.com/2022/09/29/adopting-kotlin-multiplatform-in-brown
    f
    ield-applications/

    View full-size slide

  88. Kotlin iOS Interop
    * relative to other cross-platform languages
    It’s amazing!*

    View full-size slide

  89. It’s Objective-C
    iOS devs *generally* don’t love Objc

    View full-size slide

  90. Kotlin -> Objc -> Swift

    View full-size slide

  91. Swift Interop
    Discussed and (presumably) coming

    View full-size slide

  92. Kotlin != Swift

    View full-size slide

  93. Kotlin
    • Sealed Classes


    • Data Classes


    • Generics


    • Default Parameters


    • Unchecked exceptions


    • Basic Types (Int, etc)


    • Coroutines
    Swift
    • Enums with associated values


    • Structs


    • Sure, but super di
    ff
    erent


    • Again, yeah, but


    • What?!


    • Well, sure, but



    Similar-ish

    View full-size slide

  94. Assume Objc for a while

    View full-size slide

  95. Kotlin
    • Sealed Classes


    • Data Classes


    • Generics


    • Default Parameters


    • Coroutines


    • Continued…
    Interop
    • Just classes


    • Just classes


    • No comment


    • No


    • Suspend, callbacks, no Flows*


    Today

    View full-size slide

  96. The Kotlin Sophistication Journey
    ๏ Android engineer(s) mostly code Kotlin


    ๏ Don’t quite grasp why the output is rough


    ๏ Work around output “quirks”


    ๏ Incorporate some tools


    ๏ Write wrappers


    ๏ (Maybe) write in-house tooling

    View full-size slide

  97. (Pitch Time)

    View full-size slide

  98. Touchlab Pro
    Velocity in a box

    View full-size slide

  99. Touchlab Pro
    Velocity in a box?

    View full-size slide

  100. Touchlab Pro
    Velocity in a box?

    View full-size slide

  101. SKIE
    * maybe Enhancer
    Swift/Kotlin Interface Extender*

    View full-size slide

  102. SKIE
    * maybe Enhancer
    Swift/Kotlin Interface Extender*

    View full-size slide

  103. Translations
    Enums, Sealed Classes, Default Parameters

    View full-size slide

  104. Reactive Interface
    Suspend, Flow

    View full-size slide

  105. Packaging
    Same Framework

    View full-size slide

  106. Licensing TBD

    View full-size slide

  107. 1000+ libraries

    View full-size slide

  108. SKIE Info and demos

    View full-size slide

  109. Other options

    View full-size slide

  110. KMP-NativeCoroutines
    github.com/rickclephas/KMP-NativeCoroutines

    View full-size slide

  111. moko-kswift
    github.com/icerockdev/moko-kswift

    View full-size slide

  112. Complexity growth isn’t linear

    View full-size slide

  113. SKIE Info and demos

    View full-size slide

  114. Presenting to a Team

    View full-size slide

  115. Presenting to a(n iOS) Team

    View full-size slide

  116. Start with empathy

    View full-size slide

  117. The problems they bring up are
    problems

    View full-size slide

  118. Accept that you may not
    succeed

    View full-size slide

  119. Understand the issues, and be
    prepared to address them

    View full-size slide

  120. Start with a module


    (AKA Mode 1, AKA SDK-
    f
    low)

    View full-size slide

  121. What module?
    Pick something nobody wants to do…

    View full-size slide

  122. Find an ally (or co-conspirator)

    View full-size slide

  123. People stuff is hard

    View full-size slide

  124. Modularization
    1 Framework, 1 Namespae

    View full-size slide

  125. Adapter and _Adapter

    View full-size slide

  126. Adapter and _Adapter and
    __Adapter

    View full-size slide

  127. @ObjCName
    https://kotlinlang.org/api/latest/jvm/stdlib/
    kotlin.native/-obj-c-name/

    View full-size slide

  128. Still need multiple frameworks/
    namespaces
    I’ve heard positive things…

    View full-size slide

  129. Formal SPM Support

    View full-size slide

  130. Best practices for shared code

    View full-size slide

  131. Ongoing quality of life
    Compiler Speed
    Swift Interop
    Debugger Improvements
    Header/API Reload (in Xcode)
    Publishing tools
    Gradle Con
    f
    ig
    Library Developer Best Practice

    View full-size slide

  132. Don’t get caught up with the
    problems
    It’s amazing tech, it is the future

    View full-size slide

  133. Go Watch the Keynote

    View full-size slide

  134. WASM and Compose Web

    View full-size slide

  135. WASM on the Server

    View full-size slide

  136. WASM needs a default
    language…

    View full-size slide

  137. Compose UI and OSUI (obv)

    View full-size slide

  138. Really open web
    Sandboxed container vs quirky JS-only API’s and tech

    View full-size slide

  139. Simply better ways to build and
    deliver products

    View full-size slide

  140. Different Teams
    di
    ff
    erent approaches

    View full-size slide

  141. KMMBridge
    https://kmmbridge.touchlab.co/

    View full-size slide

  142. Optionally Shared UI is a better
    cross-platform
    (if successful) this will be a default option in a year

    View full-size slide

  143. SKIE
    * maybe Enhancer
    Swift/Kotlin Interface Extender*

    View full-size slide

  144. The Future ❤ Kotlin

    View full-size slide

  145. SKIE Info, demos, and
    Touchlab...

    View full-size slide