We're doing a PoC of rewriting our RN app to nativ...

# compose-ios

[Pearce Keesling]

We're doing a PoC of rewriting our RN app to native and as part of that I've been doing a bake off of CMP vs swiftui + kmp data layer. I was fully expecting swiftui to be better than CMP but the question was by how much. Instead I'm finding that for non-trivial usage (we're up to ~50 screens now) CMP is actually outperforming swiftui. Both startup and memory usage are better by a slim margin. For trivial pages (like a signed out state) swiftui wins but for real workloads (like our complex dashboard page) CMP is a bit better. It loads ~10% faster and has a little lower memory usage (200ish mb vs 250ish mb).

I guess what I'm hoping for is to see if anyone else has had a similar experience. This seems really hard for me to believe at face value so I'm going to dig in and try to figure out why swiftui isn't performing better. Has anyone else done a bake off who can comment?

[Pearce Keesling]

One noteworthy standout is that LazyColumn is dramatically better than LazyVStack. For the screen I'm comparing it can't be a List so I think LazyVStack just not being very good might be a big factor

[Colton Idle]

at kotlinconf last year they had a slide with stats and said that there were cases were cmp outperformed swiftui. i think in like scrolling lists etc. and it was by a pretty good margin IIRC. maybe someone from the jetbrains team will chime in, but in general yeah cmp is good!

[Pearce Keesling]

Something I have noticed with some more testing is that occasionally the CMP side will hitch pretty bad. I assume that is because of garbage collection but I haven't been able to catch it in a profiler yet to be sure

[Nikita Lipsky]

the jetbrains team will chime in

We measured startup, memory, fps for CMP vs SwiftUI on a relatively trivial benchmark last year. Startup and memory were worse for CMP but what surprised us that fps was better for CMP especially for 120Hz devices. We also expected to get worse numbers and tune performance as much as possible before iOS release but in the end the numbers were quite satisfactory for us (though we worked on iOS performance regardless the benchmark last 3 years).

[Jonathan]

Since the benchmark last year, has the team improve startup and memory performance of CMP?

[Nikita Lipsky]

We improved rendering performance via parallel rendering and other optimizations. We did not work specifically on startup/memory.

[Pearce Keesling]

I believe there are also improvements from the compose team on things like look-ahead rendering for virtualized lists.

[Pearce Keesling]

Thanks for weighing in, that is helpful to know I'm not totally off the reservation

[Christopher Mederos]

I've found that it's much easier to manage re-renders in Compose than SwiftUI. So for those screens with complex layouts or hundreds of pieces (like a chart)... it's easier to know if what you're writing will be performant or not. Thats the framework itself having more clear patterns + good tooling like the layout inspector or compose compiler reports

[Pearce Keesling]

Following up on this, it did turn out I was doing something stupid in swiftui 🤦. I was virtualizing a horizontal list in compose but not in swiftui so that was seriously hurting the top-level vertical scroll. Fixing that dropped it down to 100mb memory usage.