I'll be that annoying guy this time, who questions why you even want to switch on your sealed state in Swift 🙂
I'm also in the midst of a KMM project and for us this wouldn't come up because, while we do also use sealed classes heavily to represent states (great aren't they?), this stays within the shared presentation logic and never leaks into each platform specific view layer.
In the interest of keeping the view layer as thin and as dumb as possible; our view models spell-out the presentation in terms of the individual strings, booleans, and numbers that are required to drive the on screen widgets. Even de-structuring a state in the view is a no-no.
In this way the Swift side is only ever really collecting `Flow`s of primitive values, and calling back Kotlin functions of user interactions with the same.
Appreciate all use cases are different and you may have your own good principles for doing this - just throwing it out there in case it helps!