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
2. Welcome to Kotlin Church
4. Introduction
5. Kevin Galligan Founder/Technical Partner Touchlab Kotlin GDE
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
7. Different Teams di ff erent approaches
8. Shared code “modes”
9. (Sort of) Complexity/ Sophistication models don’t think of them too linearly
10. Mode 1 - Shared Module
11. Mode 1 - Shared Module AKA SDK- f low
12. Android Shared Kotlin Xcode Framework
13. Rather Complex need production Android, iOS, and Kotlin con f iguration experience
14. Why KMMBridge Exists
15. Mode 2 - Shared Architecture
16. Individuals and smaller teams “Everybody builds Kotlin”
17. Stock Kotlin
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
19. Mode 3 OPTIONALLY SHARED UI ™
20. Shared UI == Failure!
21. Shared Logic == Computers
22. People remember this
23. Not UI well, not necessarily UI
24. Nothing is prime time (yet)
25. Nothing is prime time (yet)
26. Photo @antonarhipov
27. Compose UI on iOS did Droidcon last year
28. First?
29. Other Examples
30. Redwood/Treehouse See Jake’s talk a bit later
31. SwiftUI run by Compose we’re experimenting
32. OK. What’s “optionally”?
33. 80/20 mostly native UX, mostly shared code
34. Apple Health Main Feed Settings
35. Android - 100 Everything is Kotlin. Everything is “native”.
36. iOS - 80/20 Shared architecture and some UI
37. Possible with “other” tech? Yes, but “possible” and “designed for” are not the same.
38. We’re excited about this Lot’s to f igure out
39. Shared UI is Hard but done well?
40. Optionally Shared UI is a better cross-platform (if successful) this will be a default option in a year
41. Photo @sebi_io
42. (More on the future later…)
43. Mode 4 - Shared Everything
44. Not discussed basically Flutter
45. Compose UI and tooling will make this possible but, to me, the “optional” potential, even if not used, is important
46. Zero Sum?
47. Zero Sum? (not scienti f ic, obv)
48. UX Complexity/Sensitivity 2014 Not-Native Native
49. UX Complexity/Sensitivity 2018 Not-Native Native
50. UX Complexity/Sensitivity 2022 Not-Native Native
51. UX Complexity/Sensitivity The boring middle Not-Native Native
52. UX Complexity/Sensitivity 2026? Not-Native Native
53. Zero Sum? Kotlin vs Flutter?
54. Kotlin, Flutter, RN, etc vs Native
55. Integration Approaches
57. How to integrate Kotlin iOS? of course…
58. It depends
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…)
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)
62. Larger Teams • More coordination issues • More inertia/risk averse • Specialized dev focus • More politically “entrenched” • Mode 1 to start (and maybe forever)
63. New Apps • Fresh start • Pick architecture, CI, etc • Monorepo (if you want) • More f lexibility with options
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)
65. Everybody can do Mode 1
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
67. Versioned SDK - Cons ๏ Limiting to shared e ff iciency ๏ iOS never gets “ownership” ๏ Slow feature and bug- f ix cycle ๏ “Unwelcome Guest”
68. Everybody* starts with Mode 1 Many stay there (and that’s OK)
69. KMMBridge https://kmmbridge.touchlab.co/
70. Stock tools for local dev What do teams do?
71. (I’ve seen this movie)
72. https://www.droidcon.com/2022/09/29/adopting-kotlin-multiplatform-in-brown f ield-applications/
73. All that before you “start” Many points of failure (or, really, scuttle)
74. KMMBridge was part of something more “ambitious”…
75. Wide adoption needs publishing (and SPM)
76. KMMBridge Publishes XCFrameworks SPM and Cocoapods, public or private, to GitHub Packages, JetBrains Space, Artifactory, etc
77. But… Also local dev!
78. Close the PLATFORM GAP ™ “ f lip a switch”
79. From Platform Engineers to Mobile Engineers
80. Consume remote frameworks *(With Kotlin tools installed, of course) Easily build/debug local builds*
81. Also local SPM dev SPM is *critical* for Kotlin on iOS
82. After Mode 1?
83. “Hey, how do you solve this problem?” “Oh, damn. I was going to ask you…”
84. Everybody builds local Shared code actually “shared”
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”
86. The Secret? <taps the sign>
87. “Hey, how do you solve this problem?” “Oh, damn. I was going to ask you…”
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…
90. After that? (these are broad generalizations)
91. However… “Flutter doesn’t have that problem”
92. SCHRODINGER’S CODE ™
93. Another win with OSUI (need another acronym)
94. The Interop
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!
96. https://www.droidcon.com/2022/09/29/adopting-kotlin-multiplatform-in-brown f ield-applications/
97. Kotlin iOS Interop * relative to other cross-platform languages It’s amazing!*
98. It’s Objective-C iOS devs *generally* don’t love Objc
99. Kotlin -> Objc -> Swift
100. Swift Interop Discussed and (presumably) coming
101. Kotlin != Swift
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 • <Deep breaths> Similar-ish
103. Assume Objc for a while
104. Kotlin • Sealed Classes • Data Classes • Generics • Default Parameters • Coroutines • Continued… Interop • Just classes • Just classes • No comment • No • Suspend, callbacks, no Flows* Today
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
106. API Anxiety
107. (Pitch Time)
108. Touchlab Pro Velocity in a box
109. Touchlab Pro Velocity in a box?
110. Touchlab Pro Velocity in a box?
111. SKIE * maybe Enhancer Swift/Kotlin Interface Extender*
112. SKIE * maybe Enhancer Swift/Kotlin Interface Extender*
113. Translations Enums, Sealed Classes, Default Parameters
114. Reactive Interface Suspend, Flow
115. Packaging Same Framework
116. Licensing TBD
117. 1000+ libraries
118. SKIE Info and demos
120. Other options
121. KMP-NativeCoroutines github.com/rickclephas/KMP-NativeCoroutines
122. moko-kswift github.com/icerockdev/moko-kswift
123. Complexity growth isn’t linear
124. SKIE Info and demos
125. Presenting to a Team
126. Presenting to a(n iOS) Team
127. Start with empathy
128. The problems they bring up are problems
129. Accept that you may not succeed
130. Understand the issues, and be prepared to address them
131. Start with a module (AKA Mode 1, AKA SDK- f low)
132. What module? Pick something nobody wants to do…
133. Find an ally (or co-conspirator)
134. People stuff is hard
135. Other Stuff
136. Modularization 1 Framework, 1 Namespae
137. Adapter and _Adapter
138. Adapter and _Adapter and __Adapter
139. @ObjCName https://kotlinlang.org/api/latest/jvm/stdlib/ kotlin.native/-obj-c-name/
141. Still need multiple frameworks/ namespaces I’ve heard positive things…
142. Formal SPM Support
143. Best practices for shared code
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
145. Don’t get caught up with the problems It’s amazing tech, it is the future
146. The Future
147. Go Watch the Keynote
148. WASM and Compose Web
149. WASM on the Server
150. WASM needs a default language…
151. Compose UI and OSUI (obv)
152. Really open web Sandboxed container vs quirky JS-only API’s and tech
153. Simply better ways to build and deliver products
154. Recap
155. Different Teams di ff erent approaches
156. KMMBridge https://kmmbridge.touchlab.co/
157. Optionally Shared UI is a better cross-platform (if successful) this will be a default option in a year
158. SKIE * maybe Enhancer Swift/Kotlin Interface Extender*
159. The Future ❤ Kotlin
160. SKIE Info, demos, and Touchlab...