[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.