Hello! :wave: I was wondering if the idea of using...

# compose

[franztesca]

Hello! 👋
I was wondering if the idea of using compose + compose UI based on the native iOS views (instead of custom components rendered with skia) was ever considered and what are the limitations.
Is it just a matter of wanting the UI to be exactly the same at the pixel level between platforms, or there are technical blockers to that solution?
thank you color

[ephemient]

it's doable, see #squarelibraries redwood

[franztesca]

Thanks! My question was directed to the JB compose multiplatform though.
I know that native UI experience (and maybe even bundle size) is so important that some teams may decide to use swift UI on iOS, even when the skia-based compose multiplatform will be available.
I expect that at least 90% of the UI in swift UI has actually the same logic and a similar syntax to the compose one. If compose mutliplatform would use native UI even on iOS we would get:
• smaller binary size of the app (no need for skia)
• native UI experience and looks (which is generally considered superior to the skia ones)
and we would lose:
• same exact UI at the pixel level (which is generally not so important, at least between Android and iOS) from my experience)

[ephemient]

if you want to keep the same API, I don't see any way to avoid Skia even if you do use "native" views for some components

[ephemient]

going all native would result in something like compose-html or Glance, with a similar but incompatible API

[franztesca]

with a similar but incompatible API

That is what I was asking about. What is the incompatible API? For example, if I add a text with font size X, right margin Y and color Z I would expect that I can implement that same exact API with iOS platform API, skia or anything. 🤔 Can you tell me what I'm missing?