Just a question about the future of compose-ios: ...
# compose-ios
m
Just a question about the future of compose-ios: I’ve discovered the low level details how the compose-ios works - that it is based on Skia library etc. Actualy it looks like the whole composed view is “rendered” so there is no view tree nor accessibility for any composables on the screen on iOS. My question is if it is doable and will be done in Beta/Future version of the compose-ios or it is hard to say? In my project I have bunch of UI tests based on appium so the only way to instrument the app is via the accessibility identifiers. It means that I am not able to switch to the compose-ios right now as such tests won’t work. And I am wondering if it is just matter of time or it is something that I should not expect because of technical issues or something…
👍 2
👀 2
i
All elements still be rendered in the release of Compose for iOS, and it won't use the native components like UIButton, UITextField, etc. Accessibility will be supported - we will investigate how we can implement it without usual views. Not sure about third-party test frameworks - if they only use accessibility API, then it may work in the future. If it is based on UIView and its subclasses - it won't work. Either the testing framework should support Compose, or the framework should be replaced by Compose UI Test framework (it will be ported from Jetpack Compose UI Test)
m
XCUITest
framework is relying mostly on accessibility properties on the View tree, and the mentioned appium is using
XCUITest
as a driver, so I think if something will be accessible then it may be used in tests. I’ll follow the new releases of the compose-ios as it is very promising, but I am not able to migrate project yet. Thanks for the reply! 👍
@Igor Demin is there any way of use composable to create simple
UIView
instead of
UIViewController
? Or
UIControl
? I wonder if I may use compose-ios to create simple iOS controls instead of the whole screen on iOS 🤔