I have implemented the same app 15 times for Andro...

# feed

[alitahasubfly]

I have implemented the same app 15 times for Android and iOS by gradually introducing KMP and CMP with different settings for UI including XML, UIKit and SwiftUI and tested the FPS, Memory Usage and App Sizes and compared the results. I wrote an article regarding that in Medium, feel free to check out:
https://medium.com/@alitahasubfly/i-made-the-same-app-15-times-here-are-the-results-part-1-introduction-methodology-ae9fcc1485e4
Since it was a very long article, I divided it into three parts, if you want to jump directly to the results, here is the second part:
https://medium.com/@alitahasubfly/i-made-the-same-app-15-times-here-are-the-results-part-2-experiments-results-27aeb93cb42b

[Stefan Oltmann]

Wow, that’s quite some research you did there. 😳

Could you distill something like your top 5 Dos and Donts out of it?
Like a list of performance patterns and anti patterns.

I’m currently in the process to converting all XML resources to coded VectorImages (like we have with the material3 icons) because I expect a better performance than parsing that XML every time. Could you also comment on that?

[alitahasubfly]

Hi Stefan, I have wrote about some dos and dont's in the Acknowledgements section of third article (mostly dont's 😄) and one of them already addresses about your XML icon issue. Fell free to check from here: https://medium.com/@alitahasubfly/i-made-the-same-app-15-times-here-are-the-results-part-3-outcomes-acknowledgements-d25a82f1c403

[Stefan Oltmann]

I scrolled over that, yes. But to be honest: TL;DR. 😅
That’s why I’m asking for distilled list. 😬

[Stefan Oltmann]

But I can try to copy and paste the whole article to ChatGPT and ask for bullet points there. 🫣

[Dave Leeds]

Goodness, 15 times! That's dedication! 👏

[alitahasubfly]

Considering that the app is based on only two screens with only two usecases, in fact there are nothing I can say that to improve the performance as the nature off the app(s) were not performance intensive. However, I am going to publish another article when CMP 1.6.0 gets stable and updating all the apps where I will also do this changes and compare with the previous results:
• Use ListView rather than using LazyVStack inside of a ScrollView in SwiftUI
• Use keys for items in LazyColumn where I utilize Jetpack Compose or CMP
• Try to utilize KMM-ViewModel library and other solutions for collecting Flows (maybe improve the performance compared to the implementation of shared flows that I am using)
• Considering the network side implementation or making the requests faster, there is basically nothing much to do as the app is too simple
• Use ComposeUIViewController's lifecycle methods rather than using the owner UIViewController's lifecycle methods, which I believe that will increase performance when CMP views used as TableViewCell
I believe that there will be better advices when I updated the apps and do the same tests 😄

[Joel Denke]

One thing noticed, did you run iOS part only on simulator? If not, which iPhones run on?

[alitahasubfly]

Unfortunately, because of my almost-non-existent iOS development experience, I was unable to send the file that I saved the test results from my iPhone to the localserver, like I did in Android 😕. Hence I did the tests in the simulator and printed out the file location in order to get the measurements data. As far as I remember, the error was, UrlSession couldn't be able to locate the file location from the given URL of the file. I appreciate any advice in order to solve that 😄

[Stefan Oltmann]

iOS Simulator on Apple Silicon Mac may have better performance than an actual iPhone 🤔

[Joel Denke]

Yeah what im curious about if Apple do some fake things in simulator. Compared to Android emulator impacts a lot not using complete iOS OS or iphone hardware. The tests very nice, just think would be very nice if compare more physical devices. Like low, medium and high end devices. Like Pixel 8 Pro on Android vs Sony Experia. iOS compare like iPhone 8 vs iPhone 15 or whats supported. Can then compare more charts and rule out some oddness caused by computer run on.
I Imagine run tests on MacBook pro M2 chip has huge impact on emulator and simulator.

[Stefan Oltmann]

Android emulator is much slower than actual devices, but iOS simulator running with the power of Apple Silicon outperforms actual devices. At least my M1 Pro is faster than my iPhone 12.

[Joel Denke]

Isnt simulator also doing less stuff? Meaning its not really same as actual software doing in iOS?

[alitahasubfly]

Yes, It can be true, and it would be better to mention that I did the tests on an M3 Pro device. However, the repository link is available in the articles and feel free to test it on your devices. I will constantly update the repo until CMP reach stable for iOS. For those who needs the link ina hurry:
https://github.com/Subfly/the_compose_experiment
will improve readme soon 😄

[Pablichjenkov]

Hats off, this article is basically a university research paper 👏

[Stefan Oltmann]

If Ashampoo Photos would run on real iOS devices like it does on my simulator I would have released it a long time ago. 🤭

[Stefan Oltmann]

I don’t think there is an option to adjust/throttle iOS simulator speeds to match real devices. But I must say that the low Android emulator performance actually helps in spotting problem areas.
At least if it runs well in the emulator you have some level of certainty that it will run acceptable on real devices.

[Joel Denke]

I will check. Regardless awesome article series. I really think the upside of CMP will be enormous.
And curious comparing myself XML vs XML + Compose vs Compose on Android only.
Your results is kind of what I was expected.
Will be interesting if Jetbrains will go similar was Google did with Interpeller for Skiko I mean.
Also if K2 compiler will do more optimizations.

[Stefan Oltmann]

Are there valid performance measurements that show how much faster Impeller actually is compared to SKIA? 🤔

[alitahasubfly]

It would be a good article topic too 😄

[Stefan Oltmann]

I am hoping too for way better Kotlin/Native performance and native GC improvements. Looking forward to K2 and can’t wait to see what it brings to the table for my app in real world scenarios. 👀

[Stefan Oltmann]

It would be a good article topic too 😄

But maybe a bit less wordy next time.
I like charts and tables with hard numbers, not so much long texts. 😉
No offense 🙂

[alitahasubfly]

Yeah you are right, but believe me this is the shortest I get 😄, next time since there are direct comparisons between different CMP versions, it will be less shorter but with more %'s and #'s 😄

[Joel Denke]

@Stefan Oltmann Also I think interesting compare GCC vs ObjC/Swift having another memory system closer to C. That gives one overhead itself I think, but not entirely sure how Skiko vs native Canvas operates at core level. Would be interesting read about these topics in itself. Also interested hear how Google compare Compose and Flutter themselves.

[Joel Denke]

For my semi small app feels like run smooth on real iPhones. Using 100% compose, except root level uiviewcontroller.

[alitahasubfly]

While working on the apps, I asked from my friends to test Twine, which is another %100 CMP app that in prod right now, and all of them said that it was pretty laggy, even with iPhone 14 Pro Max. However, there are so many questions that needed to be asked, like your CMP version, or AGP version, or any other setting might effect the performance differences 😄 @Joel Denke

[Joel Denke]

Yeah I noticed some things is Firebase on iOS is horrible slow if using that. Depending on libs it impacts a lot I noticed. Also if apps doing bad code, like odd Coroutines or work in background impacts a lot as thread handling very different in iOS.
Best imo compare pure CMP without any other libs.

[Stefan Oltmann]

The first version of Ashampoo Photos iOS was written in SwiftUI until Compose for iOS was available. I dropped that SwiftUI version, because it was tiresome to do double work and also it had not all the features because (to my surprise) SwiftUI APIs are lacking. There are a lot of things you just can’t do with SwiftUI - for example handling scrollstates of a list.

I feel that the Compose version is more performant than SwiftUI. It renders faster and has better scrolling performance. I especially noticed that operations on images using Core Image seem to be somewhat slower than SKIA - I expected the opposite.

The problem now is that it runs quickly into memory issues. So it’s faster than the SwiftUI version up until the point that memory is full and after that it’s laggy. The SwiftUI version, which was 100% equivalent code to the Compose version (I made Compose first and derived SwiftUI from that) was slower, but never had memory issues. (And was also lacking some features due to limited SwiftUI API)

So up until now Ashampoo Photos iOS is only available in TestFlight while the Desktop JVM & Android versions got released two years ago. 👀

I’m waiting on Kotlin/Native improvements so I can release this thing. Sometimes my managers tell me to just release it, but since it receives memory warnings after scrolling for some time I feel that’s not the experience I want users to have and I also fear bad reviews in the App Store that may destroy my products (or even companies) reputation.

[Joel Denke]

@Stefan Oltmann Yeah Jetbrains mention performance here https://blog.jetbrains.com/kotlin/2023/11/kotlin-multiplatform-development-roadmap-for-2024/#compose-multiplatform. Hopefully when CMP is iOS beta then performance of that is enough. Interesting SwiftUi vs CMP btw.