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!)

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