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

KotlinConf 2023: Kotlin Mobile Multiplatform fo...

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. 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
  2. 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
  3. Compose UI and tooling will make this possible but, to

    me, the “optional” potential, even if not used, is important
  4. 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…)
  5. 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)
  6. Larger Teams • More coordination issues • More inertia/risk averse

    • Specialized dev focus • More politically “entrenched” • Mode 1 to start (and maybe forever)
  7. New Apps • Fresh start • Pick architecture, CI, etc

    • Monorepo (if you want) • More f lexibility with options
  8. Existing Apps • Lots of existing code • Maybe multiple

    repos • CI is “robust” (AKA complex to change) • Existing procedures • Existing test coverage (or lack thereof)
  9. 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
  10. Versioned SDK - Cons ๏ Limiting to shared e ff

    iciency ๏ iOS never gets “ownership” ๏ Slow feature and bug- f ix cycle ๏ “Unwelcome Guest”
  11. KMMBridge Publishes XCFrameworks SPM and Cocoapods, public or private, to

    GitHub Packages, JetBrains Space, Artifactory, etc
  12. 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”
  13. 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…
  14. 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!
  15. 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 • <Deep breaths> Similar-ish
  16. Kotlin • Sealed Classes • Data Classes • Generics •

    Default Parameters • Coroutines • Continued… Interop • Just classes • Just classes • No comment • No • Suspend, callbacks, no Flows* Today
  17. 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
  18. 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