DEV Community: Emad Beyrami

Breaking Up Big SwiftUI Views the Right Way

Emad Beyrami — Mon, 17 Aug 2026 23:28:32 +0000

Why computed properties help readability, what `@ViewBuilder` actually does, and when a separate `View` type matters

Every SwiftUI codebase eventually grows a view nobody wants to open.

Four hundred lines. A body that scrolls forever. Several layers of modifiers. State, navigation, sheets, animations, and business logic all living in the same place.

The usual first attempt at cleaning it up is to split body into computed properties:

var body: some View {
    VStack {
        header
        content
        footer
    }
}

private var header: some View {
    // ...
}

private var content: some View {
    // ...
}

private var footer: some View {
    // ...
}

That makes the file easier to read, and that's useful.

But it is important to understand what this refactoring does and doesn't change.

A computed property doesn't create a new View type, a new identity, or an independent dependency-tracking node. It is still part of the same enclosing view's body evaluation.

If you're trying to improve update locality or isolate expensive sections of UI, that's where extracting a separate View type becomes useful.

The important distinction is:

Computed properties organize your source code. Separate View types can organize your view hierarchy, dependencies, state, and update work.

Let's look at why.

The mental model that makes SwiftUI easier to reason about

SwiftUI is easier to understand if you think in terms of three concepts:

Identity — how SwiftUI recognizes something as the same or different across updates.
Lifetime — how SwiftUI associates state with that identity.
Dependencies — which pieces of data a view reads and therefore depends on.

Apple describes these concepts as fundamental to how SwiftUI decides what needs to change and when.

The important one for this discussion is dependencies.

Consider:

struct UserNameView: View {
    let user: User

    var body: some View {
        Text(user.name)
    }
}

With SwiftUI's Observation system, the view establishes a dependency on user.name because its body reads that property.

If user.email changes but body doesn't read email, that change doesn't create the same dependency.

This is why it's better to think:

"What data does this view depend on?"

rather than:

"Which giant view contains this code?"

Apple's documentation explains that Observation tracks the observable properties actually read during a view's body evaluation.

That distinction becomes important when deciding whether a large view should be split.

A computed property is not a separate view

Consider this:

struct DashboardView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Button("Count: \(count)") {
                count += 1
            }

            expensiveSection
        }
    }

    private var expensiveSection: some View {
        ForEach(0..<200) { index in
            RowView(index: index)
        }
    }
}

The computed property makes the source code cleaner.

But expensiveSection is still part of DashboardView.

When DashboardView.body is evaluated again, evaluating the VStack also evaluates the expression that produces expensiveSection.

The compiler doesn't turn that property into an independent SwiftUI view node just because it has a some View return type.

So this:

private var header: some View
private var content: some View
private var footer: some View

is primarily a source-code organization technique.

And that's perfectly fine.

You should absolutely use computed properties when they make a view easier to read.

The mistake is assuming that they automatically create performance boundaries.

Extracting a real `View` type changes the structure

Now compare that with:

struct DashboardView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Button("Count: \(count)") {
                count += 1
            }

            ExpensiveSection()
        }
    }
}

private struct ExpensiveSection: View {
    var body: some View {
        ForEach(0..<200) { index in
            RowView(index: index)
        }
    }
}

ExpensiveSection is now an actual View type.

That gives SwiftUI another node in the hierarchy with its own identity and dependencies.

If ExpensiveSection doesn't depend on count, changing count doesn't automatically mean that the section's own body must be updated because of that state change.

This is an important distinction:

A separate View type doesn't magically make SwiftUI faster. It gives you a place to establish narrower dependencies and isolate state and work.

That's the real benefit.

Narrow inputs matter more than extraction alone

Here's where view extraction becomes particularly useful.

Imagine a dashboard model:

@Observable
final class DashboardModel {
    var sessions: [Session] = []
    var currentStreak: Int = 0
    var isSyncing = false
    var errorMessage: String?
    var selectedWorkout: Workout?
}

You could pass the entire model everywhere:

struct SummarySection: View {
    let model: DashboardModel

    var body: some View {
        VStack {
            Text(model.sessions.count.formatted())
            Text("\(model.currentStreak) days")
        }
    }
}

This is not automatically wrong.

With the Observation framework, SummarySection forms dependencies on the observable properties it actually reads.

So passing an observable reference does not mean that every property change necessarily invalidates the view.

However, passing narrow inputs can still make the dependency surface much clearer:

struct SummarySection: View {
    let sessionCount: Int
    let streakDays: Int

    var body: some View {
        VStack {
            Text(sessionCount.formatted())
            Text("\(streakDays) days")
        }
    }
}

Now the contract is explicit.

SummarySection doesn't know that a dashboard model exists.

It doesn't know about synchronization.

It doesn't know about errors.

It doesn't know about selected workouts.

It only needs two values.

That's useful for several reasons:

The dependencies are obvious.
The view is easier to preview.
The view is easier to test.
The view is easier to reuse.
Changes to unrelated application state don't become part of the view's interface.
Expensive calculations can be performed at an appropriate level rather than repeatedly inside the leaf view.

So the principle isn't:

"Never pass a model."

It's:

Prefer the narrowest inputs that make sense for the view.

A practical example

Suppose the original screen looks like this:

struct DashboardView: View {
    @State private var model = DashboardModel()
    @State private var selectedRange: DateRange = .week
    @State private var isChartExpanded = false

    var body: some View {
        VStack(spacing: 16) {
            summarySection
            chartSection
            controlsSection
        }
        .sheet(item: $model.activeSheet) { sheet in
            SheetHost(item: sheet)
        }
        .task {
            await model.load()
        }
    }

    private var summarySection: some View {
        HStack {
            MetricTile(
                title: "Distance",
                value: model.totalDistance(in: selectedRange)
                    .formatted(.number.precision(.fractionLength(1)))
            )

            MetricTile(
                title: "Streak",
                value: "\(model.currentStreak) days"
            )
        }
    }

    private var chartSection: some View {
        // large chart implementation
    }

    private var controlsSection: some View {
        // controls implementation
    }
}

This isn't necessarily bad code.

The computed properties make it readable.

But the screen still owns:

the model
the selected range
chart state
summary calculations
chart rendering
controls

You can introduce real boundaries:

struct DashboardView: View {
    @State private var model = DashboardModel()

    var body: some View {
        DashboardContent(model: model)
            .sheet(item: $model.activeSheet) { sheet in
                SheetHost(item: sheet)
            }
            .task {
                await model.load()
            }
    }
}

private struct DashboardContent: View {
    let model: DashboardModel

    @State private var selectedRange: DateRange = .week

    var body: some View {
        VStack(spacing: 16) {
            SummarySection(
                totalDistance: model.totalDistance(in: selectedRange),
                streakDays: model.currentStreak
            )

            ChartSection(
                samples: model.samples(in: selectedRange)
            )

            RangeControls(selection: $selectedRange)
        }
    }
}

private struct SummarySection: View {
    let totalDistance: Double
    let streakDays: Int

    var body: some View {
        HStack {
            MetricTile(
                title: "Distance",
                value: totalDistance
                    .formatted(.number.precision(.fractionLength(1)))
            )

            MetricTile(
                title: "Streak",
                value: "\(streakDays) days"
            )
        }
    }
}

Now the code has more meaningful boundaries.

SummarySection doesn't know about the dashboard model.

RangeControls owns the range selection.

ChartSection can own chart-specific state.

And the dashboard screen doesn't have to know how the summary is rendered.

That's a much stronger reason to extract a view than simply making the file shorter.

Don't confuse `body` evaluation with rendering

There's another important SwiftUI distinction.

You will sometimes hear:

"The parent body ran, so all the views were rebuilt."

That's misleading.

SwiftUI views are lightweight value descriptions. Evaluating body produces new view values, and SwiftUI uses identity and dependencies to determine what needs to change in the resulting hierarchy.

Evaluating a body does not mean that 200 platform views were necessarily recreated or that 200 rows were necessarily redrawn on screen.

For example:

struct CounterScreen: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Button("Count: \(count)") {
                count += 1
            }

            ForEach(0..<200) { index in
                RowView(index: index)
            }
        }
    }
}

When count changes, CounterScreen.body can be evaluated again.

That doesn't mean SwiftUI throws away the entire UI and constructs 200 new UIKit/AppKit views.

SwiftUI evaluates the new view description and reconciles it with the existing hierarchy.

This is why statements such as:

"The button rebuilds 200 rows"

should be avoided unless you're very specifically describing body evaluation.

A better statement is:

"The parent body is evaluated again, so the expressions that produce the list are evaluated again. SwiftUI then determines which parts of the resulting hierarchy actually need updating."

That distinction is important.

So when should you extract a `View`?

Not every computed property deserves its own type.

Use a separate View when it gives you a meaningful seam.

Good reasons include:

1. The section owns state

For example:

struct ChartSection: View {
    let samples: [Sample]

    @State private var isExpanded = false

    var body: some View {
        // ...
    }
}

If the state belongs specifically to the chart, the chart is a natural owner.

2. The section has a distinct dependency surface

If a component only needs:

let title: String
let value: String
let isHighlighted: Bool

that's a useful boundary.

3. The section contains expensive computation

For example:

struct StatisticsSection: View {
    let sessions: [Session]

    private var statistics: Statistics {
        calculateStatistics(from: sessions)
    }

    var body: some View {
        // ...
    }
}

Putting this work behind a meaningful component can make ownership clearer.

But don't assume extraction alone solves the performance problem.

If calculateStatistics is expensive, consider whether the calculation should instead be:

cached,
moved into the model,
computed incrementally,
performed asynchronously,
or otherwise optimized.

A new View type isn't a substitute for fixing expensive computation.

4. You want a reusable component

This is the easiest case:

MetricTile(
    title: "Distance",
    value: "12.4 km"
)

If the component appears in multiple places, make it a component.

5. You want an independently previewable component

This:

#Preview {
    SummarySection(
        totalDistance: 12.4,
        streakDays: 8
    )
}

is much easier to work with than constructing an entire application's model just to preview a small section.

Where does `@ViewBuilder` fit?

This is where SwiftUI developers often mix up two different concepts.

@ViewBuilder is primarily about building view structure.

It allows you to express conditional and multi-view content conveniently:

@ViewBuilder
private var statusIndicator: some View {
    switch connectionStatus {
    case .offline:
        OfflineBadge()

    case .syncing:
        ProgressView()

    case .connected:
        Image(systemName: "checkmark.circle.fill")
    }
}

This is a perfectly good use of @ViewBuilder.

You don't need three separate view types just because there are three small branches.

@ViewBuilder makes the composition expressive.

What `@ViewBuilder` does not do

@ViewBuilder is not a performance annotation.

Consider:

struct CounterScreen: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Button("Count: \(count)") {
                count += 1
            }

            expensiveList()
        }
    }

    @ViewBuilder
    private func expensiveList() -> some View {
        ForEach(0..<200) { index in
            RowView(index: index)
        }
    }
}

Adding @ViewBuilder doesn't turn expensiveList() into an independent view type.

It changes how the function can build its result.

The function still belongs to CounterScreen.

If you genuinely want a separate component, make it one:

struct CounterScreen: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Button("Count: \(count)") {
                count += 1
            }

            ExpensiveList()
        }
    }
}

private struct ExpensiveList: View {
    var body: some View {
        ForEach(0..<200) { index in
            RowView(index: index)
        }
    }
}

Now ExpensiveList has its own type, identity, dependencies, and state ownership.

The important distinction is:

@ViewBuilder helps you express view structure. A separate View type gives you a separate component with its own dependency and state boundary.

But don't extract everything

There's a temptation to take this advice too far.

You don't need:

struct TitleView: View
struct SubtitleView: View
struct IconView: View
struct DividerView: View

for every three lines of SwiftUI.

This can make the code harder to follow.

For small, purely structural pieces, this is often perfectly reasonable:

@ViewBuilder
private var statusView: some View {
    if isLoading {
        ProgressView()
    } else {
        Image(systemName: "checkmark")
    }
}

Use a separate type when the component has a meaningful responsibility.

Don't create types just to increase the number of files.

The identity trap: conditional modifiers

There is another SwiftUI issue that becomes easier to understand once identity is clear.

Consider this pattern:

extension View {
    @ViewBuilder
    func applyIf<Content: View>(
        _ condition: Bool,
        transform: (Self) -> Content
    ) -> some View {
        if condition {
            transform(self)
        } else {
            self
        }
    }
}

You might then write:

Rectangle()
    .applyIf(isCompact) {
        $0.frame(width: 100)
    }

It looks convenient.

But the if creates structurally different view branches.

When you are actually trying to modify the same logical view, it's usually better to express the condition as a modifier parameter:

Rectangle()
    .frame(width: isCompact ? 100 : nil)

The second version keeps the operation on the same logical view rather than conditionally producing two different structures.

This matters for identity, state lifetime, transitions, and animations.

But `if` is not bad

This distinction is important.

Don't take the previous section to mean:

"Never use if in SwiftUI."

That's completely wrong.

This is perfectly normal:

if isLoading {
    ProgressView()
} else {
    ContentView()
}

Those are genuinely different pieces of UI.

Conditional structure is exactly what @ViewBuilder is designed to express.

The problem is using structural branching to conditionally apply a modifier to what is conceptually the same view.

A useful rule is:

Use structural branching when the content is actually different. Prefer conditional modifier parameters when the content is the same and only a property changes.

State belongs where it is used

Another benefit of extracting views is clearer state ownership.

Instead of:

struct DashboardView: View {
    @State private var isChartExpanded = false
    @State private var selectedRange: DateRange = .week
    @State private var showDetails = false

    // hundreds of lines...
}

you can move state toward the component that owns it:

struct DashboardView: View {
    @State private var selectedRange: DateRange = .week

    var body: some View {
        VStack {
            ChartSection()
            RangeControls(selection: $selectedRange)
        }
    }
}

struct ChartSection: View {
    @State private var isExpanded = false

    var body: some View {
        // ...
    }
}

Now the state has a clear owner.

This also makes the lifetime of that state easier to reason about because SwiftUI associates state with the identity of the view that owns it.

That's one reason structural identity matters.

A useful code-review checklist

When reviewing a large SwiftUI view, ask these questions.

1. Is this computed property only improving readability?

If yes, that's fine.

Don't extract it solely because someone says every some View property should become a struct.

2. Does this section have its own state?

If yes, consider making it a separate View.

3. Does this section have a distinct dependency surface?

If it only needs:

let title: String
let count: Int
let isEnabled: Bool

that's often a good component boundary.

4. Am I passing an entire model when the component only needs a few values?

Prefer narrow inputs when practical.

But remember that with the Observation framework, passing an observable reference does not automatically mean the view depends on every property of that object. Dependencies are established by the properties read by body.

5. Am I doing expensive work during `body` evaluation?

If yes, ask whether that work should be:

moved,
cached,
simplified,
performed asynchronously,
or otherwise optimized.

Extracting a view can improve structure, but it doesn't automatically make expensive algorithms cheap.

6. Am I using `@ViewBuilder` because I need conditional structure?

Good.

Am I using it because I believe it creates a performance boundary?

That's the wrong reason.

7. Am I conditionally applying a modifier with `if`?

Ask whether the modifier can instead take a conditional parameter:

.padding(isCompact ? 8 : 16)

rather than creating separate structural branches unnecessarily.

8. Does this component have a meaningful responsibility?

If yes, a separate type may improve the architecture.

If not, a computed property may be clearer.

What about performance?

This is the most important qualification.

Don't turn view extraction into a cargo-cult performance rule.

This:

struct SmallView: View {
    var body: some View {
        Text("Hello")
    }
}

isn't automatically faster than:

private var smallView: some View {
    Text("Hello")
}

And making a view smaller doesn't automatically make the application faster.

The value of extraction comes from better separation of dependencies, state, identity, and work.

If you have a performance problem, measure it.

Useful things to investigate include:

How often is a view's body being evaluated?
Which state changes cause the evaluation?
Is expensive computation happening during body evaluation?
Are large collections being transformed repeatedly?
Is layout expensive?
Is drawing expensive?
Is an animation causing frequent updates?
Is state owned at the wrong level?
Are observable dependencies broader than necessary?

Use Instruments and SwiftUI's debugging/profiling facilities rather than assuming that a refactoring is faster because it looks more modular.

The rule of thumb

Here's the mental model I use:

Computed properties are for organizing a view's implementation.

@ViewBuilder is for expressing view structure and conditional composition.

Separate View types are for creating meaningful components with their own identity, state ownership, dependencies, and responsibilities.

Narrow inputs make those boundaries easier to reason about.

Performance improvements should be measured rather than assumed.

That's a much more reliable way to structure SwiftUI code.

The practical takeaway

When you encounter a 500-line SwiftUI view, don't immediately turn every computed property into another struct.

Instead, look for meaningful boundaries.

Start with sections that:

own local state,
have a distinct set of dependencies,
perform meaningful computation,
contain complex UI,
are reused,
need independent previews,
or are updated independently from the rest of the screen.

For example:

struct DashboardView: View {
    @State private var model = DashboardModel()

    var body: some View {
        DashboardContent(
            summary: SummaryData(
                distance: model.totalDistance,
                streak: model.currentStreak
            ),
            samples: model.samples
        )
    }
}

Then let the components own their own concerns:

struct DashboardContent: View {
    let summary: SummaryData
    let samples: [Sample]

    var body: some View {
        VStack {
            SummarySection(data: summary)
            ChartSection(samples: samples)
        }
    }
}

And keep small structural branches local:

@ViewBuilder
private var connectionStatus: some View {
    switch status {
    case .offline:
        OfflineBadge()

    case .syncing:
        ProgressView()

    case .connected:
        ConnectedBadge()
    }
}

That's a good balance.

You get readable code without turning the entire application into hundreds of tiny view types.

Final thought

Breaking up a large SwiftUI view isn't about hitting a magic number of lines.

It's about making the structure of the UI reflect the structure of its responsibilities.

A computed property can make a large view easier to read.

A @ViewBuilder can make conditional composition easier to express.

A separate View type can give a piece of UI a clearer identity, state owner, dependency surface, and responsibility.

And when performance is the motivation, the most important question isn't:

"Did I extract this into a struct?"

It's:

"Did I reduce unnecessary dependencies or expensive work, and can I measure the difference?"

That's the approach that scales.

Supporting Multiple iOS Versions in SwiftUI Without Turning Your Views Into a Mess

Emad Beyrami — Wed, 29 Jul 2026 22:21:00 +0000

One of the nicest things about SwiftUI is how quickly it evolves. Every WWDC introduces new APIs, new modifiers, and little improvements that make building interfaces cleaner or require less code than before.

Naturally, you want to start using those improvements.

Then the compiler reminds you that your app still supports older versions of iOS.

'sectionIndexLabel' is only available in iOS 26.0 or newer

At first, this doesn't seem like a huge problem. Swift has supported availability checks for years, so it feels like wrapping the new code in an if #available should solve everything.

Unfortunately, SwiftUI isn't quite that straightforward.

Most views are built as long chains of modifiers, and you can't simply drop an availability check in the middle of one. You could duplicate an entire view for different iOS versions, but that quickly becomes difficult to maintain as your UI grows.

Instead, the goal should be to isolate the compatibility code while keeping the view itself almost identical.

If you want a ready-made version of these patterns, I also built SwiftUIBackportKit - a tiny, dependency-free Swift Package that packages the ideas in this article into a real API instead of copy-paste helpers. here is the link SwiftUIBackportKit

In this article, we'll look at a few approaches that make supporting multiple iOS versions much cleaner without sacrificing readability.

Checking API Availability

Swift already provides built-in availability checks for this exact purpose.

if #available(iOS 26, *) {
    // New implementation
} else {
    // Older implementation
}

Or, if you find it easier to think in terms of older operating systems:

if #unavailable(iOS 26) {
    // Older implementation
}

When the app runs on a newer version of iOS, Swift executes the first branch. Otherwise, it safely falls back to the alternative implementation.

If you've worked with UIKit before, this is probably a familiar pattern.

Note

If you're experimenting with an iOS version that's still in beta, older versions of Xcode won't recognize it yet. It's usually easier to keep those changes in a separate branch until the matching Xcode release becomes available.

Why Doesn't This Work Inside a Modifier Chain?

This is where SwiftUI catches a lot of people.

Imagine you have a simple view.

Text("Hello, World!")
    .padding()
    .foregroundStyle(.blue)

Now suppose newModifier() only exists on iOS 26.

Your first instinct might be something like this.

Text("Hello, World!")
    .padding()

if #available(iOS 26, *) {
    .newModifier()
}

Unfortunately, Swift won't compile this.

The reason is that a modifier chain isn't a series of statements it's one continuous expression.

Every modifier returns a brand-new view, which becomes the input for the next modifier. Once you break that chain with an if statement, the compiler can no longer treat it as a single expression.

So while if #available works perfectly in normal Swift code, it doesn't fit naturally inside a modifier chain.

Instead of rewriting an entire view just to add one conditional modifier, it's much cleaner to create a small helper that gives us somewhere to perform that conditional logic.

A Small Helper for Conditional Modifiers

A simple extension is enough.

import SwiftUI

extension View {

    @ViewBuilder
    func applying<Content: View>(
        @ViewBuilder _ transform: (Self) -> Content
    ) -> some View {
        transform(self)
    }

}

Instead of interrupting the modifier chain, we wrap the current view inside a closure.

Section {

}
.applying { view in
    if #available(iOS 26, *) {
        view
            .sectionIndexLabel(Text("Favorites"))
    } else {
        view
    }
}

The view hierarchy remains intact because Swift still sees a single expression. The conditional logic is simply moved inside the closure, where control flow is allowed.

One thing that's easy to overlook is the else branch.

else {
    view
}

Always return the original view when the new API isn't available.

Without it, that portion of your interface simply disappears on older versions of iOS.

This pattern works well whenever you need to conditionally apply one or more modifiers without changing the rest of the view.

Sometimes You Don't Need Different Views

Not every compatibility issue involves a brand-new API.

Sometimes the modifier already exists everywhere you just want to tweak a value on newer versions of iOS.

Spacing, padding, animation timing, and layout adjustments are common examples.

Rather than branching your view hierarchy, you can branch the value itself.

func platformValue<T>(
    new: T,
    old: T
) -> T {
    if #available(iOS 26, *) {
        new
    } else {
        old
    }
}

Now your modifier stays exactly the same.

.padding(.trailing, platformValue(new: 0, old: 16))

Personally, I prefer this approach whenever only a value changes. It keeps the view easy to scan because the modifier chain never gets interrupted.

Reuse Compatibility Logic

If you notice yourself writing the same availability check throughout your project, it's usually worth extracting it into a custom modifier.

extension View {

    @ViewBuilder
    func compatibleSectionIndexLabel(_ label: Text) -> some View {
        if #available(iOS 26, *) {
            self.sectionIndexLabel(label)
        } else {
            self
        }
    }

}

Using it is no different than any other SwiftUI modifier.

Section {

}
.compatibleSectionIndexLabel(Text("Favorites"))

This has another advantage besides readability.

If you eventually stop supporting older versions of iOS, there's only one place to update. Remove the compatibility logic here, and every usage automatically starts using the native modifier.

Organizing Everything with a Backport Namespace

For small projects, custom modifiers are usually enough.

Larger projects, however, can accumulate dozens of these compatibility helpers. Prefixing everything with names like compatible... or legacy... eventually starts feeling noisy.

A common solution is to group them under a dedicated namespace.

import SwiftUI

struct Backport<Content> {
    let content: Content
}

extension View {

    var backport: Backport<Self> {
        Backport(content: self)
    }

}

From there, you can expose compatibility APIs that closely mirror SwiftUI itself.

extension Backport where Content: View {

    @ViewBuilder
    func sectionIndexLabel(_ label: Text) -> some View {
        if #available(iOS 26, *) {
            content.sectionIndexLabel(label)
        } else {
            content
        }
    }

}

Which lets you write this:

Section {

}
.backport.sectionIndexLabel(Text("Favorites"))

I like this pattern because it makes compatibility code easy to spot. Whenever I see .backport, I immediately know I'm looking at an API that's only there because of deployment target constraints.

It also makes cleanup much easier later on. Once older iOS versions are dropped, every compatibility helper lives in one place instead of being scattered across the project.

A Practical SDK Option

At this point, you have two choices:

Keep these helpers local to your project.
Move them into a reusable package.

For many teams, the second option is the more convenient one.

That's exactly what SwiftUIBackportKit is for. It's a lightweight, dependency-free Swift Package that brings the patterns from this article into a reusable API, so you don't have to rebuild the same compatibility helpers for every project.

The package includes:

.modify { } for conditionally applying view transforms without breaking the modifier chain.
.backport for reusable version-gated SwiftUI APIs.
platformValue(_:ifAtLeast:else:) for version-specific values.
OS.isAtLeast(_:) for simple runtime version checks outside of SwiftUI views.

That makes it a convenient option if you want to adopt these patterns without maintaining the underlying infrastructure yourself.

Here's a simple example:

import SwiftUI
import SwiftUIBackportKit

struct RowView: View {
    let title: String

    var body: some View {
        Text(title)
            .font(.headline)
            .modify {
                if #available(iOS 17, *) {
                    $0.contentTransition(.numericText())
                } else {
                    $0
                }
            }
            .padding(
                .vertical,
                platformValue(12, ifAtLeast: OSVersion(17), else: 8)
            )
    }
}

The package also includes a growing collection of backported SwiftUI APIs, along with unit tests and an example app, making it a practical option for projects that need to support multiple iOS versions.

👉 GitHub: https://github.com/EmadBeyrami/SwiftUIBackportKit

Which Approach Should You Use?

There's no universal solution, and that's perfectly fine.

Here's the approach I generally follow:

Situation	Recommended Approach
A one-off compatibility check	`if #available`
Applying a modifier conditionally	`applying {}`
Only changing a value	A helper function
Reusing the same logic repeatedly	A custom modifier
Supporting lots of compatibility APIs	A `.backport` namespace

As with most things, start simple.

If an availability check only appears once, don't over-engineer it. If it starts showing up everywhere, that's usually a good signal that it's time to extract it into something reusable.

Final Thoughts

Supporting multiple iOS versions is one of those things that starts out simple and gradually becomes messy if you're not careful.

The trick isn't avoiding availability checks altogether it's keeping them from taking over your view code.

By isolating compatibility logic into small helpers, reusable modifiers, or a dedicated backport namespace, your SwiftUI views stay focused on describing the UI rather than worrying about deployment targets.

And when the day finally comes to raise your minimum iOS version, cleaning everything up becomes much less painful.

The Silent iOS 17 Crash Hiding in `@Dependency` and `withTaskGroup`

Emad Beyrami — Wed, 29 Jul 2026 16:59:51 +0000

A subtle Swift Concurrency pitfall for developers using Point-Free's swift-dependencies.

I recently tracked down a crash that only affected users running iOS 17.

The stack trace pointed deep into Swift's concurrency runtime:

swift_task_reportIllegalTaskLocalBindingWithinWithTaskGroup

None of my code interacted with task-local values directly. The only suspicious line was reading a @Dependency property from Point-Free's swift-dependencies library inside a withThrowingTaskGroup.

The exact same code worked flawlessly on iOS 18.

After digging into Swift's task-local behavior, the cause turned out to be surprisingly subtle.

TL;DR

Reading a @Dependency property inside a withTaskGroup or withThrowingTaskGroup body including inside an addTask closure's capture list can crash on iOS 17 with a fatal swift_task_reportIllegalTaskLocalBindingWithinWithTaskGroup trap.

The same code runs without issue on iOS 18+, making it easy to miss during development.

The fix is simple:

let client = self.client

try await withThrowingTaskGroup(of: ...) { group in
    group.addTask {
        try await client.doWork()
    }
}

Resolve every @Dependency before entering the task group.

Background: How `swift-dependencies` Works

Point-Free's swift-dependencies provides dependency injection built on top of Swift's task-local values.

A dependency might look like this:

@Observable
final class MyViewModel {

    @ObservationIgnored
    @Dependency(\.myClient)
    private var myClient
}

Although myClient looks like a stored property, accessing it isn't just a simple field lookup. The property wrapper resolves the dependency from the current task-local dependency context.

This design is what makes scoped dependency overrides possible:

withDependencies {
    $0.myClient = .mock
} operation: {
    // Uses the mocked dependency
}

It's an elegant approach that integrates naturally with Swift Concurrency but it also means dependency access participates in the task-local system.

The Problem: Task-Local Values and Task Groups

Swift's structured concurrency places an important restriction on task-local values.

Child tasks inherit the task-local values that exist when they're created. Allowing new task-local bindings while a task group is actively spawning children would make inheritance ambiguous, so the runtime explicitly forbids it.

On iOS 17, violating this rule results in an immediate runtime trap:

Fatal error:
Attempted to write to a task local value from a task group.

Internally, this comes from:

swift_task_reportIllegalTaskLocalBindingWithinWithTaskGroup

How `@Dependency` Triggers It

The surprising part is that you're not explicitly writing to a task-local value.

You're simply reading a property:

self.connectionClient

However, swift-dependencies ultimately resolves dependencies through Swift's task-local infrastructure. On iOS 17, accessing a @Dependency from inside a task group body can trigger the runtime's task-local binding restriction, causing an immediate fatal error.

The same code does not crash on iOS 18, making this especially difficult to discover if your development devices and simulators are already running the latest OS.

A Concrete Example

Consider a service that performs multiple checks concurrently:

@Observable
final class MyService {

    @ObservationIgnored
    @Dependency(\.connectionClient)
    private var connectionClient

    func checkConnections() async throws {

        try await withThrowingTaskGroup(of: Bool.self) { group in

            // ❌ Crashes on iOS 17
            group.addTask { [connectionClient] in
                try await connectionClient.isAvailable()
            }

            // ❌ Also crashes
            let connected = try await connectionClient.currentState()

            for try await result in group {
                ...
            }
        }
    }
}

Both accesses occur inside the task group body.

Even the capture list is evaluated while constructing the closure, so the dependency is still being resolved from within the task group before the child task begins executing.

Why the Capture List Doesn't Help

A common instinct is to write:

group.addTask { [connectionClient] in
    ...
}

It looks like the dependency is copied before the task starts.

Unfortunately, that's not what happens.

Capture lists are evaluated when the closure is created, and the closure is created inside the task group body. Reading the dependency still occurs within the task group, triggering the same runtime restriction on iOS 17.

The Fix

Resolve every dependency before entering the task group.

func checkConnections() async throws {

    // ✅ Resolve outside the task group
    let connectionClient = self.connectionClient

    try await withThrowingTaskGroup(of: Bool.self) { group in

        group.addTask {
            try await connectionClient.isAvailable()
        }

        for try await result in group {
            ...
        }
    }
}

The local constant contains the already-resolved dependency, so no task-local access occurs inside the task group.

The behavior is identical across iOS 17 and iOS 18.

Why This Bug Slips Into Production

1. It only affects iOS 17

Most developers build and test on the latest OS.

If your development devices, CI, and QA all run iOS 18, you'll never encounter this crash.

Meanwhile, users still running iOS 17 experience a deterministic runtime failure.

2. There are no compiler warnings

Swift provides no static analysis for this pattern.

The code compiles cleanly with zero warnings.

The failure is entirely runtime-enforced.

3. The stack trace isn't obvious

Instead of pointing directly at your code, the crash appears inside Swift's concurrency runtime:

Thread 1: EXC_BREAKPOINT (SIGTRAP)

swift_task_reportIllegalTaskLocalBindingWithinWithTaskGroup
swift_task_localValuePush
...
swift-dependencies
...
Your @Dependency getter

Unless you already know how swift-dependencies works internally, it's difficult to connect the runtime trap back to a seemingly innocent property access.

4. `@Dependency` Looks Like a Stored Property

This declaration feels no different than any other property:

@Dependency(\.connectionClient)
private var connectionClient

Nothing in the syntax suggests that accessing it interacts with Swift's task-local machinery.

It's natural to treat it like a stored property including capturing it inside a task group until iOS 17 reminds you otherwise.

Finding Affected Code

A quick way to identify potentially affected code is to search for files that contain both @Dependency and task groups:

grep -rl "withTaskGroup\|withThrowingTaskGroup" --include="*.swift" . | \
xargs grep -l "@Dependency"

Then inspect each occurrence.

Safe

let client = self.client

withTaskGroup { group in
    group.addTask {
        try await client.doWork()
    }
}

Unsafe

withTaskGroup { group in

    group.addTask { [client] in
        ...
    }

    let state = self.client
}

If a @Dependency is accessed anywhere inside the task group body, move it outside.

Reproducing the Crash

To verify the issue yourself:

Download an iOS 17 simulator runtime from Xcode → Settings → Platforms.
Create an iOS 17 simulator.
Run the affected code path.
The crash is immediate and deterministic.

Testing on iOS 18 alone won't reproduce it.

Summary


Affected OS	iOS 17.x
iOS 18+	No crash observed
Compiler warning	None
Crash	`swift_task_reportIllegalTaskLocalBindingWithinWithTaskGroup`
Root cause	Accessing a `@Dependency` inside a task group interacts with task-local state in a way the iOS 17 runtime rejects
Fix	Resolve every `@Dependency` before entering the task group

Final Takeaway

The lesson isn't just about swift-dependenciesit's about property wrappers built on top of Swift Concurrency.

A property may look like a simple stored value while performing considerably more work under the hood.

Whenever you combine swift-dependencies with withTaskGroup or withThrowingTaskGroup, make it a habit to resolve your dependencies before entering the task group:

let connectionClient = self.connectionClient
let analytics = self.analytics
let logger = self.logger

try await withThrowingTaskGroup(of: Void.self) { group in

    group.addTask {
        try await connectionClient.doWork()
    }

    group.addTask {
        await analytics.track()
    }

    group.addTask {
        logger.log("Finished")
    }
}

It's a tiny change, but it avoids a crash that's easy to miss during development and difficult to diagnose once it reaches production.

Have you run into similar Swift Concurrency edge cases? I'd love to hear about them in the comments.

Build a SwiftUI PreviewProvider for UIKit Views

Emad Beyrami — Tue, 02 Aug 2022 10:32:00 +0000

Build a SwiftUI PreviewProvider for UIKit Views

A simple way to see your UIKit ViewController changes instantly — live and on-demand

Have you ever tried the SwiftUI? Haven’t you found it so delightful and easy to work with?

However, in UIKit views, if you are prototyping a design in your codebase, you have to recompile and build your project every time to see the results in the simulator. But in SwiftUI it’s so pleasant to view changes on-demand without rebuilding.

What if we can do that something similar to it for our UIKit Components? Like previewing or hot reloading the UIKit changes immediately without the time-consuming build and compile process.

Essentially, we’re looking to create a live preview system for our UIKit views using SwiftUI.

There are many ways to make this process easier such as simple annotations like @IBDesignable, @IBInspectable and etc.

But if you have experience using these sometimes it gets buggy and causes some compile errors for rational reasons and sometimes it’s not the best approach.

So in this article, you will learn a new and way simpler way to see your changes instantly. if you used SwiftUI you already know it but we add a little trick to it so it will work with UIKit.

SwiftUI: PreviewProvider

PreviewProvider is a protocol type that produces view previews in Xcode. It contains an associated type called Previews which is of type View. View is a SwiftUI view that we’ll return for the PreviewProvider to display — we’ll see this later.

After creating an object which is conforming to this protocol, we’ll pass the view we want to see in our preview. It’ll automatically pop up a split view like the picture below.

If the preview doesn’t load, worry not: simply use the below keyboard shortcut to see the reset the live preview:

⌘ + ⌥ + Return (Command + option + Return)

Note: Make sure to click on the resume button that appears in the upright corner of the preview content if you won’t see that it means it is working and showing you the live content.

UIKit: PreviewProvider

So now that we know about the PreviewProvider and how it works in SwiftUI, how can we achieve this in UIKit?

The answer is simple: We have to convert our UIKit codebase into something that SwiftUI understands and use the SwiftUI PreviewProvider to see the live simulation of the content. Any guesses how?

How to convert UIKit content to SwiftUI Content?

It is way easier than you think. Don’t make it complicated. All we need is the popular UIViewControllerRepresentable protocol.

UIViewControllerRepresentable acts as a bridge to help convert the UIViewController to SwiftUI view. Have you guessed what are we planning to do yet?

Implementation

Now that we know about UIViewControllerRepresentable and PreviewProvider in SwiftUI, Let’s get our hands dirty and use them in a practical way.

UIKit Controller

Let’s create a simple UIKit controller (UIViewController) which contains some UI modifications:

class ViewController: UIViewController {

    @IBOutlet var imageView: UIImageView!
    @IBOutlet var titleLabel: UILabel!
    @IBOutlet var confirmBtn: UIButton!

    override func viewDidLoad() {
        super.viewDidLoad()
        // Do any additional setup after loading the view.
        setupView()
    }

    private func setupView() {
        imageView.layer.cornerRadius = imageView.frame.height / 2
        imageView.clipsToBounds = true
        imageView.layer.borderWidth = 1
        imageView.layer.borderColor = UIColor.red.cgColor

        titleLabel.text = "This is a test ViewController to see if we can use swiftUI previews for UIKit Controllers"

        confirmBtn.setTitle("Confirm", for: .normal)
        confirmBtn.backgroundColor = .cyan
        confirmBtn.clipsToBounds = true
        confirmBtn.layer.borderWidth = 1
        confirmBtn.layer.borderColor = UIColor.blue.cgColor
        confirmBtn.layer.cornerRadius =  20
    }
 }

If we run this ViewController you will see something like this:

Now let's create a SwiftUI Preview. Any changes we’ll make in the UIKit UI could be simply displayed in real-time and we won’t have to build and compile like earlier.

Convert this UIViewController to SwiftUI Controller

We simply make an object from our controller which is conforming to UIViewControllerRepresentable to make it readable for SwiftUI.

import Foundation

#if canImport(SwiftUI) && DEBUG
import SwiftUI

struct ViewControllerRepresentable: UIViewControllerRepresentable {

    func makeUIViewController(context: Context) -> some UIViewController {
        return UIStoryboard(name: "Main", bundle: nil).instantiateInitialViewController()!
    }

    func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {

    }
}
#endif

In the code above:

canImport(SwiftUI) is used to ensure it will compile only for the iOS versions which support SwiftUI .
DEBUG makes sure it is running in our debug environment only.
Inside the MakeUIViewController(context: Context) function, you should simply instantiate the Controller you want to see in previews.
Here I just instantiated my Main Storyboard.

Preview our `UIViewController` using PreviewProvider

Now that we have the UIViewController and have already converted it to SwiftUI Controller we just have to add a few lines of code for our PreviewProvider.

Add the following lines of code before the #endif:

struct ViewController_Preview: PreviewProvider {
    static var previews: some View {
         ViewControllerRepresentable()    
    }
}

The full code should look like this:

import Foundation

#if canImport(SwiftUI) && DEBUG
import SwiftUI

struct ViewControllerRepresentable: UIViewControllerRepresentable {

    func makeUIViewController(context: Context) -> some UIViewController {
        return UIStoryboard(name: "Main", bundle: nil).instantiateInitialViewController()!
    }

    func updateUIViewController(_ uiViewController: UIViewControllerType, context: Context) {

    }
}

struct ViewController_Preview: PreviewProvider {
    static var previews: some View {
        ViewControllerRepresentable()
    }
}
#endif

Now that we have the full codebase, you can see the live preview of the UIKit UIViewController on-demand. Try modifying the UI slightly and notice the instant results. Say goodbye to the time-consuming building process.

That’s all for now. Thanks for reading. You can check the full source code below:

EmadBeyrami / UIKitPreviews

SwiftUI preview provider for UIKit

A simple way to see your UIKit ViewController changes live and on-demand.

This is a practical project for my article SwiftUI preview provider for UIKit it is usefull. read it. :)

Introduction

Have you ever tried the SwiftUI haven’t you found it so delightful and easy to work with In UIKit views, if you are working on a piece of design that is mostly working with your codebase and you have to check it every once in a while to make sure your code makes the UI design you are trying to make; So every now and then you compile and build your code into the simulator to check your code result but in SwiftUI you can see the changes you made on-demand without having to wait for your project to build and compile What if we can use that or something similar to it…

View on GitHub

Buy me a coffee ☕️:

Donate

paypal.com

nowpayments.io

Refrences:

My Medium:

betterprogramming.pub

DEV Community: Emad Beyrami

Breaking Up Big SwiftUI Views the Right Way

Why computed properties help readability, what @ViewBuilder actually does, and when a separate View type matters

The mental model that makes SwiftUI easier to reason about

A computed property is not a separate view

Extracting a real View type changes the structure

Narrow inputs matter more than extraction alone

A practical example

Don't confuse body evaluation with rendering

So when should you extract a View?

1. The section owns state

2. The section has a distinct dependency surface

3. The section contains expensive computation

4. You want a reusable component

5. You want an independently previewable component

Where does @ViewBuilder fit?

What @ViewBuilder does not do

But don't extract everything

The identity trap: conditional modifiers

But if is not bad

State belongs where it is used

A useful code-review checklist

1. Is this computed property only improving readability?

2. Does this section have its own state?

3. Does this section have a distinct dependency surface?

4. Am I passing an entire model when the component only needs a few values?

5. Am I doing expensive work during body evaluation?

6. Am I using @ViewBuilder because I need conditional structure?

7. Am I conditionally applying a modifier with if?

8. Does this component have a meaningful responsibility?

What about performance?

The rule of thumb

The practical takeaway

Final thought

Further reading

Supporting Multiple iOS Versions in SwiftUI Without Turning Your Views Into a Mess

Checking API Availability

Why Doesn't This Work Inside a Modifier Chain?

A Small Helper for Conditional Modifiers

Sometimes You Don't Need Different Views

Reuse Compatibility Logic

Organizing Everything with a Backport Namespace

A Practical SDK Option

Which Approach Should You Use?

Final Thoughts

The Silent iOS 17 Crash Hiding in `@Dependency` and `withTaskGroup`

TL;DR

Background: How swift-dependencies Works

The Problem: Task-Local Values and Task Groups

How @Dependency Triggers It

A Concrete Example

Why the Capture List Doesn't Help

The Fix

Why This Bug Slips Into Production

1. It only affects iOS 17

2. There are no compiler warnings

3. The stack trace isn't obvious

4. @Dependency Looks Like a Stored Property

Finding Affected Code

Reproducing the Crash

Summary

Final Takeaway

Build a SwiftUI PreviewProvider for UIKit Views

Build a SwiftUI PreviewProvider for UIKit Views

SwiftUI: PreviewProvider

UIKit: PreviewProvider

How to convert UIKit content to SwiftUI Content?

Implementation

UIKit Controller

Convert this UIViewController to SwiftUI Controller

Preview our UIViewController using PreviewProvider

EmadBeyrami / UIKitPreviews

SwiftUI preview provider for UIKit

A simple way to see your UIKit ViewController changes live and on-demand.

Introduction

Buy me a coffee ☕️:

Donate

Refrences:

Why computed properties help readability, what `@ViewBuilder` actually does, and when a separate `View` type matters

Extracting a real `View` type changes the structure

Don't confuse `body` evaluation with rendering

So when should you extract a `View`?

Where does `@ViewBuilder` fit?

What `@ViewBuilder` does not do

But `if` is not bad

5. Am I doing expensive work during `body` evaluation?

6. Am I using `@ViewBuilder` because I need conditional structure?

7. Am I conditionally applying a modifier with `if`?

Background: How `swift-dependencies` Works

How `@Dependency` Triggers It

4. `@Dependency` Looks Like a Stored Property

Preview our `UIViewController` using PreviewProvider