I mean that’s quite possibly the most charitable, Iraqi-general-during-desert-storm way you could put it.
Eventually it will infect your project because those developers will start pushing it into new features. I regret not being more vocal in my current job about not using it in production and now we have a huge amount of bugs caused by it even between point releases of iOS.
In my extensive experience, this is the only major disadvantage I found: UIs with hundreds of stylized elements can be too slow
I suspect this happens especially because adding style to an element makes the graph deeper (e.g. Text(“”).shadow().colorInvert() means SwiftUI will add three function calls in the stack on each render pass)
But if that case does not apply to your UI, the advantages are massive.
For example my Volum [1] app works on iOS, iPadOS and macOS and because of SwiftUI it shares 95% of the code between platforms. That’s hard enough with other frameworks that I couldn’t even consider starting such a project before SwiftUI.
There's a fair bit of UIKit-parity that's still missing, which forces you to create a ViewRepresentable class and do the UIKit bridging yourself (this ranges in complexity, but can definitely present significant challenge depending on the task). This becomes more frequent too for lesser used Apple platforms (watchOS and tvOS).
Another place that's lacking that the author doesn't quite dig into is that SwiftUI has no concept of cell re-use at all. The Lazy UI components (stacks, grids) will _delay_ their initialization, however, nothing actually ever gets re-used. So if you're working with a layout similar to Netflix, every time you scroll left/right/up/down, new cells are being created and are loading more image data into memory. With UIKit, cell re-use is a foundational concept that all devs should be utilizing, so it's a bit of a headscratcher that something like this is still missing from SwiftUI by now.
To top it all off, as Apple does get SwiftUI up to spec, they are completely resistant to releasing support libraries (or anything along those lines) - so rudimentary UI features/modifiers/etc. that get added years later will only ever support the latest version of iOS and forward. This makes it much more restrictive to work with, as most apps are targeting at least 1 year back and not only the latest major version of the OS.
What's the trade-off here for loading versus pre-loading? I guess if you are pre-loading all of that content is loaded into memory from the start, right? I'm guessing there's a performance advantage to have images pre-loaded, but then:
1. Are you doing that dynamically? How would you know what content to pre-load onto the device? My Netflix queue is different from others.
2. If you're loading a lot of content (like scrolling left/right to get new titles) maybe it makes sense to guess/decide what the next cells off the screen might be and load those up as the user scrolls versus loading them for sure, and what about the case where the user scrolls down/up but not left right? You wouldn't necessarily want to load all of that content unless you know the user is going to look at it? Also wondering how for Netfilx this would factor into their algorithms. If I "like" a show when I first load the app if they pre-load the cells then they'll have more compute to re-load all the cells to change their recommendations?
Curious about this.
How many cells would you create? I guess maybe Netflix has a default limit per category of titles they would display?
This is not true, `List` definitely uses the same approach internally as `UITableView` for cell reuse.
(Pretty misguided in my opinion, but it’s their platform to ruin…)
Objective-C is an awful mess but at least the toolchain is able to natively mix Objective-C, C and C++ code without much effort.
And the low-level parts of iOS are still using C API.
Google tried the same thing at first, Java was the only supported API for many years, they reluctantly added the NDK for "special uses".