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 Slide

  2. Welcome to Kotlin Church

    View Slide

  3. View Slide

  4. Introduction

    View Slide

  5. Kevin Galligan
    Founder/Technical Partner


    Touchlab


    Kotlin GDE

    View Slide

  6. 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 Slide

  7. Different Teams
    di
    ff
    erent approaches

    View Slide

  8. Shared code “modes”

    View Slide

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

    View Slide

  10. Mode 1 - Shared Module

    View Slide

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

    View Slide

  12. Android
    Shared
    Kotlin
    Xcode
    Framework

    View Slide

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

    View Slide

  14. Why KMMBridge Exists

    View Slide

  15. Mode 2 - Shared Architecture

    View Slide

  16. Individuals and smaller teams
    “Everybody builds Kotlin”

    View Slide

  17. Stock Kotlin

    View Slide

  18. 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 Slide

  19. Mode 3


    OPTIONALLY SHARED UI ™

    View Slide

  20. Shared UI == Failure!

    View Slide

  21. Shared Logic == Computers

    View Slide

  22. People remember this

    View Slide

  23. Not UI
    well, not necessarily UI

    View Slide

  24. Nothing is prime time (yet)

    View Slide

  25. Nothing is prime time (yet)

    View Slide

  26. Photo @antonarhipov

    View Slide

  27. Compose UI on iOS
    did Droidcon last year

    View Slide

  28. First?

    View Slide

  29. Other Examples

    View Slide

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

    View Slide

  31. SwiftUI run by Compose
    we’re experimenting

    View Slide

  32. OK. What’s “optionally”?

    View Slide

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

    View Slide

  34. Apple Health
    Main Feed Settings

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  39. Shared UI is Hard
    but done well?

    View Slide

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

    View Slide

  41. Photo @sebi_io

    View Slide

  42. (More on the future later…)

    View Slide

  43. Mode 4 - Shared Everything

    View Slide

  44. Not discussed
    basically Flutter

    View Slide

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

    View Slide

  46. Zero Sum?

    View Slide

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

    View Slide

  48. UX Complexity/Sensitivity
    2014 Not-Native
    Native

    View Slide

  49. UX Complexity/Sensitivity
    2018 Not-Native
    Native

    View Slide

  50. UX Complexity/Sensitivity
    2022 Not-Native
    Native

    View Slide

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

    View Slide

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

    View Slide

  53. Zero Sum?
    Kotlin vs Flutter?

    View Slide

  54. Kotlin, Flutter, RN, etc vs Native

    View Slide

  55. Integration Approaches

    View Slide

  56. View Slide

  57. How to integrate Kotlin iOS?
    of course…

    View Slide

  58. It depends

    View Slide

  59. View Slide

  60. 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 Slide

  61. 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 Slide

  62. Larger Teams
    • More coordination issues


    • More inertia/risk averse


    • Specialized dev focus


    • More politically “entrenched”


    • Mode 1 to start (and maybe
    forever)

    View Slide

  63. New Apps
    • Fresh start


    • Pick architecture, CI, etc


    • Monorepo (if you want)


    • More
    f
    lexibility with options

    View Slide

  64. 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 Slide

  65. Everybody can do Mode 1

    View Slide

  66. 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 Slide

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


    ๏ iOS never gets “ownership”


    ๏ Slow feature and bug-
    f
    ix cycle


    ๏ “Unwelcome Guest”

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  71. (I’ve seen this movie)

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  75. Wide adoption needs publishing
    (and SPM)

    View Slide

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

    View Slide

  77. But… Also local dev!

    View Slide

  78. Close the


    PLATFORM GAP ™

    f
    lip a switch”

    View Slide

  79. From Platform Engineers to
    Mobile Engineers

    View Slide

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

    View Slide

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

    View Slide

  82. After Mode 1?

    View Slide

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

    View Slide

  84. Everybody builds local
    Shared code actually “shared”

    View Slide

  85. 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 Slide

  86. The Secret?

    View Slide

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

    View Slide

  88. View Slide

  89. 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 Slide

  90. After that?
    (these are broad generalizations)

    View Slide

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

    View Slide

  92. SCHRODINGER’S CODE ™

    View Slide

  93. Another win with OSUI
    (need another acronym)

    View Slide

  94. The Interop

    View Slide

  95. 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 Slide

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

    View Slide

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

    View Slide

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

    View Slide

  99. Kotlin -> Objc -> Swift

    View Slide

  100. Swift Interop
    Discussed and (presumably) coming

    View Slide

  101. Kotlin != Swift

    View Slide

  102. 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 Slide

  103. Assume Objc for a while

    View Slide

  104. Kotlin
    • Sealed Classes


    • Data Classes


    • Generics


    • Default Parameters


    • Coroutines


    • Continued…
    Interop
    • Just classes


    • Just classes


    • No comment


    • No


    • Suspend, callbacks, no Flows*


    Today

    View Slide

  105. 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 Slide

  106. API Anxiety

    View Slide

  107. (Pitch Time)

    View Slide

  108. Touchlab Pro
    Velocity in a box

    View Slide

  109. Touchlab Pro
    Velocity in a box?

    View Slide

  110. Touchlab Pro
    Velocity in a box?

    View Slide

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

    View Slide

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

    View Slide

  113. Translations
    Enums, Sealed Classes, Default Parameters

    View Slide

  114. Reactive Interface
    Suspend, Flow

    View Slide

  115. Packaging
    Same Framework

    View Slide

  116. Licensing TBD

    View Slide

  117. 1000+ libraries

    View Slide

  118. SKIE Info and demos

    View Slide

  119. View Slide

  120. Other options

    View Slide

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

    View Slide

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

    View Slide

  123. Complexity growth isn’t linear

    View Slide

  124. SKIE Info and demos

    View Slide

  125. Presenting to a Team

    View Slide

  126. Presenting to a(n iOS) Team

    View Slide

  127. Start with empathy

    View Slide

  128. The problems they bring up are
    problems

    View Slide

  129. Accept that you may not
    succeed

    View Slide

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

    View Slide

  131. Start with a module


    (AKA Mode 1, AKA SDK-
    f
    low)

    View Slide

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

    View Slide

  133. Find an ally (or co-conspirator)

    View Slide

  134. People stuff is hard

    View Slide

  135. Other Stuff

    View Slide

  136. Modularization
    1 Framework, 1 Namespae

    View Slide

  137. Adapter and _Adapter

    View Slide

  138. Adapter and _Adapter and
    __Adapter

    View Slide

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

    View Slide

  140. View Slide

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

    View Slide

  142. Formal SPM Support

    View Slide

  143. Best practices for shared code

    View Slide

  144. 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 Slide

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

    View Slide

  146. The Future

    View Slide

  147. Go Watch the Keynote

    View Slide

  148. WASM and Compose Web

    View Slide

  149. WASM on the Server

    View Slide

  150. WASM needs a default
    language…

    View Slide

  151. Compose UI and OSUI (obv)

    View Slide

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

    View Slide

  153. Simply better ways to build and
    deliver products

    View Slide

  154. Recap

    View Slide

  155. Different Teams
    di
    ff
    erent approaches

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  159. The Future ❤ Kotlin

    View Slide

  160. SKIE Info, demos, and
    Touchlab...

    View Slide