Does anyone have any wisdom to offer regarding using KMP with SwiftUI? Is it better to use Swift types directly in your SwiftUI code, and some glue code that translates between Kotlin and Swift? Or should we use Kotlin types directly in the SwiftUI code? I’m going for a more lightweight MVVM approach than the heavy/complicated MVIKotlin approach.

I haven't done it but I like your first solution better. Create a layer in swift itself that consume the kotlin interop. It would allow to make any tweaks in this layer if needed or some data processing before reaching swiftui

There is more than one stable point. It is unquestionable possible to bury Kotlin way down into a data/light calculation only role. I hope to hear others share their stable points, but others have in the past (and used much higher up UI components than I have directly)

I want Kotlin to be as close to the UI layer as possible, since I want to share as much code as possible between iOS and Android. However, I still want it to be clear to other developers looking at my code what everything is doing. (When I look at MVIKotlin code, my head spins.) I quite like what Point-Free has been doing with their Composable architecture in Swift. They have a UI component that takes a store and a transformation function and shuttles data into the UI type. If I could pull off something like that it would be great. But the question is still there, where exactly do you draw the line between Swift and Kotlin? https://pointfreeco.github.io/swift-composable-architecture/main/documentation/composablearchitecture/withviewstore

At some point, some of the issue is the "how willing are you to ignore iOS UI conventions". Like the interaction and update schemes for jetpack and swiftUI and data around them are different enough that you run into issues at times. For instance, there is a lot more "construct a lot of a hypothetical object across more than one screen then confirm you will store it to your source of truth" on iOS than on Android generally. Beyond the point free guys, there are iOS things like reswift and a few others which are similar ideas and have longstanding communities. iOS definitely supports a "this is the model now" approach natively with swift UI. I haven't brought kotlin up that high into our app yet though to stick it right there though yet 😄

I have worked closely with my iOS colleagues implementing semi complex screens and there is no way they would buy into bringing the state directly from kotlin

For Jacob: Even with native approaches to iOS development, "redux style systems" tend to be vulnerable to "large model object" issues with performance

They might accept bringing in utility libraries and such but for the UI state, they want to work it out themselves

with redux style systems you can keep UI state out of it (Jacob had pointed at one with the point free stuff which is why I mention it). It isn't such a bottleneck then, but you lose a lot of "shared code" especially test cases.

@Pablichjenkov Yeah, I can see that. However, I’m working on a much smaller team and keen on a type of “mobile full-stack” developer where developers are writing both Kotlin and Swift. That way you can do that sort of code sharing. Perhaps that’s overly ambitious, though.

it's not about the developer taste though

FWIW, I have ViewModels in Kotlin that manage UI State, and expose the UI State flow for SwiftUI to consume. The ViewModel is

@Observable

@ObservedObject

and the SwiftUI view pulls the

uiState

from the model and responds accordingly (updating when the flow emits a new state). At that point you're just writing SwiftUI like you normally would.

It's about the "that's not how a text box works"

Michael: What do you mean you run into large model object issues? Like, the model gets so gigantic from all the different state that it becomes a performance issue? It was my understanding that the redux-style systems allow you to break your code down into smaller chunks, decoupling from UI, allowing unit tests, and making things pluggable to share between platforms.

So in addition to this whole "where do you start KM" in the stack question, there is often a lot of "undecided data modelling" from the api side

Ah I gotcha. Well, we don’t quite have that problem yet. I can also limit the specific fields and such which get passed around at the service-level. Additionally, we use GraphQL which allows me to target which particular fields I actually care about in an object graph.

GraphQL definitely helps a lot at getting the fields you need, yes. It sounds like there is some success at the level you're looking for above ^. I'd probably just reserve enough development capacity to lose a level on the iOS app if it doesn't pan out.

Yeah, that was part of what I like about KMP is that I can deliver native-feeling apps. Whereas Flutter and RN are going to be approximating it all the time. And this is a customer-facing app, so I care about the quality of the product a lot more.

Like on iOS, you can occasionally need to make a set of conditional code for iPad vs iPhone (and apple tests on iPads, so...). As long as you leave time and don't get intractable about getting that where you need it for your business, you'll make it.

@Jacob Rhoda I meant to say

@ObservedObject

not

@Observable

. There are various ways to achieve view model sharing. I suggest taking a look at the samples - https://www.jetbrains.com/help/kotlin-multiplatform-dev/multiplatform-samples.html - and finding the samples that share models / view models. Looking through the samples, you should be able to find an approach that resonates with you and your team. Specifically for making a view model observable, you'll want a Swift extension that conforms your view model to the

ObservableObject

protocol, and then a helper that receives the uiState flow and fires off

objectWillChange.send()

. Rather than setting that all up by hand, I might suggest looking at a library that does it already, such as https://github.com/rickclephas/KMM-ViewModel