Ironic, given Flutter's infamy regarding performance (jank).

I'm actually surprised at this because while UIKit is hard to use, at least it's fast. Though I remember the concurrency model being confusing, so you could accidentally block your UI thread.

UIKit is pretty fast although a major step down in dev velocity.

AppKit on the other hand seems to be pretty intrinsically slow and the controls are looking increasingly dated.

Odd criticism.

UIKit is the iOS counterpart to MacOS’s AppKit and both are implemented as convenience wrappers around CALayers. They are also infinitely customizable. You can overload UI/NSView and draw vector-pen style on a blank canvas or render whatever you want on a GPU frame buffer. This is how MapKit, Safari, and the Camera view is implemented.

It’s a criticism from recent experience trying to build AppKit based UI. The examples you list barely use the stock widgets.

There’s decades of accumulated cruft in Cocoa that Apple discarded when implementing iOS.

Not sure what you mean by "implemented as convenience wrappers around CALayers," especially when it comes to NSView where you have to opt-in to layer-backing.

Yeah I worried about that going in too but in fact I've found it much easier to get good performance with Flutter than SwiftUI, especially for large collection views and especially on the mac.

The work the Flutter team did on Impeller seems to have paid off.

You should try to implement the iOS photos.app in flutter and see how that goes. This requires scrolling through gigabytes of photos as fast as your finger can swipe without a single hint of slowdown or a loading spinner. And it’s been that fast since.. iOS 7?

Yeah it’s not the language or the SDK that’s slow. Rather it’s inexperienced, lazy, or overworked developers that can’t/won’t write performant software.

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.