In order to force that iCloud data syncing I even provided a forcing option to users.

So the UI keeps smiling. You keep waiting. Nothing arrives. You start questioning your life choices 🤔

Walk Mate is doing the normal responsible things: save locally first, mirror into iCloud-ish places, merge when the other device finally sees the data. For avoided segments I even have that “syncing from iCloud…” kind of waiting state because ubiquity files really can be “not downloaded yet”. But there is a ceiling to what an app can explain. So of course people blame the app. I would too. If your favorite route is missing, Walk Mate is the face of the crime 🕵🏻‍♂️

Then I heard a fix from a super talented software developer who basically said: once he understood Photos/iCloud were getting stuck because the UDP/QUIC path was unhealthy and Apple wasn’t falling back in a useful way, he basically just shut UDP down on his network and forced everything onto TCP.

Under the hood a lot of this content traffic goes through Apple’s system daemons; cloudd, nsurlsessiond. And modern Apple networking loves HTTP/3 over QUIC, which basically means UDP 443 instead of the old reliable TCP lane. QUIC is supposed to be the cool fast future. Until it isn’t.

There’s a whole Apple forums thread about this exact “silent upload deadlock” energy with stale HTTP/3 sessions.

If you want the deep technical rabbit hole: Apple Developer forums thread.

Short answer: the main queue is serial. 😀

If you think about the mainQueue, it is designed for the UI. If you want to make changes on the UI, their order you dispatched asynchronous action in the mainQueue still matters. For instance, when you run an animation or update labels, images, or navigation, you don’t want those updates racing each other. So the main queue works like one-after-another: each task must complete before the next task is able to start. That’s exactly what a serial queue gives you. On the other hand the GlobalQueues are in general concurrent with tasks with respect to each other’s completion. Because you can dispatch offline things of main thread and do something maybe super intensive (networking, decoding, file I/O etc.) and then when it finished you can update the UI. Those are usually concurrent on parallel depending on the needs.

A quick mental model that helps in interviews:

Also don’t mix up serial/concurrent with sync/async. Those are different axes:

• Serial vs concurrent → how the queue runs tasks (one-by-one vs overlapping)

• sync vs async → whether the caller waits

  • sync → wait until that work finishes

  • async → submit the work and continue

So DispatchQueue.main.async { ... } still runs on the serial main queue. Async only means “don’t block the caller while waiting to schedule it.” It does not mean “run this in the background.”

That distinction also explains a classic crash/freeze: calling DispatchQueue.main.sync while you are already on the main thread. The main queue is waiting for the sync block to finish but the sync block can’t start until the main queue is free, it is deadlock. Prefer main.async for UI updates and if you must use sync, never sync a queue against itself.

Where does this land with modern Swift?

Actors protect mutable state by serializing access, one caller at a time. An actor gives us its own isolation domain and that work usually runs off the main thread unless the actor is main-actor isolated. So conceptually it’s similar energy to a serial queue: controlled, ordered access. But the main actor / main queue remains special because UIKit/SwiftUI UI updates still need that serial main-thread world.

Interview takeaway: Main queue = serial, UI-bound, order matters. Global queues = concurrent, good for heavy work. Sync/async is about waiting, not about which queue you are on.

It is a short question with a long answer. Most people say it depends… and move on. Chris Eidhof wrote the classic take on this years ago: Why Conditional View Modifiers are a Bad Idea (objc.io). Apple’s Xcode 27 swiftui-expert-skill now says the same thing under Prefer Modifiers Over Conditional Views. I have been applying both while reviewing Walk Mate’s map screen and this post is the answer I would give in that interview.

The Core Idea

In SwiftUI, views are value types (struct). They do not have object identity like UIKit. SwiftUI figures out “sameness” from structure and type. When you animate, it needs to compare the view before/after and interpolate between those values.

As it explained very well in objc.io’s blog post, an if/else branch produces _ConditionalContent. That is an enum: either the true branch or the false branch. When the condition flips, SwiftUI does not interpolate. It removes one view and inserts another. Default transition: fade. And any @State / @StateObject sitting on that position gets reset, because as far as SwiftUI is concerned a new view just appeared.

The Interview Trap: .if and applyIf

A lot of codebases still have something like this:

// Please don’t use this:
extension View {
    @ViewBuilder
    func `if`<T: View>(_ condition: Bool, transform: (Self) -> T) -> some View {
        if condition {
            transform(self)
        } else {
            self
        }
    }
}

Or the applyIf variant from countless blog posts. It feels clever. It is also the exact pattern Apple calls out as problematic!

Why?

The return type changes per branch. One branch is T (the transformed view). The other is Self. Outermost type becomes _ConditionalContent. Identity breaks. Animations break. State can reset.

objc.io’s example makes it obvious. Conditionally framing a Rectangle with applyIf fades. Writing .frame(width: myState ? 100 : nil) keeps one ModifiedContent type and animates smoothly.

Apple’s guidance matches that:

• Prefer always-present modifiers with ternary values:

Text(”Hello”)
    .opacity(isHighlighted ? 1 : 0.5)

Text(”Hello”)
    .foregroundStyle(isError ? .red : .primary)

When writing new code, never reach for a .if modifier. When reviewing existing code that already uses one, point out the identity and animation risk and show the ternary alternative but don’t silently refactor it inside an unrelated PR. Swapping it can change behavior (state resets, transition timing). That belongs in its own focused edit.

• Prefer Modifiers Over Conditional Views

When you introduce a branch, are you representing multiple views or two states of the same view?

Same view, different states → prefer a no-effect modifier:

SomeView()
    .opacity(isVisible ? 1 : 0)

Avoid create/destroy for visibility:

if isVisible {
    SomeView()
}

Why?

Conditional inclusion can lose state, hurt animation, and break identity. Modifiers keep the same view across state changes.

Conditionals are appropriate when you truly have different views:

if isLoggedIn {
    DashboardView()
} else {
    LoginView()
}

if let user {
    UserProfileView(user: user)
}

That last one matters. Optional content is fine. Fundamentally different screens are fine. “Hide this card for a second” is usually not, that is opacity (and often allowsHitTesting(false) when it should not receive taps).

What I Found in Walk Mate

I put breakpoints on a few conditionals in ContentView and AdventureCompletedView and asked myself: is this two states of the same view or truly different views?

1. Good: same view, different visual state

In MyStatsView, locked milestones stay in the tree and only dim:

.opacity(milestone.unlocked ? 1.0 : 0.7)

Same pattern in MapStyleView for non-interactive rows:

.opacity(isInteractive ? 1 : 0.55)

That is exactly Apple’s “no-effect modifier” advice. One view identity. Value changes.

2. Correct conditionals: fundamentally different UI modes

In ContentForegroundStack I switch between drawing and the normal bottom chrome:

if store.drawRoute.isDrawingRoute {
    DrawRouteOverlayView(store: store)
} else if !store.avoidance.isEditingAvoidedLocations {
    BottomControls(...)
}

DrawRouteOverlayView and BottomControls are not two opacities of the same thing. They are different modes of the map UI. Same idea for MapControlsView and AdventureStatsView disappearing while the user draw or mark avoidance. Those branches are appropriate.

Optional content is also fine:

if let medal {
    MedalCollectionToast(...)
}

That matches Apple’s if let user example.

3. The gray area: overlays that come and go

ContentMainView still has:

if store.routeGeneration.isGeneratingRoutes {
    LoadingOverlay()
}

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

And inside AdventureCompletedView, confetti is also gated:

if showConfetti {
    ConfettiView()
}

Are these “wrong”? Not automatically. Loading and adventure-completed are closer to modal layers than to a button that toggles highlight. Creating them when needed is readable and for LoadingOverlay there is little state to preserve.

But AdventureCompletedView holds animation state:

@State private var showConfetti = false
@State private var cardScale: CGFloat = 0.8
@State private var cardOpacity: Double = 0

The outer if in ContentMainView creates and destroys that whole view. That resets @State every time the overlay appears which we actually rely on because .onAppear kicks the spring for cardScale/cardOpacity. So the conditional is doing intentional lifecycle work not just “hide me”.

Still, there is a smell 🦨: AdventureCompletedView’s body also checks showAdventureCompleted and selectedRoute again. Double gate. The parent already decided the overlay should exist. The child repeating the same if means an empty branch when state is inconsistent and it keeps the “presence” question inside a view that also owns animation state.

For confetti specifically, Apple’s opacity guidance fits better than create/destroy:

ConfettiView()
    .opacity(showConfetti ? 1 : 0)
    .allowsHitTesting(false)

Same view. No identity flip when the Bool toggles. If ConfettiView ever grows internal state, you won’t reset it by accident.

Interview answer in one line: use if when the view graph is genuinely different; use modifiers when you are only changing how the same view looks or whether it receives interaction.

Practical Checklist (What I Use in Code Reviews Now)

1. Ask first: same view, two states or two different views?

2. Prefer ternary values on always-present modifiers (opacity, foregroundStyle, frame with nil etc.).

3. Never add a new .if / applyIf View extension. If one exists, call out the risk; refactor in a dedicated change.

4. Use if / else for real mode switches and if let for optional content.

5. Be careful when @State lives inside a view that is itself behind an if, otherwise appearance resets state. Sometimes you want that (entrance animation). Sometimes you just lost the user’s text field.

6. Do not “fix” every overlay if in the app overnight. Loading and completion modals can stay as conditionals when create/destroy is the lifecycle you want.

The Answer I Would Give In an Interview

No, not the applyIf / .if extension kind. They wrap if/else around modifiers, change the return type per branch, break structural identity and turn smooth property animations into transitions. Prefer modifiers that are always applied with values that change.

Conditional views (if in a body) are fine when the branches are actually different views or optional content. They are the wrong tool when you only mean “this same view, hidden or dimmed.”

That is Chris Eidhof’s objc.io argument. It is also what Apple wrote into Xcode 27’s swiftui-expert-skill. In a map-heavy app like Walk Mate, the win is knowing which of your ifs are mode switches, which are optional content and which are visibility hacks that should have been opacity all along.

Sources

• Why Conditional View Modifiers are a Bad Idea

• Prefer Modifiers Over Conditional Views - Apple / Xcode 27 swiftui-expert-skill (view-structure.md)

The main difference between SDD and vibe-coding is vibe-coding excels at rapid prototyping and SDD is essential for complex production systems to prevent AI hallucinations, architectural drift and technical debt. Spec Kit is a workflow that executes scripts and very fine-tuned prompts to produce high quality context for your coding agent and the lightweight framework compared to the other ones. And this is what GitHub says:

Spec-Driven Development flips the script on traditional software development. For decades, code has been king — specifications were just scaffolding we built and discarded once the “real work” of coding began. Spec-Driven Development changes this: specifications become executable, directly generating working implementations rather than just guiding them.

AI-assisted iOS development for me is still typing a prompt in Cursor and pray 🛐 Type a prompt, skim the diff, accept, re-prompt when the tests break.

Spec-Driven Development (SDD) is the pushback. And GitHub’s Spec Kit is the toolkit that makes it usable inside the editor you already have.

This post is a walkthrough of installing Spec Kit into an existing ~40k-line SwiftUI + TCA app Walk Mate and for learning purposes shipping one small feature (Favorites sort + search) end-to-end through the full flow. Every step will be tied to a real file in the repo.

What SDD actually is (and what Spec Kit gives you)

SDD is not write more comments before you code. It is a fixed pipeline:

1. Constitution: the rules of your project

2. Specification: user stories, requirements, success criteria

3. Plan: the technical approach with your chosen stack (SwiftUI + TCA)

4. Tasks: the plan decomposed into buildable phases (spec + plan)

5. Implementation: one phase at a time

Each stage validated before the next.

Spec Kit is GitHub’s implementation of this pipeline. You’ll get:

• A CLI specify that scaffolds the artifacts into your project

• Markdown .md templates for each stage (constitution, spec, plan, tasks)

• Editor-native slash commands so Cursor can drive the flow with a shared vocabulary

The command surface I used in Cursor:

Command | Purpose

/speckit-constitution | Project principles and hard constraints

/speckit-specify | User stories, requirements, success criteria

/speckit-clarify | Structured Q&A to close ambiguity before planning

/speckit-plan | Technical plan with the chosen stack

/speckit-tasks | Decompose the plan into buildable phases

/speckit-analyze | Cross-artifact consistency check

/speckit-implement | Execute one phase at a time

Setup in an existing project

You need three things: uv (Astral’s Python package manager), Python 3.11+, and Cursor. Install the CLI once:

> uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Then, inside your Xcode project’s root:

> cd MyExistingIOSApp
> specify init . --integration cursor-agent --force

Two things worth calling out here. --force is necessary because the directory isn’t empty Spec Kit merges its templates in rather than wiping. And cursor-agent is the skills-based integration. It installs 10 skills under .cursor/skills/, one per slash command so Cursor’s palette picks them up automatically.

After init, the new tree looks like this:

Two side quests before you move on:

• First, gitignore: Spec Kit’s post-install output specifically warns that agent folders can hold credentials and suggests .gitignore -ing .cursor/. I already ignored that folder which means my installed skills are per-clone. For a solo indie app that’s fine. For a team I would commit at least .cursor/skills/ so everyone has the same slash commands. Make it an explicit decision.

• Second, Xcode 16+’s file-system-synchronized groups. Any new .swift file dropped into a synchronized folder is auto-added to the target. When /speckit-implement creates FavoritesSortOption.swift, I don’t need to touch project.pbxproj. If you’re on a legacy project with manually managed file references, budget extra time for this friction.

The constitution: fold in what your project already enforces

This is the most crucial section for me because it’s where SDD stops being a novelty and starts paying rent 🤑 This usually set up once at the very start of your project.

In a greenfield app the constitution is aspirational: rules you hope to follow. In an existing app it’s descriptive: rules the codebase already enforces (tribal knowledge, PR comments or Cursor rules files) but in a form no AI agent can read. Writing the constitution is the act of making that knowledge machine-readable for every future agent session.

I ended up with four principles in .specify/memory/constitution.md:

1. SwiftUI + TCA architecture

@Reducer, @ObservableState, delegate actions, @Dependency clients. This is descriptive: FavoriteRoutesFeature.swift already uses @Dependency(\.persistenceClient) and a Delegate enum to talk to its parent. The constitution just names the pattern.

2. Localization completeness

Every user-facing string must exist in all 15 locales (da, de, es, fr, it, ja, ko, nl, pl, pt, ru, sv, tr, zh-Hans, zh-Hant) inside Localizable.xcstrings with ”state”: “translated”. This is a verbatim promotion of .cursor/rules/localization.mdc same rule but now the AI sees it at every SDD step not only when it happens to load that rule file.

3. No magic numbers in UI

Layout, spacing, corner radius, animation timing become named constants under AppConstants.UI, Typography, AppColors or a feature-scoped UIConstants.<Feature> enum.

4. Test-first for reducer logic

Swift Testing + TCA TestStore before or alongside any reducer change.

Driving one real feature through the pipeline

The feature: add user-selectable sorting (by date saved, name, distance) and search to the Favorites list in Walk Mate. Small, self-contained, real. Two production files touched at the start FavoriteRoutesFeature.swift and FavoriteRoutesView.swift.

1. /speckit-specify (define what to build)

This is where we tell the agent what we’d like to build. This step excludes any technical information. It’s purely the business requirements for this feature.

Input verbatim: “Add user-selectable sorting (date, name, distance) and search to the Favorites list.” Spec Kit generated a feature slug (001-favorites-sort-search), scaffolded a directory under specs/, and dropped a filled-out spec.md in it three prioritized user stories (P1 sort, P2 search, plus edge cases), functional requirements FR-001 through FR-010, and measurable success criteria (SC-001: “20 favorites, target route found by name in under 5 seconds”).

The template forced a discipline I keep skipping when I write my own tickets: independently testable user stories, prioritized. If I had just typed “add sort and search” into a normal ticket, sort and search would have shipped bundled. Here they became User Story 1 (P1) and User Story 2 (P2), each with its own acceptance scenarios, either shippable alone.

2. /speckit-clarify (optional follow up questions)

This is the optional action where the agent can look at our requirements and ask any follow-up questions.

Eight questions surfaced. A few of them:

• What’s the default sort? (Answer: dateSaved descending, matches current behavior, so users who never touch the menu see no change.)

• Does search match name only or also formatted stats like “3.2 km”? (Name only. Matching localized formatted text would be fragile across locales and units.)

• How do we sort favorites whose name is empty? (Sort them last when the user picks “Name”, with savedDate as tie-breaker.)

• Persist sort selection? Persist search text? (Sort yes, search no.)

3. /speckit-plan (implementation plan)

The planning phase is really cozy. This will create a plan, the data models, the service interfaces and even perform research.
The current view had a private computed property doing the sorting inline which violates Principle I (business logic in views). The plan moved sort and filter into FavoriteRoutesFeature.State.filteredSortedFavorites a computed property on the state. The view goes back to being a thin observer.

private var sortedFavoriteRoutes: [FavoriteRoute] {
    store.favoriteRoutes.sorted { $0.savedDate > $1.savedDate }
}

Notice: the plan step not a code reviewer, caught the constitution violation. That’s the whole point.

The plan ends with a five item constitution-compliance checklist, all green. If any box had been red, the plan would have been the artifact I fixed, not the code.

4. /speckit-tasks (break plan into actionable steps)

It takes the plan and break it up into individual tasks. These are all the individual tasks like the actual code changes to implement this feature.

Tasks came out in three phases:

A (reducer + data model + persistence + tests),

B (view with sort menu and .searchable),

C (localization for all 15 locales).

Ordering matters: each phase leaves the project buildable and green.

/speckit-analyze then produced an alignment matrix mapping every FR to a task, a test and a status. That table is now the artifact I’d hand to a reviewer instead of “trust me, it’s covered.” 😬

5. /speckit-analyze (optional validate docs)

Then we have another optional step called analyze. It will simply look at everything that’s been produced before it to make sure that the documentation is complete and we’ve covered everything.

6. /speckit-implement (execute tasks and test)

Then finally, we have the implement step. This is where we tell the coding agent, hey, we have everything we need. Go ahead and implement all of these tasks. We should be able to test our changes in the system and ask the agent to make any adjustments.

Concrete numbers from the run:

• Files touched: FavoritesSortOption.swift (new), PersistenceClient.swift, FavoriteRoutesFeature.swift, FavoriteRoutesFeatureTests.swift, FavoriteRoutesView.swift, UIConstants.swift, Shared/L10n.swift, Localizable.xcstrings.

• Localization: 5 new keys × 15 locales = 75 xcstrings entries, zero missed locales. This is Principle II operationalized. The AI knew the constitution required 15 locales, so it produced 15.

• Tests: 12 in FavoriteRoutesFeatureTests before, 21 after (+9 new). All 88 tests across 10 suites pass.

• Compile-break as a feature. Widening PersistenceClient with two new closures broke every test that constructed one. That’s not a bug, it’s the compiler surfacing the exact migration the plan had already enumerated. One edit fixed all callsites. Compiler-enforced migrations are a friend of SDD, they turn “did we get every callsite?” from a grep into a build error.

The view diff is the tweetable moment:

// Before
private var sortedFavoriteRoutes: [FavoriteRoute] {
    store.favoriteRoutes.sorted { $0.savedDate > $1.savedDate }
}
// ...
ForEach(sortedFavoriteRoutes) { favorite in ... }

// After
ForEach(store.filteredSortedFavorites) { favorite in ... }

That’s what “thin view, fat reducer” looks like when it’s enforced by a plan and not by a reviewer’s comment.

What Spec Kit does not solve?

• Overhead on tiny changes. Running /speckit-specify to add a SwiftUI #Preview block or fix a typo is absurd. Reserve SDD for changes that touch more than one file or introduce user-visible behavior. Below that bar, just edit the code :)

• The constitution is only as good as your enforcement. Nothing in Spec Kit runs tests, greps for magic numbers, or diffs your xcstrings for missing locales. The constitution is a single source of truth the AI reads; enforcement is still your CI, your pre-commit, your reviewer.

• Xcode integration is via file system. Spec Kit never touches project.pbxproj. On Xcode 16+ with synchronized groups this is fine. On legacy projects, add friction to your estimate.

• Localization can’t be verified without inspecting the catalog. String(localized:) alone doesn’t guarantee entries exist in Localizable.xcstrings. I ran a one-liner to prove it after each phase:

python3 -c "import json; d=json.load(open('.../Localizable.xcstrings')); \
[print(k, len(d['strings'][k]['localizations'])) \
 for k in ['Sort','Name','Date saved','Search favorites','No matching favorites']]"

SDD is a framework for making AI collaboration reviewable: every step produces an artifact you’d be willing to defend in code review and every artifact is validated against a constitution you wrote deliberately. If you’ve been using Cursor like me as a smarter autocomplete, this is the next promotion.

Two pieces I leaned on heavily and would recommend as further reading: Mad Devs on SDD in iOS (https://maddevs.io/writeups/spec-driven-development-in-ios/) for the process wisdom, and Stackademic’s “Death of Vibe Coding” (https://blog.stackademic.com/kiro-ai-for-ios-how-agentic-development-and-spec-driven-swiftui-replace-prompt-coding-091bf760bdbc) for the mindset shift.

Next I want to write about adding /speckit-checklist to CI so the constitution enforces itself in PR review, instead of quietly hoping I’ll remember. If the constitution is the point, that’s the natural next step.

Sources:

• Other similar options to Spec Kit; https://specs.md, https://github.com/bmad-code-org/bmad-method

• Mad Devs on SDD in iOS - (https://maddevs.io/writeups/spec-driven-development-in-ios/)

• Death of Vibe Coding - (https://blog.stackademic.com/kiro-ai-for-ios-how-agentic-development-and-spec-driven-swiftui-replace-prompt-coding-091bf760bdbc)

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<ContentFeature> // 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<ContentFeature>
    @Namespace private var mapScope

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

private struct ContentConfiguredView: View {
    @Bindable var store: StoreOf<ContentFeature>
    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<ContentFeature>
    let mapScope: Namespace.ID

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

private struct ContentMainView: View {
    @Bindable var store: StoreOf<ContentFeature>
    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<ContentFeature>
    let mapScope: Namespace.ID

    var body: some View {
        MapContainerView(store: store, mapScope: mapScope)
            .overlay(alignment: .trailing) {
                if !store.drawRoute.isDrawingRoute
                    && !store.avoidance.isMarkingAvoidanceMode
                    && !store.avoidance.isEditingAvoidedLocations {
                    MapControlsView(store: store, mapScope: mapScope)
                }
            }
            .safeAreaInset(edge: .top) {
                if !store.drawRoute.isDrawingRoute
                    && !store.avoidance.isMarkingAvoidanceMode
                    && !store.avoidance.isEditingAvoidedLocations {
                    AdventureStatsView(store: store)
                }
            }
    }
}

private struct ContentForegroundStack: View {
    @Bindable var store: StoreOf<ContentFeature>

    var body: some View {
        VStack(alignment: .leading, spacing: 0) {
            if store.avoidance.isMarkingAvoidanceMode {
                ContentAvoidanceBanner(
                    showsTapToMarkBanner: store.avoidance.temporarySelectedSegment == nil
                        && store.avoidance.avoidedSegments.isEmpty
                )
            }
            Spacer()
            if store.drawRoute.isDrawingRoute {
                DrawRouteOverlayView(store: store)
            } else if !store.avoidance.isMarkingAvoidanceMode
                        && !store.avoidance.isEditingAvoidedLocations {
                BottomControls(
                    routes: store.routeGeneration.routes,
                    isGeneratingRoutes: store.routeGeneration.isGeneratingRoutes,
                    store: store,
                    selectedRoute: store.routeGeneration.selectedRoute
                )
            }
        }
    }
}

The parent ContentView body is now one line. Each layer owns its own invalidation boundary.

I extracted the card into AdventureCompletionCard and passed only what it needs:

AdventureCompletionCard(
    selectedRoute: selectedRoute,
    distanceWalked: store.walkSession.distanceWalked,
    distanceUnit: store.distanceUnit,
    newlyUnlockedMilestones: store.walkSession.newlyUnlockedMilestones,
    onWalkAgain: { store.send(.walkSession(.walkAgainTapped)) }
)

And the card struct:

private struct AdventureCompletionCard: View {
    let selectedRoute: Route
    let distanceWalked: Double
    let distanceUnit: DistanceUnit
    let newlyUnlockedMilestones: [Milestone]
    let onWalkAgain: () -> Void

    var body: some View {
        VStack(spacing: 0) {
            // trophy, title, stats, achievements, buttons
        }
        .compatibleGlassEffect(cornerRadius: 24)
    }
          ...
}

I also split button styling into AdventureCompletedActionButtons, AdventureCompletedActionButton and AdventureCompletedButtonBackground.

Now animation state (cardScale, showConfetti) lives in AdventureCompletedView, while the heavy card content lives in a separate type with stable inputs.

What this gives you

• Better diffing: SwiftUI compares struct inputs, not one giant parent body.

• Less wasted work on unrelated state changes.

• Easier previews: you can preview AdventureCompletionCard with sample data.

• Clearer ownership: each file section has one responsibility. Solid? :D

@ViewBuilder (and What It Does NOT Do)

This is where the X thread gets interesting. @ViewBuilder is useful but it solves a different problem than subview extraction.

What @ViewBuilder is good at

@ViewBuilder helps when you need conditional view structure inside one body:

@ViewBuilder
private var conditionalView: some View {
    if isExpanded {
        VStack {
            Text(”Expanded View”)
            Image(systemName: “star”)
        }
    } else {
        Text(”Collapsed View”)
    }
}

It gives you clean syntax for if/switch branches and structural identity for those branches.

Apple’s guidance also says: use it for small, simple sections that do not need their own invalidation boundary.

What @ViewBuilder does not do

It does not create a new invalidation boundary. If you put your whole complex section in a @ViewBuilder function inside the parent struct that function still runs whenever the parent body runs 🔄.

So this is still one boundary. Tapping the button re-evaluates complexSection() every time.

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

    var body: some View {
        VStack {
            Button(”Tap: \(count)”) { count += 1 }
            complexSection()
        }
    }

    @ViewBuilder
    func complexSection() -> some View {
        ForEach(0..<100) { i in
            Text(”Item \(i)”)
        }
    }
}

The objc.io lesson: conditional branches can break identity

Chris Eidhof wrote a great post on this: Why Conditional View Modifiers are a Bad Idea.

The key point: when you branch with if/else, SwiftUI often sees different view types in each branch (_ConditionalContent<...>). That can:

• break smooth animations (fade transition instead of interpolation)

• reset @State / @StateObject when the branch flips

Example from that post:

Rectangle()
    .applyIf(condition: myState, transform: { $0.frame(width: 100) })

vs

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

The second one keeps the same view identity and animates correctly.

Same idea applies to @ViewBuilder conditionals inside one parent: they are fine for structure but they are not a free performance win and they can still hurt identity if you use them like a conditional modifier wrapper.

Where I still use small extracted structs instead of @ViewBuilder helpers

In Walk Mate, I extracted ContentAvoidanceBanner instead of keeping nested if blocks inline:

private struct ContentAvoidanceBanner: View {
    let showsTapToMarkBanner: Bool

    var body: some View {
        VStack(spacing: 0) {
            if showsTapToMarkBanner {
                TapToMarkBanner()
                    .padding(.horizontal, AppConstants.UI.largeSpacing)
                    .padding(.trailing, AppConstants.UI.bannerTrailingPadding)
                    .padding(.top, 80)
            }
        }
    }
}

This is a small view but it has a clear input (showsTapToMarkBanner) and its own boundary. The parent only passes a Bool, not the whole banner layout logic.

That is the pattern I follow now:

• @ViewBuilder for tiny local branching when extraction would be noisy

• separate View structs for anything stateful expensive or reused

Practical Checklist (What I Use in Code Reviews Now)

1. If a screen has private var section: some View and that section depends on changing state, extract a struct.

2. Pass narrow inputs (Route, Double, [Milestone], Bool) instead of the whole store when possible.

3. Do not use computed properties as a fake performance split 😂

4. Do not use custom .applyIf style helpers for modifiers.

5. Prefer modifier(value ? a : b) over if branches for the same view.

6. Keep @ViewBuilder for small structural branching not as a replacement for subviews.

Splitting a large SwiftUI view is not just a style preference anymore. Apple is calling it out directly and in a map-heavy app like Walk Mate it makes a real difference.

@ViewBuilder is still useful. It gives you clean conditional structure. But if your goal is fewer body re-evaluations, separate View types with narrow inputs are the win.

If you are refactoring an old screen, start with the noisiest part first: map overlays, stats sections, completion cards, sheet containers. That is where I saw the biggest readability and performance payoff.

Sources

• Apple view structure guidance (Xcode 27 coding skills)

• swiftui-expert-skill/references/view-structure.md

• Why Conditional View Modifiers are a Bad Idea by Chris Eidhof (objc.io)

• https://www.avanderlee.com/ai-development/using-xcode-27s-agent-skills-in-claude-codex-and-cursor/

As you know when you double-tapped the user location button in an iOS app, it follows your heading. When I do that I hit a bug in Walk Mate which was architected in The Composable Architecture, my daily route generator app . The blue user location button jumped, and bounced with view redraws in SwiftUI.

The weird part is the same map setup worked fine in my other app, EV Charge Stations Map written in MVVM. Same Map, same MapUserLocationButton, same double-tap for heading-follow. One app broken, one app fine.

In this post I’ll explain why it happens and show to fix in the pure TCA way.

What is heading-follow mode?

When you tap the location button once, MapKit enters follow location mode. The map keeps your blue dot centered.

When you tap it twice, it enters heading-follow mode. A small blue cone appears in front of the dot. As you rotate your phone left or right, the map rotates with you.

That’s when my bug showed up. At certain zoom levels, the map kept jumping and bouncing while I rotated. Sometimes the heading cone flashed for a moment and then disappeared as if heading mode turned off by itself.

The setup (WalkMate)

My map lived inside TCA. The camera position was stored in ContentFeature.State:

var cameraPosition: MapCameraPosition = .region(...)

And the Map used a hand-rolled 🫛 binding that sent an action on every write:

Map(
    position: Binding(
        get: { store.cameraPosition },
        set: { store.send(.updateCameraPosition($0)) }
    ),
    scope: mapScope
) {
    // route polyline, medals, UserAnnotation(), etc.
}

On paper this looks correct for TCA. State in the store, view reads from store, user interaction writes back through actions. That’s the pattern we use everywhere else.

But MapKit in heading-follow mode doesn’t behave like a text field or a slider :)

Why the bug happens?

In heading-follow mode, MapKit runs a continuous camera animation. Every time your device heading changes even a little, MapKit updates the camera (many times per second).

With our hand-rolled 🫛 binding, every single camera frame did this:

1. MapKit writes a new camera position → set fires

2. store.send(.updateCameraPosition($0)) runs

3. Reducer sets state.cameraPosition

4. SwiftUI re-renders the Map

5. get returns the value from state

6. MapKit receives it back as an external camera command

The problem: In step 6, we send the camera position back to MapKit, but that value is already old. MapKit is still rotating the map for heading-follow and at the same time it gets a new position from the app. So the map tries to follow two things at once. That’s why we see the jump, the shake and why heading mode often turns off. The blue cone goes away.

When you zoom in, this looks even worse. Small camera mistakes are easier to see when you’re close to the map.

There was a second problem too. On location updates, the reducer sometimes did:

state.cameraPosition = .region(...)

That runs on GPS ticks. So right after you entered heading-follow, the next location update could overwrite MapKit’s follow pointer with a fixed region. Heading cone flashes → gone.

Why EV Charge Stations Map didn’t have this bug?

I compared with my other app. The difference wasn’t the button. It was who owns the camera during animation.

EV app:

Map(position: $mapViewModel.cameraPosition, scope: mapScope)

Direct binding to @Published var cameraPosition. onMapCameraChange only updated currentRegion for clustering not the camera position on every frame.
Location updates didn’t constantly reset cameraPosition to a fixed .region(...).

Fix - Pure TCA way (BindingReducer + $store.cameraPosition)

TCA bindings exist partly to remove boilerplate like this:

case updateCameraPosition(MapCameraPosition)

case let .updateCameraPosition(position):
    state.cameraPosition = position
    return .none

I replaced the hand-rolled 🫛 binding with first-class TCA bindings. We can eliminate boilerplate using BindableAction and BindingReducer.

Reducer:

enum Action: BindableAction, Equatable {
    case binding(BindingAction<State>)
    // ...
}

var body: some ReducerOf<Self> {
    BindingReducer()
    contentWithMapSheets
}

View:

@Bindable var store: StoreOf<ContentFeature>

Map(position: $store.cameraPosition, scope: mapScope) {
    // ...
}

Now Map-driven updates go through $store.cameraPosition → BindingReducer() → state.cameraPosition. No custom updateCameraPosition action. No send on every frame through a closure we wrote by hand.

We also guarded location-driven camera resets:

let shouldUpdateCamera = !state.avoidance.isEditingAvoidedLocations
    && !state.cameraPosition.followsUserLocation
    && (/* other conditions */)

So GPS updates don’t pull the map out of heading mode.

What stays in the reducer on purpose: programmatic moves like framing a route, opening a sheet or reapplying the camera after a sheet animation (forceCameraPosition). Those are business logic, not UI bindings. BindingReducer() doesn’t replace them.

My takeaway: the bug was treating MapKit’s continuous camera stream like a simple two-way form field. Sliders and text fields want every write in the store. Heading-follow wants MapKit to drive until you programmatically take over.

Sources:

• TCA Bindings documentation

• MapCameraPosition - followsUserLocation / followsUserHeading

My app stores three things locally: favorited charging stations, their connector details, and saved route planner inputs. No CloudKit sync. No background contexts. Just one viewContext passed around SwiftUI views. I thought “this should be straightforward.”

It was. Mostly. But I also hit a launch crash, one schema mistake that almost made me panic about user data. So here is what actually happened.

What I Had Before

Classic Core Data setup. PersistenceController with NSPersistentContainer, entities in .xcdatamodeld, and a bunch of +CoreDataProperties.swift files.

The stack looked like this:

import CoreData

final class PersistenceController: ObservableObject {
    let container = NSPersistentContainer(name: "EV Charge Stations Map")

    init() {
        container.loadPersistentStores { desc, error in
            if let error = error {
                Log.log("Core Data failed to load: \(error.localizedDescription)", level: .error)
            }
        }
    }
}

In the app entry point I injected the context everywhere:

.environment(\.managedObjectContext, dataController.container.viewContext)

Views used @FetchRequest and moc:

@Environment(\.managedObjectContext) var moc
@FetchRequest(sortDescriptors: []) var favorites: FetchedResults<ChargingPoint>

And when someone favorited a charger from the map, the code was very Core Data 🙂

let newFavorite = ChargingPoint(context: moc)
newFavorite.name = chargingPointPOILocation.title
newFavorite.latitude = chargingPointPOILocation.coordinate?.latitude ?? 0.0
// ...

let connection = ChargingPointConnection(context: moc)
connection.powerkW = chargingPointConnectionType.powerkW
newFavorite.addToChargingPointConnections(connection)

try moc.save()

How I Thought About the Migration

I did not want in one PR. I treated it like rewiring a house room by room while people still live in it. Same SQLite file on disk. Same entity names. Same property names. Just swap the API layer on top.

Step 1: Replace Entities With @Model Classes

I started with the simplest entity, RoutePlannerSelectionPersistence. No relationships. Just saved route fields.

Core Data had a .xcdatamodel entry plus two generated Swift files. SwiftData wants one file:

import SwiftData

@Model
final class RoutePlannerSelectionPersistence {
    var initialSOC: Double
    var selectedTargetLocationLat: Double
    var selectedTargetLocationLon: Double
    var selectedTargetLocationName: String?
    var selectedTypecode: String?
    var selectedVehicleDetails: String?
    var yourLocationLat: Double
    var yourLocationLon: Double
    var yourLocationName: String?

    init(initialSOC: Double = 0.0, /* ... */) {
        self.initialSOC = initialSOC
        // ...
    }
}

Then ChargingPointConnection (child), then ChargingPoint (parent with the relationship):

@Model
final class ChargingPoint {
    var name: String?
    var latitude: Double
    var longitude: Double
    // ...

    @Relationship(deleteRule: .nullify, inverse: \ChargingPointConnection.chargingPoint)
    var chargingPointConnections: [ChargingPointConnection] = []

    func addConnection(_ connection: ChargingPointConnection) {
        connection.chargingPoint = self
        chargingPointConnections.append(connection)
    }
}

One thing I learned: put @Relationship on one side only (the parent). On the child just declare var chargingPoint: ChargingPoint? without the macro. Apple’s docs say this, I ignored it at first, then went back and fixed it 👻

I deleted all +CoreDataClass and +CoreDataProperties files and eventually removed .xcdatamodeld from the project entirely.

Step 2: Swap the Stack

Old:

NSPersistentContainer(name: "EV Charge Stations Map")

New:

static let schema = Schema([
    ChargingPoint.self,
    ChargingPointConnection.self,
    RoutePlannerSelectionPersistence.self,
])

static var storeURL: URL {
    let directory = FileManager.default.urls(
        for: .applicationSupportDirectory,
        in: .userDomainMask
    ).first!
    return directory.appendingPathComponent("EV Charge Stations Map.sqlite")
}

let configuration = ModelConfiguration(
    "EV Charge Stations Map",
    schema: schema,
    url: storeURL,
    cloudKitDatabase: .none
)

modelContainer = try ModelContainer(for: schema, configurations: configuration)

That storeURL line is the whole game if you care about existing users. Point SwiftData at the same .sqlite file Core Data already used. Same folder (Application Support), same filename. If you get this wrong, the app launches fine but looks like everyone lost their data. They did not. You just opened an empty new drawer.

Step 3: Wire the App

Instead of injecting managedObjectContext:

.modelContainer(dataController.modelContainer)

On the WindowGroup in EVChargeStationsMapApp. That is it for the plumbing. Child views pick up @Environment(\.modelContext) automatically.

Step 4: Update Views One by One

This part is mostly search and replace with small brain engaged.

SavedRouteListView after migration:

@Environment(\.modelContext) private var modelContext
@Query(sort: \RoutePlannerSelectionPersistence.yourLocationName)
private var savedRoutes: [RoutePlannerSelectionPersistence]

ItemInfoView for favorites:

@Environment(\.modelContext) private var modelContext
@Query(sort: \ChargingPoint.id) private var favorites: [ChargingPoint]

func toggleFavoriteForPOIData() {
    if let existingFavorite = favorites.first(where: { $0.matches(chargingPointPOILocation) }) {
        modelContext.delete(existingFavorite)
    } else {
        let newFavorite = ChargingPoint.favorite(from: chargingPointPOILocation)
        modelContext.insert(newFavorite)
    }
    try modelContext.save()
}

I pulled the “create favorite from map data” logic into a helper on ChargingPoint so I was not copy pasting 20 lines in every view. Small thing, saved my sanity.

View models that cannot use @Query (because @Query only works inside SwiftUI views) still fetch manually:

favorites = try modelContext.fetch(ChargingPoint.favoritesFetchDescriptor())

The Crash That Almost Ruined My Evening

First build after migration. App launches. Instant crash. 😬

Fatal error: SwiftData container failed to load: SwiftDataError(...loadIssueModelContainer...)

The cause was embarrassing. During migration I added a new property id: UUID on RoutePlannerSelectionPersistence. Felt like a good idea. Clean identity for lists, Identifiable, future proofing, all that.

But that column never existed in the old Core Data model. SwiftData tried to open the existing SQLite file, saw a schema it could not reconcile, and gave up.

Fix: remove id. Match the legacy schema exactly. SwiftData already gives you persistentModelID for identity. You do not need to invent a new column on day one.

After that fix the app launched and all my old favorites and saved routes were still there.

What I Would Tell Another iOS Dev

1. Check your scope first. If you have CloudKit sync, complex migrations, heavy background contexts… budget more time. My app was small. That helped a lot. However, I’m planning to think about CloudKit sync as well later.

2. Match the old schema on the first pass. Do not add properties “while you are here.”

3. Keep the same .sqlite path. Seriously. 😉

4. Migrate file by file. Models → stack → app entry → views. You can keep the project compiling between steps if you are disciplined.

5. Delete .xcdatamodeld last. Not first.

6. Test on a device with real old data. Simulator with a fresh install will not teach you anything about schema mismatches.

7. @Query is not for view models. Only views. I learned this the boring way.

Core Data was not hurting me. But SwiftUI + @Query + @Model feels more elegant now, and I do not miss old age NSFetchRequest factory extensions one bit.

If you are sitting on a similar small Core Data layer and thinking about SwiftData, you can do it incrementally. Same locker, new key. Just do not change the lock on the first try 🔐

Sources:

• Adopting SwiftData for a Core Data app

Have you ever encountered to store weak references in an array in other words using arrays with weak references? I know that’s not a case for every array usage in Swift but that’s not an excuse not to know how to achieve it.

In Swift, standard arrays store strong references to the objects they contain. This means as long as an object is in the array, its reference count stays above zero, preventing it from being deallocated from memory.

The Need for Weak References

Sometimes, you want to keep track of a collection of objects without owning them. This is where you need weak references. If the only remaining reference to an object is in your collection, you want that object to be deallocated automatically to avoid memory leaks.

Why weak references?

For example, I have a HomeViewController and I wanna pop-up some custom views from there. I’m creating an array which points to the PopupView array strongly and injecting it in the initializer of HomeVC. Also, I have a ViewPresenter class to present my custom views and passing them to HomeVC. If we try to break the strong reference cycle in destroyViews() function it won’t happen since arrays are value types.

import Foundation

class PopupView {}

class HomeViewController {
    private var views: [PopupView]? //Strong reference
    
    init(views: [PopupView]) {
        self.views = views
    }
    
    func poppAction() {
        print("Views popped up!")
    }
}

class ViewPresenter {
    private var popupA: PopupView? = PopupView()
    private var popupB: PopupView? = PopupView()
    private var homeVC: HomeViewController
    
    init() {
        self.homeVC = HomeViewController(views: [popupA!, popupB!])//injection of strong reference
    }
    
    func destroyViews () {
        popupA = nil
        popupB = nil //destroyViews doesn't destroy the two views 
        // because the array inside HomeViewController is maintaining a strong reference of the views.
    }
}

We can avoid this problem replacing the array with NSPointerArray.

What is NSPointerArray?

NSPointerArray is a Foundation class that acts like a specialized, mutable collection. Unlike a standard array, it can store weak references to objects.

It is specifically designed to store pointers. By configuring it with NSPointerArray.weakObjects, it doesn't increment the reference count of the objects you add to it.

Using the following extension we can add convenience methods, allowing us to cast the AnyObject pointers back to our specific class types easily. Using the pointer may be annoying, you can use this extension which made to simplify the NSPointerArray:

extension NSPointerArray {
    func addobject(_ object: AnyObject?) {
        guard let strongObject = object else { return }
        
        let pointer = Unmanaged.passUnretained(strongObject).toOpaque()
        addPointer(pointer)//: UnsafeMutableRawPointer?
    }
    
    func object(at index: Int) -> AnyObject? {
        guard index < count,
              let pointer = self.pointer(at: index) else { return nil }
        return Unmanaged<AnyObject>.fromOpaque(pointer).takeUnretainedValue()
    }
}

We can get rid of Unmanaged.passUnreateined usage in the following code by using the above NSPointerArray extension!

class MyView { }

var array = NSPointerArray.weakObjects()

let obj = MyView()
let pointer = Unmanaged.passUnretained(obj).toOpaque()
array.addPointer(pointer)

We can replace the previous example with:

class MyView { }

var array = NSPointerArray.weakObjects()

let obj = MyView()
array.addObject(obj)

Let’s fix the problem in the Why weak references? code example:

import Foundation

class PopupView {}

class HomeViewController {
    private let views: NSPointerArray
    
    init(views: NSPointerArray) {
        self.views = views
    }
    
    func poppAction() {
        print("Views popped up!")
    }
}

class ViewPresenter {
    private var popupA: PopupView? = PopupView()
    private var popupB: PopupView? = PopupView()
    private var homeVC: HomeViewController
    
    init() {
        let pointerArray = NSPointerArray.weakObjects()
        pointerArray.addObject(popupA)
        pointerArray.addObject(popupB)
        self.homeVC = HomeViewController(views: pointerArray)
    }
    
    func destroyViews () {
        popupA = nil // it now destroys the views from memory since we made them weak
        popupB = nil
    }
}

ViewPresenter().destroyViews()

It now destroys the views from memory since we made them weak in the initializer of the ViewPresenter class. The NSPointerArray stores pointers of AnyObject only, it means that we can only store just classes (not structs or enums) but we can store protocols if they are class-bound;

protocol SomeProtocol: AnyObject {}

The biggest concern about NSPointerArray is type safety. The compiler is not able to infer the type of the objects inside NSPointerArray, since it uses pointers of objects AnyObject. For this reason, when we get an object from the array, we must cast it to a specific type:

if let objectAtIndexZero = array.object(at: 0) as? Class { // Cast to Class
    print("The object at index zero is MyClass")
}

To solve this type-cast problem we need a type-safe alternative generic class.
Let’s make the previous example type-safe by generic WeakConverter wrapper class;

import Foundation

typealias WeakConverterView = WeakConverter<PopupView>

final class WeakConverter<A: AnyObject> {

    // private(set) exposes convert as read-only, 
    // so callers cannot reassign the weak reference from outside the class.
    private(set) weak var convert: A? 
    
    init(_ value: A?) {
        convert = value
    }
}

class PopupView {}

class HomeViewController {
    private let views: [WeakConverterView]
    
    init(views: [WeakConverterView]) {
        self.views = views
    }
    
    func popupAction() {
        print("Views popped up!")
        
    }
}

class ViewPresenter {
    private var popupA: PopupView? = PopupView()
    private var popupB: PopupView? = PopupView()
    private var homeVC: HomeViewController
    
    init() {
        var array = [WeakConverterView]()
        array.append(WeakConverterView(popupA))
        array.append(WeakConverterView(popupB))
        self.homeVC = HomeViewController(views: array)
    }
    
    func destroyViews () {
        popupA = nil
        popupB = nil
    }
}

ViewPresenter().destroyViews()

A: AnyObject restricts the generic to class instances, which is required because only reference types support weak. The wrapper gives the compiler a concrete type. For example [WeakConverter<PopupView>], so we no longer need casting when we use the array.

When destroyViews() runs, popupA and popupB release their strong references. The PopupView instances are deallocated, and each WeakConverterView.convert becomes nil without HomeViewController needing to remove entries manually.

If you want to see all of the code above in an editor you can watch my youtube video here;

Sources:
- Swift Arrays Holding Elements With Weak References

- NSPointerArray

What I Was Trying To Do

My app, Walk Mate, has a Heatmap screen with two filters: “You” and “Others”. The “You” filter shows places where the current user walked. The “Others” filter shows anonymous walks from all other users around the world. The data goes through CloudKit Public Database so every user can see everyone else’s walk place in a circular region. (i.e. over Taipei City and Kaohsiung City)

I shipped version 3.4.2 on App Store last week. Real users from Turkey, USA, Taiwan, Sweden, Japan and Canada started using the app. I could see their accounts in App Store Connect Analytics. But when I opened my Heatmap “Others” tab in the simulator from Xcode, I saw nothing from those countries. Only my own old test walks from Izmir, Turkey.

This was the start of the confusion. 🤯

First Mistake: I Trusted The Dashboard Without Checking The Environment

I opened CloudKit Dashboard. I picked Production. I picked Public Database. I picked the record type HeatmapContribution. I saw a lot of records. Some had latitude around 25 (Taiwan), some around 35 (Japan), and so on. So I thought “the data is there, the bug must be in my app.”

I asked an AI agent to help me debug. We added log lines to the fetch function. We ran the app from Xcode. The logs said the fetch returned 134 records. All of them were near Izmir. None from Taiwan or Japan.

This made no sense to me at first. The dashboard clearly showed Taiwan records. The app clearly did not return them. We tried many things. We checked sort orders. We checked permissions. We checked if records were lost during parsing. Nothing explained it.

The Real Cause: Two CloudKit Worlds

Then we tried one direct test. We picked one record name (9A85DFF-089E-4435-90E5-XXXXX) from the dashboard for a Taiwan record. We told the app to fetch that exact record by its name. The app got back “Record not found”.

That was the moment everything clicked.

CloudKit has two separate databases for every container. One is called Development. One is called Production. They look the same in code. They have the same name, the same record types, and the same fields. But they hold different data and they live on different servers.

When you build and run your app from Xcode with your normal Apple developer signing, your app talks to Development. When Apple builds your app for App Store or TestFlight with distribution signing, your app talks to Production. This switch happens because of the signing profile, not because of your build configuration. So even if I changed Xcode scheme to Release, my Xcode build still talked to Development as long as I used my normal developer certificate.

So my picture was like this:

• My old test walks from past development runs went into Development.

• Real App Store users on 3.4.2 wrote their walks into Production.

• The CloudKit Dashboard tab said “Production” at the top and showed me Production data.

• My Xcode debug build read only Development data.

Two different worlds. Looking at one in the dashboard, and reading the other in the app. They never met.

A Second Bug Hiding Behind The Confusion

While we were fixing the environment confusion, we found another real problem. The “Others” fetch in 3.4.2 was failing silently for every real user. Why? Because the Production schema needed a Queryable index on the system field recordName, and a Queryable + Sortable index on the timestamp field. These indexes were not deployed in Production. Without them, every “Others” query returned the error “Field ‘recordName’ is not marked queryable”.

The good news is that CloudKit indexes apply right away once you deploy them. So I went into the dashboard, added the indexes in Development, then clicked “Deploy Schema Changes to Production”. After that, my live App Store users could finally see global heatmap data without me shipping a new version.

I tested this by deleting Walk Mate from my iPhone, reinstalling 3.4.2 from the App Store, and opening the Heatmap. I saw my own Izmir walks under “You” and global walks by others under “Others”. It worked. 🚀

The Confusion Came Back

Then I built and ran the same code from Xcode in Debug mode. The others walks were gone again. Only my local one under both “You” and “Others”. I thought I broke something. 😮‍💨

I did not break anything. The Xcode debug build was reading Development again. Development still has no Taiwan or others records because no real user ever writes to Development. Only my past tests wrote to Development. So the Heatmap “Others” looks empty in Xcode debug runs and that is the correct expected behavior.

How To Verify Production Data From Xcode If You Want

There are two ways:

1. Add this temporary key in your entitlements file:

   <key>com.apple.developer.icloud-container-environment</key>
   <string>Production</string>

This forces Xcode builds to talk to Production. Use it only for testing and remove it after. Apple’s archive flow does not need this key. It picks Production by itself when it signs with a distribution profile.

2. Distribute the build through TestFlight Internal Testing. TestFlight builds use Production by default. So if you install your TestFlight build on a simulator or a device, you will see real user data.

What I Learned

A few simple things I now keep in mind:

• CloudKit Development and CloudKit Production are not the same database. They look the same in code. They are not the same at runtime.

• The CloudKit Dashboard tab you are looking at controls only the dashboard view. Your app picks its own database based on signing.

• Schema changes and index changes only apply to one environment. You must click “Deploy Schema Changes” to push them from Development to Production.

• Indexes are not auto created in Production by save. Records can be saved without indexes but cannot be queried. So users will quietly upload data that nobody can ever read until you deploy the indexes.

• A simple query log that prints the count of records returned would have saved me hours. I added that log on day one for next time.

• A direct fetch by record name is the fastest way to confirm “is this record actually in the database my app talks to”. If you get back “Record not found” for a record you can clearly see in the dashboard, you are not in the same database.

The bug felt huge while I was inside it. The fix in code was tiny. The fix in dashboard was just a few clicks. The real lesson was about understanding which CloudKit world I was talking to at any moment. 🤔

Short answer is;

Frame = a view’s location and size using the parent view’s coordinate system. Placing the view on the parent.

Bounds = a view’s location and size using its own coordinate system. Placing the view’s content or subview within itself.

If you think about the view frame in its parent coordinate system when you are rotating, you are changing parent view’s coordinate system. Bounds value will be same and frame value changes. Figure 1.0 shows how it looks like before transformation (rotating) and look carefully to the values.

The values in CGRect(x: 5, y: 5, width: 30, height: 40) define the rectangle's position and size:

• x (5): The horizontal distance from the left edge of the parent view to the rectangle’s origin.

• y (5): The vertical distance from the top edge of the parent view to the rectangle’s origin.

• width (30): The horizontal span of the rectangle.

• height (40): The vertical span of the rectangle.

These values specifically define the frame of the view, representing its location and size within its superview (parent) coordinate system.

View:

frame = { 5, 5, 30, 40 }
bounds = { 0, 0, 30, 40 }
center = { 20, 25 }

When the view rotated:

• Frame (changed): Because the view is now at an angle, it occupies more “horizontal and vertical space” relative to the parent’s X and Y axes.

• Bounds (unchanged): The view’s internal size remains (30 x 40) because the object itself hasn’t grown.

The dashed line in Figure 1.1 shows rotation and parent view’s location. Its width (52) and height (54) are calculated based on the rotated corners of the original (30 x 40) rectangle. Its corners push further out along the X and Y axes. To keep the view contained the parent system must calculate a new bounding box (the dashed line in Figure1.1) that reaches these new outermost points. The distance between its leftmost corner and rightmost corner is now 52, and the distance between its topmost and bottommost corner is 54.

View:

frame = { -6, -2, 52, 54 } // changed
bounds = { 0, 0, 30, 40 } // unchanged
center = { 20, 25 } // unchanged

I’m back with another concurrency question asked in one of the interviews like:

“When you have a Singleton (shared resource) in a multi-threaded environment, multiple queues can access to Singleton, the same shared state. You need to use a mechanism for accessing the common resource synchronously. What else do you remember for synchronizing the access to the common resource other than NSLock and DispatchSemaphore?”

I answered with DispatchBarrier by trying my best to explain. Let’s deep dive into the DispatchBarrier and then the modern way!

DispatchBarrier

It tells the compiler; “Wait. Let’s finish all the work that has already started. Then, just ME will work. Once I’m finished, the other tasks can continue.” In order to prevent data race, run tasks in an ordered way. Don’t run read and write operations at the same time! Once at a time!

Let’s explain it with a real life scenario;

Concurrent queue = multi-lane highway 🛣️

• Read operations = normal cars 🚗

• Write operations = road maintenance car 🚧

When the Dispatch Barrier arrives;

1. All cars pass first,

2. Road is closed completely,

3. Road maintenance car works alone,

4. Road opens again once the maintenance completed.

Let’s jump into the code example:

final class Highway {

    private let roadQueue = DispatchQueue( // 1
        label: "highway.queue",
        attributes: .concurrent
    )

    // Current road status
    private var roadStatus = "Road is Open"

    // Normal cars
    func carPass(carName: String) {

        roadQueue.async { // 2
            print("🚗 \(carName) is passing...")
            sleep(2)
            print("✅ \(carName) passed")
        }
    }

    // Road maintenance car is coming
    func roadMaintenance() {

        roadQueue.async(flags: .barrier) { // 3
            print("🛑 Road is closing...")
            print("🛠️ Maintenance car is working...")
            
            sleep(3)

            self.roadStatus = "Maintenance Completed!"

            print("✅ Maintenance is done")
            print("🟢 Road opens again")

            // new cars can pass concurrently again
        }
    }
}

Let’s dive into comment number lines:

1. Create a concurrent queue

2. async + concurrent queue

3. Use barrier. At this point queue behaves as serial temporarily.

Usage:

let highway = Highway()

highway.carPass(carName: "Car 1")
highway.carPass(carName: "Car 2")
highway.carPass(carName: "Car 3")

highway.roadMaintenance()

highway.carPass(carName: "Car 4")
highway.carPass(carName: "Car 5")

The workflow would roughly be like:

🚗 Car 1 is passing...
🚗 Car 2 is passing...
🚗 Car 3 is passing...

✅ Car 1 passed
✅ Car 2 passed
✅ Car 3 passed

🛑 Road is closing...
🛠️ Maintenance car is working...

✅ Maintenance is done
🟢 Road opens again

🚗 Car 4 is passing...
🚗 Car 5 is passing...

The critical points are here:

• The first 3 car can go at the same time (concurrent)

• Everybody waits when the maintenance car arrive (barrier)

• Road opens again when the maintenance completed.

Modern Way Actor

In a modern Swift Concurrency way, actors allow us to protect shared mutable state from data races. It means that an actor can help us fix a data race in a same way we had before by serializing access to mutable state. This is what we did manually with the DispatchBarrier earlier except actors are a lot smarter than the naive .barrier approach we took earlier.

Let’s update the code example with the modern and safer way:

// 1
actor Highway {

    // Current road status
    private var roadStatus = "Road is Open" // 2

    // Normal cars
    func carPass(carName: String) async {

        print("🚗 \(carName) is passing...")
        try? await Task.sleep(for: .seconds(2)) // 3
        print("✅ \(carName) passed")
    }

    // Road maintenance car is coming
    func roadMaintenance() async {

        print("🛑 Road is closing...")
        print("🛠️ Maintenance car is working...")

        try? await Task.sleep(for: .seconds(3))

        roadStatus = "Maintenance Completed!"

        print("✅ Maintenance is done")
        print("🟢 Road opens again")
    }

    func currentStatus() -> String {
        roadStatus
    }
}

Let’s dive into comment number lines:

1. I will queue access to the mutable state within this object.

   • No need .barrier definition

   • No queue creation

   • No synchronization code

2. actor protects state of private var roadStatus

   • Two tasks cannot change state simultaneously

   • One cannot interrupt while the other is changing state

   • No data race

Similarity with DispatchBarrier

Mentally that’s what actor makes under the hood: concurrent queue + barrier. But the main difference is: in the .barrier approach you write synchronization manually, in the actor, Swift runtime manages synchronization automatically.

Conclusion

In the Dispatch Barrier version of our Highway example, every car that wanted to access the road had to wait for the barrier operation to finish before continuing. During this waiting period, the underlying thread was blocked. In other words, the thread could not do any other useful work until the road maintenance operation completed.

This is one of the biggest differences between traditional GCD synchronization techniques and Swift Concurrency.

With Dispatch Barrier, we manually tell the queue: “Stop all traffic temporarily and let this critical operation run alone.” While this approach is safe and effective, waiting tasks often end up blocking threads.

Actors take a different approach. By converting our Highway type from a class into an actor, Swift automatically serializes access to mutable state for us. Instead of blocking threads while waiting for access, Swift Concurrency suspends tasks.

So mentally, you can think of the difference like this:

Dispatch Barrier

“Block the road until maintenance is done.”

Actor

“Cars waiting for maintenance don’t block the road itself. They pause and resume later.”

This is one of the core ideas behind Swift Concurrency: Suspend tasks, not threads.

Sources:

• Apple Developer - Managing a Shared Resource Using a Singleton

• Thread safe singleton in swift - Stack Overflow

• Stack Overflow Legend Rob 🤩

• Practical Swift Concurrency - Donny Wals

Most recently, when I was trying to end Live Activities completely and immediately and remove from both Dynamic Island and lock screen when the app terminated, I had a nondeterministic behavior. That Live Activity was sometimes removed sometimes not. After conducting some research, I discovered the solution using both modern Swift Concurrency and old Semaphore like below.

final class AppDelegate: NSObject, UIApplicationDelegate {
    
    func applicationWillTerminate(_ application: UIApplication) {
        let semaphore = DispatchSemaphore(value: 0)
        
        // Intentional: on termination we have a tiny window to end Live Activities.
        // A detached task avoids main-actor inheritance while we do a short bounded wait.
        Task.detached(priority: .high) {
            for activity in Activity<WalkActivityAttributes>.activities {
                let finalContent = ActivityContent(state: activity.content.state, staleDate: nil)
                await activity.end(finalContent, dismissalPolicy: .immediate)
            }
            // the semaphore’s .signal method is called to increment the number of available resources
            // so that whoever is waiting to access our resource can eventually gain access
            semaphore.signal()
        }
        // Every time we call .wait on the semaphore, the number of available resources either
        // decreases, or we wait for a resource to become available.
        _ = semaphore.wait(timeout: .now() + 2)
    }
}

Let’s visualize that code in the Dining Philosopher Problem manner but from the restaurant staff perspective.

The main purpose here is to clear the Live Activity as quickly as possible before the app completely terminates.

But the problem is;

• activity.end(...) works async,

• the process may be interrupted,

• Result: Live Activity stays remaining in both screens.

That semaphore solution does; wait for a while before the app termination and Live Activity cleaning ends.

Let’s visualize in the restaurant analogy 👇

Restaurant Analogy

You are the restaurant owner. Restaurant will close soon. But there are still customers eating:

• Live Activities appear in lock screen

• Live Activities in the Dynamic Island

You say: “Get out all customers before restaurant close 🤬”

1. Creating Semaphores

let semaphore = DispatchSemaphore(value: 0)

It means, put a waiter to the door. But the waiter at first in “None of the customers have not completed their dinner.“ status. So, the restaurant owner (app) has to wait.

value: 0 means there is no allowance to close restaurant.

2. Cleaning starts in background

Task.detached(priority: .high) {}

Send waiters to clean tables quickly.

Logic behind detached is “have a separate team work without involving the main restaurant manager”

3. Remove all customers

for activity in Activity<WalkActivityAttributes>.activities {
    await activity.end(...)
}

This means, the waiter goes to all tables and says “Restaurant is closing, you must leave.“

await is important because, the waiter is really expecting customers to leave. But, this doesn’t happen immediately.

4. Notify the waiter when the job is finished

semaphore.signal()

It means, the waiter comes and tells “Finally, all customers are gone 😮‍💨“

DispatchSemaphore value becomes 0 → 1. So, we can close the restaurant.

5. App waits for a bit

_ = semaphore.wait(timeout: .now() + 2)

The restaurant owner waits on the doorstep and yells to staff “I’ll wait for 2 sec until cleaning completes“.

If:

• Staff finish their job → restaurant closes properly.

• If they can’t → time’s up → restaurant closes.

Why this code is important?

Because iOS doesn’t wait async jobs while app is terminating.

So, normally if you do that app can directly close:

await activity.end()

Semaphore solution says, “One minute, let’s finish this job before close”.

What does Semaphore represent here?

In the restaurant example:

wait(): The waiter waits on the doorstep.

signal(): The staff says “Job is done”.

value: 0: No close.

value: 1: Can be close now.

Briefly

1. App will terminate

2. Start closing Live Activities

3. Wait a short while so the app doesn’t close immediately

4. Continue when the work is finished

5. Close again after 2 sec max

Semaphore here works like a:

“Traffic police who manages closing road for a short time” 🙂

The Modern Way

DispatchSemaphore is an old school synchronization tool which comes from Grand Central Dispatch world. In the modern swift concurrency approach async/await and Task usage will be chosen.

In theory we can use something like below for terminating Live Activities:

func endAllActivities() async {
    for activity in Activity<WalkActivityAttributes>.activities {
        let finalContent = ActivityContent(
            state: activity.content.state,
            staleDate: nil
        )

        await activity.end(
            finalContent,
            dismissalPolicy: .immediate
        )
    }
}

and we can call it:

Task {
    await endAllActivities()
}

However, there is an important problem here is the applicationWillTerminate is not an async lifecycle callback. iOS doesn’t guarantee the completion of async tasks when terminating and application. Therefore, while using only Task {} is more modern in theory, it may not be reliable in practice.

Hence, the most healthier approach is not doing Live Activity cleanup while app termination but doing it in either while switching to background or doing it before the scene has been inactive.

For instance:

func sceneDidEnterBackground(_ scene: UIScene) {
    Task {
        await endAllActivities()
    }
}

This approach:

• It is natively compatible with Swift Concurrency

• It does not cause thread blocking

• It removes Semaphore requirement

• It increases completion possibility of async tasks

Conclusion

Task + async/await is the modern approach but there is no 100% guarantee during the app termination. Hence, the best approach is doing cleanup at the early stages of the lifecycle.

Nowadays, I’m brushing up my iOS concurrent programming skills based on my past iOS interview experiences. I’ve been creating an interview questions pool for the past 5 years based on the interviews that I have so far. Just after a week, the modern Swift Concurrency officially announced by Apple, I had a technical interview with Spotify and faced beautiful concurrency questions. Based on these questions, I decided to write some comparison article between DispatchGroup(legacy way) and TaskGroup (modern way). Let’s start with the legacy one!

DispatchGroup

It’s briefly used when you have a bunch of asynchronous tasks running in parallel and wait for all work to be completed in a given queue and you want to be notified when all of them are finished. Dispatch group have various work items to execute, and perform another work item once all of our work items are completed. A dispatch group doesn’t actually execute work and it’s up to you to decide where and how all of your work runs. It only tracks the number of tasks that you’ve started, and the number of tasks that you’ve completed.

Let’s look at the example:

func fetchUserProfiles() {
    let group = DispatchGroup() // 1
    var results = [Data]()
    let userIDs = [1, 2, 3]
    let urls = userIDs
        .compactMap { URL(string: "https://jsonplaceholder.typicode.com/users/\($0)") }

    for url in urls {
        group.enter() // 3
        URLSession.shared.dataTask(with: url) { data, response, error in
            if let data {
                results.append(data)
            }
            defer { group.leave() } // 4
        }.resume()
    }

    group.notify(queue: .main) { [weak self] in // 2
        self?.textLabel.text = "All jobs have completed!"
    }
}

The code above kicks off an API call for each url, appends the fetched user data to an array, and once all API calls done the textLabel.text will be “All jobs have completed!”.

Let’s deep dive into comment lines:

1. Create a new DispatchGroup() to track the number of times we start work, and the number of times we complete work.

2. Schedule a work item (update textLabel’s text) that will be executed on the main thread (indicated dispatch queue) once all work in the group is done. Note: The notification is itself asynchronous, so it’s possible to submit more jobs to the group after calling notify, as long as the previously submitted jobs haven’t already completed. (Source: Concurrency by Tutorials - Ray Wenderlich)

3. For each url that was created, enter the dispatch group. It will increment the counter for the number of running tasks every time we enter the group.

4. Once the API call done, independently from the error or success cases, leave the dispatch group. Otherwise, you will never be signaled of completion. Once the last task is completed, notify(queue:) callback method will be informed.
   
   As you can see the dispatch groups are very handy tool. Now, let’s see the Swift Concurrency version.

TaskGroup

It’s pretty much like DispatchGroup, but in the modern Swift Concurrency world. A TaskGroup manages a dynamic number of child tasks, and automatically waits for all of them to complete before returning. Unlike DispatchGroup, it doesn’t track counters manually (comment line // 3 in the previous code block) instead, it ties the lifetime of child tasks directly to the group itself.

Let’s look at the example:

@MainActor
func fetchUserProfiles() async {
    var results = [Data]()
    let userIDs = [1, 2, 3]
    let urls = userIDs
        .compactMap { URL(string: "https://jsonplaceholder.typicode.com/users/\($0)") }

    await withTaskGroup(of: Data?.self) { group in // 1
        for url in urls {
            group.addTask { // 3
                let (data, _) = try? await URLSession.shared.data(from: url)
                return data
            }
        }

        for await data in group { // 2
            if let data {
                results.append(data)
            }
        }
    } // 4

    textLabel.text = "All jobs have completed"
}

I used exact same code example in a TaskGroup way.

Let’s deep dive into comment lines:

1. withTaskGroup(of:) creates a new task group, similar to DispatchGroup(). Unlike DispatchGroup though, you declare upfront what type each child task will produce (i.e Data?.self).

2. for await data in group replaces group.notify(queue:). Instead of scheduling a callback to fire when all work is done, you iterate over results as each child task completes. The loop ends naturally once every child task finishes.

3. group.addTask {} replaces the group.enter() + closure + group.leave() threes*me 🙊. Adding a task implicitly enters the group, and returning from the closure implicitly leaves it, no risk of forgetting a leave().

4. The closing brace of withTaskGroup is the moment all child tasks are guaranteed to be done. This is where group.notify(queue:) would have fired in the DispatchGroup world. After this point, results is safe to use.

Note: Even though fetchUserProfiles() is marked @MainActor, the network calls inside addTask will never run on the main thread. URLSession is in charge of its own execution context, not the caller. So marking the function @MainActor is completely safe and won’t block the main thread. Thanks Matt for pointing out! 🤩

As you can see, TaskGroup achieves the exact same goal as DispatchGroup but the structured approach eliminates the enter/leave counter belly dance, and await replaces the callback entirely, making the code read easily like synchronous code.

If you find modern concurrency super confusing like me, let’s start with these WWDC videos first:

- WWDC21 - Swift concurrency: Behind the scenes
- WWDC22 - Visualize and optimize Swift Concurrency
- WWDC23 - Beyond the basics of structured concurrency

- the adaptee (UK wall socket) has the incompatible interface the client (MacBook charger) can’t plug directly,
- your MacBook charger is the client that has the protocol it was built with EU 2-pin,
- the adapter that we bought from the store, sits in between, translating one protocol to the other without changing either side’s behavior

Here's the Swift code demonstrated on the plug analogy. UK wall socket as Adaptee, MacBook EU charger as Client, and the travel adapter as the Adapter:

// MARK: - Adaptee
// The UK wall socket — it only has UK 3-pin
 
class UKWallSocket {
    func provideUKPower() -> String {
        return "⚡️ 240V via UK 3-pin socket"
    }
}

The MacBook charger expects EU 2-pin power and it only works with EUPowerProvider. It has no idea whether the power comes from an EU socket
or a UK socket adapted via TravelAdapter. MacBookCharger depends on the protocol (EUPowerProvider), not the concrete adapter. This keeps it decoupled.

// MARK: - Client Protocol
// The MacBook charger expects EU 2-pin power
 
protocol EUPowerProvider {
    func provideEUPower() -> String
}

// MARK: - Client
 
class MacBookCharger {
    
    private let powerProvider: EUPowerProvider
 
    init(powerProvider: EUPowerProvider) {
        self.powerProvider = powerProvider
    }
 
    func charge() {
        let power = powerProvider.provideEUPower()
        print("MacBook charging... %\(power)")
    }
}

The travel adapter sits between the two. It plugs into the UK socket (Adaptee) and
exposes the EU interface the MacBook charger (Client) expects. TravelAdapter wraps the adaptee(UKWallSocket) via composition (not inheritance), which is the preferred Swift approach.

// MARK: - Adapter
 
class TravelAdapter: EUPowerProvider {
 
    private let ukSocket: UKWallSocket
 
    init(ukSocket: UKWallSocket) {
        self.ukSocket = ukSocket
    }
 
    func provideEUPower() -> String {
        let ukPower = ukSocket.provideUKPower()
        return "🔌 Adapted to EU 2-pin -> \(ukPower)"
    }
}

Doing so, the UK socket's behavior is unchanged and the adapter only translates, exactly as the pattern intends.

// MARK: - Usage
 
let ukSocket = UKWallSocket() // Adaptee
// Plug adapter into the ukSocket
let adapter = TravelAdapter(ukSocket: ukSocket) // Adapter
// Plug MacBook charger into the adapter
let macCharger = MacBookCharger(powerProvider: adapter) // Client
 
macCharger.charge()
// MacBook charging... 🔌 Adapted to EU 2-pin -> ⚡️ 240V via UK 3-pin socket

Conclusion

In this article, I explained how the Adapter Pattern is used to make two classes with incompatible APIs work together. I demonstrated how to define an adapter by creating a class that wraps around the object being adapted, conforming to the interface the client expects.

Sources:
- https://www.amazon.com/Design-Patterns-Swift-Adam-Freeman/dp/148420395X

The lesson is not never use LLMs. It is don’t trust the diff until you’ve validated size, bundle contents, and build configuration. The same things we should have checked before shipping anything, human or AI-written.

What went wrong

Apple’s Game Center integration in modern Xcode often uses a GameCenterResources.gamekit package: JSON plus optional localized images, Pull / Push with App Store Connect. That file belongs in the project for authoring and sync.

What it typically does not need, for a standard achievement setup, is to sit in Copy Bundle Resources for your Release app target. `GameKit` loads achievement metadata and art from Apple’s services when your app uses the right IDs. Much of that art lives on Apple’s CDN (you will see `mzstatic.com` URLs inside `gameCenterResources.json`). If some locales instead use relative paths (for example `da/AchievementImage-….png`), those files are candidates to be bundled. If the entire `.gamekit` tree is copied into the app, every user pays for that download and disk use.

In Walk Mate, the package had been wired like ordinary app resources including many megabytes of achievement images. It had also landed in more than one target (including an extension), where it had no runtime purpose.

That’s the edge case: Game Center is configured with only what must ship in the IPA should ship.

What I changed

1. GameCenterResources.gamekit was removed from Copy Bundle Resources for the main iOS app and the notification service extension (it should never have been duplicated there).

2. The `.gamekit` bundle stays in the repository under version control so you can still use Xcode → (Game Center editor) … → Pull from / Push to App Store Connect; you simply stop embedding that package in the built product shipped to users.

3. gameCenterResources.json clarified the mechanics: many locales referenced CDN URLs, Localization entries used local relative paths, which is how multi-megabyte PNGs became part of the payload while other languages did not!

After a clean Archive, the App Thinning Size Report moved from roughly ~125–130 MB compressed for representative iPhone/iPad variants down to roughly ~23–26 MB compressed 😀 for comparable slices, a drop on the order of ~100 MB of avoidable bundle weight, consistent with removing the mistaken resource package. 🤨

How to check size

After Xcode → Product → Archive, use the workflow that produces App Thinning analysis from Xcode Organizer when working with an App Store archive. Open App Thinning Size Report.txt.

• Compare compressed vs uncompressed per variant: compressed is closest to download perception, uncompressed reflects expansion for that thinned slice.

• Keep two reports (before / after a change) and diff the same variant family. That is a cheap regression guard for accidental resource bloat.

Reducing app size in general

• Judge shipping app size from Release/Archive, not default Debug Run.

• Asset catalogs: correct scales, avoid overweight PNGs where better formats or simplification suffice.

• Dependencies: every Swift package and framework has a cost! Periodic review of what links into the main target matters!

• Extensions: each target has its own resources rules, so, avoid duplicating large blobs.

• When prompting an LLM, state non-goals explicitly like: “Do not add to Copy Bundle Resources unless runtime-required; verify with Archive + App Thinning diff.”

Why we shouldn’t use LLMs blindly

Models optimize for edit from your prompt and visible code. For instance, they don’t automatically enforce your download size or budget, the distinction between authoring / sync assets and runtime bundle contents.

Conclusion

AI can speed things up, -but it’s anyways your responsibility to triple-check- so you don’t embed authoring assets nobody needed at runtime 😅



Source: https://developer.apple.com/documentation/xcode/reducing-your-app-s-size

Even almost every people can speak English in Nordic countries, we’re supporting 7 different Nordic languages in my company.

We’re using POEditor for faster localization processes.

POEditor

In this article, I will explain how to add a language, export, and import localization files in a faster way.

First of all, we have a String extension like this:

extension String {
    public func localized(_ bundle: Bundle = .locales) -> String {
        NSLocalizedString(self, bundle: bundle, comment: "")
    }
}

//Usage
class Foo: UIViewController {
    let title = "settings_title".localized()
}

When the new strings are added to the code base,

“settings_title”.localized()

then you need to add these new strings to

Add the string to the English version of Supporting Files/Localizable.strings
i.e.: Project_Directory/Project_Name/Sources/Locales/en.lproj/Localizable.strings

and send to POEditor (either manually or automatically). Then someone(licensed translator) does the translation in POEditor manually.
After that, you should be able to fetch them (either manually or automatically) from POEditor.

How do we extract/import translations from/to POEditor automatically?

We can either manually send the new strings to poeditor.com using
fastlane translations_extract fastlane script or GitLab CI doing it for us automatically.

After someone(licensed translator) does the translation in POEditor manually.

After all of that has been done we can run the following command
fastlane translations_import to fetch the new translations and check them into the codebase.

Conclusion

POEditor is a great localization tool to increase user experience and save time since you will be waiting for translations for the new strings.

What is VoiceOver?

As you guess disabled people use smartphone apps as well. Designing your apps with accessibility in mind helps everyone use them, including people with vision, or hearing disabilities.

VoiceOver is a screen reader built into Apple Inc.’s macOS, iOS, tvOS, watchOS, and iPod operating systems. By using VoiceOver, the user can access their Macintosh or iOS device based on spoken descriptions and, in the case of the Mac, the keyboard.

Why Accessibility?

In my current company, we’re also supporting Accessibilities, especially VoiceOver. In our e-paper applications, we have active 2K blind users.

• You’ll reach a larger group.

• It feels good to know you’re making a noticeable difference in more people’s life.

How to Activate and Use VoiceOver?

You can find detailed information about activation and usage of VoiceOver on iPhone on Apple’s website:
https://support.apple.com/guide/iphone/iph3e2e415f/ios

• Single-tap anywhere and VoiceOver will read information from the item’s accessibility attributes loudly.

• Single-swipe left or right and VoiceOver will select the next visible accessibility item and read it loudly.

• Single-swipe down to spell the focused item letter-by-letter.

• Double-tap to select the specific item.

• Three-finger-swipe left or right to navigate forward or backward in a page view.

For the complete list of VoiceOver gestures, check out Apple’s Learn VoiceOver gestures on iPhone. So now you know how VoiceOver works.

Accessibility Attributes

An accessibility attribute has five properties:

First of all, you should define the accessibility element of the UI element.

titleLabel.isAccessibilityElement = true

1. accessibilityLabel: A concise way to identify the control or view.

titleLabel.accessibilityLabel = foo.title

2. accessibilityTraits: These describe the element’s state or behavior. A cell trait might be .button, for example.

cell.accessibilityTraits = .none

cell.accessibilityTraits = .button

cell.accessibilityTraits = .link

cell.accessibilityTraits = .header

cell.accessibilityTraits = .adjustable

cell.accessibilityTraits = .allowsDirectInteraction

cell.accessibilityTraits = .causesPageTurn

cell.accessibilityTraits = .image

cell.accessibilityTraits = .keyboardKey

cell.accessibilityTraits = .notEnabled

cell.accessibilityTraits = .playSound

cell.accessibilityTraits = .searchField

cell.accessibilityTraits = .startsMediaSession

cell.accessibilityTraits = .staticText

cell.accessibilityTraits = .selected

cell.accessibilityTraits = .summaryElement

cell.accessibilityTraits = .tabBar

3. accessibilityHint: Describes the action an element completes. For example:

playButton.accessibilityHint = "double_tap_to_pause"
loginCell.accessibilityHint = "double_tap_to_log_out"

4. accessibilityFrame: The frame of the element within the screen, in the format of a CGRect. VoiceOver speaks the contents of the CGRect.

5. accessibilityValue: The value of an element. For example, with a progress bar or a slider, the current value might read: 5 out of 100.

Using the Accessibility Inspector

There’s a tool named Accessibility Inspector, which does the following:

• Lets you check the accessibility attributes of UI elements in Inspection Mode.

• Provides live previews of accessibility elements without leaving your app.

• Supports all platforms including macOS, iOS, watchOS, and tvOS.

To do all of these things, open it in the Xcode menu by navigating to Xcode ▸ Open Developer Tool ▸ Accessibility Inspector.

Conclusion

You learned about VoiceOver. You used the Accessibility Inspector to perform audits by scrolling through every accessible element. See you 🖖🏼

@MainActor Attribute:

- The `@MainActor` attribute plays a crucial role in Swift Concurrency by ensuring specific parts of your code always run on the main thread.

- Particularly useful in SwiftUI, where UI updates must be performed on the main thread.

- SwiftUI views are implicitly marked as `@MainActors` when they have `@ObservableObject` properties like `@StateObject`, `@ObservedObject`, and `@EnvironentObject`.

struct MyView: View {
  @StateObject var vm = MyViewModel()
  
  var body: some View {
   Button {
    Task {
      await vm.performSomeWork()
    }
   } label: {
     Text("Test")
   }
  }
}

Key Points:

- `await` doesn’t block the current thread; it allows suspension of the current task, enabling other operations to continue.

- Functions decide the execution context, not where they are called from.

Changing Execution Context:

- You can explicitly specify the execution context using `@MainActor` or opt out of `MainActor` isolation with `noisolated`.

class MyViewModel: ObservableObject {
 // This will always run on the Global executor
 func performSomeWork() async {}
// This will always run on the Main actor / thread
 @MainActor func performSomeWork() async {}
// This will _not_ run on the Main actor / thread
 nonisolated func performSomeWork() async {}
}

Structured Concurrency and Tasks:

- A Task represents a unit of work, and there are two types: unstructured and detached.

- Unstructured tasks inherit parts of their creation context but are not child tasks of their creation context.

- Detached tasks inherit nothing and work independently.

// Creating an unstructured Task
Task {
 // I'm an unstructured task
}
// Creating a detached Task
Task.detached {
 // I'm a detached task
}

Key Takeaways:

- Unstructured tasks are not child tasks of their creation context.

- Detached tasks inherit nothing and are their own islands of concurrency.

Structured Concurrency:

- Structured concurrency ensures that child tasks are completed before the parent task finishes.

- Unstructured tasks can outlive their parent tasks, but structured tasks enforce completion of child tasks before the parent task concludes.

Example:

func runTask() async {
  let result = await withTaskGroup(of: Int.self) { group -> Int in
  group.spawn {
  await longRunningTask()
 }

// Wait for all child tasks to finish and collect the results
 var total = 0
 for await result in group {
  total += result
 }
  return total
 }
  print("Result: \(result)")
}

Actor Isolation:

- Actors provide a safe way to access and modify mutable state concurrently.

- Methods and properties marked with `@MainActor` are actor-isolated.

- Using `@MainActor` ensures that the method or property runs on the main thread.

@MainActor
class SafeActorIsolatedClassExample {
 var foo = Foo(bar: "baz")

 func thisIsSafe() {
   Task {
     foo.bar = "qux"
   }
  }
}

Key Insights:

- Whole classes or properties can be marked as `@MainActor`.

- `UIViewController` is actor-isolated to `@MainActor`, ensuring safe concurrent access.

Conclusion:

Swift Concurrency brings powerful features to the table, allowing developers to create responsive and efficient asynchronous code. Understanding the nuances of `@MainActor`, structured concurrency, and actor isolation is essential for building robust and reliable Swift applications. Donny Wals’s presentation at iOS Conf SG 2023 provides valuable insights into mastering Swift Concurrency.

Sources:
- [Your Brain 🧠 on Swift Concurrency — iOS Conf SG 2023](

)
- [Mutating a mutable Struct within a Swift Task](https://stackoverflow.com/a/76868102/4442254)

Introduction:

Map annotation clustering is a technique used to group nearby annotations on a map into a single cluster, which is represented by a single annotation. This is important for improving performance and user experience, especially when dealing with large datasets. Without clustering, a map with many annotations can become cluttered and difficult to read, leading to a poor user experience. Clustering reduces the number of annotations displayed on the map, making it easier to read and improving performance by reducing the amount of data that needs to be rendered.

Overview of Map Annotation Clustering

First of all, I got a lot of help from this open-source project (ClusterMap) in order to implement map annotation clustering in iOS 17 SwiftUI Map. I highly recommend checking it out if you want to learn more about how it works.

Difference between working with UIKit Map and SwiftUI Map

In terms of data handling and performance, ClusterMap library provides a solution for implementing map annotation clustering in SwiftUI Map() by changing the data structure from an array or dictionary to a tree.

The most critical difference from the native implementation in UIKit is that the ClusterMap library handles adding data asynchronously, avoiding lags when adding significant quantities of data. In contrast, Apple handles adding data to the MainThread, which can cause lags when scrolling or zooming. The library requires the dimensions of the grid used in clustering to be provided through a custom configuration object. This allows for custom configuration of the grid size used in clustering, improving performance during scrolling or zooming. While Apple’s implementation is more straightforward, the performance issue could be critical (e.g. Memory usage reduced from ~500 MB to ~230 MB).

Integration with SwiftUI Map

When working with iOS 17, the library can be placed in an object marked with the @Observable macro and added to the hierarchy via the .environment modifier. The map will automatically reload when needed, such as when the camera position changes, and annotations can be added or removed in any other views. In my case I was trying to MKLocalSearch to search for places and display them on the map through a tabbar button.

An asynchronous local search is started using the MKLocalSearch class and the initialized request. The result of the search is stored in an async let variable called searchResult. After the search is completed, the clusterManager object is used to remove all existing annotations from the map. The mapItems property of the searchResult is then added to the clusterManager using the add method. Finally, the reloadAnnotations method is called to update the map view with the new annotations.

import ClusterMap
import Foundation
import MapKit
 
struct ExampleClusterAnnotation: Identifiable {
    var id = UUID()
    var coordinate: CLLocationCoordinate2D
    var count: Int
}
    
@Observable
class LocalSearchCompleter: NSObject {
var mapSize: CGSize = .zero
var currentRegion: MKCoordinateRegion = .userLocation
var annotations = [MKMapItem]() // #1 element of the tree
var clusters = [ExampleClusterAnnotation]() // #2 element of the tree
 
let customConfig = ClusterManager<MKMapItem>.Configuration(
    cellSizeForZoomLevel: { (zoom: Int) -> CGSize in
        switch zoom {
        case 13...15: return CGSize(width: 64, height: 64) // grid size used in clustering
        case 16...18: return CGSize(width: 32, height: 32)
        case 19...: return CGSize(width: 16, height: 16)
        default: return CGSize(width: 88, height: 88)
        }
    }
)
 
var clusterManager: ClusterManager<MKMapItem>
 
override init() {
    clusterManager = ClusterManager<MKMapItem>(configuration: customConfig)
}
 
func search(for query: String) async {
        let request = MKLocalSearch.Request()
        request.naturalLanguageQuery = query
        request.region = currentRegion
        do {
            async let searchResult = MKLocalSearch(request: request).start()
            await clusterManager.removeAll()
            try await clusterManager.add(searchResult.mapItems)
            await reloadAnnotations()
        } catch {
            assertionFailure("Error: \(error.localizedDescription)")
        }
    }
 
    func reloadAnnotations() async {
        async let changes = clusterManager.reload(mapViewSize: mapSize, coordinateRegion: currentRegion)
        await applyChanges(changes)
    }
 
    @MainActor
    private func applyChanges(_ difference: ClusterManager<MKMapItem>.Difference) {
        for removal in difference.removals {
            switch removal {
            case .annotation(let annotation):
                annotations.removeAll { $0 == annotation }
            case .cluster(let clusterAnnotation):
                clusters.removeAll { $0.id == clusterAnnotation.id }
            }
        }
        for insertion in difference.insertions {
            switch insertion {
            case .annotation(let newItem):
                annotations.append(newItem)
            case .cluster(let newItem):
                clusters.append(ExampleClusterAnnotation(
                    id: newItem.id,
                    coordinate: newItem.coordinate,
                    count: newItem.memberAnnotations.count
                ))
            }
        }
    }
}
 
extension MKMapItem: CoordinateIdentifiable, Identifiable {
  public var id: String {
      placemark.region?.identifier ?? UUID().uuidString
  } 
 
  public var coordinate: CLLocationCoordinate2D {
      get { placemark.coordinate }
      set(newValue) { }
  }
}

The customConfig object is defined using the ClusterManager class, which allows for custom configuration of the grid size used in clustering. Finally, the clusterManager property is initialized with the custom configuration.

Usage of the LocalSearchCompleter() in SwiftUI View:

import SwiftUI
import MapKit
import ClusterMap
 
struct LocationRequestIsOnView: View {
    
    @State private var searchClient = LocalSearchCompleter()
 
    var body: some View {
        NavigationStack {
            ZStack {
                mapView
            }
        }
    }
    
    var mapView: some View {
        Map(
            initialPosition: .region(searchClient.currentRegion),
            selection: $selectedResult
        ) {
            if !showSettingsView {
                ForEach(searchClient.annotations) { result in
                    if systemImageName == "bolt.car.circle.fill" {
                        Marker(result.placemark.name ?? "", systemImage: "bolt.car.circle.fill", coordinate: result.coordinate)
                            .tag(result)
                    } else {
                        Marker(result.placemark.name ?? "", systemImage: "fuelpump.circle.fill", coordinate: result.coordinate)
                            .tag(result)
                    }
                }
 
                ForEach(searchClient.clusters) { result in
                    if systemImageName == "bolt.car.circle.fill" {
                        Marker("\(result.count)", systemImage: "bolt.car.fill", coordinate: result.coordinate)
                    } else {
                        Marker("\(result.count)", systemImage: "fuelpump.circle.fill", coordinate: result.coordinate)
                    }
                }
                
                UserAnnotation()
                
                if let route {
                    MapPolyline(route)
                        .stroke(.blue, lineWidth: 5)
                }
            }
        }
        .readSize(onChange: { newValue in
            searchClient.mapSize = newValue
        })
        .onChange(of: selectedResult) {
            if selectedResult != nil {
                getDirections()
                isShowingBottomSheet = true
            } else {
                isShowingBottomSheet = false
            }                
        }
        .sheet(isPresented: $isShowingBottomSheet) {
            ItemInfoView(
                isShowingBottomSheet: $isShowingBottomSheet,
                route: $route,
                selectedResult: $selectedResult, selectedTabBarButton: selectedTabBarButton,
                url: self.shareLocation()
            )
            .presentationDetents([.medium, .fraction(0.12), .large])
            .presentationBackgroundInteraction(.enabled(upThrough: .medium))
            .presentationDragIndicator(.visible)
        }
        .onMapCameraChange { context in
            searchClient.currentRegion = context.region
        }
        .onMapCameraChange(frequency: .onEnd) { context in
            Task.detached {
                await searchClient.reloadAnnotations()
            }
        }
        .mapControls {
            MapUserLocationButton()
            MapCompass()
            MapScaleView()
        }
        .environment(searchClient)
    }
}

There is a ForEach loop that iterates over the searchClient.annotations array (which are the first element of the tree). For each annotation, a Marker view is created and displayed on the map. The Marker represents a location on the map and includes a title, a system image, and a coordinate. Similarly, there is another ForEach loop that iterates over the searchClient.clusters array (which are the second elements of the tree). For each cluster, a Marker view is created and displayed on the map. The Marker represents a cluster of locations and includes the count of locations in the cluster, a system image, and a coordinate. The mapView also includes various modifiers and event handlers. For example, the readSize modifier is used to update the searchClient's mapSize property when the size of the map view changes. The onChange event handler is used to perform actions when the selectedResult changes, such as getting directions and showing or hiding a bottom sheet.

Performance Benefits of ClusterMap

…and so many other hangs, hitchs and lags that I was experiencing with the native MapKit implementation which I couldn’t add the Xcode Instruments screenshots.

Overall, the project demonstrates how the combination of SwiftUI Map, ClusterMap, and other technologies can be used to create a performant and customizable map view in iOS 17. “Thanks Apple 🤣” By following best practices for implementing map annotation clustering, such as using a third-party library and providing custom configuration for the grid size, you can create a better user experience and improve the performance of your MapKit projects.

See you ✌🏼

The Composable Architecture (TCA, for short)(opens in a new tab) is a library for building applications in a consistent and understandable way, with composition, testing, and ergonomics in mind, developed by Brandon Williams(opens in a new tab) and Stephen Celis(opens in a new tab) from Point-Free. It can be used in SwiftUI, UIKit, and more, and on any Apple platform (iOS, macOS, tvOS, and watchOS).”

Core tools

• State management

How to manage the state of your application using simple value types, and share state across many screens so that mutations in one screen can be immediately observed in another screen.

• Composition

How to break down large features into smaller components that can be extracted to their own, isolated modules and be easily glued back together to form the feature.

• Side effects

How to let certain parts of the application talk to the outside world in the most testable and understandable way possible.

• Testing

How to not only test a feature built in the architecture, but also write integration tests for features that have been composed of many parts, and write end-to-end tests to understand how side effects influence your application. This allows you to make strong guarantees that your business logic is running in the way you expect.

• Ergonomics

How to accomplish all of the above in a simple API with as few concepts and moving parts as possible.

Basic Usage

To build a feature using the Composable Architecture you define some types and values that model your domain:

• State: A type that describes the data your feature needs to perform its logic and render its UI.

• Action: A type that represents all of the actions that can happen in your feature, such as user actions, notifications, event sources and more.

• Reducer: A function that describes how to evolve the current state of the app to the next state given an action. The reducer is also responsible for returning any effects that should be run, such as API requests, which can be done by returning an Effect value.

• Store: The runtime that actually drives your feature. You send all user actions to the store so that the store can run the reducer and effects, and you can observe state changes in the store so that you can update UI.

The benefits of doing this are that you will instantly unlock testability of your feature, and you will be able to break large, complex features into smaller domains that can be glued together.

Demo Project

As a basic example, consider a UI that shows a 2-columns grid list along with “#” team/player ids, names and, team logos. When the views appear, there is an API request to fetch NBA teams and players and then displays in a 2-columns grid list.

🧑🏼‍🦳👨🏼‍🦳 To implement this root (grand-parent) feature we create a new type that will house the root domain and behavior of the feature by conforming to Reducer:

import ComposableArchitecture

struct RootFeature: Reducer {}

In here we need to define a type for the root feature’s state, which consists of a selected tab, as well as parent feature states that are TeamListFeature.State() and PlayerListFeature.State():

struct RootFeature: Reducer {
    struct State: Equatable {
        var selectedTab = Tab.teams
        var teamListState = TeamListFeature.State()
        var playerListState = PlayerListFeature.State()
    }
}

We need to define a type for the feature’s tabs. There are the obvious tabbar items, such as teams, favorites and players.

struct RootFeature: Reducer {
    struct State: Equatable {
        var selectedTab = Tab.teams
        var teamListState = TeamListFeature.State()
        var playerListState = PlayerListFeature.State()
    }
    enum Tab {
        case teams
        case favorites
        case players
    }
}

We also need to define a type for the root (grand-parent) feature’s actions. There are the obvious actions, such as tabbar item selected, and the actions that are encapsulate all actions from the child domain/feature of the root (grand-parent) domain/feature, providing a comprehensive and cohesive approach.

struct RootFeature: Reducer {
    struct State: Equatable {
        var selectedTab = Tab.teams
        var teamListState = TeamListFeature.State()
        var playerListState = PlayerListFeature.State()
    }
    enum Tab {
        case teams
        case favorites
        case players
    }
    enum Action: Equatable {
        case tabSelected(Tab)
        case teamList(TeamListFeature.Action)
        case playerList(PlayerListFeature.Action)
    }
}

And then we implement the reduce method which is responsible for handling the actual logic and behavior for the feature. It describes how to change the current state to the next state, and describes what effects need to be executed. Some actions don’t need to execute effects, and they can return .none to represent that:

struct RootFeature: Reducer {
    struct State: Equatable {
        var selectedTab = Tab.teams
        var teamListState = TeamListFeature.State()
        var playerListState = PlayerListFeature.State()
    }
    
    enum Tab {
        case teams
        case favorites
        case players
    }
    
    enum Action: Equatable {
        case tabSelected(Tab)
        case teamList(TeamListFeature.Action)
        case playerList(PlayerListFeature.Action)
    }
    
    // Dependencies
    var fetchTeams: () async throws -> TeamsModel
    var fetchPlayers:  @Sendable () async throws -> PlayersModel
    var uuid: @Sendable () -> UUID
    
    static let live = Self(
        fetchTeams: MatchScoresClient.liveValue.fetchTeams,
        fetchPlayers: MatchScoresClient.liveValue.fetchPlayers,
        uuid: { UUID() }
    )
    
    var body: some Reducer<State, Action> {
        Reduce { state, action in
            switch action {
            case .teamList:
                return .none
            case .playerList:
                return .none
            case .tabSelected(let tab):
                state.selectedTab = tab
                return .none
            }
        }
        Scope(state: \.teamListState, action: /RootFeature.Action.teamList) {
            TeamListFeature(uuid: uuid)
        }
        Scope(state:  \.playerListState, action: /RootFeature.Action.playerList) {
            PlayerListFeature(uuid: uuid)
        }
    }
}

And then finally we define the view that displays the feature. It holds onto a StoreOf<RootFeature> so that it can observe all changes to the state and re-render, and we can send all user actions to the store so that state changes. WithViewStore is a view helper that transforms a Store into a ViewStore so that its state can be observed by a view builder:

struct RootView: View {
    let store: StoreOf<RootFeature>
    
    var body: some View {
        WithViewStore(self.store, observe: { $0 }) { viewStore in
            TabView(
                selection: viewStore.binding(
                    get: \.selectedTab,
                    send: RootFeature.Action.tabSelected
                )
            ) {
                TeamListView(
                    store: self.store.scope(
                        state: \.teamListState,
                        action: RootFeature.Action
                            .teamList
                    )
                )
                .tabItem {
                    Image(systemName: "list.bullet")
                    Text("Teams")
                }
                .tag(RootFeature.Tab.teams)
                
                PlayerListView(
                    store: self.store.scope(
                        state: \.playerListState,
                        action: RootFeature.Action.playerList
                    )
                )
                .tabItem {
                    Image(systemName: "person.fill")
                    Text("Players")
                }
                .tag(RootFeature.Tab.players)
            }
            .accentColor(Color("launch-screen-background"))
        }
    }
}

Once we are ready to display these views, for example in the app’s entry point, we can construct a store. This can be done by specifying the initial state to start the application in, as well as the reducer that will power the application:

import SwiftUI
import ComposableArchitecture

@main
struct MatchScoresTCAApp: App {
    var body: some Scene {
        WindowGroup {
            RootView(
                store: Store(initialState: RootDomain.State()) {
                    RootDomain(fetchTeams: { TeamsModel.sample}, fetchPlayers: { PlayersModel.sample }, uuid: { UUID() }
                    )
                }
            )
        }
    }
}

👱🏻‍♂️👱🏼To implement this parent feature we create a new type that will house the domain and behavior of the feature by conforming to Reducer:

import ComposableArchitecture

struct TeamListFeature: Reducer {
}

In here we need to define a type for the feature’s state, which consists of a data loading status, as well as an TeamsModel that is an Identified collection which are designed to solve all of the collection problems by providing data structures for working with collections (teams and meta) of identifiable elements in an ergonomic, performant way:

struct TeamListFeature: Reducer {
    struct State: Equatable {
        var dataLoadingStatus = DataLoadingStatus.notStarted
        var resultTeamRequestInFlight: TeamsModel?
        var teamList: IdentifiedArrayOf<TeamFeature.State> = []
        
        var shouldShowError: Bool {
            dataLoadingStatus == .error
        }
        
        var isLoading: Bool {
            dataLoadingStatus == .loading
        }   
    }
}

We also need to define a type for the feature’s actions. There are the obvious action, such as view on appear and the action that occurs when we receive a response from the team/player API request, and define a team(id: TeamFeature.State.ID, action: TeamFeature.Action) case to handle actions sent to the child domain (TeamFeature: Reducer):

struct TeamListFeature: Reducer {
    struct State: Equatable {
        var dataLoadingStatus = DataLoadingStatus.notStarted
        var teamList: IdentifiedArrayOf<TeamFeature.State> = []
        var shouldShowError: Bool {
            dataLoadingStatus == .error
        }
        var isLoading: Bool {
            dataLoadingStatus == .loading
        }   
    }
    enum Action: Equatable {
        case fetchTeamResponse(TaskResult<TeamsModel>)
        case team(id: TeamFeature.State.ID, action: TeamFeature.Action)
        case onAppear
    }
}

And then we implement the reduce method which is responsible for handling the actual logic and behavior for the feature. It describes how to change the current state to the next state, and describes what effects need to be executed. Some actions don’t need to execute effects, and they can return .none to represent that:

struct TeamListFeature: Reducer {
  struct State: Equatable { /* ... */ }
  enum Action: Equatable { /* ... */ }

func reduce(into state: inout State, action: Action) -> Effect<Action> {
        switch action {
        case .fetchTeamResponse(.failure(let error)):
            state.dataLoadingStatus = .error
            print(error)
            print("Error getting products, try again later.")
            return .none
            
        case let .fetchTeamResponse(.success(teamData)):
            state.teamList = IdentifiedArrayOf(
                uniqueElements: teamData.data.map {
                    TeamFeature.State(
                        id: uuid(),
                        team: $0
                    )
                }
            )
            state.dataLoadingStatus = .loading
            return .none
            
        case .onAppear:
            return .run { send in
                await send (
                    .fetchTeamResponse(
                        TaskResult { try await MatchScoresClient.liveValue.fetchTeams()
                        }
                    )
                )
            }
        case .team:
            return .none
        }
    }
}

And then finally we define the view that displays the feature. It holds onto a StoreOf<TeamListFeature> so that it can observe all changes to the state and re-render, and we can send all user actions to the store so that state changes. ForEachStore loops over a store’s collection with a store scoped to the domain of each element. This allows us to extract and modularize an element’s view and avoid concerns around collection index math and parent-child store communication:

struct TeamListView: View {
    let store: StoreOf<TeamListFeature>
    
    private let columns = Array(
        repeating: GridItem( .flexible()),
        count: 2
    )
    
    var body: some View {
        WithViewStore(self.store, observe: { $0 }) { viewStore in
            ZStack{
                ScrollView {
                    LazyVGrid(columns: columns,
                              spacing: 16) {
                        ForEachStore(
                            self.store.scope(
                                state: \.teamList,
                                action: TeamListFeature.Action.team(id:action:)
                            )
                        ) {
                            TeamView(store: $0)
                        }
                    }
                              .padding()
                              .accessibilityIdentifier("peopleGrid")
                }
                .refreshable {
                    viewStore.send(.onAppear)
                }
            }
            .navigationTitle("Teams")
            .onAppear {
                viewStore.send(.onAppear)
            }
        }
    }
}

👶🏼👶🏼 To implement this child (grand-child of RootFeature or child of TeamListFeature) feature we create a new type that will house the domain and behavior of the child feature by conforming to Reducer:

struct TeamFeature: Reducer {
    struct State: Equatable, Identifiable {
        let id: UUID
        let team: TeamData
    }
    enum Action: Equatable { }
    
    func reduce(into state: inout State, action: Action) -> Effect<Action> { }
}

And then we define the view that displays the feature. It holds onto a StoreOf<TeamFeature> so that it can observe all changes to the state and re-render, and we can send all user actions to the store so that state changes. WithViewStore is a view helper that transforms a Store into a ViewStore so that its state can be observed by a view builder:

import SwiftUI
import ComposableArchitecture

struct TeamView: View {
    let store: StoreOf<TeamFeature>
    
    var body: some View {
        WithViewStore(self.store, observe: {$0} ) { viewStore in
            VStack(spacing: .zero) {
                
                background
                
                VStack(alignment: .leading) {
                    Text(viewStore.team.fullName)
                        .foregroundColor(Theme.text)
                        .font(
                            .system(.largeTitle, design: .rounded)
                        )
                        .background(
                            Image(avatars[viewStore.team.id - 1])
                                .opacity(0.4)
                                .aspectRatio(contentMode: .fill)
                        )
                }
                .frame(maxWidth: .infinity, alignment: .leading)
                .frame(height: 150.0)
                .padding(.horizontal, 8)
                .padding(.vertical, 5)
                .background(Theme.detailBackground)
                
                VStack {
                    PillView(id: viewStore.team.id)
                        .padding(.leading, 10)
                        .padding(.top, 10)
                }
                
            }
            .clipShape(
                RoundedRectangle(cornerRadius: 16,
                                 style: .continuous)
            )
            .shadow(color: Theme.text.opacity(0.1),
                    radius: 2,
                    x: 0,
                    y: 1)
            .edgesIgnoringSafeArea([.top, .leading, .trailing])
        }
    }
}

Result:

You can find all the codes in here.