View Protocol — Key Concepts, the View Protocol in SwiftUI

What is the View Protocol in SwiftUI?

View Protocol is the central SwiftUI protocol that defines how any visual element describes its content. Unlike UIKit, where each element inherits from UIView through classes, SwiftUI uses a protocol-oriented approach: any type that conforms to the View protocol can be displayed on screen.

The View protocol requires implementing a single computed property body that returns some content. However, behind this simplicity lies a powerful composition system: body can return any type that conforms to View, including primitives (Text, Image, Button), containers (VStack, HStack, ZStack), and custom composite components.

According to WWDC 2023, over 95% of all screens in SwiftUI applications are built through the composition of structures that implement the View protocol. This makes the View Protocol the foundation of the entire SwiftUI architecture.

Value type vs reference type

SwiftUI requires View to be a value type (struct), not a class. This is a key architectural decision: value types have a predictable lifetime, no shared mutable state, and allow SwiftUI to efficiently determine which parts of the hierarchy have changed and need redrawing.

If you try to make a View a class, the compiler will throw an error: the View protocol inherits from the DynamicViewProperty protocol, which requires value semantics. Classes can conform to View, but this breaks the idiomatic approach and forfeits the benefits of automatic updates.

body: The Computed Property of the View Protocol

body is the only required requirement of the View protocol. It is a computed property that returns the content displayed on screen. The return type is some View, which means “a type that conforms to View, to be determined by the compiler”.

struct GreetingView: View {
    var name: String

    var body: some View {
        VStack {
            Text("Hello, \(name)!")
                .font(.title)
                .foregroundColor(.blue)
            Button("Start") {
                print("Button pressed")
            }
        }
    }
}

How body works: SwiftUI calls body every time the application state changes and redrawing is required. The framework compares the new View tree with the old one and applies only the necessary changes (diffing). This is a fully declarative approach — you describe what should be displayed, and SwiftUI takes care of how to implement it.

An important detail: body must not have side effects. It is called multiple times during the application's lifetime, and if body modifies external state, it leads to unpredictable behavior. For side effects, use task, onChange, or DispatchQueue.

Element count limitation

SwiftUI imposes a restriction: body can only return a single root element. If you need to display multiple elements at the same level, wrap them in a container — VStack, HStack, ZStack, or Group. With the introduction of @ViewBuilder, this limitation became less noticeable, but conceptually body always returns a single View.

some View: Opaque Type in the Protocol

some View is the opaque type syntax introduced in Swift 5.1 specifically for SwiftUI. It means that a function or property returns a concrete type that conforms to the View protocol, but the calling code does not know and does not need to know which exact type is returned.

The Swift compiler fixes the concrete type at compile time for each body implementation, but hides it from the outside world. This allows SwiftUI to optimize the View hierarchy by knowing the exact types of all components, while giving the developer flexibility to change implementations without changing the signature.

struct ContentView: View {
    var body: some View {
        Text("Hello, World!") // Compiler knows this is Text
    }
}

Why some View and not just View? If body returned just View (as a protocol), SwiftUI would not be able to determine the concrete type at compile time. This would add overhead for wrapping in an existential container. some View gives the compiler enough information for optimization while maintaining protocol flexibility.

Limitations of some View

The main limitation is that body must return the same type. You cannot return Text in one branch of a condition and Image in another without special wrappers (AnyView, Group, or @ViewBuilder). The compiler checks this at compile time: all possible return paths must have the same type.

To work around this limitation, use @ViewBuilder (creates a single TupleView type), Group (which also returns a single type), or AnyView (erases the type but adds overhead). AnyView should only be used when other options are not possible, as it disables SwiftUI optimizations.

@ViewBuilder: Assembling Multiple Views

@ViewBuilder is a result builder whose annotation allows assembling multiple Views into one composition without nested containers. @ViewBuilder automatically wraps multiple expressions into a tuple (TupleView) or applies conditional logic (If / else / switch) with the correct return type.

struct DashboardView: View {
    var isLoggedIn: Bool

    @ViewBuilder
    var body: some View {
        if isLoggedIn {
            Text("Welcome!")
                .font(.largeTitle)
            ProfileCard()
        } else {
            LoginButton()
                .padding()
        }
    }
}

How @ViewBuilder works: the compiler transforms each block of code inside @ViewBuilder into calls to static methods buildBlock, buildEither, buildOptional, etc. If a block contains multiple expressions, they are wrapped in TupleView. If a block contains conditional logic, the compiler generates ConditionalContent, hiding the branch type.

@ViewBuilder imposes a limitation: up to 10 elements per block (TupleView limitation). If you need to assemble more than ten elements, use Group, ForEach, or split into subcomponents. This limitation exists because Swift generates a separate buildBlock overload for each arity from 1 to 10.

View Composition and Modifiers

Composition is a key principle of SwiftUI: complex interfaces are built from small, reusable View components. Each component implements the View protocol and is responsible for its part of the screen. Modifiers (font, padding, foregroundColor) are applied to a View and return a new View with changed settings.

Modifiers in SwiftUI are not mutations but the creation of a new wrapper around the original View. Each modifier returns a new type (ModifiedContent), allowing SwiftUI to build a modifier tree and efficiently redraw only changed parts. The order of applying modifiers matters: different orders produce different visual results.

Text("Hello, SwiftUI!")
    .font(.title)        // ModifiedContent
    .padding()           // ModifiedContent<..., PaddingModifier>
    .background(.yellow) // ModifiedContent<..., BackgroundModifier>
    .cornerRadius(8)    // ModifiedContent<..., CornerRadiusModifier>

Performance optimization: SwiftUI does not compare concrete View values but their identity through the identity mechanism (id, ForEach, stable identity of structures). If the View structure has not changed, body is not called. This is achieved through Equatable comparison and the PreferenceKey mechanism for passing data up the hierarchy.

For effective composition, it is recommended to split complex screens into independent subcomponents, each with its own minimal state. This allows SwiftUI to redraw only the changed parts of the hierarchy, not the entire screen.