When I first proposed migrating the cache to DocumentDB (MongoDB-compatible), I estimated it would take a week. In the end, just the initialization alone took two weeks, and the full migration took about three weeks. We hit a lot of unexpected issues along the way. This post documents the approach, the problems, and the outcome.

Background and Goals

We have a Cache Service that syncs relationship and node data from Neo4J into Redis for fast reads of user relationship data. Performance was never the issue — cost was:

• A large portion of the cached data was rarely accessed, resulting in low cache utilization.
• Memory-optimized instances were holding cold data long-term, which is terrible value for money.

The goal of this refactor was to introduce a hot/cold data separation:

• Hot data stays in Redis.
• Infrequently accessed cache moves to AWS DocumentDB.

State of the Code (Before)

Reading the code before starting, I had a bad feeling.

• Many files across apps/ shared the same names.
• The code itself was nearly identical across them.
• ElasticSearch logic was mixed in with cache initialization code.
• Incremental cache update logic was scattered across multiple apps.
• Lots of lint errors, lots of commented-out code blocks.

All classic red flags — any change risked a cascade of side effects, making estimation impossible. Before touching the migration, I did two things first:

1. Fixed all related lint issues and deleted dead code.
2. Read the entire call chain end-to-end, then cross-checked it against Codex’s analysis.

Migration Strategy

The approach was low-risk: dual-write first, then shift reads, then shrink Redis.

1. Dual-write phase: writes go to both Redis and DocumentDB simultaneously.
2. Validation phase: monitor consistency and production behavior.
3. Convergence phase: remove unnecessary cold-data writes from Redis.

Challenge 1: Query and Write Pressure

Indexing

This is a common problem when writing large volumes of data — usually adding an index is enough. However, DocumentDB has poor support for indexing arrays of embedded documents: $in queries on such fields do not use indexes. For example:

{  ...  identities: {    platform: x,    id: 1234,  }}

The following query will not hit an index:

db.relation.find({    identities: {        $in: [            {                platform: "x",                id: 1234,            },        ],    },});

To work around this, we manually concatenated the identity fields and stored them as a flat string x_1234. This allows the query to hit the index:

db.relation.find({    identities: {        $in: ["x_1234"],    },});

Database I/O

The original code was fetching 10,000 records at a time. I had already reduced this to 1,000, but DocumentDB Insights was still flagging many queries with I/O warnings. The batch size had to be reduced further to 100 records per query or update.

Challenge 2: Controlling Runtime Memory

The original concurrency was set to 100 with a taskGroup size of 1,000, which meant the EC2 instance had to load 100 × 1,000 records into memory simultaneously — enough to OOM the instance. I went down several dead ends trying to fix this: deduplicating documents in memory, splitting requests into batches of 100. In the end, setting concurrency to 1 and groupSize to 100 solved it completely, making all those earlier optimizations unnecessary — so I deleted that code.

Challenge 3: Full Cache Initialization Was Too Slow

We had long avoided doing a full cache rebuild for exactly this reason: it’s slow. This refactor made it unavoidable, and we needed it to finish fast. Investigating the root cause revealed the main bottleneck: every time a record was written to Redis, it triggered a synchronous HTTP request to update ElasticSearch data and indexes.

The fix was to decouple ES from the write path entirely. All ES operations were pushed onto an asynq queue, and a dedicated ES-Init Worker was started to process those updates asynchronously.

AWS OpenSearch Default Request Body Limit: 1 MB

To improve throughput, we batched tasks and submitted data for 1,000 nodes in a single request. This quickly produced a wave of errors. Checking the logs revealed the request body was exceeding the size limit. We extracted the ES code into a shared package at pkg/es and updated the document assembly logic to ensure each request stays under 1 MB.

Concurrent ES Update Conflicts

After fixing the request size, things worked locally but still errored in production. The errors turned out to be document version conflicts — the same document was being updated concurrently more than once. Without proper deduplication in place, the only option was to run single-threaded for now. If we want to improve throughput later, we’ll need to deduplicate before dispatching requests — currently the dispatch layer is already working with raw bytes, which makes this tricky. Left as a known issue for future optimization. The priority for now was getting the new cache live.

Results

The refactor delivered three concrete wins:

1. Redis instance downgraded from cache.r7g.4xlarge to cache.r7g.2xlarge, cutting roughly 60 GB of memory usage and reducing instance cost by about half — saving approximately $1,000/month.
2. Cache utilization improved: DocumentDB now handles infrequently accessed data, Redis is focused on hot data, and the overall cost-efficiency is much better.
3. Full cache initialization time cut from ~8 hours to ~4 hours.

Closing Thoughts

Hold your code to a standard. Don’t copy-paste. Delete dead code instead of commenting it out. Keep things decoupled.

Most importantly: read the code fully before estimating the work. Otherwise, be prepared to work late every night for a week.

Recently, I started building a video player that uses CoreText to render subtitles. However, when scrolling through the UI, the frame rate dropped to an unacceptable 15 FPS. To fix this, I created a demo that wraps a native text view with CoreText rendering, eventually optimizing the performance to a smooth 60 FPS.

Main Reasons for the FPS Drop

I found two main culprits for the performance drop:

1. intrinsicContentSize was being called too many times.
2. CTFrameDraw was being called too many times.

Optimizing intrinsicContentSize

intrinsicContentSize determines the natural size of a view. A ScrollView needs to fetch this size for all of its child views in order to calculate the layout. Under the hood, this property uses CTFramesetterCreateWithAttributedString and CTFramesetterSuggestFrameSizeWithConstraints to calculate the dimensions based on the text and font size.

A simple optimization here is to cache the calculated size, using the font size and text content as the cache key. This prevents redundant, expensive calculations.

Drawing in the Correct Order

In my original code, I was mistakenly calling CTFrameDraw twice—a classic AI-generated mistake! :D

// Code before the fix:// ❌ Drawing in the wrong orderoverride func draw(_ dirtyRect: NSRect) {    let context = NSGraphicsContext.current!.cgContext    // Mistake 1: Drawing the text first    CTFrameDraw(frame, context)    if let selectionRange = self.selectionRange {        let rects = getSelectionRects(from: frame, range: selectionRange)        // Draw the background selection        context.setFillColor(NSColor.selectedTextBackgroundColor.cgColor)        context.fill(rects)        // Mistake 2: The background just hid the text, so we have to draw it again!    CTFrameDraw(frame, context)

Another way to prevent views from being unnecessarily recreated is to assign unique identifiers to your text views using a combination of their text, font size, and color.

Why is Scrolling Up Slower Than Scrolling Down?

While investigating these performance issues, I noticed something interesting: scrolling downwards was smooth and stable, but scrolling upwards (from bottom to top) caused severe FPS drops.

Why does this happen? As mentioned earlier, a ScrollView needs to calculate the layout of its child views. When scrolling up, the system has to calculate the positions of the views above the current viewport. To do this, it needs to figure out the heights of all those preceding views, which repeatedly triggers CTFramesetterSuggestFrameSizeWithConstraints—a highly CPU-intensive operation. This is exactly why caching text sizes, as discussed earlier, is so crucial for performance.

Core Code

override func draw(_ dirtyRect: NSRect) {    NSColor.textBackgroundColor.setFill()    bounds.fill()    guard !text.isEmpty else { return }    let insetRect = bounds.insetBy(dx: 12, dy: 12)    guard insetRect.width > 1, insetRect.height > 1 else { return }    let frame = frameForCurrentContent(in: insetRect)    guard let context = NSGraphicsContext.current?.cgContext else { return }    context.saveGState()    context.textMatrix = .identity    CTFrameDraw(frame, context)    drawSelection(in: frame, context: context, pathRect: insetRect)    drawComments(in: frame, context: context, pathRect: insetRect)    context.restoreGState()}override var intrinsicContentSize: NSSize {    let contentWidth = max(120, (bounds.width > 1 ? bounds.width : 760) - 24)    let height = suggestedTextHeight(for: contentWidth)    return NSSize(width: NSView.noIntrinsicMetric, height: max(84, height + 24))}private func suggestedTextHeight(for width: CGFloat) -> CGFloat {    guard !text.isEmpty else { return 0 }    let key = LayoutCacheKey(        styleKey: styleKeyForCurrentContent(),        contentWidth: width,        markupVersion: markupVersion    )    if let cachedHeightKey,       cachedHeightKey == key,       let cachedSuggestedHeight {        return cachedSuggestedHeight    }    let attributed = buildAttributedString()    let framesetter = CTFramesetterCreateWithAttributedString(attributed)    let target = CGSize(width: width, height: .greatestFiniteMagnitude)    let size = CTFramesetterSuggestFrameSizeWithConstraints(        framesetter,        CFRange(location: 0, length: attributed.length),        nil,        target,        nil    )    let measured = ceil(size.height)    cachedHeightKey = key    cachedSuggestedHeight = measured    return measured}private func makeFrame(for string: NSAttributedString, in rect: CGRect) -> CTFrame {    let framesetter = CTFramesetterCreateWithAttributedString(string)    let path = CGPath(rect: rect, transform: nil)    return CTFramesetterCreateFrame(framesetter, CFRange(location: 0, length: string.length), path, nil)}private func frameForCurrentContent(in rect: CGRect) -> CTFrame {    let styleKey = styleKeyForCurrentContent()    let key = LayoutCacheKey(        styleKey: styleKey,        contentWidth: rect.width,        markupVersion: markupVersion    )    if let cachedFrameKey,       cachedFrameKey == key,       let cachedFrame {        return cachedFrame    }    let attributed = buildAttributedString()    let frame = makeFrame(for: attributed, in: rect)    cachedFrameKey = key    cachedFrame = frame    return frame}

Background

I remember when I first graduated and started iOS game development, I used NSThread directly for multithreading. When GCD (Grand Central Dispatch) was introduced, it was very convenient to use, and I used it almost exclusively. occasionally, when tasks had dependencies, I would use NSOperation.

When using multithreading, having too few locks can easily lead to program crashes due to concurrent access to shared data in multiple places; having too many locks can easily cause deadlocks. In short, it was quite a headache. When developing apps, there were a few crashes that were never resolved, and these bugs were very difficult to troubleshoot.

So Swift introduced the concept of Structured Concurrency, whose concurrency threading model ensures no deadlocks. At the same time, the introduction of Actor maximizes data safety. Why maximize? Because Actors have reentrancy issues for performance reasons, and there can also be issues with competitive access to the same data.

GCD (Grand Central Dispatch)

GCD mainly consists of queues and task closures. Queues are divided into:

• Serial Queue: Executes tasks sequentially
• Concurrent Queue: Executes tasks in parallel

You will notice there is no concept of threads here. In fact, concurrent queues and threads have a many-to-many relationship:

• A queue can distribute tasks to multiple threads
• A thread can also process tasks distributed by multiple concurrent queues

GCD encapsulation hides the details of threads. There are some special queues, such as:

• main serial queue
• global QoS concurrent queue

You can also define custom queues if necessary.

Common GCD Issues

Synchronously calling tasks in a Serial Queue can cause program deadlocks. You need to be careful when using locks to solve data access issues to avoid crashes and deadlocks.

Although GCD blocks can set priorities, if there is a low-priority task in a Serial queue, and then a high-priority task is added. In this case, since the low-priority task occupies less CPU time, the high-priority task needs to wait for it to complete. Here GCD will perform Priority Inversion, adjusting all previous low-priority tasks to be the same as itself. This approach is far less elegant than the structured concurrency model.

GCD code can easily lead to Callback Hell.

GCD Group Usage Notes

group.enter() / group.leave() must appear in pairs:

let group = DispatchGroup()let queue = DispatchQueue.global()// --- Task A ---group.enter() // 1. Enter groupqueue.async {    print("Start requesting data A...")    sleep(2) // Simulate network delay    print("Data A request completed")    group.leave() // 2. Leave group}// --- Task B ---group.enter()queue.async {    print("Start requesting data B...")    sleep(3)    print("Data B request completed")    group.leave()}// --- Summary Notification ---// Note: This will not block the current thread, it is an asynchronous callbackgroup.notify(queue: .main) {    print("🎉 All requests completed! Refresh UI")}print("I am the main thread, I will not be blocked")

NSOperation

NSOperation is an encapsulation based on GCD. A natural question is: Why do we need NSOperation when we have GCD?

Advantages of NSOperation

Task organization is less error-prone compared to GCD, and dependencies can be set:

let queue = OperationQueue()// 1. Create specific taskslet opA = BlockOperation {    print("Task A: Download image")    sleep(2)}let opB = BlockOperation {    print("Task B: Download video")    sleep(3)}let opC = BlockOperation {    print("Task C: Synthesize and upload to server")}// 2. Set dependencies: C depends on A and B completingopC.addDependency(opA)opC.addDependency(opB)// 3. Add to queuequeue.addOperations([opA, opB, opC], waitUntilFinished: false)print("Tasks submitted, main thread continues running")

Structured Concurrency

From GCD to NSOperation, there has been an improvement in usage safety, but common concurrency programming issues—data race access and deadlocks—have not been resolved. Additionally, whether using Blocks or Delegates, it is easy to end up with Callback Hell and spaghetti code.

These have all been resolved with the introduction of async/await in Swift.

What is Structured?

When learning C, many books suggest not using goto syntax because such code is hard to debug and maintain. This means a piece of code has multiple entries and multiple exits, which is spaghetti code. Besides goto, closures and delegates also lead to a poor code experience.

Using async/await can reduce cognitive load, making code easier to maintain.

Example of Callback Hell

func loadUserProfileOldSchool() {    print("1. Start login...")    // Level 1: Login    login(username: "user", password: "123") { [weak self] result in        guard let self = self else { return }        switch result {        case .success(let token):            print("2. Login success, Token: \(token)")            // Level 2: Get ID (Code starts indenting to the right)            self.fetchUserID(token: token) { [weak self] result in                guard let self = self else { return }                switch result {                case .success(let userID):                    print("3. Got ID: \(userID)")                    // Level 3: Get details (Continues indenting right...)                    self.fetchProfile(userID: userID) { [weak self] result in                        switch result {                        case .success(let profile):                            // Finally got the result!                            self?.updateUI(with: profile)                        case .failure(let error):                            self?.showError(error)                        }                    }                case .failure(let error):                    // Error handling scattered in each layer                    self.showError(error)                }            }        case .failure(let error):            self.showError(error)        }    }}

Example of async/await

You will find the code is shorter, and most importantly, the code executes from top to bottom, making it readable and easy to maintain:

func loadUserProfileModern() async {    print("1. Start login...")    do {        // Code executes sequentially like synchronous code        let token = try await login(username: "user", password: "123")        print("2. Login success, Token: \(token)")        let userID = try await fetchUserID(token: token)        print("3. Got ID: \(userID)")        let profile = try await fetchProfile(userID: userID)        // Update UI        await MainActor.run {            updateUI(with: profile)        }    } catch {        // Error handling concentrated in one place!        await MainActor.run {            showError(error)        }    }}// How to callTask {    await loadUserProfileModern()}

Concurrency Threading Model

When talking about synchronous functions, we think of threads, but when talking about asynchronous functions, we use Tasks. Asynchronous functions run within Tasks.

Swift concurrency introduces a new scheduling method called Cooperative Thread Pool, where a serial queue schedules work, abstracting the remaining execution content in a function as a continuation, and then scheduling it. The actual work is handled by a global concurrent queue, which is assigned to threads for execution.

This new scheduling method ensures the program will not deadlock and also solves the previous Priority Inversion problem.

When a scheduling thread is idle (e.g., after await), the executor finds the next instruction for it to execute. Unlike traditional preemptive GCD scheduling, this scheduling method uses executors, pending work, and scheduling queues to jointly ensure thread execution instructions.

After Task {}, the task is submitted to the Default Executor, then assigned to an idle thread in the thread pool for execution. Upon encountering await, the current task is suspended (context saved to heap, packaged into a Continuation), and other tasks continue execution.

This is the underlying reason why Swift Concurrency reduces “cognitive load”: You no longer need to worry about “creating too many threads will freeze the App” or “deadlocks”. Because the number of threads is always equal to the number of CPU cores, when waiting, everyone yields to each other, rather than hiring temporary workers without limit like GCD.

Common Issues

• Do not block threads: Although the executor schedules tasks, if all threads are blocked, the program will freeze.
• Try not to use locks: Even if you must use them, use lock/unlock on the same side of an await, otherwise it is easy to cause thread blocking.
• DispatchSemaphore or NSCondition: Semaphores represented by these will unconditionally block the current thread when waiting, so use them with caution.

Common Executors

• Global Concurrent Executor
• RunLoop Executor
• Schedulable Executor
• Serial Executor
• Task Executor

let executor = CustomTaskExecutor(label: "com.example.custom")await withTaskExecutorPreference(executor) {    await performWork()}

Actor Model

To avoid data races, the Actor model was introduced. Actor is a reference type. Each Actor has an Executor to be responsible for external access calls to it.

Global Actor

Mainly MainActor. All code marked with @MainActor belongs to MainActor.

Sendable

Sendable is a marker used to tell the compiler that they can be passed across different concurrency domains.

• Actor is also Sendable
• Basic value types are Sendable
• If a struct only contains basic value types, then it is also Sendable
• If it is a class, all members must be constants, or marked with @unchecked Sendable

Additionally, the sending keyword can transfer ownership and ensure subsequent inability to use. This can also avoid data race analysis for safe passing.

Summary

Swift Concurrency provides a safer and more maintainable concurrency programming solution for iOS/macOS development through structured concurrency, the Actor model, and cooperative thread pools. Although the learning curve is steeper, in the long run, it can significantly reduce hard-to-troubleshoot concurrency bugs and improve code quality.

1. init
2. loadView
3. viewDidLoad
4. loadViewIfNeeded
5. viewWillAppear
6. viewWillLayoutSubviews
7. viewDidLayoutSubviews
8. viewDidAppear

9. viewWillDisappear
10. viewDidDisappear
11. deinit

I hadn’t noticed loadViewIfNeeded before. Usually I just access vc.view to force the view to load. loadViewIfNeeded is definitely clearer and more explicit—it avoids accidental side-effects when you only want to load the view conditionally.

viewWillLayoutSubviews

Use viewWillLayoutSubviews() when you want to update constraints. Examples:

• Activate/deactivate constraints depending on size class / orientation
• Update constraint constants

viewDidLayoutSubviews

Use viewDidLayoutSubviews() when you need the final frames (they are already computed at this point). Examples:

• Setting cornerRadius = view.bounds.height / 2
• Updating CAShapeLayer.path
• Adjusting contentInset based on final sizes
• Doing “scroll-to-visible” once frames are valid

Note: viewDidDisappear() might not be called if a dismissal is cancelled. For example, if you interactively pull down a modal sheet but then release it to cancel the dismissal, the view never actually disappears. These appear/disappear methods can be called multiple times during such interactions.

Rotate the screen

Sequence:

• viewWillTransition(to:with:)
• viewWillLayoutSubviews (source VC)
• viewDidLayoutSubviews (source VC)
• viewWillLayoutSubviews (target VC)
• viewDidLayoutSubviews (target VC)

What’s the difference between a struct and a class?

Struct

• Value type (allocated on stack)
• Thread safe (usually)
• Cannot inherit (but can adopt protocols)
• Default choice
• The Swift standard library uses structs for frequent types: numbers, strings, arrays, and dictionaries.
• Compiler optimization: Copy-on-Write

Class

• Reference type (allocated on heap)
• Not thread safe
• Can inherit; can adopt protocols

How to choose?

• Struct by default: Easier for compiler optimization and thread safety.
• Class if you need interoperability with Objective-C APIs.
• Class if you need to share mutable state.
• Class if you need identity (===).

What’s protocol oriented programming?

Common protocols: Hashable, Decodable, Encodable, Identifiable.

• Define behavior as protocols
• Provide shared implementations via protocol extensions
• Compose types from multiple protocols

Why?

• Better reuse than deep inheritance
• More modular and testable

Concurrency in Swift

Grand Central Dispatch (GCD)

Queue types:

• Serial Queue
• Concurrent Queue

(Another term is “Task” or “Block” for the actual logic code)

DispatchGroup: Manually call enter() and leave() if executing an async task inside the closure.

let group = DispatchGroup()let queue = DispatchQueue.global()queue.async(group: group) {    // task A}queue.async(group: group) {    // task B}group.notify(queue: .main) {    print("done")}let result = group.wait(timeout: .now() + 3)print(result == .success ? "ok" : "timeout")

Delay API:

DispatchQueue.main.asyncAfter(deadline: .now() + 1) {    print("1s later")}

Note: wait() will block the current thread.

Cancel an async task:

var workItem: DispatchWorkItem?func schedule() {    workItem?.cancel()  // Cancel the previous one    let item = DispatchWorkItem {        print("run")    }    workItem = item    DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, execute: item)}

Create a queue:

let concurrentQueue = DispatchQueue(label: "com.yourapp.concurrent", attributes: .concurrent)

NSOperation

Built on top of GCD, but object-oriented.

• Operation: An abstract class. Use BlockOperation or subclass it.
• OperationQueue: Executes operations.

Why use it over GCD?

• Dependencies: op2.addDependency(op1) (Run op2 after op1).
• Cancelable: You can cancel operations (need to check isCancelled inside the operation).
• Control: maxConcurrentOperationCount = 1 makes it a serial queue.

let queue = OperationQueue()let op1 = BlockOperation { print("Task 1") }let op2 = BlockOperation { print("Task 2") }op2.addDependency(op1)queue.addOperations([op1, op2], waitUntilFinished: false)

Swift Concurrency

Introduced in Swift 5.5. Replaces closure callback hell.

• async/await: Linear code flow for async operations.
• Task: The bridge between sync and async worlds. Task { await ... }
• async let: Run tasks in parallel (Structured Concurrency).

// Parallel executionasync let image1 = fetchImage(1)async let image2 = fetchImage(2)let (img1, img2) = await (image1, image2)

• TaskGroup: Dynamic parallelism (e.g., fetch a list of IDs).

await withTaskGroup(of: Data.self) { group in    for id in ids {        group.addTask { await fetch(id) }    }}

of: Data.self acts as a strict contract:

• Constraint: All child tasks added via group.addTask must return Data.
• Type Safety: If you try to add a task returning Int, the compiler stops you.
• Usage: When you collect results (for await result in group), Swift knows result is Data.

Actors & Isolation

Actor

• Reference type (like class) but thread-safe.
• Protects mutable state. Only one task accesses the mutable state at a time.
• Internal properties are isolated. External access requires await.

actor Counter {    var value = 0    func increment() { value += 1 }}// Outside: await counter.increment()

MainActor

• A global actor for UI.
• @MainActor ensures code runs on the main thread.

Model-View-Controller

weak open var dataSource: UITableViewDataSource?weak open var delegate: UITableViewDelegate?

Lazy

lazy var v: View = {...}()let x = numbers.lazy.map { $0 * 2 } // x is not [Int]

lazy means creation happens only when needed.

TL;DR

You can view the full GitHub Workflows file here.

Recently, I’ve been developing ABPlayer, a macOS app that allows users to import audio, supports transcription generation, and enables simultaneous listening and watching. I have configured GitHub Actions into what I consider the optimal setup for a one-person development team.

I use Tuist to generate the macOS project. I chose Tuist because native Xcode project files (.xcodeproj) often suffer from poor readability and prone to conflicts, even in solo projects (and especially in collaboration). With this setup, the CI system only needs to read and process Tuist’s Project.swift file.

The workflow is built on two core principles:

1. Feature Development: Develop features on new branches. Every time a PR is submitted, tests run automatically. Once passed, the code is ready to be automatically merged.

2. Automated Releases: After merging to the main branch, if the app version is higher than the latest version in GitHub Releases, the system automatically builds and publishes it to GitHub Releases.

Job: Tests

Whenever a new PR is created, the CI automatically builds the project and runs tests. The main steps are:

1. Checkout code

2. Setup Xcode

3. Setup Swift (Version 6.2)

4. Install mise (for installing Tuist)

5. Install Tuist

6. Run tests

I use xcodebuild to execute the tests:

- name: Run Tests  run: |    xcodebuild test \      -workspace ABPlayer.xcworkspace \      -scheme ABPlayer \      -destination 'platform=macOS' \      -enableCodeCoverage YES \      -derivedDataPath DerivedData

Job: Build-and-Release

While this job shares similarities with the test job, there are several key differences:

• Comparing the build version against the latest GitHub Release.

• Building the Artifact and packaging the App.zip.

• Publishing the latest version to GitHub Releases.

• Uploading dSYM files to Sentry.

Note on Permissions: By default, the GITHUB_TOKEN only has read-only access. Publishing an app to Releases requires write permissions. You must explicitly verify contents: write in your YAML file to authorize the CI to publish the release.

permissions:  contents: write

Version Comparison

The version comparison is primarily implemented via a Shell script.

First, it uses the GitHub API to fetch the latest version tag from Releases. Then, it uses a script to read the version configured in the Project.swift file. The comparison result is stored in $GITHUB_OUTPUT, allowing subsequent steps to read the steps.compare_versions.outputs.should_release variable directly.

- name: Get Current Version  id: get_version  run: |    VERSION=$(grep '"CFBundleShortVersionString":' Project.swift | sed -E 's/.*"CFBundleShortVersionString": "([^"]+)".*/\1/')    echo "version=$VERSION" >> $GITHUB_OUTPUT    echo "Current Version: $VERSION"- name: Get Latest Release Version  id: get_latest_release  env:    GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}  run: |    LATEST_TAG=$(gh release view --json tagName --jq .tagName 2>/dev/null || echo "0.0.0")    echo "latest_tag=$LATEST_TAG" >> $GITHUB_OUTPUT    echo "Latest Release Tag: $LATEST_TAG"- name: Compare Versions  id: compare_versions  run: |    CURRENT="${{ steps.get_version.outputs.version }}"    LATEST="${{ steps.get_latest_release.outputs.latest_tag }}"        # Remove 'v' prefix if exists for comparison    CURRENT_CLEAN=$(echo $CURRENT | sed 's/^v//')    LATEST_CLEAN=$(echo $LATEST | sed 's/^v//')        if [ "$CURRENT_CLEAN" = "$LATEST_CLEAN" ]; then      echo "Versions are the same. Skipping release."      echo "should_release=false" >> $GITHUB_OUTPUT    else      HIGHER=$(printf "$CURRENT_CLEAN\n$LATEST_CLEAN" | sort -V | tail -n1)      if [ "$HIGHER" = "$CURRENT_CLEAN" ] && [ "$CURRENT_CLEAN" != "$LATEST_CLEAN" ]; then        echo "Current version $CURRENT is higher than latest $LATEST. Proceeding with release."        echo "should_release=true" >> $GITHUB_OUTPUT      else        echo "Current version $CURRENT is NOT higher than latest $LATEST. Skipping release."        echo "should_release=false" >> $GITHUB_OUTPUT      fi    fi

Other Essential Configurations

Humans are prone to laziness, but machines are not. Therefore, I enforce a rule that code must pass tests before it can be merged into main. This is absolutely necessary.

By configuring Branch Protection Rules, you can enforce this requirement. For the main branch, you need to check Require status checks to pass. In addition to this, I have configured the following:

• Restrict deletions

• Require a pull request before merging

• Require status checks to pass

• Block force pushes

Future Ideas

I plan to automate the changelog generation by reading the current version’s changes—including bug fixes and new requirements—from a CHANGELOG file and writing these updates directly into the GitHub Releases.

If your team is hiring for iOS / Swift / SwiftUI roles (Calgary or remote), I’d love to connect.

A minimalist abstract graphic design of a sunrise breaking through darkness. The composition is a full square, edge-to-edge design with no borders and no rounded corners. The bottom section is deep midnight black representing the night. A warm, glowing amber and golden apricot light rises softly from the horizon line, diffusing into the darkness. Atmospheric lighting, subtle grain texture, smooth gradients, modern aesthetic. High definition, 8k resolution, flat surface. --ar 1:1

This is the App icon generated using the prompt above.

How to Generate the Prompt Above

Use the prompt below to create the actual prompt for the App Icon. I used Chinese for this example, but feel free to translate it into English and tweak it to fit your needs. I’m just sharing the general workflow here.

需要生成一个iOS app 的icon, 辅助我写prompt. 你是一个位资深的app设计师. 对于绘制app icon非常精通, 能用流程化的方式, 绘制出简洁又有深意的App icon

I sent this to Gemini 3 Pro and got the following response:

你好。很高兴能以资深设计师的身份协助你。设计一枚优秀的 iOS App Icon，绝不仅仅是画一个好看的图形。它是在方寸之间，用最极简的视觉语言，浓缩产品的核心价值和灵魂。它必须在拥挤的手机主屏幕上瞬间抓住用户的眼球，并传达出“我是干什么的”。作为一名深耕 iOS 设计规范多年的设计师，我有一套成熟的“结构化设计流程”。我们将分四个阶段来完成这个任务。请跟随我的引导，一步步提供必要的信息，最后我会为你合成一条高质量的 AI 绘图 Prompt。我们的设计流程：核心定义 (Discovery): 理解 App 的灵魂。隐喻与符号 (Metaphor): 寻找视觉载体。风格与美学 (Aesthetics): 确定视觉语言。Prompt 合成 (Synthesis): 生成最终指令。阶段一：核心定义 (Discovery)一枚好的图标始于对产品的深刻理解。请尽可能精炼地回答以下问题：App 的核心功能是什么？ (请用一句话概括，例如：“一个帮助用户管理植物浇水周期的工具” 或 “一个专注于极简主义的番茄工作法时钟”。)App 的目标用户和情绪基调 (Vibe) 是怎样的？ (例如：专业的/金融的；活泼的/游戏化的；宁静的/冥想的；高效的/工具类的。)App 的名称是什么？ (有时名称本身就包含视觉线索，比如 "Spotify" 或 "Airbnb"。如果没有也没关系，切记 iOS 图标中尽量不要出现文字。)👉 请在此处回复阶段一的答案。(等待你的回复后，我会引导你进入下一阶段。为了演示，我先假设一个案例，展示整个流程是如何运作的)【演示案例：假设你要做一个名为 "FlowWrite" 的极简写作 App】假设你给我的回复是：核心功能：一个让用户专注于写作，排除一切干扰的极简文本编辑器。基调：宁静的、富有创造力的、极其干净和现代的。名称：FlowWrite。阶段二：隐喻与符号 (Metaphor)（根据你的回复，我会分析并提出建议。以下是基于演示案例的分析）设计师分析： 对于“专注写作”和“心流 (Flow)”，我们不能只画一支笔或一张纸，那样太直白且无聊。我们需要寻找更深层次的隐喻。概念 A (侧重“心流”)： 水流、波纹。代表思绪的顺畅无阻。概念 B (侧重“专注与极简”)： 一个极其干净的几何形状，比如一个完美的圆点，或者一条抽象的线段。代表聚焦。概念 C (侧重“创造力”)： 抽象的羽毛笔尖，或者墨水晕开的瞬间。我的建议方向： 结合“笔尖”与“心流”。一个抽象化的、流畅的线条组成的笔尖形状，看起来像是在流动。👉 在实际流程中，这一步我会给你提供 2-3 个创意方向供你选择，或者让你提供你脑海中浮现的第一个物体。阶段三：风格与美学 (Aesthetics)（以下是基于演示案例的分析）设计师分析： iOS 的设计趋势目前主要有几种：现代拟物 (Modern Skeuomorphism / Depth): 有微妙的渐变、柔和的阴影和层次感，看起来想触摸它。（Apple 原生应用多为此类，如相册、Safari）。超级扁平 (Super Flat): 没有任何质感和阴影，纯色块。（现在比较少见，容易显得廉价）。3D 渲染 (3D Render): 看起来像一个可爱的 3D 玩具模型，材质感很强。（常用于游戏或年轻化的应用）。对于 FlowWrite，我建议采用 “现代拟物 (Modern Depth)” 风格。它既保持了极简，又通过微妙的质感显得高级。颜色： 既然是宁静的，我建议使用冷色调。例如：深海蓝渐变到青色，或者一个非常干净的米白色背景配上深灰色的主体。👉 在实际流程中，你需要告诉我你偏好的风格类型和核心配色方案。阶段四：Prompt 合成 (Synthesis)（现在，我将把以上所有信息，转化为 AI 能听懂的专业术语。这是最关键的一步。）基于演示案例 "FlowWrite" 的最终 Prompt：Markdown**Prompt:**An iOS app icon for "FlowWrite", a minimalist writing tool. The design features an abstract, fluid line forming a stylized fountain pen nib, suggesting creative flow and focus. The style is modern Apple aesthetic, with subtle depth, soft gradients, and a tactile feel, not flat. The color palette uses deep ocean blues transitioning to soft teal, set against a clean, off-white background. The composition is centered and balanced within a squircle shape. High quality render, 4k, detailed texture, minimalist design. --ar 1:1Prompt 解析（设计师的秘密配方）：主体明确: "An iOS app icon for..." 开门见山定性。核心隐喻: "abstract, fluid line forming a stylized fountain pen nib" 描述了我们确定的符号。风格界定: "modern Apple aesthetic, with subtle depth, soft gradients... not flat" 这是为了防止 AI 生成过时的扁平化图标。颜色指定: "deep ocean blues transitioning to soft teal" 精确控制色彩氛围。构图与容器: "centered... within a squircle shape" 强调了 iOS 图标的物理形态。质量增强词: "High quality render, 4k, detailed texture" 保证输出的精细度。现在，轮到你了。请回到 “阶段一：核心定义”，回答那三个问题，我们开始创造属于你的 App Icon。

From there, just answer the questions one by one. Eventually, you will get the final prompt to use for image generation. If the image doesn’t turn out quite right, just keep the conversation going to refine it and get a new prompt.

Hope everyone gets an image they’re happy with!

    var body: some View {        VStack(spacing: 24) {            search            Spacer()        }//        .padding() // #1        .background(ThoughtStreamAsset.Colors.bgPrimary.swiftUIColor)    }        var search: some View {        TextField("Search", text: $searchText, prompt: Text("Search your knowledge base").foregroundColor(.gray))            .foregroundColor(ThoughtStreamAsset.Colors.textPrimary.swiftUIColor)            .padding()            .background(Color.red)    }

When the padding at #1 is not commented out, the layout renders as expected:

But when you remove the parent padding, SwiftUI changes how the backgroud is applied, causing the red search background to expand and cover areas you wouldn’t expect. These kinds of layout propagation rules are often why developers find SwiftUI unintuitive.

Before iOS 16, you could get the ScrollView’s offset using the following code. However, if the UI becomes complex, the scrollViewOffset will not update while scrolling.

ScrollView {VStack(alignment: .leading, spacing: 32) {// 1. 将监测器独立出来，包裹在无间距的 VStack 中以避免布局干扰VStack(spacing: 0) {Color.clear.frame(height: 0) // 占据 0 高度，不可见但存在.background(    GeometryReader { proxy in        Color.clear            .preference(                key: ScrollOffsetKey.self,                value: proxy.frame(in: .named("scroll")).minY            )    })LargeNavBarView().opacity(largeHeaderOpacity)}ContentArea}.padding(.horizontal, 24)}.coordinateSpace(name: "scroll").onPreferenceChange(ScrollOffsetKey.self) { value in     self.scrollOffset = value }

After iOS 16, you can reliably obtain the scrollView’s offset using the following code.

ScrollView {VStack(alignment: .leading, spacing: 32) {// 1. 将监测器独立出来，包裹在无间距的 VStack 中以避免布局干扰VStack(spacing: 0) {Color.clear.frame(height: 0) // 占据 0 高度，不可见但存在.onGeometryChange(for: CGFloat.self) { proxy inproxy.frame(in: .named("scroll")).minY} action: { newValue inself.scrollOffset = newValueprint("scrollOffset: \(self.scrollOffset)")}LargeNavBarView().opacity(largeHeaderOpacity)}ContentArea}.padding(.horizontal, 24)}

I wrapped my view in a NavigationStack and used .toolbarVisibility(.hidden, for: .tabBar) to navigate while hiding the tab bar. However, this causes an issue: the transition animation becomes stiff and unnatural. I haven’t found a good solution yet.

I’m trying to research how Apple’s official apps handle this. It seems that many of them simply present a new view when they need to hide the tab bar.

The tab bar is generally always visible. When an app needs to hide it, the common pattern is to present a modal view, rather than pushing a view inside the existing navigation stack.

The completed code is here:

import SwiftUIstruct ContentView: View {    var body: some View {        TabView {            HomeTab()                .tabItem {                    Label("Home", systemImage: "house.fill")                }                        Text("Settings Tab")                .tabItem {                    Label("Settings", systemImage: "gear")                }        }    }}struct HomeTab: View {    var body: some View {        NavigationStack {            MainView()        }    }}struct MainView: View {    var body: some View {        List {            NavigationLink("Go to Detail Page 1") {                DetailView(title: "Detail 1")                    .toolbarVisibility(.hidden, for: .tabBar)            }            NavigationLink("Go to Detail Page 2") {                DetailView(title: "Detail 2")            }        }        .navigationTitle("Main View")    }}struct DetailView: View {    let title: String        var body: some View {        Text("This is the \(title)")            .navigationTitle(title)            .navigationBarTitleDisplayMode(.inline)    }}#Preview {    ContentView()}

In Swift, Type Erasure is a key concept for understanding protocols and generics.

It explains why any exists and how Swift’s generic protocols differ from other languages.

1️⃣ Why Type Erasure Matters

protocol ReReduce {}struct AppReduce: ReReduce {}let a: any ReReduce = AppReduce()

any ReReduce means “a type that conforms to ReReduce,” , but the exact type is unknown at compile time.

The compiler performs type erasure, wrapping the value in an existential container. This allows storing and calling methods on multiple conforming types in one collection.

2️⃣ Generics vs Existential Types

func process<T: Reducable>(_ value: T) { }   // Genericfunc process(_ value: any Reducable) { }     // Existential

Generics let the compiler know the type;
any lets it forget the type but keep its behavior.

3️⃣ Swift vs Other Languages

protocol ReReducer {    associatedtype S    associatedtype A    func reduce(_ state: S, _ action: A) -> S}

TypeScript equivalent:

interface ReReducer<S, A> {  reduce(state: S, action: A): S;}

Swift needs type erasure to mix generic implementations in one array.

4️⃣ Binding Associated Types

You can fix associated types using typealias to unify them:

typealias AnyAppReducer = any ReReducer  where S == AppState, A == AppActionlet reducers: [AnyAppReducer] = [    AppReducer(),    AnotherAppReducer()]

🧩 Summary

• Use generics for performance and type safety.
• Use any for polymorphism and dynamic flexibility.

Understanding type erasure helps you design clearer, more adaptable Swift architectures.

昨天在 YouTube 上看到一个讲「大脑如何高效学习」的频道 (Justin Sung)。里面提到：死记硬背是被动学习，效率非常低。真正有效的学习是把知识主动消化，融入自己的知识体系里。要想记得牢，必须不断从大脑里“取出来”——也就是使用、复述、应用。这也解释了为什么需要复习和回忆。

今天我也解决了 ANKI 卡片数量爆炸的问题。原来不是每一个定义都要做成一张卡片，而是要用“提问”来让自己从大脑中检索知识，让神经连接真正建立起来。

今天学习的时候，我尝试用 Obsidian 的 canvas 来组织知识。一边学习，一边把知识点画出来、连接起来。要学会一个东西，必须让大脑主动参与。要给知识编码、建立上下文，把它放进自己已有的认知架构里。否则大脑会直接把它当成“无用信息”丢掉。如果强行硬背，大脑还会直接“关机”，让你犯困。

明天继续早起。
上午学 iOS。
下午学英语。
晚上工作。
就这样，一点点把自己拉回正轨。

我开始尝试关闭编译器优化, 重新编译运行. 同样能正常运行, 没有报Simultaneous access的运行时错误.

为了对的起我的起床, 我决定深入研究一下. 我先简化代码, 然后阅读汇编代码.

通过上图, 可以看到take方法的调用在swift_beginsAccess与 swift_endAccess之间, 说明swift确实检查了内存安全. 但是它只检查了一次, 并没有针对第8行的闭包和take方法分别检查, 所以我的程序能过正常运行.

对了, swift_beginsAccess 方法会对访问内容进行检查, 如果都是读取操作不会有问题, 如果针对某个地址还有其它操作就会报运行时错误.

This post is about creating a confetti animation in SwiftUI with a customizable duration. I learned the technique from this Patreon tutorial.

In the original animation, the confetti pieces would change color while falling, which I considered a bug. I’ve since fixed it. Another optimization I considered was adding a fade-out effect to make the disappearance of the confetti smoother, but the result wasn’t satisfactory, so I have not included that change.

Let’s break down how to build this.

Step 1: Animate a Single Piece of Confetti

First, we’ll create the animation for a single piece of confetti. The code and the result are below:

struct ConfettiView: View {    @State private var animate = false    @State private var xSpeed = Double.random(in: 0.7...2.0)    @State private var zSpeed = Double.random(in: 1.0...2.0)    @State private var anchor = CGFloat.random(in: 0...1).rounded()    @State private var color: Color = [.orange, .green, .blue, .red, .yellow].randomElement() ?? .green    var body: some View {        Rectangle()            .fill(color)            .frame(width: 14, height: 14)            .onAppear { animate = true }            .rotation3DEffect(.degrees(animate ? 360 : 0), axis: (x: 1, y: 0, z: 0))            .animation(.linear(duration: xSpeed).repeatForever(autoreverses: false), value: animate)            .rotation3DEffect(.degrees(animate ? 360 : 0),                              axis: (x: 0, y: 0, z: 1),                              anchor: UnitPoint(x: anchor, y: anchor))            .animation(.linear(duration: zSpeed).repeatForever(autoreverses: false), value: animate)    }}

This line of code is the key to fixing the color-changing issue:

@State private var color: Color = [.orange, .green, .blue, .red, .yellow].randomElement() ?? .green

The color used to change because the original code would assign a new random color during the animation process. By using @State to store the color, we ensure its value is preserved for the view’s lifetime, preventing the color from changing unexpectedly.

Step 2: Create the Confetti Container

Next, we’ll create a container to hold 50 confetti pieces and manage their positioning.

struct ConfettiContainerView: View {    var count: Int = 50    @State private var ySeed: CGFloat = 0    var body: some View {        GeometryReader { geo in            ZStack {                ForEach(0..<count, id: \.self) { _ in                    ConfettiView()                        .position(                            x: CGFloat.random(in: 0...geo.size.width),                            y: ySeed == 0 ? 0 : CGFloat.random(in: 0...geo.size.height)                        )                }            }            .ignoresSafeArea()            .onAppear {                ySeed = geo.size.height            }        }    }}

Step 3: Encapsulate as a View Modifier

Finally, to make the animation reusable and easy to apply, we’ll wrap it in a ViewModifier.

struct ConfettiModifier: ViewModifier {    @Binding var isActive: Bool    @State private var opacity = 1.0    private let animationTime = 3.0    private let fadeTime = 1.6    func body(content: Content) -> some View {        content            .overlay(                ZStack {                    if isActive {                        ConfettiContainerView()                            .opacity(opacity)                            .allowsHitTesting(false)                    }                }            )            .onChange(of: isActive) { _, newValue in                guard newValue else { return }                Task {                    await sequence()                }            }    }    private func sequence() async {        do {            try await Task.sleep(nanoseconds: UInt64(animationTime * 1_000_000_000))                        withAnimation(.easeOut(duration: fadeTime)) {                opacity = 0            }                        try await Task.sleep(nanoseconds: UInt64(fadeTime * 1_000_000_000))            isActive = false            opacity = 1.0        } catch {}    }}extension View {    func displayConfetti(isActive: Binding<Bool>) -> some View {        modifier(ConfettiModifier(isActive: isActive))    }}// Usage Examplestruct ContentView: View {    @State private var showConfetti = false    var body: some View {        VStack {            Text("You did it!").font(.title.bold())            Button("Celebrate") {                showConfetti = true            }        }        .frame(maxWidth: .infinity, maxHeight: .infinity)        .displayConfetti(isActive: $showConfetti)    }}

A Journey Across the Stack

Every technology I’ve worked with has taught me something invaluable.

• Building backend systems gave me a deep appreciation for data architecture, APIs, and the logic that powers applications from behind the scenes.
• Working with React Native and Flutter was a fantastic lesson in efficiency and the challenge of creating a consistent experience across different operating systems. The promise of “write once, run anywhere” is compelling, and I learned a great deal about managing a single codebase for multiple targets.

This broad perspective is something I wouldn’t trade. It gave me a holistic view of how a product comes to life, from the database all the way to the user’s screen. But it also created a point of comparison that continually highlighted what makes native development, and specifically iOS, so special to me.

The Pull of Native iOS

There’s a certain elegance and satisfaction in iOS development that I kept coming back to. The seamless integration between the Swift language, powerful frameworks like SwiftUI, and the hardware itself allows for a level of polish and performance that is simply a joy to create. The pursuit of the perfect animation, the crispness of a native UI component, and the satisfaction of building something that feels completely at home on the device—that’s what excites me as a developer.

After reflecting on this, I felt a renewed surge of energy and inspiration. To channel it into something tangible, I decided to build a small, focused project that captures the kind of delightful interaction I love: a simple “lights-out” animation.

Project: The “Lights-Out” Animation

I wanted to create more than just a toggle. I wanted to build an experience. The idea was to mimic the satisfying, physical act of pulling a cord to turn a light on and off, complete with animated light beams, a draggable cord, and a crisp sound effect.

Here is a video of the final result!

This project, while small, was a great way to put SwiftUI’s strengths to the test, focusing on:

• Declarative UI: Building complex views that react to state changes.
• State Management: Using @State and @Binding to drive the entire UI from a single source of truth (isOn).
• Animation: Leveraging withAnimation and animation modifiers to create fluid transitions and spring physics for the pull cord.
• Gestures: Implementing a DragGesture to create an interactive and intuitive pull-cord mechanism.

A Look at the Code

For those interested in how it works, the full source code is available on my GitHub. But here are a few key pieces that bring the experience to life.

The core of the app is the ContentView, which manages the isOn state. This single boolean drives everything from the background color to the sound playback.

struct ContentView: View {    @State var isOn = true        var body: some View {        ZStack {            // The background's gradient changes based on the 'isOn' state            LightBeamBackground(isOn: self.$isOn)                .ignoresSafeArea()                        // The main lightbulb button that can also toggle the state            Button(action: {                withAnimation {                    self.isOn.toggle()                }            }) {                // ... button content            }        }        .overlay(alignment: .topTrailing) {            // The interactive pull cord is an overlay            PullCord(isOn: self.$isOn)                .padding(.top, -40)        }        .onChange(of: self.isOn) { _, newValue in            // Play a sound effect whenever the state changes            SoundPlayer.shared.play(newValue ? .lightOn : .lightOff)        }    }}

The most interactive piece is the PullCord view. It uses a DragGesture to track the user’s finger and provides physical feedback by stretching. When the drag is released, it decides whether to toggle the light based on how far it was pulled.

struct PullCord: View {    @Binding var isOn: Bool    @State private var dragOffsetY: CGFloat = 0    private let maxDragDistance: CGFloat = 140        var body: some View {        ZStack(alignment: .top) {            // ... visual components for the cord and handle        }        .gesture(            DragGesture(minimumDistance: 0)                .onChanged { value in                    let dy = max(0, value.translation.height)                    dragOffsetY = min(dy, maxDragDistance)                }                .onEnded { value in                    let shouldToggle = value.translation.height > maxDragDistance * 0.6                    withAnimation(.spring(response: 0.35, dampingFraction: 0.8)) {                        dragOffsetY = 0                        if shouldToggle {                            isOn.toggle()                        }                    }                }        )    }}

This project reaffirmed my belief in the power and elegance of SwiftUI for creating these kinds of delightful, polished user experiences.

What’s Next

This journey of exploration across the tech stack has been invaluable, but now I know where I want to build my future. I’m currently based in Calgary and am actively seeking my next role as an iOS Developer. I’m looking for a team where I can contribute my diverse experience, my passion for Apple’s ecosystem, and my drive to build beautiful, high-performing applications.

If you’re looking for a passionate iOS developer with a broad technical perspective, I would love to connect. You can find my LinkedIn profile here.

Good night, Calgary. Hopeful for new opportunities and interviews tomorrow!

While the standard property wrappers handle most state management needs, you will often encounter situations where the shape of your state doesn’t perfectly match the requirements of a SwiftUI view. For example, a view might need a Binding<String>, but your model provides a Binding<String?>. Or a view needs to bind to the associated value of an enum case.

SwiftUI’s Binding type is incredibly powerful, and with a few extension methods, we can transform bindings to fit our exact needs. Let’s use the following data model for our examples:

struct Item: Hashable, Identifiable {    let id = UUID()    var color: Color?    var status: Status        enum Status: Hashable {        case inStock(quantity: Int)        case outOfStock(isOnBackOrder: Bool)    }}

Given a state variable like @State var item: Item, a binding to its status, $item.status, would have the type Binding<Item.Status>. Let’s see how we can manipulate this and other bindings.

Drilling Down into Bindings with Key Paths

SwiftUI has built-in support for creating bindings to the properties of a bound value. When you write $item.status, Swift is transparently applying a transform to map the Binding<Item> to a Binding<Item.Status>. This is conceptually achieved through a map function that uses a WritableKeyPath:

extension Binding {    func map<LocalValue>(_ keyPath: WritableKeyPath<Value, LocalValue>) -> Binding<LocalValue> {        self[dynamicMember: keyPath]    }}

You rarely need to call this map function directly, as the . syntax ($item.status) is convenient shorthand for the same operation. It’s the simplest way to transform a Binding<A> into a Binding<B>.

Handling Optionals: The unwrap Extension

A very common scenario is dealing with optional state. For instance, our item.color property is a Color?, making $item.color a Binding<Color?>. However, SwiftUI’s ColorPicker view requires a Binding<Color>. It cannot work with optionals.

To bridge this gap, we can create a handy unwrap extension that transforms an optional binding Binding<A?> into a non-optional binding Binding<A>?. The result is itself an optional: it will be nil if the original state is nil, or a valid, non-optional Binding if the state has a value.

extension Binding {    /// Transforms a `Binding<Wrapped?>` into a `Binding<Wrapped>?`.    /// If the original binding's value is `nil`, this returns `nil`.    func unwrap<Wrapped>() -> Binding<Wrapped>? where Value == Wrapped? {        // If the wrapped value is nil, we can't create a binding.        guard let value = self.wrappedValue else { return nil }                // Create a new binding that gets the non-optional value        // and sets the optional value on the original source.        return Binding<Wrapped>(            get: { value },            set: { self.wrappedValue = $0 }        )    }}

Usage:

You can use this with an if let statement to conditionally show a view that requires a non-optional binding.

struct ItemEditorView: View {    @Binding var item: Item    var body: some View {        // Only show the ColorPicker if a binding to a non-optional Color can be created.        if let colorBinding = $item.color.unwrap() {            ColorPicker("Item Color", selection: colorBinding)        } else {            Text("This item has no color set.")        }    }}

A More General Solution for Enums: matching with CasePaths

The unwrap function is actually a specific version of a broader problem: how do we bind to the associated value of an enum case? An Optional is just an enum with two cases: .none and .some(Wrapped). unwrap effectively extracts the associated value from the .some case.

To create a more generic solution for any enum, we can leverage the excellent CasePaths library. A CasePath is like a “key path for an enum case,” allowing you to reliably extract associated values from and embed them back into an enum.

Building on this, we can create a matching function that returns a binding to an associated value if and only if the binding’s value is currently in that specific case.

// Requires the 'CasePaths' library: https://github.com/pointfreeco/swift-case-pathsimport CasePathsextension Binding {    /// Returns a new binding focused on a specific case of an enum.    /// If the original binding's value does not match the case, this returns `nil`.    func matching<Case>(        _ casePath: CasePath<Value, Case>    ) -> Binding<Case>? {        // Attempt to extract the associated value from the current state.        guard let `case` = casePath.extract(from: self.wrappedValue) else { return nil }                // Create a new binding.        return Binding<Case>(            // The getter returns the extracted associated value.            get: { `case` },            // The setter embeds the new value back into the case and updates the original source.            set: { `case` in self.wrappedValue = casePath.embed(`case`) }        )    }}

Usage:

This powerful extension allows you to build UI that adapts to the state of an enum. For our Item.Status, we can show completely different controls for each case.

struct ItemStatusView: View {    @Binding var status: Item.Status        var body: some View {        VStack {            // This UI will only appear and work if status is .inStock            if let quantityBinding = $status.matching(/Item.Status.inStock) {                Stepper("Quantity: \(quantityBinding.wrappedValue)", value: quantityBinding)            }                        // This UI will only appear and work if status is .outOfStock            if let onBackOrderBinding = $status.matching(/Item.Status.outOfStock) {                Toggle("Is on backorder", isOn: onBackOrderBinding)            }        }    }}

These techniques for transforming Binding are essential for writing clean, decoupled SwiftUI code. They allow your views to remain simple and focused on their specific data requirements, while your data models can remain complex and robust.

In SwiftUI, managing the state of your application—the data that drives your UI—is a fundamental concept. SwiftUI provides a set of powerful property wrappers that handle view updates automatically when your data changes. This guide explores the core tools: @State, @StateObject, @ObservedObject, and @Published.

Core Property Wrappers at a Glance

The following table provides a quick reference for the most common state management property wrappers in SwiftUI. Note that @StateObject, @ObservedObject, and @Published are all integral parts of the Combine framework, which SwiftUI uses for reactive programming.

A key distinction to remember is that a view’s @State can be destroyed and recreated if the view is removed and re-added to the view hierarchy. In contrast, @StateObject is designed to survive view redraws as long as the view maintains its identity.

Understanding the Nature of SwiftUI Views

Before diving deeper, it’s crucial to understand what a SwiftUI View is. The struct you define (e.g., struct MyView: View) is not the persistent object you see on screen. Instead, it’s a lightweight “blueprint” or “description” of your UI.

• View Structs are Ephemeral: Every time SwiftUI needs to update the UI (perhaps because a @State variable changed), it re-creates your view struct and calls its body property to get a new blueprint. Creating and destroying these structs is extremely fast and low-cost.
• “Redraw” = “Re-evaluating body“: When we say a “view redraws,” it’s more accurate to say that “the view’s body property is re-evaluated,” which often results in new view structs being created.

The Magic of @StateObject: Separating State from the View Struct

@StateObject was introduced to solve the problem of state being reset during view redraws. Its mechanism works as follows:

1. View Identity: SwiftUI uniquely identifies a view by its position and type within the View Tree. For example, “the first UserProfileView inside the VStack in ContentView.”

2. First-Time Creation & Storage: The very first time a view with this specific identity appears, SwiftUI sees the @StateObject property wrapper. It then:

   • Executes your initialization code (e.g., _viewModel = StateObject(wrappedValue: UserViewModel())) to create an instance of your ObservableObject.
   • SwiftUI then takes this newly created instance and stores it in a special, managed memory area associated with that specific view identity.

3. Subsequent Redraws: Later, when a parent view’s state changes and your view’s body is re-evaluated, a new view struct is created. However:

   • SwiftUI again sees the @StateObject property wrapper.
   • This time, it checks its internal storage and finds that an object is already associated with this view’s identity.
   • It skips your initialization code and simply connects the property to the pre-existing instance from its managed memory.

Practical Example: The Lifecycle of @State

The following code demonstrates how @State is tied to the view instance’s lifetime within the view hierarchy.

import SwiftUIstruct CounterView: View {    // A @State variable, initialized to 0    @State private var count = 0    init() {        // Log when this view is created        print("✅ CounterView has been initialized.")    }    var body: some View {        VStack {            Text("Counter Value: \(count)")                .font(.title)                .padding()                        Button("Increment Count") {                count += 1            }        }        .padding()        .border(Color.blue, width: 2)        // This is called when the view is removed from the view tree        .onDisappear {            print("❌ CounterView has disappeared.")        }    }}struct ContainerView: View {    @State private var showCounter = true    var body: some View {        VStack(spacing: 30) {            Toggle("Show/Hide Counter", isOn: $showCounter.animation())                .padding()            if showCounter {                // When showCounter is true, CounterView exists in the view tree                CounterView()            } else {                // When showCounter is false, CounterView is completely removed                // A placeholder Text shows the structural change                Text("Counter is hidden")                    .foregroundColor(.gray)            }                        Spacer()        }        .navigationTitle("State Lifecycle Demo")    }}

How to Run and Observe

1. Run the ContainerView. You will see the counter, and the console will print: “✅ CounterView has been initialized.”
2. Click the “Increment Count” button a few times to increase the count (e.g., to 5).
3. Now, tap the “Show/Hide Counter” Toggle to turn it off.
   • The CounterView will disappear from the screen.
   • The console will print: “❌ CounterView has disappeared.” This confirms the view instance was destroyed.
4. Tap the Toggle again to turn it back on.
   • CounterView reappears on the screen.
   • The console will again print: “✅ CounterView has been initialized.” This proves that SwiftUI has created a brand new CounterView instance.
   • You will notice that the counter’s value has reset to 0, not the 5 you left it at.

This behavior perfectly illustrates that @State‘s storage is tied to the lifecycle of its containing view in the view hierarchy. If the view is removed, its state is lost. This is precisely the scenario where @StateObject should be used if you need the state to persist as long as the view’s identity remains the same.

Part 1: Core Concepts

1. Value vs. Reference Types

Types in Swift are divided into value types (struct, enum) and reference types (class). The fundamental difference lies in how their data is stored and passed.

• Value Types: Each instance keeps a unique copy of its data. When you pass a value type, it is copied.
• Reference Types: Instances share a single copy of their data. When you pass a reference type, a reference (or pointer) to the instance is passed.

Copy-on-Write

To optimize performance, many of Swift’s standard library value types (like Array and Dictionary) use a technique called Copy-on-Write. This means a copy is only made when the data needs to be modified; otherwise, multiple instances share the same data storage.

import Foundation// A backing class for demonstrationclass BackendQueue<T> {    private var items = [T]()    public init() {}    private init(_ items: [T]) { self.items = items }    public func addItem(item: T) { items.append(item) }    public func getItem() -> T? {        if items.count > 0 { return items.remove(at: 0) }         else { return nil }    }    public func count() -> Int { return items.count }    public func copy() -> BackendQueue<T> { return BackendQueue<T>(items) }}// A struct wrapper to implement Copy-on-Writestruct Queue {    private var internalQueue = BackendQueue<Int>()        public mutating func addItem(item: Int) {        checkUniquelyReferencedInternalQueue()        internalQueue.addItem(item: item)    }        public func count() -> Int {        return internalQueue.count()    }        mutating private func checkUniquelyReferencedInternalQueue() {        if !isKnownUniquelyReferenced(&internalQueue) {            internalQueue = internalQueue.copy()            print("Making a copy of internalQueue")        } else {            print("Not making a copy of internalQueue")        }    }}print("Start")var queue1 = Queue()var queue2 = queue1 // No copy happens hereprint("ADD")queue1.addItem(item: 1) // Modifying queue1 triggers a copyqueue1.addItem(item: 2)print(queue1.count())print("Done")/*Console Output:StartADDMaking a copy of internalQueueNot making a copy of internalQueue2Done*/

Noncopyable Types (~Copyable)

Swift 6 introduces noncopyable types to represent unique resources like file handles or network sockets, ensuring they are not accidentally duplicated.

struct Person: ~Copyable {    var firstName: String    var lastName: String}

Two key concepts related to noncopyable types are borrowing and consuming.

• Borrowing (borrowing): Grants temporary, read-only access to a noncopyable value without transferring ownership. Borrowed values are thread-safe.
• Consuming (consuming): Transfers ownership of a noncopyable value, and the original variable becomes invalid. A consuming method ends the object’s lifetime upon its return. Global instances cannot be consumed.

// The `borrowing` keyword indicates the function temporarily borrows `user` without taking ownershipfunc sendEmail(_ user: borrowing Person) {    print("Sending Email to \(user.firstName)")}// The `consuming` keyword indicates the function consumes `user`, taking ownershipfunc consumeUser(_ user: consuming Person) {    print("Consuming User \(user.firstName)")}func userFunction() {    let user = Person(firstName: "Jon", lastName: "Hoffman")    sendEmail(user) // user is borrowed    consumeUser(user) // user is consumed, and the variable becomes invalid afterward}

We can also create consuming methods that invalidate the instance once executed.

struct SecrectMessage: ~Copyable {    private var message: String    init(_ message: String) { self.message = message }        // After this consuming method is executed, the instance is destroyed    consuming func read() {        print("\(message)")    }}

2. Enumerations

Enumerations define a common type for a group of related values.

• Raw Values: Enum members can be prepopulated with a default value.

  enum Direction: String {    case North = "N", South = "S", West = "W", East = "E"}enum Month: Int {    case January = 1, February, March, April // 2, 3, 4 are inferred automatically}

• Associated Values: Store custom values associated with an enum member.

  enum Product {    case Book(Double, Int, Int) // price, year, pages    case Puzzle(Double, Int)   // price, pieces}

• Pattern Matching: The switch statement makes it easy to handle different enum cases and extract their associated values.

  let masterSwift = Product.Book(49.99, 2024, 394)switch masterSwift {case .Book(let price, let year, let pages):    print("Mastering Swift was published in \(year) for \(price) and has \(pages) pages")case .Puzzle(let price, let pieces):    print("A puzzle with \(pieces) pieces and sells for \(price)")}

• Enum Iteration: By conforming to the CaseIterable protocol, you can iterate over all members of an enumeration.

  enum DaysOfWeek: String, CaseIterable {    case Monday = "Mon", Tuesday = "Tues", Wednesday = "Wed", Thursday = "Thur", Friday = "Fri", Saturday = "Sat", Sunday = "Sun"}for day in DaysOfWeek.allCases {    print("-- \(day.rawValue)")}

3. Closures

Closures are self-contained blocks of functionality that can be passed around and used in your code.

• Basic Syntax:

  let clos1 = { () -> Void in  print("hello world")}clos1()

• Shorthand Syntax: Swift provides several ways to simplify closure syntax.

  // $0, $1 represent the first and second parametersguests.map { print("hello \($0)") }// If the closure is the only argument to a function, the parentheses can be omittedtestFunction2(num: 5) {    print("hello from \($0)")}// Single-expression closures can implicitly return their resultlet clos7 = { (first: Int, second: Int) -> Int in first + second }print(clos7(1, 2)) // Prints 3

• Escaping Closures (@escaping): When a closure is called after the function it was passed to returns, it needs to be marked with the @escaping keyword. This typically happens when the closure is stored for later use or executed in an asynchronous operation.

  var handlers: [LogLevel: [logLevelHandler]] = [:]func registerHandler(for level: LogLevel, handler: @escaping logLevelHandler) {    handlers[level, default: []].append(handler)}

4. Error Handling

Swift provides a powerful error handling model that allows you to represent and respond to recoverable errors.

• Defining Errors: Create an enum that conforms to the Error protocol to represent different kinds of errors.

  enum PlayerNumberError: Error {    case NumberTooHigh(description: String)    case NumberTooLow(description: String)    case NumberAlreadyAssigned    case NumberDoesNotExist}

• Throwing Errors (throws): Use the throw keyword to throw an error within a function. The function’s signature must be marked with throws.

  mutating func addPlayer(player: BaseballPlayer) throws {    guard player.number < maxNumber else {        throw PlayerNumberError.NumberTooHigh(description: "Max number is \(maxNumber)")    }    // ... other checks}

• Catching Errors (do-catch): Use a do-catch statement to call a function that can throw an error.

  do {    let player = try myTeam.getPlayerByNumber(number: 34)    print("Player is \(player.firstName)")} catch PlayerNumberError.NumberDoesNotExist {    print("No player has that number")} catch let error { // Catch all other errors    print("An error occurred: \(error)")}

  You can also match multiple error patterns in a single catch clause:

  catch PlayerNumberError.NumberTooHigh, PlayerNumberError.NumberTooLow {    print("Number is out of range.")}

• LocalizedError Protocol: Conforming to this protocol can provide richer, localized descriptions for your errors.

  enum PlayerNumberError: Error, LocalizedError {    // ... cases    var errorDescription: String? {        switch self {        case .NumberAlreadyAssigned:            return "Player number already assigned"        // ... other descriptions        }    }}

• Defer Statement (defer): The code within a defer block is executed just before the current scope is exited, whether by normal completion or by throwing an error. This is very useful for resource cleanup.

  func processFile() {    let file = openFile()    defer {        closeFile(file) // Ensures the file is always closed        print("File closed.")    }    // ... file processing code that might throw an error    print("File processed.")}

5. Memory Management

Swift uses Automatic Reference Counting (ARC) to manage memory. ARC tracks the number of references to class instances. When the reference count for an instance drops to zero, the instance is deallocated, and its memory is freed.

class MyClass {    var name: String    init(name: String) { self.name = name; print("Initializing \(name)") }    deinit { print("Releasing \(name)") }}var ref1: MyClass? = MyClass(name: "One") // Reference count is 1var ref2: MyClass? = ref1               // Reference count is 2ref1 = nil                              // Reference count is 1ref2 = nil                              // Reference count is 0, instance is deallocated

Strong Reference Cycles

If two class instances hold a strong reference to each other, they will never be deallocated, causing a memory leak.

class MyClass1_Strong {    var class2: MyClass2_Strong?    // ...}class MyClass2_Strong {    var class1: MyClass1_Strong?    // ...}var class1: MyClass1_Strong? = MyClass1_Strong(name: "Class1")var class2: MyClass2_Strong? = MyClass2_Strong(name: "Class2")class1?.class2 = class2 // class1 holds class2class2?.class1 = class1 // class2 holds class1 (cycle!)class1 = nilclass2 = nil // Instances will not be released

Solutions:

• Weak References (weak): Use when the referenced instance might become nil. A weak reference does not increase the reference count and must be an optional type.

  class MyClass2_Weak {    weak var class1: MyClass1_Weak? // Weak reference}

• Unowned References (unowned): Use when you are certain the referenced instance will never be nil during the current instance’s lifetime. An unowned reference is not optional, and accessing a deallocated unowned reference will trigger a runtime error.

  class MyClass1_Unowned {    unowned let class2: MyClass2_Unowned // Unowned reference}

Part 2: Protocol-Oriented & Functional Programming

Swift is a multi-paradigm language with strong support for Protocol-Oriented Programming (POP) and Functional Programming.

1. Object-Oriented Programming (OOP)

The three pillars of OOP are Encapsulation, Inheritance, and Polymorphism.

• Inheritance: Supported by reference types (class). While powerful, complex class hierarchies can increase code complexity and coupling, making modification and maintenance difficult.
• Dynamic Dispatch: When a method on a class is called, the runtime uses a virtual table (VTable) to look up and call the correct implementation. This provides flexibility but is slightly slower than a direct call.

2. Protocol-Oriented Programming (POP)

POP is a core design philosophy in Swift. It emphasizes defining blueprints using protocols rather than relying on class inheritance.

• Protocol Definition: A protocol defines a blueprint of methods, properties, and other requirements.

  protocol Nameable {    var firstName: String { get }}

• Protocol Composition: A type can conform to multiple protocols, combining different functionalities.

  protocol Person: Nameable, Contactable { /* ... */ }struct Employee: Person, Occupation { /* ... */ }

• Protocol Inheritance: Protocols can also inherit from other protocols, aggregating multiple requirements.

Compared to class inheritance, POP offers greater flexibility and modularity, helping to avoid bloated base classes.

3. Protocols and Protocol Extensions

• Type Checking and Casting: You can use is and as? to check if an instance conforms to a protocol.

  for person in people where person is SwiftProgrammer {    print("\(person.firstName) is a Swift Programmer")}

• Protocol Extensions: You can extend protocols to provide default implementations for methods. Types conforming to the protocol automatically gain this functionality.

  protocol Dog {    var name: String { get }}extension Dog {    func speak() -> String {        return "Woof Woof"    }}

• Any vs any:

  • Any: Can represent a value of any type, including function and optional types.
  • any: Used to modify a protocol, representing an existential type. It allows you to store values of different types that conform to the same protocol in a container and supports dynamic dispatch.

• Implicitly Opened Existentials: Swift 6 allows the compiler to implicitly open existential types, simplifying operations on protocol arrays.

  protocol Drawable { func draw() }// No manual casting needed, protocol methods can be called directlyfunc drawAll(_ items: [any Drawable]) {    for item in items {        item.draw()    }}

4. Generics

Generic code enables you to write flexible, reusable functions and types that can work with any type.

• Generic Functions:

  func swapGeneric<T>(a: inout T, b: inout T) {    let tmp = a; a = b; b = tmp}

• Associated Types (associatedtype): Used in a protocol as a placeholder for a type that is specified only when the protocol is adopted.

  protocol Queue {    associatedtype QueueType    mutating func add(item: QueueType)    mutating func getItem() -> QueueType?}

• Conditional Extensions and Conformance: You can add extensions to a generic type that are only available if the generic parameter meets certain conditions.

  // Add the sum method only if T is a numeric typeextension List where T: Numeric {    func sum() -> T { items.reduce(0, +) }}// List conforms to Equatable only if T also conforms to Equatableextension List: Equatable where T: Equatable {    static func == (l1: List, l2: List) -> Bool {        // ... comparison logic    }}

5. Functional Programming

Core principles of functional programming include:

• Immutability: Prefer constants (let) to avoid direct state modification.

  let numbers = [1, 2, 3, 4, 5]let doubled = numbers.map { $0 * 2 } // The `numbers` array itself is not changed

• Pure Functions: Always produce the same output for the same input and have no side effects.

  func add(_ first: Int, _ second: Int) -> Int {    return first + second}

• Higher-Order Functions: Functions that take other functions as arguments or return them, such as map, filter, and reduce.

  func performMathOperation(_ first: UInt, _ second: UInt, function: (UInt, UInt) -> UInt) -> UInt {    return function(first, second)}

Advanced Techniques:

• Function Composition: Combining multiple functions into a new one.

  infix operator >>>func >>> <A, B, C>(lhs: @escaping (A) -> B, rhs: @escaping (B) -> C) -> (A) -> C {    return { rhs(lhs($0)) }}let addOneToString = addOne >>> toString

• Currying: Transforming a function that takes multiple arguments into a sequence of functions that each take a single argument.

  func curriedAdd(_ a: Int) -> (Int) -> Int {    return { a + $0 }}let addTwo = curriedAdd(2)let result = addTwo(3) // result is 5

• Recursion: A function calling itself to solve a problem.

  func factorial(_ n: Int) -> Int {    if n <= 1 { return 1 }    return n * factorial(n - 1)}

Part 3: Modern Concurrency

Swift provides a concurrency model ranging from the low-level GCD to the modern async/await structured approach.

1. Grand Central Dispatch (GCD)

GCD is a low-level C API that manages tasks via queues.

• Concurrency: Multiple tasks starting, running, and completing in the same time period.
• Parallelism: Multiple tasks running at the exact same moment, which requires a multi-core processor.

Queue Types:

• Serial Queues: Tasks are executed one at a time in FIFO order. Often used to synchronize access to a shared resource.
• Concurrent Queues: Tasks start in order but can run concurrently. The system determines the number of concurrent tasks.
• Main Dispatch Queue: A globally available serial queue that executes tasks on the application’s main thread, typically used for UI updates.

Using Queues:

// Create a concurrent queuelet cqueue = DispatchQueue(label: "cqueue.example", attributes: .concurrent)// Create a serial queuelet squeue = DispatchQueue(label: "squeue.example")// Execute a task asynchronously without blocking the current threadcqueue.async {    performCalculation(tag: "async1")}// Switch from a background thread to the main thread to update the UIsqueue.async {    let resizedImage = image.resize()    DispatchQueue.main.async {        picView.image = resizedImage    }}