At a “Meet with Apple” developer event, an Apple engineer made a statement:

“Writing a value to the Environment doesn’t only affect the views that read the key you’re updating. It updates any view that reads from any Environment key.”

That means a single environment write can trigger checks across the affected view subtree.

In this post, we’ll look at the difference between a cheap dependency check and an actual body re-evaluation, why even skipped updates have a cumulative cost, and the rules to avoid unnecessary environment overhead.

Understanding O(n) in a Mobile Context

O(n), or linear time complexity, simply means that the amount of work grows with the number of items involved.

In this case, the items are the views in the affected subtree. A smaller subtree means fewer views to check; a larger one means more work. When these checks happen frequently, such as during interactive UI updates, that cost can start to matter.

Changing an environment value causes SwiftUI to walk through the relevant view subtree and check the views that depend on the environment.

The View Hierarchy and Environment Propagation

EnvironmentValues are propagated downward through a view hierarchy from parent to child. When you apply an .environment() modifier, the value you set affects the view you modify and all its descendants, until a different environment modifier overrides it.

Here is a critical distinction: The Environment is not a true global store; it’s a hierarchical propagation mechanism:

• A view only receives environment values from its ancestors.
• Changes to environment values only propagate to descendants, not to ancestors or siblings.
• As Apple engineers clarified: “This only applies to child views of the .environment modifier that you’re writing with”. If View B applies an environment modifier on View C and View D, only C and D are affected, not View A or View B themselves.

The Convenience-Performance Trade-off

The Environment solves the problem of passing data through deep view hierarchies without “prop drilling.” You can inject a value at the root and access it five levels deep with a single line of code.

However, this convenience comes at a cost. Every environment read creates a dependency that must be checked during every environment write.

The Environment is designed for cross-cutting concerns such as themes, localization, managed object contexts. It is not designed for frequently-changing application state like GPS coordinates, timer values, or scroll offsets.

The Anatomy of an Environment Write

The Propagation Traversal

When an environment value changes, SwiftUI first needs to determine which views might be affected. It does this by walking down the view hierarchy from the point where the .environment() modifier was applied.

In Instruments’ Cause and Effect Graph, you’ll typically see two types of environment update nodes:

1. External Environment updates: changes originating outside SwiftUI, such as a system-level colour scheme change when the device switches to Dark Mode.
2. EnvironmentWriter updates: changes made within SwiftUI, such as updating a value through the .environment() modifier.

The important part is what happens next: SwiftUI doesn’t immediately re-evaluate every view it encounters. It first performs a much cheaper dependency check.

The “Mailbox Check” -The Cheap Part

For each view in the affected subtree, SwiftUI check:

1. Does this view’s body read from the environment?
2. If it does, is the environment key that changed one of the keys it reads?

If the answer is no, SwiftUI can skip re-evaluating the view’s body. These appear as skipped updates in Instruments.

Apple describes this behaviour explicitly as:

“The view bodies are only run if the body uses the environment value for the key(s) used in that view and the value changes.”

So if a view reads .name and you change .age, its body doesn’t run because it doesn’t depend on .age.

Walking the subtree and checking dependencies is not the same thing as re-evaluating every body.

The “Unpacking” -The Expensive Part

If a view does read the environment key that changed, SwiftUI needs to re-evaluate that view’s body.

Remember that body is a computed property. SwiftUI can evaluate it frequently. But there’s an important performance detail here: even when a view is skipped, SwiftUI still had to visit it and perform the dependency check. Across a large subtree, those small checks can add up.

Apple’s Instruments guidance highlights exactly this behavior: skipped updates can have a significant cumulative cost, even though their associated view bodies never run.

The Cost of Comparison: Equatable and the Default Value

When SwiftUI reaches an environment reader, it compares the old and new values using Equatable to determine if a body re-evaluation is necessary. This comparison itself carries a cost: comparing an Int is a single CPU instruction, whereas comparing a massive Dictionary or a 20-property Struct forces SwiftUI to check every element or property.

If a value is not Equatable, SwiftUI lacks the information to detect a change. It defensively assumes the value did change, triggering unnecessary re-evaluations.

Reference types (Classes) add another layer: they compare by memory address (pointer), not content. Two distinct class instances with identical properties are considered “changed” because their pointers differ.

The Default Value Trap: If a view reads an environment key that wasn’t explicitly provided, it falls back to the key’s default. If this default is an unstable reference type (e.g., a computed default returning a new class instance), it appears different across environment passes. This invalidates the view even when the write was for an unrelated key.

Performance isn’t just about how many body properties run. The dependency checks, value comparisons, and how defaults are provisioned all contribute to the final cost.

Three Scenarios for Cost Evaluation

Scenario A: Changing a Value No One Uses

What happens when you change an environment value that no view in the subtree actually uses?

SwiftUI still needs to walk through the affected subtree and perform its “mailbox check” on each view. The views can ultimately be skipped, but SwiftUI still has to visit them to determine that they don’t need to update.

This is visible in Apple’s Instruments demonstrations: even when a view’s body doesn’t execute, the update itself still has an associated cost.

The important takeaway is that the cost isn’t limited to views whose body is re-evaluated. Every view that SwiftUI checks contributes to the cost.

Scenario B: Changing a Value Used Deep in the Hierarchy

Now consider a value that’s actually used by a deeply nested view.

SwiftUI still traverses the relevant subtree. The root and sibling views perform their dependency checks and are skipped because they don’t depend on the changed key. The deeply nested view that does read that key, however, needs to re-evaluate its body.

The important distinction is that a view’s body only runs when the body uses the changed environment key and the value actually changes.

You can see this distinction in the Cause and Effect Graph:

• A view that reads the changed environment value shows the environment update followed by execution of its body.
• A view that reads the environment but doesn’t use the specific key that changed still shows the environment update as a cause, but its body isn’t executed. Instruments represents this as a skipped or dimmed update.

So, a single environment write can contain both kinds of work: cheap checks for views that can be skipped and more expensive body evaluations for views that actually depend on the changed value.

Scenario C: High-Frequency Writes

This is where the cost becomes much more noticeable. Suppose you put a frequently changing value such as a timer, GPS coordinate, or scroll offset into the environment. If that value changes 60 times per second, SwiftUI has to perform the propagation and dependency checks 60 times per second.

The exact numbers will vary with the hierarchy and workload, but the underlying pattern is what matters: frequent writes multiplied by a large affected subtree can create a substantial amount of unnecessary work.

Apple explicitly warns against putting frequently updated values, such as geometry values or timers, into the environment for this reason.

The “Skipped” Update Cost

This is an easy detail to overlook because a skipped view doesn’t execute its body. It can therefore look like SwiftUI did almost no work.

But the traversal still happened, and every skipped view still required a dependency check. Apple’s WWDC session and related discussions demonstrate that these skipped updates can have a significant cumulative cost.

Environment performance isn’t about how many views re-evaluate. It’s about how many views SwiftUI has to check and how often those checks happen.

Some Rules of Environment Usage

These rules establish the foundation for using the Environment without unnecessarily expanding the cost of propagation.

Rule 1: Keep Values Tiny and Specific

Avoid putting one large AppState containing dozens of unrelated properties into the environment.

Instead, split independent pieces of state into small, specific environment values.

// AVOID: One massive struct
struct AppState {
    var isLoggedIn: Bool
    var preferredColor: Color
    var language: String
    var lastLocation: CLLocation?
    // ... 10 more properties
}

ContentView().environmentObject(AppState())

// PREFER: Tiny, specific keys
ContentView()
    .environment(\.isLoggedIn, true)
    .environment(\.preferredColor, .blue)
    .environment(\.language, "en")

This makes the values themselves simpler to compare and, more importantly, keeps dependencies more focused. A view that only needs .language doesn’t need to depend on unrelated pieces of application state.

Keep environment values small enough that a view only depends on what it actually needs.

Rule 2: Isolate the View

If only a small part of a view needs an environment value, move that dependency into a dedicated child view.

Consider this example from a Location app:

struct ContentView: View {
    @EnvironmentObject var locationManager: LocationManager

    var body: some View {
        VStack {
            Text("Welcome")
            Text("Lat: \(locationManager.lastLocation?.latitude ?? 0)")
            Text("Long: \(locationManager.lastLocation?.longitude ?? 0)")
        }
    }
}

Here, ContentView reads locationManager directly, even though only the latitude and longitude display actually needs the location. When the location changes, ContentView becomes one of the views that needs to be considered for the update.

A better approach is to isolate that dependency:

struct ContentView: View {
    // ContentView does NOT read location data
    var body: some View {
        VStack {
            Text("Welcome")
            LocationDisplayView()
        }
    }
}

struct LocationDisplayView: View {
    @EnvironmentObject var locationManager: LocationManager

    var body: some View {
        if let location = locationManager.lastLocation {
            Text("Lat: \(location.coordinate.latitude)")
            Text("Long: \(location.coordinate.longitude)")
        }
    }
}

Now the environment dependency is scoped to LocationDisplayView. The larger ContentView doesn’t need to re-evaluate its body just because the location changes.

Don’t make a large view listen to a value when only a small part of that view needs it.

Rule 3: Never Put High-Frequency Data in the Environment

The third rule is the most important one for performance-sensitive code: avoid putting frequently changing data in the Environment.

GPS coordinates, timer values, scroll offsets, and drag gesture values can change many times during normal interaction. Putting those values high in the environment can turn every update into repeated propagation and dependency checks across a potentially large subtree.

For example:

class LocationManager: ObservableObject {
    @Published var currentLocation: CLLocation? // DON'T put this in environment!
}

A better architecture is to keep the manager itself as a stable dependency while scoping the frequently changing data closer to the views that actually need it.

Stable dependencies can live high in the hierarchy. Frequently changing data should stay as close as possible to the views that actually use it.

The important thing to understand is the difference between a check and a re-evaluation.

A check is SwiftUI walking through the affected subtree and determining whether a view depends on the environment value that changed. A re-evaluation is when SwiftUI actually calls that view’s body. The second is more expensive, but the first isn’t free either.

Use the Environment for relatively stable, cross-cutting values such as theme, locale, and other shared dependencies. Keep frequently changing data in local state or scoped observation, and throttle updates when appropriate.

The Environment isn’t inherently a performance problem. The problem comes from placing the wrong kind of data in it, especially data that changes frequently and sits high in the view hierarchy.

We’ll see a little more about Environment in Part 2, till then see ya, 👋 .

Thanks for reading Cross Commit

Before you go:

👉 Clap and follow Rajveer so their next story lands in your feed 👏

👉 Want their stories by email? After you follow, tap Following on their profile and choose Email notifications on 📩

👉 Follow Cross Commit for practical iOS, Android and mobile AI stories from engineers who ship real apps

👉 Writing about Swift, Kotlin or mobile AI? Cross Commit is open to writers worldwide. Leave a response below and we’ll get in touch ✍️

SwiftUI @Environment: The Overlooked Performance Overhead was originally published in Cross Commit on Medium, where people are continuing the conversation by highlighting and responding to this story.