I have the feeling that SwiftUI was slightly rushed. Swift's language development has been slow and methodical, with a lot of care put into making sure new language features are not only substantially valuable and well conceived from a design standpoint, but also that they don't risk moving the language in a direction which would limit potentially better possibilities in the future. This can be frustrating, as it means it takes a long time for obvious and useful features to make their way into the language (looking at you variadic generics), but the tradeoff is that Swift is a very elegant and well-designed language which doesn't have some of the awkward edges you see in other languages which have to exist for legacy reasons, like you see in C++.

In that respect, it seems like function builders skipped that whole process. It's not that they're a bad feature, and similar facilities exist in other languages, but the fact that they were added to the language without a lengthy vetting process seems very out of character.

In a way I don't even know if it's really needed. I have a project which uses declarative code to achieve similar goals to SwiftUI, and you can get really close without function builders. For instance, you can write code like this:

    var view: [View] {[
        Foo(...),
        Bar(...),
        Baz(...),
    ]}

It's not quite as clean as the function builder approach, and it doesn't have all the same benefits (i.e. producing a typed result vs an array of protocol instances) but it's very easy to understand and doesn't require any additional language features.

My theory is that since Google has been pushing Flutter aggressively, Apple needed to answer with a "modern" FRP-style workflow for iOS to retain its developer mindshare.