And it will only support the native targets they support which a few weeks ago seemed like only iOS, unfortunately

iOS and native macOS for now.

Sounds good as a starter 🙂

There's no reason to limit the runtime to so few targets. We build the runtime for another project for all native targets without problem.

For Compose UI, it makes sense. They have to integrate with the platform’s UI libraries, which means adding a new platform is a lot of work. Luckily, this creates a higher level abstraction so libraries using Compose can support all compose targets.

No, for Compose UI it makes sense. For Compose it makes no sense.

You’re right. Currently, Compose UI is the primary use for Compose, but hopefully that changes over time.

@jw is this a prioritization issue on their part (i.e. they have no incentive to support them so they won't)? It's a shame that you called these things out years ago and nothing's happened. Aren't you glad there's now Compose, Compose UI, and Compose for Desktop?

It’s more likely that iOS support for Compose UI is taking up all their time right now.

Adding native targets to the runtime is exceptionally easy. Like I said, we build and run the Compose runtime's test suite on all targets that coroutines supports.