[jumhyn]

From what I understand, SwiftUI uses this so that each "snapshot" of the View tree generated by the app can be intelligently diffed against future snapshots. This helps make rendering more efficient, as well as with things like animations. Consider a simple view like:

  var body: some View {
    if someStateBool {
      Text("True")
    } else {
      Text("False")
  }

Suppose that initially, `someStateBool ` evaluates to `true`, and then is updated to `false` (triggering an update. If the control flow were "flattened" (i.e., without `buildEither`), the two snapshots would look like:

  1. Text("True")
  2. Text("False")

The algorithm wouldn't be able to tell the difference between "same view with different string" and "different view entirely". With `buildEither`, the snapshots end up looking more like:

  1. ConditionalContent(first: Text("True"))
  2. ConditionalContent(second: Text("False"))

Now, the update algorithm can determine that the entire view was swapped out for another on the update, rather than just changing the text.

[ridiculous_fish]

It's more fundamental than that. Consider:

    var body : some View {
       if something {
          return Image("hi")
       } else {
         return Text("hi")
       }
    }

this function won't even compile because Swift infers different types for the returns (Image vs Text).

In order to give the return value a type, the if statement has to be encoded in the type system itself.

[jumhyn]

That problem could have been resolved via type erasure (either via `AnyView`, or, if SwiftUI had been designed differently, by having the `body` property be of type `View` rather than `some View`). In fact, opaque types (a la `some View`) were motivated by SwiftUI so that the type information could be preserved to enable the necessary optimizations/animations, without requiring users/library authors to write out/expose the complex type signatures that can arise from even simple view hierarchies.

Incidentally, if you use `AnyView` liberally you’ll likely see worse automatic animations and degraded performance [ETA: the “degraded performance” claim here appears to have been debunked—see the link below for more info!].

[LeoNatan25]

Despite what is claimed about AnyView, this has for the most part been proven wrong. AnyView is just as fast, if not faster.

https://nalexn.github.io/anyview-vs-group/

In fact, Apple themselves use AnyView internally for many of their controller presentations (such as sheets and pushed controllers).

[jumhyn]

Great article! Glad to have that misconception cleared up.