[sandoze]

So many things wrong with this. Reminds me of the Objective-c vs Swift arguments from back in the day. The author mentions the initial release, as someone who held out migrating production apps to Swift until v3 I think we all know early adoption is going to be bumpy.

But as of iOS 15+ SwiftUI is very production ready. I’ve migrated two production applications from UIKit to SwiftUI. These have active users and are available on the App Store.

Bloated? The last migration resulted in 79k new lines of code written and 181k deletions after rewriting 80% of the application.

Photos album works out of the box. If you mean camera then there are some issues depending on your use case. Beauty of SwiftUI is we can wrap UIKit views and interop allowing it to play nicely with other frameworks.

If you’re supporting applications that target the last few iOS versions it’s time to learn the new paradigm. Do yourself a favor but most of all anyone who might inherit your codebase.

[wahnfrieden]

Try doing performant infinite scrolling on macOS

[sandoze]

I primarily do iOS and iPadOS, but it’s far easier to bridge the gap between all the platforms than the experience I had in the past with UIKit/AppKit. My last MacOS app sadly does not do infinite scrolling.

Off the top of my head, I’d consider the approach. Is it a ScrollView? A LazyVStack? What do your view redraws look like?

Anyone working with Swift Strings back in Swift 1+2 was in for some shockingly bad performance. We adopt, we adapt, and the framework matures.

[wahnfrieden]

LazyVStack and ScrollView don't scale (no cell reuse / no unloading). The only option is List which has different behaviors and performance characteristics on macOS including issues with eager rendering

[sandoze]

To be fair a LazyVStack handles cell reuse and unloading automatically which is why offscreen content that was previously viewed further back on the list will only maintain the root level state (children in the view hierarchy may and will lose state in order to save memory and energy). How that data is loaded and how you key off Identifiable is also important.

Apple’s own documentation discusses this in detail and for large data sets recommends the Lazy approach. If you’re using List you’re in for some issues.

[wahnfrieden]

Where do you see that it does cell reuse? It does not... Their docs only talk about lazy loading, not reuse or unloading, eg: https://developer.apple.com/documentation/swiftui/creating-p...

This is also why LazyVGrid/LazyHGrid are unusable as replacements for UICollectionView

Yes you can replace SwiftUI with UIKit + AppKit - replace the navigation, the text rendering, the text editing, the collection views, etc.

edit: Your link is all about how to use List

[sandoze]

I’m on a phone which means digging through Apple docs or WWDC-ascii isn’t fun. But for my recent Insta-like infinite feed on iOS this was very helpful:

https://fatbobman.com/en/posts/tips-and-considerations-for-u...

[kridsdale1]

Well the good news is you can keep using UICollectionView or MyFancyReuseView anywhere in the stack or tree of SwiftUI.