First off, I really enjoyed reading your detailed comparison of SwiftUI and UIKit performance.
That said, my view is slightly different from the conclusion of the article. Rather than taking the approach that “you should always avoid SwiftUI for performance,” I think it’s important to consider what kind of screen you’re building and how complex it is.
The screen you compared includes a feed-style UI with GIF animations, so if SwiftUI introduces overhead there and causes hangs, I agree that it can create an unpleasant experience for users. But for simpler screens, such as login, settings, or profile screens, I think using SwiftUI’s declarative UI model can still offer a reasonable set of trade-offs.
Since there’s no silver bullet, I personally found the conclusion of the article a bit too strong.
I have checked the SwiftUI code and can see that its not really ideally written. For example, "ForEach(Array(viewModel.visibleItems.enumerated())" will cause extra work. Changing the closures to use capture lists "onStickerDeleted: { [viewModel] itemID, stickerID in" helps. "VisibleItemReporter" which uses GeometryReader with the y coordiate. I only looked at the code shortly but there is a lot of potential to improve it.
Overall I dont think this is a fair comparison. I am guessing you wrote the code with Claude? The AI code is not as good for SwiftUI vs UIKit, simply because it has more training data for UIKit.
Would love to see the code improved and the performance comparsion more realistic.
would you consider open sourcing the code for this experiment?
I did! The link is partway down the first couple chapters
cheers
Love these kind of articles, cheers!
Thanks, Vlad! What could you mean by this? It must be the gifs, right? I'll have even more gifs in my next article.
GIFs first and SwiftUI vs UIKit second of course 😁
First off, I really enjoyed reading your detailed comparison of SwiftUI and UIKit performance.
That said, my view is slightly different from the conclusion of the article. Rather than taking the approach that “you should always avoid SwiftUI for performance,” I think it’s important to consider what kind of screen you’re building and how complex it is.
The screen you compared includes a feed-style UI with GIF animations, so if SwiftUI introduces overhead there and causes hangs, I agree that it can create an unpleasant experience for users. But for simpler screens, such as login, settings, or profile screens, I think using SwiftUI’s declarative UI model can still offer a reasonable set of trade-offs.
Since there’s no silver bullet, I personally found the conclusion of the article a bit too strong.
I have checked the SwiftUI code and can see that its not really ideally written. For example, "ForEach(Array(viewModel.visibleItems.enumerated())" will cause extra work. Changing the closures to use capture lists "onStickerDeleted: { [viewModel] itemID, stickerID in" helps. "VisibleItemReporter" which uses GeometryReader with the y coordiate. I only looked at the code shortly but there is a lot of potential to improve it.
Overall I dont think this is a fair comparison. I am guessing you wrote the code with Claude? The AI code is not as good for SwiftUI vs UIKit, simply because it has more training data for UIKit.
Would love to see the code improved and the performance comparsion more realistic.