https://kotlinlang.org logo
#compose
Title
# compose
f

franztesca

11/29/2023, 9:49 AM
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
e

ephemient

11/29/2023, 10:05 AM
it's doable, see #squarelibraries redwood
f

franztesca

11/29/2023, 12:07 PM
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)
e

ephemient

11/29/2023, 12:27 PM
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
going all native would result in something like compose-html or Glance, with a similar but incompatible API
f

franztesca

12/01/2023, 2:43 PM
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?