I started learning about how Compose acually works...

# compose

[Maher Safadi]

I started learning about how Compose acually works at it's core, I read that native view interop according to Gemini because Flutter replaces everything with it's Canvas, meanwhile Compose integrates its canvas in a native view so mixing native and compose views has barely any overhead and performance hits compared to Flutter, because Flutter has to cut a hole in the canvas and more heavy lifting, flutter platform views have always been known to be heavy, is what I understand about compose true? If true it's a game changer because native view interop is crucial and flutter has always been known to be bad at it.

[Sergey Y.]

Yes, Compose on Android uses the standard native canvas provided by the Android View system.

[Sergey Y.]

That's why Compose works seamlessly with any Android View, they feel like they're on the same layer, unlike Flutter's approach of rendering views into textures, sending them to its runtime, and drawing them as images, all of which adds overhead.

[Sergey Y.]

However, on iOS, the picture is completely different, it's basically like Flutter there, except for the runtime, because it blends into the iOS runtime.

[Maher Safadi]

@Sergey Y. I'm aware of the situation on Android but on iOS, after learning about Cmp/Kmp, I'm under the impression that CMP solved the performance hit that flutter has when interoping with native views, but now that you mentioned that it's the same as flutter on iOS, I'm a bit concerned about performance, also what does "blends into the iOS runtime" mean in this context in comparison to flutter?

[Sergey Y.]

🍵
As we know Flutter on iOS ships its own runtime, the Dart VM(very thin in release mode but still there), with its own heap and GC. It runs in the same process as UIKit, but Dart can't call Objective-C or Swift directly, there's no shared type system or calling convention. You cross the boundary through platform channels or dart:ffi.

Compose on iOS is similar except memory space. It runs on KotlinNative, which compiles to native code with built-in Objective-C interop(maybe it is already migrated to Swift, idk) no separate VM, no bridge. You call UIKit or Foundation directly from Kotlin, the toolchain generates bindings.
KotlinNative still has its own memory management (the newer concurrent one, much closer to JVM semantics), but it's not a walled-off runtime.
Rendering goes through a Metal-backed layer, the iOS analogue of Android's SurfaceView. Wrapping UIKit or SwiftUI inside Compose (or vice versa) has nuances around gesture dispatch and render-pass ordering between Compose's canvas and native iOS views.
On performance, I'm not sure Compose has Flutter's shader compilation jank. The team says it's not a thing and there's no hard evidence, but a few friends of mine and I have noticed the very first animation after install drops a couple of frames. Every subsequent launch, even cold starts, is smooth. Smells like KotlinNative interop warm-up or Metal pipeline state creation, but I don't actually know.

[Maher Safadi]

@Sergey Y. I appreciate the details, but my main concern is the performance when mixing compose views with native views (as in embedding native UI in a compose app), does Kotlin's advantage in sharing the same memory space benefit performance? I'm a flutter dev myself, mixing platforms views in an app, using admob for example, always made apps performance really bad, also the huge performance hit came because flutter had to cut a hole in the canvas, let's say we displayed a button in a list, flutter had to keep talking to the os trying to sync the native button in the flutter list, after I moved to kmp, I saw mixing and matching praised in the community, I assumed Kotlin's advantages somehow bypassed the large performance hit flutter has.

[shikasd]

iOS, desktop and web all use the same thing as flutter for rendering (bundling skia), so it is not that much different

[Chrimaeon]

Flutter is using Impeller now on iOS https://docs.flutter.dev/perf/impeller