Splitting Large SwiftUl Views in the Apple's Way

Splitting Large SwiftUI Views in the Apple's way

SubscribeSign in

Splitting Large SwiftUI Views in the Apple's way Extract Subviews, Not Computed Properties (and Where @ViewBuilder Actually Fits)

Emre Degirmenci Jul 07, 2026

Apple recently added this to their Xcode 27 coding skills guidance, and it started a good conversation on X. Vincent shared it and Shannon asked a fair question: if you split a large view, does @ViewBuilder help with identity?

Vincent Pradeilles@v_pradeilles

Don't use computed properties to split a large View 🙅🏽‍♀️🙅🏻‍♂️

This an official bad practice written by Apple in Xcode 27 coding skills

11:29 AM · Jun 30, 2026 · 9.94K Views

9 Replies · 22 Reposts · 210 Likes

My reply was: @ViewBuilder gives you clean structural identity for if/switch branches but it doesn’t create a new invalidation boundary. Same struct, same boundary. Separate View types are still the win for performance imho :)

I applied this in my app Walk Mate while refactoring a few heavy screens. This post is about what I changed, why it matters and where @ViewBuilder still has a place. The Core Idea

When state changes, SwiftUI re-runs the body of the smallest enclosing view type that depends on that state. Everything inside that body gets evaluated again: conditionals, modifier chains, string interpolation, helper functions, computed properties. Same invalidation boundary. Same cost. A separate View struct with narrow inputs gets its own boundary . SwiftUI can skip its body when only its inputs are unchanged. That’s the difference “skip for readability” and “split for performance”. Extract Subviews, Not Computed Properties

What I had before

My ContentView was already split into computed properties: struct ContentView: View { @Bindable var store: StoreOf // TCA thing :) @Namespace private var mapScope

var body: some View { configuredContent

private var configuredContent: some View { lifecycleContent .alert($store.scope(state: \.alert, action: \.alert)) .sheet(item: $store.scope(state: \.settingsSheet, action: \.settingsSheet)) { ... } // many more modifiers...

private var lifecycleContent: some View { mainContent .onAppear { store.send(.onAppear) }

private var mainContent: some View { ZStack(alignment: .bottom) { MapContainerView(store: store, mapScope: mapScope) // map overlays, loading, bottom controls, medal toast, adventure completed...

It reads better than one giant body but every store update still re-evaluates all of those computed properties together. Same story in AdventureCompletedView . The completion card lived inline inside body: var body: some View { if store.walkSession.showAdventureCompleted, let selectedRoute = store.routeGeneration.selectedRoute { ZStack { Color.black.opacity(0.5).ignoresSafeArea()

ScrollView { VStack(spacing: 0) { // trophy, title, stats HStack, achievements, buttons... StatCardView( icon: “medal.fill”, value: “\(selectedRoute.medals.filter { $0.isCollected }.count)/\(selectedRoute.medals.count)”, label: String(localized: “Medals Collected”), iconColor: .yellow // more cards...

Any small animation state change (cardScale , cardOpacity , confetti ) could pull the whole card tree back through evaluation 🔄. What I changed

I replaced computed properties with private view structs, each with a focused job: struct ContentView: View { @Bindable var store: StoreOf @Namespace private var mapScope

var body: some View { ContentConfiguredView(store: store, mapScope: mapScope)

private struct ContentConfiguredView: View { @Bindable var store: StoreOf let mapScope: Namespace.ID

var body: some View { ContentLifecycleView(store: store, mapScope: mapScope) .alert($store.scope(state: \.alert, action: \.alert)) .sheet(item: $store.scope(state: \.settingsSheet, action: \.settingsSheet)) { settingsStore in SettingsView(store: settingsStore, contentStore: store) // sheets only here

private struct ContentLifecycleView: View { @Bindable var store: StoreOf let mapScope: Namespace.ID

var body: some View { ContentMainView(store: store, mapScope: mapScope)

private struct ContentMainView: View { @Bindable var store: StoreOf let mapScope: Namespace.ID

var body: some View { ZStack(alignment: .bottom) { ContentMapLayer(store: store, mapScope: mapScope)

if store.routeGeneration.isGeneratingRoutes { LoadingOverlay()

ContentForegroundStack(store: store)

ContentMedalToastOverlay( medal: store.walkSession.lastCollectedMedal, isShowing: store.walkSession.showMedalCollectionToast, onDismiss: { store.send(.walkSession(.dismissMedalCollectionToast)) }

if store.walkSession.showAdventureCompleted { AdventureCompletedView(store: store)

Then I split the map and foreground UI too: private struct ContentMapLayer: View { @Bindable var store: StoreOf let mapScope: Namespace.ID

var body: some View { MapContainerView(store: store, mapScope: mapScope) .overlay(alignment: .trailing) { if !store.drawRoute.isDrawingRoute && !store.avoidance.isMarkingAvoidanceMode &&...

Splitting Large SwiftUl Views in the Apple's Way

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills

The Anatomy of an AI-Native Org