Has anyone heard of someone who regretted transiti...
# multiplatform
u
Has anyone heard of someone who regretted transitioning an existing iOS project to KMP?
plus one 1
j
Not here, at least not yet, I have under taken a huge Android/iOS codebase to KMP project, over a decade of work, the company has let me lead the migration to KMP. Right now, I have had much success and really like deleting all the duplicated logic in both apps in favor on one single unified API that has been working good. Some of the bridging from Kotlin to Swift and vs versa sucks, but I know it will become more seamless overtime, for now making little extensions to enhance the bridging API's has been helpful. What is your concern w/ KMP btw?
d
I am currently transitioning an iOS codebase to KMP. No ragrets so far.
🤣 1
u
@Jason Concerns are the obvious ones, i.e. a paradigm shift and then it won't work/suck/be slow to build etc - it rather feels like a one way door
j
@ursus Yes build times will be a slower for sure, you have to make custom gradle build tasks so you only build what is needed, especially for iOS you want to make sure your only building the framework for the current architecture and Android you want to make sure you don't build the iOS framework on each build. Also, you need to ensure your not exposing too much of the API to iOS side or it will make the framework larger, so being explicit and making sure you use public modifier where you want to expose. The cool part of KMP is you don't have to commit all the way to using it, you can integrate as much as you want and still use Native in the other layers. I'm sure there will come a time where I regret it, but i'm hoping not. If you go full stack KMP, minus the rendering layer (SwiftUI/ComposeUI), its super nice and less issues. Once you start having to bridge old swift/objective-c code to Kotlin, it gets a bit hairer. I recommend any new features you build, do it w/ KMP.
u
@Jason if you go full stack kmp and swiftui, whats the type you expose viewmodel.state Flows as?
d
@ursus for me:
StateFlow<ViewState>
...which I'm collecting using SKIE
collect
View modifier.
u
is that the codegen library that brings back generics?
d
Yes among other many useful Utilies. SKIE is more useful when you have a SwiftUI / NativeUI use-cases of KMP iOS, and less useful where you're going for pure Compose-UI.
u
I see. Is that based on ksp?
d
I don't know, but likely.
j
@ursus Ya, same here. StateFlow<T> in KMP, I wrote my own ViewModier similar to collect but called it collectAsState so both ComposeUI and SwiftUI share same function name to observe the flow. I think I tried to inline the collectAsState on SwiftUI side, but wasn't able to, maybe will try again.
Copy code
private struct StateBinding<State>: ViewModifier {

    @Binding var state: State
    let stateFlow: SkieSwiftStateFlow<State>
    let onBind: ((State)->Void)?
    
    func body(content: Content) -> some View {
        content.task {
            for await state in stateFlow {
                self.state = state
                onBind?(state)
            }
        }
    }
}
ComposeUI:
var viewState = viewModel.viewState.collectAsState()
SwiftUI:
@State private var viewState: ViewState
someView()
.collectAsState($viewState, viewModel.viewState)