A modern programming language that makes developers happier.

kotlinlang

Hey all! Is there documentation or code somewhere that I could see that answers the question of how does a composable become an iOS UI element? For example, how do we get from a `Button` composable to some equivalent `UIView` ?

I'm specifically interested in how this works: `This is possible because semantics data produced by Compose APIs is now mapped to native objects and properties that are consumed by iOS Accessibility Services.` from <https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-ios-accessibility.html#customize-synchronization-of-the-accessibility-tree>

Using `ComposeUIViewController`:
<https://www.jetbrains.com/help/kotlin-multiplatform-dev/compose-swiftui-integration.html>

It doesn't really "become" an iOS UI element (Compose handles all drawing), but simply builds an accessibility tree (telling iOS "this is a button, it can do these actions, its size is xyz and position is abc").

Same thing on Android, it doesn't map to native elements, but simply communicates accessibility semantics to the OS.

Flutter does this as well in the same way (they even support it in web too, by building a dummy DOM tree with ARIA attributes synchronized to the canvas contents)

That's really helpful thanks! That makes a lot of sense, I thought that Compose Multiplatform ends up being represented by native UI elements on both platforms but it seems like that's not the case (I think that's what I'm understanding?).

React native works that way, but google  went with the route of drawing everything yourself

<@UHQSQ5BDK> And that's pretty awesome, since it allows for a lot of flexibility in terms of UI, and Compose UI's paradigm is quite powerful (think `Modifier`s).
It's also incredibly easier to implement with less platform-specific incompatibilities.

<@U014A0WGJ7N> Yep, Compose handles all rendering and input and doesn't "convert" to native elements, but it does build a native accessibility tree for the OS (which is synchronized to the actual rendered UI). It's like Flutter.

_Note that at least on Android, Compose does use some native elements where it's beneficial for performance/compatibility. Examples are material ripples, the `Popup` Composable, and a few minor things._

Thank you! This thread has been very helpful!

Kudos to <@U01A96FQB3Q> for providing exhaustive and correct information.
To be more in-detail:
On iOS accessibility services (VoiceOver, Inspector, etc) rely on hierarchies of `NSObject`s implementing informal <https://developer.apple.com/documentation/objectivec/nsobject/uiaccessibility?language=objc|UIAccessibility> protocol. Since native `UView`s implement them, it’s just natural for AX-services to traverse the UI tree.
Since `ComposeUIViewController` is just a regular `UIViewController` with its ordinary `view`, we basically maintain a tree of <https://developer.apple.com/documentation/uikit/uiaccessibilityelement?language=objc|UIAccessibilityElements> attached to it, that reflect the current state of what user can see on the screen.
Flutter indeed does the very same thing.