KotlinConf 2023: Kotlin Mobile Multiplatform for Teams

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

Welcome to Kotlin Church

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

Introduction

Slide 5

Slide 5 text

Kevin Galligan Founder/Technical Partner Touchlab Kotlin GDE

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

Different Teams di ff erent approaches

Slide 8

Slide 8 text

Shared code “modes”

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Mode 1 - Shared Module

Slide 11

Slide 11 text

Mode 1 - Shared Module AKA SDK- f low

Slide 12

Slide 12 text

Android Shared Kotlin Xcode Framework

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

Why KMMBridge Exists

Slide 15

Slide 15 text

Mode 2 - Shared Architecture

Slide 16

Slide 16 text

Individuals and smaller teams “Everybody builds Kotlin”

Slide 17

Slide 17 text

Stock Kotlin

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

Mode 3 OPTIONALLY SHARED UI ™

Slide 20

Slide 20 text

Shared UI == Failure!

Slide 21

Slide 21 text

Shared Logic == Computers

Slide 22

Slide 22 text

People remember this

Slide 23

Slide 23 text

Not UI well, not necessarily UI

Slide 24

Slide 24 text

Nothing is prime time (yet)

Slide 25

Slide 25 text

Nothing is prime time (yet)

Slide 26

Slide 26 text

Photo @antonarhipov

Slide 27

Slide 27 text

Compose UI on iOS did Droidcon last year

Slide 28

Slide 28 text

First?

Slide 29

Slide 29 text

Other Examples

Slide 30

Slide 30 text

Redwood/Treehouse See Jake’s talk a bit later

Slide 31

Slide 31 text

SwiftUI run by Compose we’re experimenting

Slide 32

Slide 32 text

OK. What’s “optionally”?

Slide 33

Slide 33 text

80/20 mostly native UX, mostly shared code

Slide 34

Slide 34 text

Apple Health Main Feed Settings

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

iOS - 80/20 Shared architecture and some UI

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

Shared UI is Hard but done well?

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

Photo @sebi_io

Slide 42

Slide 42 text

(More on the future later…)

Slide 43

Slide 43 text

Mode 4 - Shared Everything

Slide 44

Slide 44 text

Not discussed basically Flutter

Slide 45

Slide 45 text

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

Slide 46

Slide 46 text

Zero Sum?

Slide 47

Slide 47 text

Zero Sum? (not scienti f ic, obv)

Slide 48

Slide 48 text

UX Complexity/Sensitivity 2014 Not-Native Native

Slide 49

Slide 49 text

UX Complexity/Sensitivity 2018 Not-Native Native

Slide 50

Slide 50 text

UX Complexity/Sensitivity 2022 Not-Native Native

Slide 51

Slide 51 text

UX Complexity/Sensitivity The boring middle Not-Native Native

Slide 52

Slide 52 text

UX Complexity/Sensitivity 2026? Not-Native Native

Slide 53

Slide 53 text

Zero Sum? Kotlin vs Flutter?

Slide 54

Slide 54 text

Kotlin, Flutter, RN, etc vs Native

Slide 55

Slide 55 text

Integration Approaches

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

How to integrate Kotlin iOS? of course…

Slide 58

Slide 58 text

It depends

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

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)

Slide 62

Slide 62 text

Larger Teams • More coordination issues • More inertia/risk averse • Specialized dev focus • More politically “entrenched” • Mode 1 to start (and maybe forever)

Slide 63

Slide 63 text

New Apps • Fresh start • Pick architecture, CI, etc • Monorepo (if you want) • More f lexibility with options

Slide 64

Slide 64 text

Existing Apps • Lots of existing code • Maybe multiple repos • CI is “robust” (AKA complex to change) • Existing procedures • Existing test coverage (or lack thereof)

Slide 65

Slide 65 text

Everybody can do Mode 1

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

Versioned SDK - Cons ๏ Limiting to shared e ff iciency ๏ iOS never gets “ownership” ๏ Slow feature and bug- f ix cycle ๏ “Unwelcome Guest”

Slide 68

Slide 68 text

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

Slide 69

Slide 69 text

KMMBridge https://kmmbridge.touchlab.co/

Slide 70

Slide 70 text

Stock tools for local dev What do teams do?

Slide 71

Slide 71 text

(I’ve seen this movie)

Slide 72

Slide 72 text

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

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

KMMBridge was part of something more “ambitious”…

Slide 75

Slide 75 text

Wide adoption needs publishing (and SPM)

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

But… Also local dev!

Slide 78

Slide 78 text

Close the PLATFORM GAP ™ “ f lip a switch”

Slide 79

Slide 79 text

From Platform Engineers to Mobile Engineers

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

After Mode 1?

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

Everybody builds local Shared code actually “shared”

Slide 85

Slide 85 text

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”

Slide 86

Slide 86 text

The Secret?

Slide 87

Slide 87 text

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

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

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…

Slide 90

Slide 90 text

After that? (these are broad generalizations)

Slide 91

Slide 91 text

However… “Flutter doesn’t have that problem”

Slide 92

Slide 92 text

SCHRODINGER’S CODE ™

Slide 93

Slide 93 text

Another win with OSUI (need another acronym)

Slide 94

Slide 94 text

The Interop

Slide 95

Slide 95 text

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!

Slide 96

Slide 96 text

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

Slide 97

Slide 97 text

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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

Kotlin -> Objc -> Swift

Slide 100

Slide 100 text

Swift Interop Discussed and (presumably) coming

Slide 101

Slide 101 text

Kotlin != Swift

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

Assume Objc for a while

Slide 104

Slide 104 text

Kotlin • Sealed Classes • Data Classes • Generics • Default Parameters • Coroutines • Continued… Interop • Just classes • Just classes • No comment • No • Suspend, callbacks, no Flows* Today

Slide 105

Slide 105 text

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

Slide 106

Slide 106 text

API Anxiety

Slide 107

Slide 107 text

(Pitch Time)

Slide 108

Slide 108 text

Touchlab Pro Velocity in a box

Slide 109

Slide 109 text

Touchlab Pro Velocity in a box?

Slide 110

Slide 110 text

Touchlab Pro Velocity in a box?

Slide 111

Slide 111 text

SKIE * maybe Enhancer Swift/Kotlin Interface Extender*

Slide 112

Slide 112 text

SKIE * maybe Enhancer Swift/Kotlin Interface Extender*

Slide 113

Slide 113 text

Translations Enums, Sealed Classes, Default Parameters

Slide 114

Slide 114 text

Reactive Interface Suspend, Flow

Slide 115

Slide 115 text

Packaging Same Framework

Slide 116

Slide 116 text

Licensing TBD

Slide 117

Slide 117 text

1000+ libraries

Slide 118

Slide 118 text

SKIE Info and demos

Slide 119

Slide 119 text

No content

Slide 120

Slide 120 text

Other options

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

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

Slide 123

Slide 123 text

Complexity growth isn’t linear

Slide 124

Slide 124 text

SKIE Info and demos

Slide 125

Slide 125 text

Presenting to a Team

Slide 126

Slide 126 text

Presenting to a(n iOS) Team

Slide 127

Slide 127 text

Start with empathy

Slide 128

Slide 128 text

The problems they bring up are problems

Slide 129

Slide 129 text

Accept that you may not succeed

Slide 130

Slide 130 text

Understand the issues, and be prepared to address them

Slide 131

Slide 131 text

Start with a module (AKA Mode 1, AKA SDK- f low)

Slide 132

Slide 132 text

What module? Pick something nobody wants to do…

Slide 133

Slide 133 text

Find an ally (or co-conspirator)

Slide 134

Slide 134 text

People stuff is hard

Slide 135

Slide 135 text

Other Stuff

Slide 136

Slide 136 text

Modularization 1 Framework, 1 Namespae

Slide 137

Slide 137 text

Adapter and _Adapter

Slide 138

Slide 138 text

Adapter and _Adapter and __Adapter

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

No content

Slide 141

Slide 141 text

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

Slide 142

Slide 142 text

Formal SPM Support

Slide 143

Slide 143 text

Best practices for shared code

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

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

Slide 146

Slide 146 text

The Future

Slide 147

Slide 147 text

Go Watch the Keynote

Slide 148

Slide 148 text

WASM and Compose Web

Slide 149

Slide 149 text

WASM on the Server

Slide 150

Slide 150 text

WASM needs a default language…

Slide 151

Slide 151 text

Compose UI and OSUI (obv)

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

Simply better ways to build and deliver products

Slide 154

Slide 154 text

Recap

Slide 155

Slide 155 text

Different Teams di ff erent approaches

Slide 156

Slide 156 text

KMMBridge https://kmmbridge.touchlab.co/

Slide 157

Slide 157 text

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