Today it was a great milestone! I was able to run exactly the same shared ViewModel on both Android and iOS, using

StateFlow

!!! I can easily say 85% of the code is on Kotlin Multiplatform, and 15% only on the platform-specific declarative UI (Compose and SwiftUI)! on Android, it uses Compose's `collectAsState`:

@Composable
fun MainLayout(coreModel: CoreViewModel) {
    val appState by coreModel.stateFlow.collectAsState()
    ...
}

on iOS, it uses a very simple class extending

ObservableObject

, where a StateFlow “listener” is initialized:

class AppViewModel: ObservableObject {
  let coreModel : CoreViewModel = CoreViewModel()
  @Published var appState : AppState = AppState()
     
  init() {
      coreModel.onChange { newState in
          self.appState = newState
      }
   }
}

this is the shared `ViewModel`:

class CoreViewModel {

  internal val mutableStateFlow: MutableStateFlow(AppState())
  val stateFlow: StateFlow<AppState>
      get() = mutableStateFlow

  fun onChange(provideNewState: ((AppState) -> Unit)) {
      stateFlow.onEach {
          provideNewState.invoke(it)
      }.launchIn(CoroutineScope(Dispatchers.Main))
  }
}

Congrats! Are you using

Flow

on your ViewModels? If so, were you able to consume it on iOS? I'm still doing the

CFlow

hack and I wanted to get rid of it soon

Yes, I am using

StateFlow

How are you observing it on iOS side? Edit: Just saw your edit with the code

@Kurt Renzo Acosta the

StateFlow

code on iOS is very straightforward. it’s just a “callback” providing the new state.

You are never canceling the job that is launched in onChange though.

Yup. I was looking for a solution where we don’t have to create a callback and just use the

StateFlow

like we use it on Android. I have the same pattern here with the help of KotlinConf’s CFlow so that I don’t have to create a callback for every

StateFlow

. I just hoped it would be possible to avoid it since suspend functions can be used in iOS but I guess not for

Flow

yet.

@Kurt Renzo Acosta I am not aware of a different way to collect StateFlow on iOS. But I guess it will arrive sometime soon, and it’s just a matter to update a few lines of code.

I don’t know the inter-capabilities of iOS/kmpp, but since swift has a deinit you could create a DeallocWatcher that cancels the

CoreViewModel

scope

Just treat

CoreViewModel

as an Objective-C object, as it’s defined in an Objective-C framework. Feel free to share snippets.

StateFlow is still a Flow and should work wrapped in CFlow linked above.

Yea well since

CFlow

uses a

Closable

, its the same principle, it needs to be cleaned up at some point. 👍

maybe we should ask the opinion of the Zar @elizarov

Sorry, I'm not an iOS/Swift expert, so I cannot really contribute any new ideas here.

I just opened an issue: https://youtrack.jetbrains.com/issue/KT-41953

Why create an issue for that though 🤔 In the kotlinconf app you can find the cleanup being done. And even if you wanted to somehow automatically close the

CFlow

(cancel the

Job

), this would be an implementation detail.

In summary, as you know, on JetpackCompose there is a very neat way to collect a StateFlow:

That's because Android team (from Google) has incorporated Coroutines support into JetpackCompose. I do not expect same support from Apple 😄 I think community will have to step up and create some sort of components for SwiftUI to bind

StateFlow

. Maybe it's possible to wrap it with Swift's Combine framework 🤔 (There might be some problems since SwiftCombine is Swift-only and Kotlin Native has only supports Objective-C)

@flosch I think it would be great to have a one-line

collectAsState()

, so that developers don’t have to manage the cleanup themselves. But I am not sure if it’s feasible. Let’s see what’s the reply. I also think,

StateFlow

didn’t exist at the time the kotlinconf app was made.

FYI

StateFlow

already existed before in the form of a

ConflatedBroadcastChannel

.

@Kurt Renzo Acosta by the way, I was looking for

CFlow

in the Kotlin documentation, but I cannot find it. Was it also renamed to something else?

It’s just a util or a workaround to get it working on iOS. It’s not part of the library

ok, got it now

Yes, you cannot close

StateFlow

, but if you launch it there will still be a

Job

that probably should be cleaned up

@rocketraman glad to hear! were you able to write a better code for handling StateFlow on iOS?

Not sure if you could call it better... it was just pulling together some pieces. I copied the code of

CFlow

directly from the Kotlin Conference app along with the native dispatcher from the same place: 1. https://github.com/JetBrains/kotlinconf-app/blob/master/common/src/mobileMain/kotlin/org/jetbrains/kotlinconf/FlowUtils.kt 2. https://github.com/JetBrains/kotlinconf-app/blob/master/common/src/iosMain/kotlin/org/jetbrains/kotlinconf/DispatcherNative.kt I injected the view model's

CFlow

adapter into the iOS

ObserverObject

(on Android the view model is injected directly). From there, using

StateFlow

on Android normally, and on iOS using `CFlow`'s watch to set the

@Published

vars just worked.

I am still waiting for this to be answered by the JetBrains team: https://youtrack.jetbrains.com/issue/KT-41953

@Daniele B Instead of waiting, you could make your own solution (which can be to just copy/paste

CFlow

), because they might not be able to answer the way you hope for in the timeframe you're looking for.

@louiscad the CFlow code deals with a closable Flow, but as far as I understand StateFlow is not closable

CFlow

seems to be the way to go as of now. On that, you just call

close

in the appropriate callbacks in Swift code. The conference app has some examples showing this.

@rocketraman @louiscad I have modified this:

fun onChange(provideNewState: ((AppState) -> Unit)) {
        stateFlow.onEach {
            provideNewState(it)
        }.launchIn(
            CoroutineScope(Dispatchers.Main)
        )
    }

into this:

fun onChange(provideNewState: ((AppState) -> Unit)) : Closeable {
        val job = Job()
        stateFlow.onEach {
            provideNewState(it)
        }.launchIn(
            CoroutineScope(Dispatchers.Main + job)
        )
        return object : Closeable {
            override fun close() {
                job.cancel()
            }
        }
    }

Dispatchers.Main

should probably be an expect/actual which points to this native dispatcher in iOS: https://github.com/JetBrains/kotlinconf-app/blob/master/common/src/iosMain/kotlin/org/jetbrains/kotlinconf/DispatcherNative.kt

isn’t

Dispatchers.Main

the UI dispatcher also recognised on iOS?

Otherwise, yes, that's essentially the same code as

CFlow

, except

CFlow

is nice as it wraps any

Flow

, so you don't have to add that

onChange

method directly to your view state.

@rocketraman I was thinking the implementation is comparable: in both cases a method is defined as closeable. In the kotlinconf app it’s called “watch”, in my app it’s called “onChange”.

Yeah its the same, except yours is on the View right? If you have more than one view its not DRY. Abstracting it into a wrapper class puts it in one place regardless of how many views you have.

I am actually planning to have just one ViewModel and one StateFlow

In that case, its the same, yeah, though I still think separating the concerns is a good idea i.e. the throwaway code that should eventually go away is independent from the code that should stick around.

yes, I am just using it on iOS

Exactly my point 😉

@dagomni There's already great suggestions for folks above. TL;DR: You can copy and use

CFlow

from KotlinConf app (link above) or edit it to suit your needs. Is it not enough?

I’m using

CFlow

on Android and iOS and I’m fully sharing my VMs. No need for a wrapper on iOS.

I have eventually published an article on the topic: https://danielebaroncelli.medium.com/the-future-of-apps-declarative-uis-with-kotlin-multiplatform-d-kmp-part-1-3-c0e1530a5343