https://kotlinlang.org
Join Slack
Can anyone tell me how the performance is on a real device? I don't have a iPhone to check. Is it ...
# compose-ios
u
Can anyone tell me how the performance is on a real device? I don't have a iPhone to check. Is it noticable that it's something different from say SwiftUI?
v
Of course it is.
u
why exactly? physics or just raw performance? (since with swiftui you can sometimes tell vs. uikit)
v
For example scrolling. If you have bot vertical and horizontal - you will probably notice that is is not great. I notice the difference between android and iOS for the same project. Image loading libraries are also fresh yet and they don't work perfectly, as Coil for android for example
Scroll issues for Pre 1.5 CMP, it could be better in 1.5 because they did something with scrolls there
It is alpha ui toolkit. It would be a madness to expect it will perform the same as native one.
u
yea I was hinting on the latest update
since they say 120hz & scroll physics
v
Yea
But it won't be for free for me to migrate easily, so I will have to wait maybe for a month
u
anyways, so the expectations for compose ios is - better than web but worse than native
but in my mind there is a different between perf & physic even with android
v
I don't have too much UI just yet. But I was ready and for worse so
u
I can still tell if the scroll is compose or scrollview
v
Well, complex ui
u
it might be 60fps perfect but the psysics of the scroll are different & that annoys me ... same for horizontal paging ugh
v
Just scroll is not that bad. 2 directions scroll is. Like you intent to scroll vertically, but because your finger on top of something scrollable horizontally or clickable - you see some bs. But that is okay for alpha
c
FYI: The iOS simulator is pretty good at simulating real world performance on a recent iPhone. Obviously older devices will be slower.
s
I developed a SwiftUI prototype for Ashampoo Photos for iOS and noticed improved performance after switching to Compose, particularly in terms of scrolling. While I admit my SwiftUI implementation might have had room for improvement, I found my implementation to be relatively straightforward. In my opinion, with the current state of Compose for iOS (v1.5), the overall performance is quite commendable. Barring any unexpected freezes or crashes, I am inclined to proceed with releasing the iOS version of Ashampoo Photos using Compose. The switch to Compose also resolved several issues that arose in the SwiftUI version, largely due to missing APIs when compared to Compose's capabilities.
u
really? swiftui performed worse than alpha of compose ios?
s
In my case yes. SwiftUI is overall not very performant. Some even call it not production ready and stick to the old view system. 🤷‍♂️
u
what were you doing? swiftui is supposed to be wrapper over uikit views anyways
s
In the past two years I worked on Ashampoo Photos for all platforms. For Desktop and Android it’s released now with good performance, but I had to withhold the Apple versions because of SwiftUI problems. Going with that was a bad choice, it also the only real choice I had. Compose iOS really saves me here. 😄
what were you doing? swiftui is supposed to be wrapper over uikit views anyways
Everything wrong maybe? 😄
Maybe it’s just easier to write performant Compose apps than doing the same with SwiftUI. I don’t know. I wish I could show you my source so you can tell me what I did wrong, but unfortunately it’s a closed source project.
u
was it textfields or large bitmaps or something complicated like that?
s
This view especially
It contains thumbnail images, a rating view on top and an date range overlay. Scrolling fast through a huge library of photos was pretty bad with SwiftUI and performs much better in the Compose version.
On my iPhone it’s even more performant than on my Samsung Galaxy device. I assume due to the different garbage collector implementation there are less GC pauses as old thumbnails get released and new one get loaded during scroll.
So, yes… the views are all pretty complicated and deeply nested. I used to make Compose version first and the analogue thing in SwiftUI.
I also find that SKIA processes images much faster than Apples Core libraries. I benchmarked once creating thumbnails for 10k images and SKIA was done in half the time. That is surely a factor here.
Your mileage may vary, but that’s my personal experience on one specific project.
u
thata kind of hard to believe, since iphone has cpu 2x the power of android flagships, so singlethread perf is higher
so id suspect something else going on
s
What exactly is hard to believe?
I also find that SKIA processes images much faster than Apples Core libraries. I benchmarked once creating thumbnails for 10k images and SKIA was done in half the time. That is surely a factor here.
This was tested on the same macOS machine. Apple Core Library used with Swift vs Skiko on JVM.
u
thats raw perf on apple would be lower, as they have notoriously overkill cpus and tbh compose is noticably slower than Views when it comes to scrolling obviously more goes into perf, but images decoding etc. thats pure raw power
s
Yes, the same code on Apple is faster due to „overkill cpus“. I said that.
On my iPhone it’s even more performant than on my Samsung Galaxy device. I assume due to the different garbage collector implementation there are less GC pauses as old thumbnails get released and new one get loaded during scroll.
This is comparing Compose version on iPhone vs on Android.
But on the same hardware the native Swift version using Apple Core libs is slower than SKIA. So this has to do more with software. That’s why I also assume that SwiftUI implementation is less performant than Compose implementation.
and tbh compose is noticably slower than Views when it comes to scrolling
Any proof for that?
u
well, empirical
s
You compared an app with old android view system and it’s compose rewrite?
What has that to do with SwiftUI or iOS?
You lost me somewhere.
u
yes best case RecyclerView is more performant than best case LazyColumn.. don't think thats controversial compose is great but they have loads to do in optimization space
s
SwiftUI performance is worse than Compose
On a previous project a couple of years ago I build an app for iOS and Android using the old view systems. In that case the iOS version of the grid with cell reuse was faster than Android with RecyclerView.
In my experience SwiftUI is pretty bad and I’m glad that Compose for iOS is here. ❤️
Compose indeed lacks some interesting features like prefetching data on scrolling. That would make the experience even better. SwiftUI doesn’t have that either. SwiftUI lacks a lot of API we have in Compose or even the old view system. In my opinion Apple doesn’t really do much with SwiftUI. It needs a lot of more love.
u
well, sort of, swiftui is mostly a statemanagement wrapper over uikit, doesnt do its own rendering like compose does, and uikit is 20 year old framework if you count desktop, so they do have some know how.. so I'd be shocked if performance is so much worse on scrolling but yea features are missing and you need to dip down to uikit often
you must have been hitting some gnarly case, or doing something wrong.. but okay im not gonna discount that as I dont know
s
I also don’t know what the issue was. And Performance profiling is not that easy with SwiftUI. Instruments is hard to use and I barely see anything.
I profile with YourKit and since it sees composables just as methods (what they are) it’s pretty straightforward
Remember that I just build one app with SwiftUI in total. So I can’t tell if that’s just a „gnarly case“ or a general rule. 🤷‍♂️ And since Compose for iOS is here now I honestly don’t care that much anymore. 😉
But I’m not saying that I don’t wish for further performance improvements to Compose in general. Especially on Android my app could perform better. 😄
24 Views
Open in Slack
PreviousNext
Powered by

kotlinlang

A modern programming language that makes developers happier.

Powered by