I’ve been building iOS apps since before Swift existed. Sure like I said if you code directly to UIKit and take a little care performance is good. It’s also very fast in Flutter with even less care. Rendering images in a grid isn’t hard unless your core abstractions are all wrong.

Now try that in SwiftUI. You’ll be forced back to UICollectionView.

That’s cool. I’ve been developing on Mac before Objective-C 2.0 and iOS since the AppStore was released. Millions of downloads, featured in the store, worked on dozens of projects from video games to MFi firmware, and have been invited to Cupertino to meet with teams.

I’m not defending SwiftUI. I mostly use it as a wrapper around NS/UIKit because it’s still buggy and not as flexible.

By the way, SwiftUI is also implemented on top of CALayers just like NS/UIKit. It can be fast in theory, but you have to know exactly where the pain points are and most developers don’t know how to do that.

I'm not sure why you keep bringing up CALayers. That is not where the performance bottleneck lies in SwiftUI.

I don’t think it’s impossible with proper caches to smaller dimension versions (that supposedly Apple already generates/has access to - like they are doing a bunch of processing, like object recognition, etc).

I have a feeling that UICollectionView is more optimized for this than the virtual DOM that React Native uses. There are probably photo apps that use RN anyway, but the native Photos and older Camera Roll app have been 100% lag-free since the iPhone 1, and it makes sense to optimize something everyone uses a lot.

It's only that fast is the thumbnails are not too slow, the data is all there on device, the phone isn't RAM starved, and you largely have the latest iteration of iPhone for the current software, with the most powerful chip available.

In this way, yeah, it's pretty fast. Any other way it's blank square galore.