# compose-ios
I just read the readme, and still don’t really understand what it’s doing or the exact function it’s trying to accomplish. I get that it’s allowing multiplatform development of UIs with compose, but I’m definitely still missing a critical piece of information.
The point is that Compose UI has its own renderer using skia (similar to how Flutter works). This has advantages, like keeping things more similar between platforms, but also has disadvantages, mainly that it’s harder to make the UI feel ‘right’ on the platform, and looking at the state of redwood vs compose UI for iOS, you can see that building the renderer from scratch takes longer to do right. Redwood lets you write Compose code, but delegate the rendering to the platform’s UI library (think UIKit, SwiftUI on iOS, View, Compose on Android, Swing, AWT on JVM, etc.). The main advantage to this being that the UI should feel ‘right’ on the platform by default.
All of this I assumed. Looking at the code examples in the Readme I hardly see any of that:
Looking at the samples help a little: https://github.com/cashapp/redwood/tree/trunk/samples
@jw Cool, Redwood looks eerily similar to the (currently closed source) way we do things at my current company, data classes for the widgets, per-platform implementations, and everything. What we do differently, is not only are the widgets data classes, they are also
(via kotlinx.serialization). We have a WSYWIG editor in the browser (no-code/low-code), which saves screens as JSON tree of widgets, which the clients (Android, iOS, Web) fetch, and render at runtime (a.k.a. server-side rendering). Currently the platform widget renderers are written in Compose UI for Android, Compose Web/DOM, UIViews for iOS (not SwiftUI because this is actually a 5 year old project, haven't upped minVersion to iOS 13 yet)