Hi everyone, in my company we are considering to b...

# compose-ios

[Umberto Pompei]

Hi everyone, in my company we are considering to build a ios and android app with use of compose for UI to have 100% multiplatform apps.
At the moment we have 2 big concerns that are blocking us from adopting compose multiplatform:
• Compose for iOS is in Beta
we do not feel comfortable to possibly ending up in Production with something in Beta.
• Lack of compatibility with Appium test platform
Inhouse QA uses Appium for automation tests and it seems Appium it's not compatible yet with Compose-iOS

My questions are:
• Does anyone know the roadmap of when compose-ios is going to be stable? cannot find any reference online
• How do you handle automation tests for compose-ios?
Thank you

[Richard]

• Lack of compatibility with Appium test platform

Inhouse QA uses Appium for automation tests and it seems Appium it's not compatible yet with Compose-iOS

Setting testTags should work and output on iOS as identifier that can be read by accessibility inspector and used by appium. At least with maestro it works fine. The only thing is that for Simulators you have to Always sync the accessibility options -> https://youtrack.jetbrains.com/issue/CMP-4401
Does that help with Appium?

The other question no-one can definitely answer I guess, my take on this is that CMP is very good, performant and stable using 1.7.0-beta02

[François]

iOS: You need to have a checklist of what features you need for your apps (Interactions/accessibility/...) and verify if you can do it on iOS

[François]

some missing feature for iOS are not well documented

[Michael Paus]

This also applies to your business logic. Remember that you cannot use any Java-based stuff on iOS that you might be used to on Android. This also applies to a lot of features of the standard library and external multi-platform libraries even if they claim to support iOS. E.g., try to create a ZIP file with Okio. It only works on the JVM. According to my experience Compose will not be your main problem.

[jw]

Let's be clear: Okio does support iOS. It's not a claim–it's a fact. The fact that parts of the API are not available on all targets, however, isn't unique or interesting. No one says "kotlinx.coroutines claims to support JS but try to use `runBlocking`–you can't!"

[jw]

You can still use Okio, kotlinx.coroutines, and thousands of other libraries whose full API is not supported on every target without much trouble. If you were relying on a target-specific API you simply expect/actual and delegate to something else on the unsupported targets.

[François]

Also, I’m talking not only dependencies, but compose himself, compose for iOS is incomplete and instable (just be careful)

[Umberto Pompei]

Thanks all for the inputs.
My post is very UI specific, concerns are only related to compose-ios readiness and capability of Appium to support tests on iOS when using compose.
@Richard We'll give a try to testTags to check if that can cover gap with Appium , thanks for the suggestion

[Michael Paus]

@jw It is also a fact that you cannot just blindly trust generalizing statements like library A supports platform X and assume that all features of this library will actually be available on X. It’s a good idea to first compile a feature list of what you need and then double-check this against all possible library candidates. I have burned my fingers often enough now.

[jw]

Sure, but that shouldn't be surprising. All features of the language and its stdlib are not available on all targets either. You are set up to expect different things for supporting different targets.

[Umberto Pompei]

Is there a channel to communicate with people in JetBrains? I would like to ask when compose-ios is expected to become stable

[jw]

you're in it!

[jw]

you probably have to be more specific as to what "stable" means to you. no ABI-breaking changes? zero bugs? 100% of features? (note: no library in the history of programming has ever had zero bugs nor 100% of features)

[Umberto Pompei]

I'd like to know when compose-ios is expected to be officially promoted to Stable as I want to sponsor the adoption but the fact that is in Beta is an easy argument against the proposal

[jw]

So you're just concerned specifically about the marketing label for evangelism purposes? And ABI breaking changes, bugs, and missing features are all okay?

[Umberto Pompei]

the fact that is in Beta is an immediate show stopper

[jw]

You're not really answering the question. What does the implications of "beta" even mean such that that's the case?

[Richard]

You will not get an answer, even from JetBrains as to when they put the word "Stable" on it. If that's a dealbreaker for you or your company, then you will not be able to use CMP. If you want to know how stable it is in regards of features, performance, etc. you have to give it a try yourself.

[jw]

Additionally, starting to evaluate it while it's in beta means that you can contribute feedback of the things which are valuable to you before it is deemed as "stable" so that you will actually be able to use it.

[Umberto Pompei]

the point is that I can test it immediately and have excellent results, but until it's in Beta my proposal would not be strong enough to break trough

[jw]

okay I just want to set expectations here that when it's marked as "stable" at some point it will still have bugs and be missing features. but it sounds like you have some kind of technical gate keeper that will automatically reject something if it's not marketed as stable. and that is definitely a thing.

[Umberto Pompei]

yeah I understand no software is bulletproof even after hundred releases, it's just a matter to build a proposal that is strong enough to be considered. The fact that compose-ios is in Beta is a weak point from this perspective

[Rok Oblak]

it was alpha last year and promoted to beta this year. I'd not be surprised if it's marked as stable next summer. Not many showstopper issues and most of the actual downsides CMP on iOS has compared to Swift are probably not going to be resolved in a few years, if at all.

[darkmoon_uk]

If there's a real risk of stakeholders getting hung up on the Experimental/Alpha/Beta/RC label, then I'd say CMP may not be the right choice for your project at this stage.
Personalities range widely, and some managers are risk averse enough to get upset if they learn of anything other than 'Stable' being used in their products; regardless of context. Of course, you might be able to bring them round...

By following CMP's development closely enough, proving your use-cases via personal projects, then experience will begin to inform you more about the risks than a one-word label does.

After running enough PoC's/experiments against your use case; you'll be able to carry an argument against the 'Beta' label with Stakeholders yourself. Show them working software and show them they can't break it or make it glitch.

Story time: I deployed Kotlin Multiplatform in Production when it was still 'Experimental'(!) and iOS had the freezing memory model. The only 'secret' to this was informing stakeholders, asking them to 'trust me' 😅, then owning the risk and outcome, and at one point putting in a truck-load of overtime to fix a number of issues that came up. Not going to lie it was stressful at times! But; I actually ended up delivering a polished, bug-free product that the customer was happy with, and learned a lot in the process. It's doable, but not right for everyone's priorities.

[Richard]

Roadmap: https://blog.jetbrains.com/kotlin/2024/10/kotlin-multiplatform-development-roadmap-for-2025/

[Umberto Pompei]

Thank you very much @Richard, that makes a difference