Spotlight already knows the walk exists. Siri on iOS 27 is supposed to be able to talk about it now.

Last time, Spotlight could find a favorite route. This time, I’m making Siri able to talk about it, hand it to Maps and open it by voice.

1. Make the entity speak: @Property and Spotlight keywords

Before Siri can refer to a favorite, the entity behind it needs a field Siri is allowed to read aloud. I updated WalkMatePlaceEntity so name is wrapped in @Property. That wrapper publishes a field so Shortcuts can display it and Siri can say it.

struct WalkMatePlaceEntity: IndexedEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Favorite walk"
    static let defaultQuery = WalkMatePlaceEntityQuery()
    static let spotlightIndexName = "WalkMateFavorites"

    let id: UUID
    @Property(title: "Name")
    var name: String?
    var startLatitude: Double
    var startLongitude: Double
}

I also store the route’s starting coordinate directly on the entity that I’ll need it later for the Maps handoff. Note the entity only exports the trailhead not the whole walk.

Spotlight search still works the way Part 1 showed -searching “Berlin” finds a favorite named Berlin- because attributeSet puts the name into Spotlight keywords as well as the title:

var attributeSet: CSSearchableItemAttributeSet {
    let attributes = defaultAttributeSet
    attributes.displayName = name
    attributes.title = name
    if let name {
        attributes.keywords = [name]
    }
    return attributes
}

2. Let Shortcuts search and reindex

EnumerableEntityQuery is unchanged. Spotlight and Shortcuts still resolve a favorite by id through entities(for:) and list everything through allEntities().

Two things are new on top of that:

1-) When a Shortcuts parameter is “pick a saved walk,” suggestedEntities() offers the full list and EntityStringQuery filters it as you type:

func suggestedEntities() async throws -> [WalkMatePlaceEntity] {
    try await allEntities()
}

extension WalkMatePlaceEntityQuery: EntityStringQuery {
    func entities(matching string: String) async throws -> [WalkMatePlaceEntity] {
        try await allEntities().filter { entity in
            entity.name?.localizedStandardContains(string) == true
        }
    }
}

2-) iOS 27 can ask the app to rebuild Spotlight. IndexedEntity describes the shape of what goes in the index but it doesn’t reindex by itself. IndexedEntityQuery is the write Spotlight calls when the index is stale:

@available(iOS 27, *)
extension WalkMatePlaceEntityQuery: IndexedEntityQuery {
    func reindexEntities(
        for identifiers: [WalkMatePlaceEntity.ID],
        indexDescription: CSSearchableIndexDescription
    ) async throws {
        let entities = FavoriteRouteStorage.load()
            .filter { identifiers.contains($0.id) }
            .compactMap(WalkMatePlaceEntity.init)
        try await CSSearchableIndex.default().indexAppEntities(entities)
    }

    func reindexAllEntities(
        indexDescription: CSSearchableIndexDescription
    ) async throws {
        let entities = FavoriteRouteStorage.load().compactMap(WalkMatePlaceEntity.init)
        try await CSSearchableIndex.default().indexAppEntities(entities)
    }
}

Same FavoriteRouteStorage.load(). The system passes a CSSearchableIndexDescription; I write the same default index Part 1 used.

3. Keep Siri’s phrase list in sync:

Part 1’s donateAll() deleted every WalkMatePlaceEntity in Spotlight then indexed whatever SQLite still had. That write is unchanged. What’s new: it also tells App Shortcuts the favorite names changed, so a phrase like “Load Berlin in Walk Mate” stays valid after a rename, add or delete.

static func donateAll() {
    Task { @MainActor in
        WalkMateAppShortcuts.updateAppShortcutParameters()
    }
    Task {
        guard CSSearchableIndex.isIndexingAvailable() else { return }
        let entities = FavoriteRouteStorage.load().compactMap(WalkMatePlaceEntity.init)
        let namedIndex = CSSearchableIndex(name: spotlightIndexName)
        try? await namedIndex.deleteAppEntities(ofType: WalkMatePlaceEntity.self)
        let index = CSSearchableIndex.default()
        try? await index.deleteAppEntities(ofType: WalkMatePlaceEntity.self)
        guard !entities.isEmpty else { return }
        try? await index.indexAppEntities(entities)
    }
}

The App.init function also calls updateAppShortcutParameters() once at launch, so the phrase cache is already warm the first time Siri needs it.

4. Open a favorite by voice

Part 1 had a single OpenWalkMatePlaceIntent: OpenIntent. That is still the iOS 27 open but it now adopts Apple’s .system.open schema Siri AI treats “open this favorite” as the system open action. TargetContentProvidingIntent is the iOS piece that actually brings the scene to that entity.

@available(iOS 27, *)
@AppIntent(schema: .system.open)
struct OpenWalkMatePlaceIntent: OpenIntent, TargetContentProvidingIntent {
    var target: WalkMatePlaceEntity

    @MainActor
    func perform() async throws -> some IntentResult {
        QuickActionRouter.dispatch(.openFavorite(id: target.id))
        return .result()
    }
}

ShowSavedWalkIntent is the custom intent that runs on iOS 18+: same dispatch, same reducer.

struct ShowSavedWalkIntent: AppIntent {
    static let title: LocalizedStringResource = “Show Saved Walk”
    static let openAppWhenRun = true

    @Parameter(title: “Saved walk”)
    var walk: WalkMatePlaceEntity

    @MainActor
    func perform() async throws -> some IntentResult {
        QuickActionRouter.dispatch(.openFavorite(id: walk.id))
        return .result()
    }
}

Both send .openFavorite(id:). Part 1 already queued that id during splash. Tap “Berlin” in Spotlight, Shortcuts, Siri and you still get the same map as tap “Berlin” in Favorite Routes.

5. Give Siri a phrase to say

Writing an AppIntent is not enough for Siri to pick it up as a command. You register it on an AppShortcutsProvider. Every phrase has to interpolate \(.applicationName).

struct WalkMateAppShortcuts: AppShortcutsProvider {
    static var appShortcuts: [AppShortcut] {
        AppShortcut(
            intent: ShowSavedWalkIntent(),
            phrases: [
                “Load \(\.$walk) in \(.applicationName)”
            ],
            shortTitle: “Open Favorite Walk”,
            systemImageName: “figure.walk”
        )
    }
}

\(\.$walk) expands with the donated favorite names. That is why donateAll() and App.init call updateAppShortcutParameters(). After you name a walk “Berlin”, “Load Berlin in Walk Mate” is a real phrase.

(Part 1 already showed “Open Favorite Walk” and “Find Favorite walk” inside the Shortcuts app because the system lists every discoverable intent. The tile and the spoken phrase are new. They come from this provider.)

6. Understand “this walk“ on screen

Siri can mean the row you are looking at if the view is annotated. Each FavoriteRouteCard gets the entity id. iOS 18.4+ appEntityIdentifier.

func walkMateEntityIdentifier(_ id: UUID) -> some View {
    if #available(iOS 18.4, *) {
        appEntityIdentifier(
            EntityIdentifier(for: WalkMatePlaceEntity.self, identifier: id)
        )
    } else {
        self
    }
}

This is separate from exporting data. It just lets someone say “third walk in the favorites list” while the favorites list is open and have Siri know which one that means.

7. Hand the walk’s starting point to Apple Maps

A favorite is a private loop. Apple’s Maps place schema (@AppEntity(schema: .maps.place)) is a POI which contains hours, category etc. I did not adopt .maps.place since it doesn’t fit what Walk Mate provides.

What I exported instead is a PlaceDescriptor for the first coordinate and the name. Shortcuts or Siri can hand that to Maps so you can get to where the walk starts. Maps cannot ingest Walk Mate’s polyline. Extra Maps waypoints would be a different path Maps drew.

@available(iOS 26.4, *)
extension WalkMatePlaceEntity: Transferable {
    static var transferRepresentation: some TransferRepresentation {
        ValueRepresentation(exporting: \.startPlace)
    }
}

@available(iOS 26, *)
extension WalkMatePlaceEntity {
    var startPlace: PlaceDescriptor {
        PlaceDescriptor(
            representations: [
                .coordinate(
                    CLLocationCoordinate2D(
                        latitude: startLatitude,
                        longitude: startLongitude
                    )
                )
            ],
            commonName: nil
        )
    }
}

The @available(iOS 26.4, *) is not about Transferable itself and it is not about iOS 27. ValueRepresentation(IntentValueRepresentation) is the API that exports an AppEntity as a structured system value (PlaceDescriptor) instead of a file. File/data representations cannot carry a coordinate, Maps needs a place value. Apple added that structured export in 26.4.

8. Keep every device in sync: SyncableEntity

Favorites in Walk Mate already sync across devices via CloudKit, using the same UUID (favorite.id) everywhere. iOS27’s SyncableEntity protocol is what tells Siri that fact that this id is stable across a user’s devices, so a conversation about a favorite can move from iPhone to iPad.
Apple SyncableEntity says;

The presence of this protocol tells the system that it can refer to your entity consistently across devices. For example, Siri uses this capability to transfer a conversation from one device to another.

Since WalkMatePlaceEntity.id was already the CloudKit-synced UUID, adopting the protocol is a one-line addition:

@available(iOS 27, *)
extension WalkMatePlaceEntity: SyncableEntity {}

9. Donate the action, not only the entity

Part 1 donated entities to Spotlight. That teaches the system the walk exists. It doesn’t teach the system you open it.

When a favorite is opened from the Favorites UI, I donate that open after it succeeds. On iOS 27 the donated intent is the schema open.

donateFavoriteOpened: { favorite in
    guard let entity = WalkMatePlaceEntity(favorite) else { return }
    if #available(iOS 27, *) {
        var intent = OpenWalkMatePlaceIntent()
        intent.target = entity
        IntentDonationManager.shared.donate(intent: intent)
    } else {
        var intent = ShowSavedWalkIntent()
        intent.walk = entity
        IntentDonationManager.shared.donate(intent: intent)
    }
}

Donate after the action completes. Do not donate on every list render or you’ll flood the system with noise.

Phrases (Siri Voice Commands (Saved Walks & Search))

🗣️ “Generate a route in Walk Mate”, “Generate me a route in Walk Mate”, “Make me a walk in Walk Mate”, “Create a walk in Walk Mate”, “Generate walking routes in Walk Mate”

When the app closed and said these, it opens the app and immediately generates a new route based on the distance.

🗣️ “Load Riverside Loop in Walk Mate”

Siri opens Walk Mate directly to Riverside Loop on the map.

🗣️ “Open Riverside Loop in Walk Mate” or “Open Riverside Loop with Walk Mate”

Siri resolves the entity and opens Riverside Loop on the map.

🗣️ “Search Riverside Loop in Walk Mate”

App opens in the foreground, searches favorites and displays Riverside Loop on the map.

🗣️ “Search Central Park in Walk Mate” (not a favorited route)

App opens gracefully to the Favorites List so I can pick or browse saved routes.

Shortcuts App

Generate Routes (Custom Distance)

1. Open the Shortcuts app.
2. Tap + (New Shortcut) → Add Action.
3. Search for Walk Mate → Select Generate Routes.
4. Set Distance to 5 km.
5. Tap Run.

Walk Mate opens to the foreground and starts generating a route clamped to ~5 km. Also, Walk Mate opens and generates routes using the app's current default target distance without specifying the Distance from Shortcuts app. There is also a caveat for upper-lower bounds for distances like when the user enters a distance value more than 20 kms or lesser 3 kms that distance value safely clamps within the 3-20 km operating range.

When the Open Favorite Route shortcut runs, it asks you to select with which favorite you want to open the app;

If you have multiple walks with similar names (e.g. “Park North” and “Park South”) and you say: “Open Park in Walk Mate”, Siri can’t uniquely match one, so it prompts “Which one?” with the list of matching walks.

What I did not add

Even though Walk Mate has no search bar or a results screen for it,
.system.searchInApp stays and Siri hands Walk Mate a search term. Unique match loads that favorite otherwise the existing Favorites list opens. Since Walk Mate has no start/stop button to start your walking sessions there is no start button for Siri to press. You walk, medals come to you. There is also no option for sending the full loop to Apple Maps.

Sources:

• Walk Mate’s first App Intents

• Get started with App Intents

• Making app entities available in Spotlight

• Apple Intelligence and Siri AI

• Making actions and content discoverable by Apple Intelligence

• AppShortcutsProvider

• Donating your app’s data and actions to the system

• Providing contextual cues to Apple Intelligence and Siri

This post is that first step only: one entity, Spotlight, and the OpenIntent Spotlight needs. No map navigation intents. That same open intent is also visible in the Shortcuts app, so a favorite can be opened from there without more types.

Let’s jump into the code:

To enable matching by meaning and not just text, conform to IndexedEntity protocol.

struct WalkMatePlaceEntity: IndexedEntity {
    static var typeDisplayRepresentation: TypeDisplayRepresentation = "Favorite walk"
    static let defaultQuery = WalkMatePlaceEntityQuery()

    let id: UUID
    var name: String?

    var displayRepresentation: DisplayRepresentation {
        DisplayRepresentation(
            title: "\(name ?? L10n.Spotlight.unnamedFavorite)",
            image: .init(systemName: "figure.walk")
        )
    }
}

Conforming to IndexedEntity allows the app to donate entities using the Spotlight index to get the benefits of semantic understanding. When an entity is donated, Siri can resolve it by name, by property, or by context, without requiring a custom property query.

To keep things moving, I added ways to convert between the data model and the entity.
The WalkMatePlaceEntity’s initializer maps from FavoriteRoute to pull out what the entity needs.

init?(_ favorite: FavoriteRoute) {
    guard !favorite.route.coordinates.isEmpty else { return nil }
    let title = favorite.name.isEmpty
        ? AppSettingsManager.formatDistance(favorite.route.distance)
        : favorite.name
    id = favorite.id
    name = title
}

And the query and Spotlight donate call WalkMatePlaceEntity.init / compactMap(WalkMatePlaceEntity.init).

The Query

When Spotlight asks for a favorite place, the query reads the same favorites the app already persists. FavoriteRouteStorage.load() is that read. No new db.

struct WalkMatePlaceEntityQuery: EnumerableEntityQuery {
    func entities(for identifiers: [WalkMatePlaceEntity.ID]) async throws -> [WalkMatePlaceEntity] {
        FavoriteRouteStorage.load()
            .filter { identifiers.contains($0.id) }
            .compactMap(WalkMatePlaceEntity.init)
    }

    func allEntities() async throws -> [WalkMatePlaceEntity] {
        FavoriteRouteStorage.load().compactMap(WalkMatePlaceEntity.init)
    }
}

Spotlight hits the query. The query calls FavoriteRouteStorage.load(), the same read the favorites UI uses, then maps rows to WalkMatePlaceEntity. That is the shared resource: existing SQLite favorites, not a second store. entities(for identifiers:) fetches favorites by ID and allEntities() method that returns all favorites.

Donating to the index

There’s one more piece which can be easily forgettable. IndexedEntity is the shape that Spotlight and Siri are allowed to index this type. It does not write the index.

donateAll() is the write. saveFavorites replaces every favorite, so I delete all WalkMatePlaceEntity rows in Spotlight, then indexAppEntities with whatever FavoriteRouteStorage.load() still has. Rename, add, or delete a favorite and the index matches SQLite again.

static func donateAll() {
    Task {
        let entities = FavoriteRouteStorage.load().compactMap(WalkMatePlaceEntity.init)
        let index = CSSearchableIndex.default()
        try? await index.deleteAppEntities(ofType: WalkMatePlaceEntity.self)
        guard !entities.isEmpty else { return }
        try? await index.indexAppEntities(entities)
    }
}

And it called in SQLitePersistenceStore after a successful favorite route saving process:

func saveFavorites(_ routes: [FavoriteRoute]) {
    WalkMatePlaceEntity.donateAll()
}

I favorited a route and named it “Berlin” and when I search “Berlin” through iOS spotlight I can see the name and figure.walk system image added in DisplayRepresentation show up.

Opening the favorite walk from Spotlight and Shortcuts app

Apple’s Spotlight article says the next type to add is an OpenIntent. The target is the entity Spotlight already has. When someone taps a donated result, the system is supposed to fill target and run perform().

struct OpenWalkMatePlaceIntent: OpenIntent {
    static let title: LocalizedStringResource = "Open Favorite Walk"
    static let description = IntentDescription("Opens a saved walking route.")

    @Parameter(title: "Saved walk")
    var target: WalkMatePlaceEntity

    @MainActor
    func perform() async throws -> some IntentResult {
        AppIntentRouter.dispatch(.openFavorite(id: target.id))
        return .result()
    }
}

OpenIntent is a system intent. The system brings the app forward. perform() is where the app has to change the UI. Walk Mate’s UI lives in a TCA Store, not inside the intent, so the intent cannot call FavoriteRoutesView directly.

AppIntentRouter is that bridge. App.init creates the root store, then hands the router a send closure. perform() dispatches .openFavorite(id:). If the intent runs before the store exists, the action waits and flushes when send is set.

@MainActor
enum AppIntentRouter {
    static func dispatch(_ action: ContentFeature.Action) {
        if let send {
            send(action)
        } else {
            pending = action
        }
    }
}

.openFavorite is not a new route loader. It looks up the FavoriteRoute by the Spotlight UUID and sends the same favorites(.load(favorite)) the Favorites list already uses. Tap “Berlin” in Spotlight/Shortcuts app and you get the same map states as tap “Berlin” in Favorite Routes.

case let .openFavorite(id):
    state.pendingSpotlightFavoriteID = id
    return applyPendingSpotlightFavorite(to: &state, clearPending: true)

If the tap lands during splash, the id is queued. Apply it after splash, not under the splash view.

The tap that is not perform()

indexAppEntities writes a Core Spotlight item whose unique identifier is the entity id. Tap that row and Handoff continues a user activity of type CSSearchableItemActionType. The favorite UUID is in userInfo under CSSearchableItemActivityIdentifier. See CSSearchableItemActionType.

Walk Mate also uses a custom (UIWindowSceneDelegate) for home-screen quick actions. That delegate never implemented scene(_:continue). The activity arrived. Nobody read the UUID. The app came to the foreground on the home map.

.onContinueUserActivity(CSSearchableItemActionType) { activity in
    if let id = SpotlightFavoriteActivity.favoriteID(from: activity) {
        store.send(.openFavorite(id: id))
    }
}

The same parse runs from application(_:continue) and from scene(_:continue). Cold launch puts the activity on UIScene.ConnectionOptions.userActivities before RootView exists, so that set is read in application(_:n:options).

SpotlightFavoriteActivity pulls a UUID out of the activity: the Spotlight identifier, targetContentIdentifier, or the last path component if the system prefixes the entity type. Both doors send .openFavorite(id:). One reducer. One map.

Sources:

• Get started with App Intents

• Making app entities available in Spotlight

Correction: An earlier draft blamed last-write-wins and argued that custom conflict resolution was required. Point-Free guys corrected the diagnosis: my app was seeding a CloudKit-synced table during startup. Last-edit-wins only resolved the conflict my startup code created.

Uninstalling and reinstalling an iOS app is boring. The local database disappears, the private CloudKit database remains, and the fresh install downloads the user’s data.

In Walk Mate, that path destroyed lifetime stats. 🤯🔫

Rule is simple:

Seeding a CloudKit synced table on launch was wrong in my case. If CloudKit has no stats row, I should create it after the user’s first completed walk.

What disappeared

Walk Mate uses Point-Free’s SQLiteData SyncEngine, built on Apple’s CKSyncEngine. Its lifetime totals live in on synced row whose CloudKit record name is singleton:wm2_user_stats. Achievements are separate records, one wm2_milestones row per milestone.

My Stats before uninstall (the numbers I later confirmed from CloudKit and Game Center):

My Stats before uninstall: 3367 medals, about 95 km, 174 walked routes, longest streak 9, and 19 of 31 achievements.

I uninstalled the app from my iPhone and installed it again. Before doing that, there was an Xcode Simulator running Walk Mate which was also uninstalled and reinstalled the app and trying to fetch the same amount of data with a same iCloud account at the same time. Two fresh installs, two empty local databases, one private CloudKit record. Each launch authenticated with Game Center before CloudKit had hydrated SQLite. My Stats then showed 3367 Total Medals next to zeros for distance, routes, and streaks. Only one achievement appeared unlocked. That mixed screen was not a successful restore. It was a brand-new stats row: medals copied from Game Center, every other aggregate left at its default.

The Simulator finished that seed last. Its local row carried a newer edit time than the historical CloudKit record, and newer than whatever the iPhone had already sent. Under last-edit-wins, iCloud treated that zero-filled row as the most up-to-date data.

Game Center was never a complete backup. It could preserve a leaderboard medal total and some milestone lower bounds. It could not protect distance, route history, medal categories, or exact streak state.

My Stats after reinstall, for a while:

Medals survived because they also live on a Game Center leaderboard. Everything else looked like a new player, reset 🤬.

Then CloudKit caught up with the phone. The good remote record was overwritten with the empty local one:

That last detail was the fingerprint. The Game Center seed writes the leaderboard total into beginnerMedalsCollected and zeros the other categories. CloudKit now looked exactly like that seed, not like a real walked one.

The sequence that caused the loss

The failure was in my app’s architecture and launch order, not in SQLiteData:

1. Reinstalling removed the local SQLite database. CloudKit still held the healthy singleton:wm2_user_stats record.

2. Game Center authenticated before CloudKit had hydrated the empty local db.

3. The Game Center restore path tried to raise the medal total. Because no local stats row existed, the mutation helper materialized the singleton.

4. A db insert writes the whole row. The new row therefore contained 3367 medals plus zero walks, zero distance, and zero streaks.

5. That local row had a newer edit time than the historical CloudKit row. Under last-edit-wins, it won.

6. SyncEngine uploaded the newer row, replacing the healthy server values with the startup defaults.

The seed was intended as a partial store, but there is no partial insert of a nonexistent aggregate row. Creating the singleton turned every untouched field into a real, newly written zero.

Last-edit-wins did what it was designed to do. Custom conflict resolution might have reduced the damage (for example, by taking the maximum of monotonic counters) but it was not necessary to prevent this incident. The sufficient fix was to stop manufacturing synced state during startup.

The sufficient fix

In the cleanest design, an absent local stats row remains absent while CloudKit hydrates. If CloudKit contains the singleton, sync restores it. If CloudKit does not contain it, the app creates the row only when the user completes a real walk.

That means reads may temporarily present in-memory defaults before hydration but the app doesn’t persist those default as CloudKit state.

In practical terms:

• Don’t insert wm2_user_stats from launch setup, authentication, or UI initialization.

• Don’t use a Game Center data as a reason to create that row.

• Ideally, let the first completed walk create the singleton when no cloud record exists.

That architectural rule fixes the root cause without requiring a new merge system.

What the shipped code also does

I kept the production fix deliberately conservative because this row contains a user’s lifetime progress.

The persistence layer now blocks a medal-only insert before the initial CloudKit hydration has finished:

let isInsert = existing == nil
if isInsert, !didFinishInitialCloudHydrate, !row.hasWalkProgress {
    return
}
try saveUserStatsRow(row, db: db)

The reconciliation cycle fetches before it runs Game Center recovery and sends only after both the sync fetch and a direct remote lookup are conclusive:

let fetchOutcome = await fetchWithRetries(syncEngine: syncEngine, reason: reason)
let remoteLookup = await coalesceWalkAggregatesFromCloudKit()

if fetchSucceeded, remoteLookup != .failed {
    store.markInitialCloudHydrateFinished()
}

if store.hasFinishedInitialCloudHydrate {
    await restoreProgressFromGameCenterAchievements()
    await seedTotalMedalsFromGameCenterIfNeeded()
}

if fetchSucceeded, remoteLookup != .failed {
    try await syncEngine.sendChanges()
}

The direct lookup reads singleton:wm2_user_stats, coalesces remote values into SQLite using max-style raises for monotonic totals, and treats an inconclusive lookup as a reason not to send. Game Center recovery also only raises values; it never lowers local progress.

These are useful safeguards against failed fetches, stale local state, and regressions in launch ordering. They should not obscure the simpler lesson: none of them makes startup seeding a sound design.

A separate bug in a safety net

SQLiteData stores synced payload fields in CKRecord.encryptedValues. My first direct CloudKit coalescing code read fields such as record["totalWalks"], so it missed the real values and did nothing.

The corrected parser checks the encrypted payload:

if let encrypted = record.encryptedValues[key] {
    return encrypted
}
return record[key]

CloudKit also does not allow the same key in both regular and encrypted field containers, as discussed in SQLiteData discussion #244.

That parsing mistake broke a safety net. It did not cause the overwrite. Had I never seeded the synced singleton on launch, the safety net would not have been needed to prevent this loss.

Why I kept the singleton

One row per completed walk is a stronger long-term data model. A single bad write cannot replace an entire walking history, totals can be derived from immutable events, and conflicts are isolated to individual walks.

I did not make that migration as part of this repair because the existing app was aggregate-oriented from end-2-end. The stored data, stats UI, widgets, milestone calculations, streak state, and Game Center integration all expected one set of accumulated values. Keeping the singleton was the smallest patch I could ship safely.

That choice has a cost. A per-walk model would provide better failure isolation and let me recompute totals, but adopting it properly requires:

• a schema migration

• rules for deriving current and longest streaks

• a plan for users who only have historical aggregates, not old walk events

• updates across the UI, widgets, milestones, and reconciliation code

• more CloudKit records

The singleton is not the ideal event history. It was the lowest-risk repair for the data model already in production.

Verifying the repair

After the fix, reinstalling hydrated the existing CloudKit record instead of uploading a new zero-filled one. After a later walk, the healthy values were:

• 3,367 medals

• about 95 km walked (95,365 m in CloudKit)

• 174 completed routes

• current streak of 1 day

• longest streak of 9 days

• 19 of 31 achievements

Another uninstall and reinstall restored those values correctly.

Takeaways

1. An empty local database is not permission to create defaults in a synced table. It may simply be waiting for CloudKit.

2. Create synced records from real domain events. For Walk Mate, the first completed walk is a valid reason to create stats; app launch is not.

3. Last-edit-wins was the messenger, not the defect. My newer local row accurately won the conflict my code introduced.

4. A singleton aggregate concentrates risk. Event rows provide better isolation and recoverability, but moving to them is a real data-model migration.

5. Backups need explicit boundaries. Game Center preserved a leaderboard total and some achievement information, not distance, route history, medal categories, or exact streak state.

6. Read the storage layer you actually use. SQLiteData’s CloudKit payload is in encryptedValues; querying another container can silently disable recovery logic.

The durable rule is much less complicated than the recovery code I eventually shipped: when CloudKit owns a table, do not race it with startup seeds.

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 🖖🏼