Hey all! Is there documentation or code somewhere that I could see that answers the question of how ...

# compose-ios

[Colin Marsch]

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 ?

[Colin Marsch]

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

[markturnip]

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

[Skaldebane]

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").

[Skaldebane]

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

[Skaldebane]

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)

[Colin Marsch]

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?).

[Fudge]

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

[Skaldebane]

@Fudge 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.

[Skaldebane]

@Colin Marsch 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.

[Colin Marsch]

Thank you! This thread has been very helpful!

[Elijah Semyonov]

Kudos to @Skaldebane 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 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 UIAccessibilityElements attached to it, that reflect the current state of what user can see on the screen.
Flutter indeed does the very same thing.