Forem: Raphael Martin

What Really Are The Differences Between SwiftUI and UIKit?

Raphael Martin — Fri, 16 May 2025 14:30:00 +0000

Introduction

I had a feeling that most of the devs that work with Apple Platforms (iOS, macOS, tvOS, etc) prefers SwiftUI over UIKit. I didn't found any data that proved this feeling, so I created a pool in LinkedIn, and that was the result:

This is not the most academic way to gather data, but it reveals that my feeling maybe is right: most of the devs prefers SwiftUI. Some of them, specially the most experienced ones, can argue about some pros and cons of SwiftUI and even scenarios where it should be avoided (mostly mention old OS support and team knowledge about the framework). However, I see a lot of engineers struggle to explain why they prefer SwiftUI. Sometimes it seems that they were told that SwiftUI is better, and they just accepted that. Today we're going to explore the real and impactful differences between SwiftUI and UIKit.

What SwiftUI is not

To compare SwiftUI with anything else we first need to understand what it is. Actually, for this specific UI framework I think it's even more relevant understand what SwiftUI is not. That's because I've heard a lot of wrong explanations and misconceptions about the tool in my career.

🚨 Attention: SwiftUI is not an UIKit wrapper, neither built on top of UIKit.

However, it's possible that SwiftUI uses some UIKit components behind the scenes. More on that below.

So What Is It?

SwiftUI is an UI framework developed by Apple and announced in 2019¹, introduced in iOS 13 and macOS 10.15 (Catalina). SwiftUI comes to be an alternative to the existing ways of writing UI in these platforms (UIKit and AppKit, respectively). The idea was having a declarative way of writing the UI logic.
The focus of the framework on its declarative syntax led a lot of people to think that SwiftUI was an UIKit library, that converts the SwiftUI declarative code into the UIKit one, which is a totally incorrect concept.
SwiftUI has a total unique way of building UI. The main difference compared to the older framework is that SwiftUI decides how to render a view in runtime. Based in several variables (that are not visible to the developer), such as view complexity, hardware resources availability and more, SwiftUI decides what is the best strategy to render an specific view: either using UIKit/AppKit (if available for that platform) or using Metal to draw the component completely from scratch.

Another good example that illustrates that SwiftUI cannot be an UIKit wrapper is case of visionOS (Apple Vision Pro operating system), where SwiftUI is the only UI framework available for UI development. There's not UIKit, AppKit, WatchKit, or any other previous UI frameworks in this OS. It means that, in this platform, the SwiftUI runtime will always decide to create the UI components from zero.

Commonly Mentioned Advantages of SwiftUI (That May Not Be True)

As I mentioned in the Introduction, most of the engineers understand that SwiftUI is better than UIKit, but sometimes they struggle to explain why. Below I'll cover some of the usual mentioned advantages and why they're sometimes incorrect or incomplete.

Declarative Syntax is Better

The Xcode Interface Builder (the tool to manipulate storyboards and .xib files) has several flaws: bad performance, merging difficulty, code review difficulty, and more. So SwiftUI clearly have an advantage over it, where you can write the code for the UI. However, you can also to the same in UIKit, with ViewCode. If you want to learn more about that, I have a post about how to use ViewCode with UIKit.
That said, what is commonly said as a SwiftUI benefit over UIKit is the declarative syntax: instead of "saying" to the UI do something (UIKit's imperative syntax), you say how it should look/behave. That is mostly true, but let's analyze two equivalent implementations in both frameworks:

UIKit:

let label = UILabel()
label.text = "Hello, World!" // Set the text to "Hello, World!" now. (Imperative)
label.textColor = .red // Set the text color to red now. (Imperative)

SwiftUI:

Text("Hello, World!") // You should've a text "Hello, World!". (Declarative)
    .foregroundColor(.red) // The color of the text should be red. (Declarative)

Can you really say that the second one is easier to be written? At least, easier enough for worthing using a totally new technology in your app?
It's true that in UIKit you "order" the framework to do things, in an imperative way, while in SwiftUI you tell it how it should behave when it is rendered, but why the second option is better? Just saying "SwiftUI is better because it's declarative" means nothing if you don't understand what being declarative really changes. Also, some imperative codes can have a similar complexity than declarative ones. We'll see in a bit when it really matters.

Xcode Preview

The Xcode Preview is a very cool tool (when it works) that shows you how your view looks like while you are creating it, "without" needing to build and launch the app to see the changes (actually Xcode performs a basic build process to display the preview, but it's very much faster than a regular app build).
I'll not explore the fact that Xcode Preview is very unstable, you probably already experienced that, but there's something that I'd like to mention that a lot of people don't know: Xcode Preview supports UIKit and AppKit, natively!
Yes, that's right, no workarounds, Xcode just supports it. You can check it here in Apple Developer Documentation. Since Xcode 15, you can use the #Preview macro to return an UIView or even an UIViewController object that the preview will display it.

So if you're choosing SwiftUI because "it has previews", maybe you're choosing that for the wrong reasons.

SwiftUI Is More Future-Proof

SwiftUI is already the official Apple way of writing UI for apps in all platforms. I feel that what we are experiencing with SwiftUI and UIKit nowadays is similar (but not equal) to the transition between Objective-C and Swift. Objective-C is still supported today, but it's considered a legacy technology.
However, while SwiftUI is becoming more robust and stable at each version, UIKit keeps pretty reliable, receiving updates and improvements, as the ones in the last WWDC. Starting a new app with UIKit nowadays can be considered a good idea, depending on some variables. But specially learning it, I'd say that is essential.

Reactivity

Another common advantage of SwiftUI over UIKit mentioned is Reactivity. In SwiftUI you can write Reactive Code, using States and Observed/Observable Objects. That's a totally new paradigm that is not natively present in UIKit, where you needed to imperatively set the state to the view, instead of binding a view to a state.

UIKit:

var myText = "Hello, World!"

label.text = myText

SwiftUI:

@State
var myText = "Hello, World"

Text(myText)

1. Binding vs Setting

Again, simply saying that in SwiftUI you bind state to the view instead of imperatively setting it, isn't enough to convince that it's better. It's important to know what data binding really brings to development process.

2. You can write Reactive code in UIKit

In UIKit, it's possible to write code that "reacts" to the state change:

var myText = "Hello, World!" {
    didSet {
        label.text = myText 
    }
}

The implementation above is simple and a little limited, but it's also possible adding reactiveness to your code using more robust design patterns, as Observer and Notification. Also, you can use some libraries, such as Combine, or yet the combination of RxSwift with RxCocoa to implement Reactive Code. The later allows you to bind state changes to the UI components, similar to what you do in SwiftUI.

What Being Declarative Really Means to SwiftUI

We just saw that simply saying that in declarative code you tell the OS how the view should look instead of asking it to do things isn't enough to convince that it's better.
For me, one of the main differences between the declarative syntax of SwiftUI and the UIKit's imperative one is the responsibility of holding the views instances. Let's compare two different similar codes, one in each framework

UIKit:

final class HomeViewController: UIViewController {
    // I need to store the UILabel instance in a property somewhere, a concern that I don't have in SwiftUI
    lazy var label: UILabel = {
        let label = UILabel()
        label.text = "Hello, World!"

        return label
    }()

    override func viewDidLoad() {
        // The "effort" of adding the label to view hierarchy here is similar to SwiftUI
        view.addSubview(label)
    }
}

SwiftUI:

struct HomeView: View {
    var body: some View {
        // Doing this is "so hard as" adding a subview in UIKit, but here I don't need to worry about holding a reference of `Text`
        Text("Hello, World!")
    }
}

In SwiftUI, the framework completely handles the components lifecycle, being able to reuse or simply discard it without any interaction of the developer. In UIKit on the other hand, the developer is responsible for creating, holding and sometimes deallocating these objects manually.
Also, in UIKit they are responsible for programming when all these things happens. For example: in the piece of code above, the UILabel object was created in a lazy variable, which is a good strategy to improve memory usage. In SwiftUI the developer simply doesn't need to think about it. In the newer framework, the views are value types, which eliminates the concern about allocation/deallocation.

In my opinion, that's something that makes SwiftUI really different from UIKit.

Updating the View

Another great example of a difference that the declarative syntax allows SwiftUI to have is the way that the framework updates the view. In UIKit, the developer explicitly say what should change in the view (as reloading a CollectionView, for example). In SwiftUI, the declarative syntax allows the framework decides which strategy it will use to update the view. We'll see that in details in the Diffing Algorithm section.

Reactivity

As I said, you can have reactive code in UIKit. But the thing with SwiftUI and Reactivity is that in SwiftUI, this concept is already built-in. You don't need to implement any design pattern from scratch, such as Observer, Notification or even using frameworks as RxSwift and Combine.
The UI framework has already a default implementation (@State and/or @StateObject), designed to work properly with the UI framework. The Reactivity in SwiftUI eliminates the need of managing subscriptions, lifecycle of observable objects and drastically reduces the effort to avoid data races.
So SwiftUI isn't better than UIKit because it supports reactive programming, it is better because in SwiftUI, reactivity is easier. For example, these two code examples are conceptually equivalent:

UIKit:

import UIKit
import RxSwift  
import RxCocoa

class MyCollectionViewCell: UICollectionViewCell {  
    private let disposeBag = DisposeBag()  
    private let countRelay = BehaviorRelay<Int>(value: 0)  
    var countObservable: Observable<Int> {
        return countRelay.asObservable()
    }

    private let countLabel: UILabel = {
        // ...
    }()

    private let incrementButton: UIButton = {
        // ...
    }()

    private func incrementCount() {
        // Thread-safe modification of the relay
        let newValue = countRelay.value + 1
        countRelay.accept(newValue)
    }

    override init(frame: CGRect) {
        super.init(frame: frame)
        setupUI()
        setupBindings()
    }

    private func setupUI() {
        // Add views to hierarchy and add constraints
    }

    private func setupBindings() {
        // Button taps increment the relay (main thread guaranteed by RxCocoa)
        incrementButton.rx.tap
            .observe(on: MainScheduler.instance) // Ensure main thread
            .subscribe(onNext: { [weak self] in
                self?.incrementCount()
            })
            .disposed(by: disposeBag)

        // Label reacts to relay changes (main thread guaranteed)
        countRelay
            .observe(on: MainScheduler.instance)
            .map { "\($0)" }
            .bind(to: countLabel.rx.text)
            .disposed(by: disposeBag)
    }  

    override func prepareForReuse() {
        super.prepareForReuse()

        // Create a new dispose bag to cancel all subscriptions
        disposeBag = DisposeBag()

        // Reset UI to default state
        countLabel.text = nil
    }
}

SwiftUI:

import SwiftUI

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

    var body: some View {
        VStack {
            Text("\(count)")

            Button("Increment") {
                count += 1
            }
        }
    }
}

In both examples we have a label, that displays a integer value stored in views' state, and a button that increments it. In both examples, the label reacts to the state changes, and the button modifies the state. But the amount of code to achieve it is completely different.

Observe that, in the UIKit example, since we are inside an UICollectionViewCell, we should take care of holding the subscriptions in the cell instance, since the dequeue strategy will reuse the same object. So it's needed to reset the disposeBag under the prepareForReuse(). In SwiftUI, since the view is a value type, you don't need to think about object reuse. For the newer framework, it's easier to simply destroy and recreate the view when needed.

`ViewModifiers` vs properties of `UIView` objects

One of the key differences between SwiftUI and UIKit lies in how we change the appearance and behavior of views. In UIKit, views are mutable — you can directly change the properties of a UIView instance. For example, setting view.backgroundColor = .red modifies the same view object in memory. In SwiftUI, on the other hand, views are immutable:

To add styling to views in SwiftUI, we need to use ViewModifiers. When you apply a ViewModifier like .padding() or .background(), you're not modifying the original view — you're creating a new view that wraps the previous one, with the modifier applied. Each chained modifier returns a new view value, building up a view hierarchy in a declarative way.

Because of this, the order in which you apply modifiers matters. For instance, .background(Color.red).padding() will produce a different layout than .padding().background(Color.red), because each modifier wraps the result of the previous one.

That happens because, in the first case, the background is applied over the current computed view size (100x100), and then a padding is applied to a view that already have a red background of this size. In the second case, the padding() modifier creates a new view, that is bigger than the original one, and the background is applied to this new view.

This immutability characteristic enables SwiftUI to use a smart rendering system under the hood — the Diffing Algorithm.

Diffing Algorithm

Because SwiftUI views are value types, they don’t hold identity in the traditional sense. Instead, SwiftUI needs to compare the old and new view hierarchies to determine what actually changed between frames. This process is handled by its internal diffing algorithm.

The goal of the diffing algorithm is to compute the minimal number of changes needed to bring the current view tree in sync with the new one — avoiding unnecessary work, re-renders, or animations.

Let’s look at a simple example:

// Initial state
VStack {
    Text("A") // ID: 1
    Text("B") // ID: 2
}

// Updated state
VStack {
    Text("C") // ID: 3 (new)
    Text("B") // ID: 2 (already exists)
}

How SwiftUI "sees" the view state:

Initial View Hierarchy:           Updated View Hierarchy:

VStack                            VStack
├── Text("A") [ID: 1]             ├── Text("C") [ID: 3] ← inserted
└── Text("B") [ID: 2]             └── Text("B") [ID: 2] ← reused

In this case, when the state changes SwiftUI will:

Recreate the entire view state tree (not the rendered view hierarchy yet).
Compare both trees.
Recognize that the Text("B") with ID 2 is still present, so it does nothing to that view.
Identify Text("A") (ID 1) is no longer in the hierarchy and remove it from the view.
Add Text("C") (ID 3) view at the beginning.

💡 Tip: SwiftUI automatically creates IDs for views. However, when views are inside a ForEach, you need to manually assign an .id() to each item. Assigning a unique and stable value helps SwiftUI perform a smarter diff. Without proper IDs, SwiftUI may destroy and recreate views unnecessarily, or yet not recreate them when necessary.

This behavior is completely different compared to UIKit, where you manually update existing views or remove/add them yourself. SwiftUI’s declarative model and diffing engine let you focus on what the UI should look like, and the framework handles how to get there behind the scenes in the best way (if you don't introduce any bad practice, as mentioned, if you mess with the views IDs, for example, the framework may won't be able to perform the best action).

But even this happens in a kind of a black box², understanding this diffing logic helps avoid common pitfalls like unexpected animations, performance hiccups, or views resetting their internal state.

Let’s now consider a slightly more dynamic scenario using ForEach, where SwiftUI needs to reconcile a list of items that change over time:

// Initial state
struct ContentView: View {
    var items = ["A", "B"]

    var body: some View {
        VStack {
            ForEach(items, id: \.self) { item in
                Text(item)
            }
        }
    }
}

Then, the items property is updated to:

var items = ["C", "B"] // "A" removed, "C" inserted at index 0

Visual diff:

Initial View Hierarchy:           Updated View Hierarchy:

VStack                            VStack
├── Text("A") [ID: "A"]               ├── Text("C") [ID: "C"] ← inserted
└── Text("B") [ID: "B"]               └── Text("B") [ID: "B"] ← reused

Because we provided .self as the identifier, SwiftUI can track each item’s identity based on the string value itself. It reuses "B", inserts "C", and removes "A" — all without us writing a single line of imperative code.

UIKit comparison: manual diffing

To accomplish the same thing in UIKit, you’d typically need a UICollectionView or UITableView, and manually compute the diff between the old and new data. For example:

collectionView.performBatchUpdates {
    // Manually calculate differences
    collectionView.deleteItems(at: [IndexPath(item: 0, section: 0)])
    collectionView.insertItems(at: [IndexPath(item: 0, section: 0)])
} completion: { _ in
    // Completion handler
}

That’s a lot more code, and a lot more chances to get things wrong — like forgetting to update the data source or mismatching index paths.

With SwiftUI, the framework does the diffing and view recycling for you, based solely on the new state you declare. The end result is often cleaner code, better performance, and fewer bugs.

When identifiers are not stable

Imagine this example, where each item is assigned a new UUID() on every render:

struct ContentView: View {
    var items = ["A", "B"]

    var body: some View {
        VStack {
            ForEach(items, id: \.self) { item in
                Text(item)
                    .id(UUID()) // ⚠️ bad: forces recreation every time
            }
        }
    }
}

Even though the data looks the same (["A", "B"]), every time SwiftUI recreates the view state tree the elements are created with different identifiers, leading the framework understand that the state changed. Here's how the view hierarchy behaves:

First render:                   Second render (same data!):

VStack                          VStack
├── Text("A") [UUID: 123]       ├── Text("A") [UUID: 456] ← new
└── Text("B") [UUID: 124]       └── Text("B") [UUID: 457] ← new

This means that SwiftUI will render all the views again, impacting in animations, losing state (like focus or selection), and impacting in performance.

When identifiers are not unique

Now imagine the opposite case: the id is stable, but not unique. This can happen when using a property like name as the identifier, which might be shared between multiple items:

struct Person: Identifiable {
    var id: String { name } // ⚠️ bad: name might not be unique
    let name: String
    let age: Int
}

struct ContentView: View {
    let people = [
        Person(name: "Alice", age: 30),
        Person(name: "Bob", age: 40),
    ]

    var body: some View {
        List(people) { person in
            VStack(alignment: .leading) {
                Text(person.name)
                Text("Age: \(person.age)")
            }
        }
    }
}

Let’s say your data source changes — Alice is replaced by another Person with the same name but different age:

let updatedPeople = [
    Person(name: "Alice", age: 25), // new person, same name
    Person(name: "Charlie", age: 35),
]

Since SwiftUI is using name as the ID, it thinks this is still the same "Alice" and reuses the view — but the data is different. Here's what happens:

Before update:                   After update (wrong!)

List                             List
├── Alice (age: 30) [id: Alice]  ├── Alice (age: 30) [id: Alice] ← ⚠️reused!
└── Bob (age: 40) [id: Bob]      └── Charlie (age: 35) [id: Charlie]

Even though the second Alice is 25, the view still shows the old age (30), because the view wasn’t updated — SwiftUI didn’t detect a difference due to the reused ID.

This kind of issue can lead to:

Outdated UI being shown (like wrong values),
Logic bugs if you're relying on @State or user interactions,
Hard-to-diagnose issues during animations or reordering.

Solution: ensure your IDs are both stable and truly unique, such as:

struct Person: Identifiable {
    let id: UUID
    let name: String
    let age: Int
}

That way, SwiftUI correctly understands when to reuse and when to rebuild, keeping your UI accurate and your state consistent.

Runtime Render Decision

SwiftUI doesn't commit to a single rendering strategy. At runtime, it decides how each view will be rendered based on things like hardware resources (e.g., GPU availability for Metal), view complexity, and the platform itself. For example, visionOS doesn’t even offer UIKit or AppKit — so SwiftUI uses entirely different mechanisms behind the scenes.

This means that the same SwiftUI code can result in different implementations depending on the context.

Take this example:

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

Inspecting this with Xcode’s View Hierarchy tool shows that the system used a CGDrawingView. There’s no UILabel, no UIKit — just SwiftUI rendering directly.

Now compare that to this:

typealias Item = (id: String, title: String)
@State var data = Array(
    repeating: Item(
        id: UUID().uuidString,
        title: "Hello!"
    ),
    count: 1000
)

var body: some View {
    VStack {
        List(data, id: \.id) {
            Text($0.title)
        }
    }
}

In this case, SwiftUI falls back to UIKit. The View Hierarchy reveals a UICollectionView being used under the hood. The same app, in the same device, but a completely different runtime behavior. The system evaluated the size and complexity of the data and chose the most efficient path.

So that debunks the myth that SwiftUI is built on top of UIKit, and also explain why people think that: sometimes, SwiftUI can decide for using UIKit, but that is not always the case.

Conclusion

SwiftUI and UIKit are fundamentally different tools, not just in syntax but in philosophy and runtime behavior. In this article, we explored and clarified key distinctions to go beyond surface-level comparisons.

Here’s a summary of what we covered:

The misconception that SwiftUI is just a “prettier” way to write UIKit code.
UIKit’s imperative approach vs. SwiftUI’s declarative and reactive nature.
The role of state management and how SwiftUI uses it to drive UI updates automatically.
Differences in lifecycle and rendering control between UIKit and SwiftUI.
How SwiftUI can and cannot use UIKit under the hood, and that this is decided in runtime.

Understanding these differences is key, not to have a favorite, but to correctly argue which framework is better depending on your project scenario. SwiftUI isn't just the future because it's new or cool, it's the future because it enables a more scalable way of thinking about UI. However, UIKit remains relevant and powerful, especially in contexts that demand fine-grained control. Understanding the mechanics of both frameworks empowers the developer in making a better choice.

References

Swift Testing: My First Impressions

Raphael Martin — Fri, 04 Apr 2025 14:30:00 +0000

Introduction

Recently, I posted here an Introduction to Swift Testing: Apple's New Testing Framework, in which I talked about the framework features and specially about the differences compared to XCTest (most improvements). Since then, I've been testing it a lot — no pun intended — in personal projects and I could create personal impressions about Swift Testing. Unfortunately, I didn't have the opportunity to use it in commercial projects yet, but with I have so far I think it's worth a post about my findings.
If you didn't read the introduction post yet, I highly recommend you reading it first, since here I'll skip the basics and consider you already know how Swift Testing works.

Testing Asynchronous Code

Something that I didn't cover in my first post about Swift Testing is testing asynchronous code. Testing code with with async/await is so easy as testing synchronous code. You just need make your testing function async, and you are able to use await wherever it's needed:

@Test("Test that calling the backend endpoint fetches data") 
func testBackend() async {
    let apiClient = ApiClient()
    let data = await apiClient.fetchDataFromBackend()
    #expect(!data.isEmpty)
}

This is cool because it encourages you to update your logic to the async/await paradigm. But if you use another approach to handle asynchronous execution, you'll have some more work to test it with Swift Testing.

While in XCTest we had the expectations to test asynchronous code, Swift Testing doesn't provide any specific tool/structure to do the same. What you need to do is to use the native Swift withCheckedContinuation or withCheckedThrowingContinuation functions. Let's see an example with a function with completion handler:

Function to be tested:

func auth(with credentials: Credentials, completion: @escaping (Result<Void, NetworkError>) -> Void) -> URLSessionTask {
    // ...
}

Test:

@Test("Test that calling the auth endpoint stores the JWT") 
func testAuth() async throws {
    let apiClient = DummyJSONAPIClient()
    let credentials = Credentials(username: "emilys", password: "emilyspass")

    await withCheckedContinuation { continuation in
        let _ = apiClient.auth(with: credentials) { result in
            if case .success = result {
                #expect(apiClient.jwt != nil)
            } else {
                Issue.record("Authentication Failed")
            }

            continuation.resume()
        }
    }
}

This code is copied from my last post about Creating a Network Layer with URLSession in Swift. Check it out!

Here we just mark our testing function with async and use withCheckedContinuation to "convert" the completion handler approach in async/await. You could do the same thing to test code with Promises, reactive frameworks (as Combine and/or RxSwift) or any other asynchronous context.

I find this approach very cool and compliant with the "idea" of Swift Testing being a very swifty framework. You don't use any framework-specific structure to handle asynchronous execution, you just do it the way the language provides it to do.

Explicitly Failing Tests

In the previous post, I talked about how Swift Testing replaces all the XCTAssert<Something> functions from XCTest with the single #expect macro. Instead of having multiple functions to each kind of comparison we need to do, the #expect macro receives a boolean, allowing the developer to pass the desired condition to it. But something that I missed in the last post is when you need to purposely make the test fail. This happens usually with types that cannot be used in conditions, as Results and enums:

apiClient.auth(with: credentials) { result in
    #expect(result == .success)
    // ❌ Cannot convert value of type 'Result<Void, NetworkError>' to expected argument type 'DispatchTimeoutResult'
}

In that case, you need to use other strategies to check the result value, and then decide if the test should pass or fail:

switch(result) {
case .success():
    // ✅ Pass the test
case .failure(_):
    // ❌ Fail the test
}

For passing the test, nothing really needs to be done. A test without any #expect ran is considered a passed one. But for failing, you'll need to add an explicit instruction. The most obvious one would be #expect(false), and it works, but Xcode will give you an warning saying that the expectation will always fail:

case .failure(_):
    #expect(false)
    // ⚠️ '#expect(_:_:)' will always fail here; use 'Bool(false)' to silence this warning (from macro 'expect')

The warning itself already gives you the solution for that: using Bool(false) instead of false:

case .failure(_):
    #expect(Bool(false))

The warning is now gone, however there's also another way to make the test fail, that in my opinion is better and more legible: using the static Issue.record(_) function:

case .failure(_):
    Issue.record("Authentication Failed")

Why I think it's better: it's mandatory adding a comment. This comment will appear in the test logs, helping you identify why a test is failing in a CI/CD environment, for example. Also, it's easier for other people understand why you are failing that test. Also, every expectation that fails calls the Issue.record function under the hood. But when using a #expect(Bool(false)), the message passed will be a generic one, generated by the framework.

Known Issue About Recording Tests Issues

At the moment I write this post, there's an open issue about issues recording in detached tasks. It's reported in Swift Testing Github Issues, but actually it seems to be a problem with Xcode, and not with the framework itself.
The issue is that when a test fail in a detached task (for example in the async response of a network call), Swift Testing crashes. That happens because in this async context, Swift Testing isn't able to detect for which test that error recording is.
This problem has relation with a very interesting Swift Testing feature: parallel execution. Swift Testing by default uses Swift Concurrency to execute tests in parallel, optimizing performance. The problem is that, since multiple tests can be running at same time, in a detached task is hard to know which test created that task.

Build Time Performance

That's something that I didn't really test, but I read in many places about: Swift Testing seems to have a worse perfomance in the build process compared to XCTest.
In June of 2024, people were reporting that build time could be 24x slower compared to XCTest.
There are some reasons for that, but the main one is that Swift Testing highly rely on Macros. If you don't know, Macros are "shortcuts" to bigger chunks of code. Examples of it in Swift Testing are @Test, #expect and #require. This process of converting the macro identifier into its corresponding code is called expansion. And expanding macros has a cost in build time.

Good News

The good news are that this PR and this PR from July of 2024 introduced a performance optimization to the build process, which made it 2.6x times faster, being more close to XCTest performance. We'll probably see more optimizations like these in future.

Overall Opinion

Swift Testing seems to be very promising, and I see Apple making it the official way of writing Unit Tests in near future. However you should be aware that it's a new technology, and some problems needs to be addressed. Also, it's an open-source framework managed by the Swift team, so some integrations with Xcode can be faced in short-term.

Additional Resources

Creating a Network Layer with URLSession in Swift

Raphael Martin — Fri, 28 Mar 2025 14:30:00 +0000

Introduction

Almost all the mobile apps needs to access the internet. In Swift, you can use the URLSession API for network related tasks, such as consuming web services or downloading files (as images to be displayed in the UI).
It's very easy to perform a simple network call, but you likely won't be limited to those. In a real app, it's needed to create robust solutions to complex network logic: modularity, thread-management, error handling, cancellation and more. Creating a network layer then could be the best choice in this case. Let's see how to do without any third-part library.

What is `URLSession`

URLSession is a class, part of the URL Loading System, a collection of APIs present in Swift Foundation to interact with web servers through URLs. There are other classes in this collection, as URLSessionTask and URLSessionConfiguration that are also important when working with networking, but URLSession objects are the most fundamental structure to handle this kind of tasks.

Creating tasks from URL sessions - Apple Developer - URL Loading System

The URLSession has a Singleton instance with a basic configuration, that can be used for simple calls, let's see an example consuming the Cat Fact API

let url = URL(string: "https://catfact.ninja/fact")

let task = URLSession.shared.dataTask(with: url!) { (data, _, _) in
    guard let data, 
          let stringResponse = String(data: data, encoding: .utf8) else {
        print("Invalid response")

        return
    }

    print("The task finished with response: \(stringResponse)")
}

task.resume()

print("The task started to being executed")

Analyzing the code above:

We create an URL object using the initializer from a String. This initializer creates an Optional value;
We call the dataTask(with:) function of the URLSession singleton object. This method receives an URL object and a completion handler as arguments. The later will be executed when the request is finished. The function returns an object of type URLSessionDataTask;
With task.resume() we are manually starting the task execution, that will be performed asynchronously, in a background thread. We can also cancel the network request at any time before its completion, by calling task.cancel(). We're seeing more of that later in this article.

Thread management

As mentioned in the previous section at item 3, the dataTask(with) function automatically executes the network call on a background thread:

URLSession.shared.dataTask(with: url!) { (data, _, _) in
    print(Thread.isMainThread ? "Is Main Thread" : "Not Main Thread")
}.resume()

Console Output:

Not Main Thread

That's because requests are heavy tasks, and not executing them in a background thread can lead to a bad UX, since the UI is handled in the main thread by default. Executing heavy tasks in the main thread makes the UI freeze until the task is completed. However, if you need to display a network response in the view, you'll need to manually perform that task of updating the UI in the Main Thread, otherwise you can face issues:

import UIKit

lazy var label: UILabel = {
    // ...
}()

URLSession.shared.dataTask(with: url!) { [label] (data, _, _) in
    guard let data,
          let stringResponse = String(data: data, encoding: .utf8) else {
        print("Invalid response")

        return
    }

    label.text = stringResponse // Runtime warning: ⚠️ Unable to encode UIView on a non-main thread
}.resume()

In order to make that work, you'll need some strategy to guarantee that label.text = stringResponse is executed on the Main Thread, for example:

DispatchQueue.main.async {
    label.text = stringResponse
}

Why Creating a Separate Layer

We could observe that thread management is an important subject to take care when dealing with network, that can become complex. Also, authentication, error handling and resources management are so important. Having a separate layer only to deal with networking logic is a good way to have more isolated and agnostic business logic.
Imagine a scenario where you need to store some data in your app. Initially, you decide to store it locally, but in a future version this data will be sent to a backend service. Using abstraction helps this future refactor:

let userService: UserService = LocalStorageUserService()

func save(user: User) async {
    await userService.save(user)
}

The piece of code above is about business logic. In future, if you want to create an APIUserService, you can isolate everything related to network inside the network layer, and the usage of it in your business code will be the same.

Another reason for creating a network layer is sharing logic between apps. You may have multiple apps that consumes a same service, then you can create a package with all the requirements for that specific service, and share across all apps.

Creating the Network Layer

We'll now start creating our Network Layer. This implementation above is just a suggestion, that should be adapted to the reality of your project. There's no "right way" to do it, but it's a good starting point. We are going to split our Network Layer in some steps: API Client, Authentication, Endpoint Model, Service Abstraction, Concrete Service, Error Handling and Cancellation.

We are using DummyJSON for that, that is a public API with several different endpoints, ideal for studying how to create API clients (such as mobile apps, websites and more).

API Client

The first structure we are creating is the API Client. Here, we can consider that a single app can have multiple API integrations, so we’re making it as generic as possible. The DummyJSON API is a REST service that uses JWT as authentication method, so we can start with an abstraction like that:

import Foundation

protocol JWTAPIClient {
    var baseURL: URL { get }
    var jwt: String? { get }

    func auth(with credentials: Credentials, completion: @escaping (Result<Void, Error>) -> Void) -> URLSessionTask
}

struct Credentials: Codable {
    var username: String
    var password: String
}

Here we have a protocol that holds the value of the API URL, such as the current JWT token. It also has a signature for a function that performs the API authentication.
The auth function receives as first argument the credentials object, and a completion handler as second argument. The later is an escaping closure, with a Void return type that receives a Result of Void and Error. Since the execution of the network call is an asynchronous task, that has an uncertain result (it can succeed or fail), it's important to create this completion handler with this parameter.

That's a definition for an API Client that uses JWT authentication, it can be used for different API integrations, but now we are creating the one for consuming the DummyJSON API:

import Foundation

final class DummyJSONAPIClient: JWTAPIClient {
    var baseURL: URL {
        URL(string: "https://dummyjson.com/")!
    }
    var jwt: String?

    func auth(with credentials: Credentials, completion: @escaping (Result<Void, any Error>) -> Void) -> URLSessionTask {
        // authentication logic here
    }
}

We just created a DummyJSONAPIClient class that conforms to JWTAPIClient. The idea of the auth function is to receive credentials, authenticate and store the received JWT to be used in restricted calls. We'll implement all that logic in a bit.

Authentication

Now, we're going to implement the authentication logic. Reading the DummyJSON documentation, we can notice that the auth/logic endpoint can be used to authenticate, and the auth/me endpoint is an example of a restricted service, that needs to receive a valid JWT token to work. Let's focus in the first endpoint, adding implementation to the DummyJSONAPIClient.auth function. We'll create an URLRequest object to perform this call:

func auth(with credentials: Credentials, completion: @escaping (Result<Void, any Error>) -> Void) -> URLSessionTask {
    var url = baseURL
    url.appendPathComponent("auth/login")

    var request = URLRequest(url: url)
    request.httpMethod = HTTPMethod.POST.rawValue
    request.setValue("application/json", forHTTPHeaderField: "Content-Type")

    request.httpBody = try? JSONEncoder().encode(credentials)
}

enum HTTPMethod: String {
    case GET
    case POST
    case DELETE
    case PUT
    case PATCH
}

In the piece of code above, we did the following:

Created a copy of baseURL and added the authentication endpoint path to it
Created an URLRequest object with the auth endpoint URL
Set the HTTP method to POST, following the documentation
Set the Content-Type header to application/json
Set the request body with the credentials value. Notice that it is being encoded in JSON

Creating the response model

Another thing that we can verify on DummyJSON documentation is the expected response for the authentication service.

{
  "id": 1,
  "username": "emilys",
  "email": "emily.johnson@x.dummyjson.com",
  "firstName": "Emily",
  "lastName": "Johnson",
  "gender": "female",
  "image": "https://dummyjson.com/icon/emilys/128",
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refreshToken": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

We can now create a struct to decode the response data:

struct AuthResponse: Codable {
    let id: Int
    let username: String
    let email: String
    let firstName: String
    let lastName: String
    let gender: String
    let image: String
    let accessToken: String
    let refreshToken: String
}

Notice that conforming to the Codable protocol is important to use the decoders in future.
Now that we have a model to decode our response, we can add the code to perform the network call. We should add this piece of code just below our URLRequest creation, inside the auth function:

let task = URLSession.shared.dataTask(with: request) { [weak self] data, response, error in
    if let error {
        completion(.failure(error))

        return
    }

    guard let data else {
        // TODO: Handle this scenario in future
        print("Nil data")

        return
    }

    guard let authResponse = try? JSONDecoder().decode(AuthResponse.self, from: data) else {
        // TODO: Handle this scenario in future
        print("Failed to decode JSON")

        return
    }

    self?.jwt = authResponse.accessToken

    completion(.success(()))
}

task.resume()

return task

The dataTask(with:) function performs the network call asynchronously, with the giving URLRequest object, and return a URLSessionTask object. Inside the completion handler that is being passed, it's being executed the following actions:

Checking if the error object is not nil, and if it isn't, failing the completion result
Unwrapping the data variable (the error handling for when it's nil is not implemented yet)
Trying to decode the JSON response to the model we just created
Storing the received token in the client instance to be used in future

Endpoint Model

Now that we have an working authentication method, we can start creating our Endpoints. First, we'll create a generic representation of any endpoint, then we'll create one different object for each endpoint that our app will consume. Let's see the generic one first:

protocol Endpoint {
    // The path for the endpoint. This is the part of the URL after the host of the API
    var path: String { get }
    // Headers to be sent in the request
    var headers: [String: String]? { get }
    // The HTTP method for this endpoint
    var method: HTTPMethod { get }
    // Parameters sent in the request body. It can't be used in `GET` requests
    var bodyParameters: [String: Any?]? { get }
    // Parameters sent in the URL.
    var queryParameters: [String: String]? { get }
}

This protocol defines all properties an endpoint might need. So now, we can create our concrete representation of an endpoint. Let's start with the GET auth/me one:

struct GetCurrentUserEndpoint { }

extension GetCurrentUserEndpoint: Endpoint {
    var path: String { "/auth/me" }
    var method: HTTPMethod { .GET }

    var headers: [String : String]? {
        nil
    }

    var bodyParameters: [String : Any?]? {
        nil
    }

    var queryParameters: [String : String]? {
        nil
    }
}

Observe that this endpoint doesn't require any specific value in the headers, body, neither query, so we need to implement the protocol properties returning nil. It's very common that we have several endpoints that doesn't need these properties. But the path and method are always mandatory. So we can apply an improvement to that architecture, adding default values to the protocol:

extension Endpoint {
    var headers: [String: String]? {
        nil
    }

    var bodyParameters: [String: Any?]? {
        nil
    }

    var queryParameters: [String: String]? {
        nil
    }
}

Then our specific endpoint now can be as simple as that:

struct GetCurrentUserEndpoint { }

extension GetCurrentUserEndpoint: Endpoint {
    var path: String { "/auth/me" }
    var method: HTTPMethod { .GET }
}

Service Abstraction

We are now creating a simple abstraction to services in general. It will be just a protocol that requires the service to receive an API client, we're calling it NetworkService:

protocol NetworkService {
    var apiClient: JWTAPIClient { get }
}

The next step will be adding a new function to our generic JWTAPIClient. Just below the auth(with:credentials) function, we'll add a function to perform calls to endpoints. This is the signature in the protocol:

protocol JWTAPIClient {
    // ...

    func request(from endpoint: Endpoint, completion: @escaping (Result<Data?, Error>) -> Void) -> URLSessionTask
}

Then we can adapt our concrete DummyJSONAPIClient class to implement the new required method:

final class DummyJSONAPIClient: JWTAPIClient {
    // ...
    func request(from endpoint: any Endpoint, completion: @escaping (Result<Data?, any Error>) -> Void) -> URLSessionTask {
        var url = baseURL
        url.appendPathComponent(endpoint.path)

        var request = URLRequest(url: url)
        request.httpMethod = endpoint.method.rawValue
        request.setValue("application/json", forHTTPHeaderField: "Content-Type")

        if let jwt = jwt {
            request.setValue("Bearer \(jwt)", forHTTPHeaderField: "Authorization")
        }

        let task = URLSession.shared.dataTask(with: request) { data, response, error in
            // Completion implementation here
        }

        task.resume()

        return task
    }
}

Look how similar to the auth(with:credentials) function it is, but with some more generic implementation:

A copy of baseURL is made
A path component is added to it, but now the endpoint.path instead of a hard-coded "auth/login" string
The HTTP method is also set from what is received from the endpoint object, instead of a hard-coded value

Everything else is pretty the same, except by the Authorization header, that we are sending with the stored value from the authentication. That's what will make our restricted calls work.

Now, we are going to add the implementation to the completion handler. We should replace the // Completion implementation here with:

if let error {
    completion(.failure(error))

    return
}

completion(.success(data))

Now we have our base request function, and we are able to create the specific one.

Concrete Service

We are almost done with the creation of the logic to fetch the Get current auth user endpoint. Similar to what we did for the authentication method, we need to create a model to decode the endpoint response. We are creating this one, that doesn't support all the attributes in the response, but it is enough for our purpose today:

struct UserResponse: Codable {
    let id: Int
    let firstName: String
    let lastName: String
    let maidenName: String
    let age: Int
    let gender: String
    let email: String
    let phone: String
    let username: String
    let password: String
    let birthDate: String
    let image: String
    let bloodGroup: String
    let height: Double
    let weight: Double
    let eyeColor: String
}

Now it's time to create our concrete implementation of our service, that we're calling UserService. It should conform with our NetworkService protocol:

final class UserService: NetworkService {
    var apiClient: JWTAPIClient

    init(apiClient: JWTAPIClient = DummyJSONAPIClient()) {
        self.apiClient = apiClient
    }
}

We can create functions for each user-related endpoint we want to fetch in our API inside this class. Let's create one in an extension, for code organization purposes:

// MARK: Endpoints
extension UserService {
    func currentUser(completion: @escaping (Result<UserResponse, Error>) -> Void) -> URLSessionTask{
        let endpoint = GetCurrentUserEndpoint()

        let task = apiClient.request(from: endpoint) { [weak self] result in
            // Completion implementation here
        }

        return task
    }
}

I'll break up the code above now:

A GetCurrentUserEndpoint object is created
The API client request(from:) function is called passing the desired endpoint, storing locally the URLSessionTask that it creates
The task is returned to be handled for who is calling it

We can create other functions inside services very similar to this one, just changing the endpoint object we are passing to the request(from:) function, to make requests to any endpoint in our API.

The request(from:) function calls the completion handler with some Data received from the web service, and we need to decode it to our UserResponse. Let's create a function to it:

// MARK: Decoding
extension UserService {
    private func decodeUser(from data: Data) -> UserResponse? {
        do {
            let decoder = JSONDecoder()

            /* 
            You can add here specific rules to your decoder if needed, 
            such as date/time format
            */

            return try decoder.decode(UserResponse.self, from: data)
        } catch {
            print("Failed to decode user: \(error)")
            return nil
        }
    }
}

Let's now implement the response handling of our call, just replacing // Completion implementation here in the currentUser() function with:

switch result {

case .success(let data):
    // TODO: Handle error
    guard let self else { return }

    // TODO: Handle error
    guard let data else { return }

    // TODO: Handle error
    guard let userResponse = self.decodeUser(from: data) else { return }

    completion(.success(userResponse))

case .failure(let error):
    completion(.failure(error))
}

We have now all the needed code to retrieve the data of the current authenticated user.

Error Handling

It's very important to create strategies for when requests fail. Especially in mobile apps, where connectivity can be more unstable.
Our first step will be creating a custom enum for possible errors that we may face. Let's use this one for now:

enum NetworkError: Error {
    case dataTaskError(Error)
    case systemError(String)
    case emptyData
    case decodingError(String)
    case httpError(Int)
}

Just scanning our current project and enumerating the TODOs it was possible to identify these failing situations. Note that some cases receives an argument, with details about the issue.

Let's refactor our current code to make our Network Layer throw the desired errors. First, we'll update the JWTAPIClient, changing the Result types:

protocol JWTAPIClient {
    var baseURL: URL { get }
    var jwt: String? { get }

    // Replaced here "Error" with "NetworkError"
    func auth(with credentials: Credentials, completion: @escaping (Result<Void, NetworkError>) -> Void) -> URLSessionTask

    // Replaced here "Error" with "NetworkError"
    func request(from endpoint: Endpoint, completion: @escaping (Result<Data?, NetworkError>) -> Void) -> URLSessionTask
}

Then, we'll do the same to the DummyJSONAPIClient class:

final class DummyJSONAPIClient: JWTAPIClient {
    // ...
    func auth(with credentials: Credentials, completion: @escaping (Result<Void, NetworkError>) -> Void) -> URLSessionTask {
        // ...
    }

    func request(from endpoint: any Endpoint, completion: @escaping (Result<Data?, NetworkError>) -> Void) -> URLSessionTask {
        // ...
    }
}

You should see some build errors now in the DummyJSONAPIClient class, since we are passing generic Error objects to the result completion that expects a concrete NetworkError. Let's fix that by passing a .dataTaskError in those places:

// Replace
completion(.failure(error))
// With
completion(.failure(.dataTaskError(error)))

We can now start replacing our TODOs with the properly error handling. Let's start in the DummyJSONAPIClient.auth function:

guard let data else {
    completion(.failure(.emptyData))

    return
}

guard let authResponse = try? JSONDecoder().decode(AuthResponse.self, from: data) else {
    completion(.failure(.decodingError("Failed to decode AuthResponse")))

    return
}

In the URLSession.shared.dataTask(with:) completion handler, we receive three parameters, data, response and error, but so far we used only the first and the last one. The response parameter is important to receive metadata about the network call, such as errors on server-side. If an error occur inside the API, the error attribute returns nil, so we need to check for this kind of issues in the response object. A very simple way to check it is validating the HTTP Response Code. The HTTP protocol defines that any code between 200 and 299 is considered success, so we can have a very basic error handling strategy by doing this:

guard let httpResponse = response as? HTTPURLResponse else {
    completion(.failure(.systemError("Response is not a HTTPURLResponse")))
    return
}

guard 200..<299 ~= httpResponse.statusCode else {
    completion(.failure(.httpError(httpResponse.statusCode)))
    return
}

Adding this piece of code above in both auth and request functions of the DummyJSONAPIClient class is enough for a simple validation.

We also have other 3 TODOs in the UserService.currentUser. Let's address them:

// Replaced here `Error` with `NetworkError`
func currentUser(completion: @escaping (Result<UserResponse, NetworkError>) -> Void) -> URLSessionTask{

    // ...

    guard let self else {
        completion(.failure(.systemError("Nil self in UserService.currentUser")))

        return
    }

    guard let data else {
        completion(.failure(.emptyData))

        return
    }

    guard let userResponse = self.decodeUser(from: data) else {
        completion(.failure(.decodingError("Failed to decode UserResponse")))

        return
    }

    // ...

}

Now our Network Layer responds with specific errors when it fails, allowing the client code to behave properly (display a friendly message to the user, and also log the reason of the failing, helping with debugging, for example).

Cancellation

Our Network Layer now allows us to cancel pending requests in order to save resources consumption. Imagine for example that a request starts in the Home screen, but before it finishes the user taps in a button that redirects him to the Settings screen. That network call is not needed anymore, so we can cancel it, since we receive the URLSessionTask object. This is an hypothetical piece of code doing it:

class HomeViewController: UIViewController {

    var userRequestTask: URLSessionTask? = nil

    func getUser() {
        let apiClient = DummyJSONAPIClient()
        let userService = UserService(apiClient: apiClient)

        userRequestTask = userService.currentUser { [weak self] result in
            // ...
        }
    }

    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)

        // Cancelling a possible request since the user is leaving the page
        userRequestTask?.cancel()
    }
}

Testing

We can write some Unit Tests to verify that our Network Layer is properly working. Let's see an example with Swift Testing that tests our authentication logic:

import Foundation
import Testing

@testable import URLSessionNetworkLayer

@Test("Test that calling the auth endpoint stores the JWT") func testAuth() async throws {
    let apiClient = DummyJSONAPIClient()
    let credentials = Credentials(username: "emilys", password: "emilyspass")

    await withCheckedContinuation { continuation in
        let _ = apiClient.auth(with: credentials) { result in
            if case .success = result {
                #expect(apiClient.jwt != nil)
            } else {
                Issue.record("Authentication Failed")
            }

            continuation.resume()
        }
    }
}

If you're not familiar with Swift Testing, I wrote a post detailing it here: Introduction to Swift Testing: Apple's New Testing Framework

Here we create a DummyJSONAPIClient object, a Credentials object with valid values, and then we call the auth function, checking if the jwt token is stored correctly.

🚨 Note: At the moment that I write this post, there's an open issue in Swift Testing about recording test errors in detached tasks, as we're doing. There's nothing wrong with the piece of code above, but you can face crashes in CI/CD environment that runs tests if a test fail.

It's also possible test if the request that requires authentication is working as expected:

@Test("Test that fetching current user before authentication returns error") func testCurrentUserBeforeAuth() async throws {
    let apiClient = DummyJSONAPIClient()

    let userService = UserService(apiClient: apiClient)
    await withCheckedContinuation { continuation in
        // Fetching the current user before authenticating
        let _ = userService.currentUser { result in
            guard case let .failure(error) = result else {
                Issue.record("Network call unexpectedly succeeded")
                continuation.resume()
                return
            }

            guard case let .httpError(statusCode) = error else {
                Issue.record("Network call failed with an unexpected error: \(error)")
                continuation.resume()
                return
            }

            // Checking if the response is "Unauthorized"
            #expect(statusCode == 401)

            continuation.resume()
        }
    }

}

@Test("Test that fetching current user after authentication returns the user")
func testCurrentUserAfterAuth() async throws {
    let apiClient = DummyJSONAPIClient()
    let credentials = Credentials(username: "emilys", password: "emilyspass")

    // Authenticating first
    await withCheckedContinuation { continuation in
        let _ = apiClient.auth(with: credentials) { result in
            guard case .success = result else {
                Issue.record("Authentication Failed")
                continuation.resume()
                return
            }

            continuation.resume()
        }
    }

    let userService = UserService(apiClient: apiClient)
    await withCheckedContinuation { continuation in
        // Fetching the current user after being authenticated
        let _ = userService.currentUser { result in
            guard case .success(let user) = result else {
                Issue.record("Network call failed")
                continuation.resume()
                return
            }

            #expect(user.id == 1)
            #expect(user.firstName == "Emily")
            continuation.resume()
        }
    }
}

Those tests above will guarantee that our Network Layer is still working after changes that we implement, and also are a good tool to test our implementation without needing to launching the app itself.

Additional Resources

You can find the complete project we just created in this repo: url-session-network-layer. Feel free to suggest changes or contribute!

Conclusion

Building a robust network layer with URLSession in Swift is a great way to handle complex networking requirements while keeping your code modular, maintainable, and testable. By abstracting network logic into dedicated components—such as an API client, endpoint models, and service layers—we ensure that our business logic remains clean and decoupled from networking concerns.

Key takeaways from this implementation:

Thread management – Ensuring UI updates happen on the main thread while network calls run in the background.
Authentication handling – Storing and reusing tokens for secure API calls.
Error handling – Providing meaningful feedback when requests fail.
Cancellation support – Allowing pending requests to be canceled to save resources.
Testability – Writing unit tests to verify networking logic works as expected.

While third-party libraries like Alamofire or Moya can simplify networking, understanding how to build a custom solution with URLSession gives you full control and avoids external dependencies. This approach is especially useful in performance-critical apps or when working in environments where third-party code is restricted.

You can find the complete project on GitHub: url-session-network-layer. Feel free to explore, fork, or contribute!

Have you built a custom network layer before? What challenges did you face? Let’s discuss in the comments!

Design Patterns in Swift: Singleton

Raphael Martin — Fri, 14 Mar 2025 14:00:00 +0000

What is Singleton

Singleton is a pattern that creates a single instance of a type for the entire application, usually in a global scope (with visibility from any place in the code). The idea of having an object like that is to share state and/or behavior across different layers. Although it's very effective at doing that, many consider Singleton an anti-pattern, due to its side-effects. In today's article, we're going to see how to use this pattern in Swift applications, why some engineers don't like it, and the best strategies to avoid its disadvantages.

How to Create a Singleton

In Swift, it's very easy to create Singletons. That's because Swift is a language that you don't need to specify any kind of higher-level scope, such as Namespaces or Packages. Every .swift file included in your bundle has visibility from any other .swift file in the same module.

1. Creating a Globally-Visible Object in Swift

Simply creating a variable in a global scope makes this variable visible in the entire module in Swift:

import SwiftUI

// Any file in the entire module can now access `myGlobalObj`
let myGlobalObj = MyCustomClass()

struct HomeView: View {
    // ..
}

However, this is not considered a Singleton yet. A Singleton instance must be a static property (or a class var) of a type, that is immediately initialized when the application launches, guaranteeing that the object will be alive during all its lifecycle and it's the only instance of that concrete type in the entire application.

2. Creating a Singleton

That's the most basic implementation of a Singleton in Swift:

MySingletonObject.swift file

class MySingletonObject {
    static let shared = MySingletonObject()

    var message = ""
}

This allows you to access it (read and modify) from anywhere in your module:

HomeView.swift

struct HomeView: View {
    var body: some View {
        Button("Tap Me!") {
            MySingletonObject.shared.message = "Hello, World!"
        }
    }
}

SettingsView.swift

//..
struct SettingsView: View {
    var body: some View {
        Button("Print Singleton Value") {
            print(MySingletonObject.shared.message)
        }
    }
}
//..

The value set on HomeView can be printed in SettingsView, without any of the views "knowing" each other.

You could name your static property anything, but that doesn’t mean you should. There's a convention in Swift that properties that represents a singleton should be called shared.

3. Is Any `static` Property in a Type, That Holds an Instance of the Type Itself, a Singleton?

In Apple development, is common to see things very similar to a singleton:

let defaultFileManager = FileManager.default
let standardUserDefaults = UserDefaults.standard

If you jump to the definition of any of these properties, you'll see something like:

open class UserDefaults : NSObject {

    open class var standard: UserDefaults { get }

    // ..
}

That's very similar to what we saw that is a Singleton, but it has an important difference: it's not the only possible instance of this type.

let systemSettingsStorage = UserDefaults(suiteName: "system-settings")

With UserDefaults, for example, you can have multiple instances of that type in the same application.

So, default and standard are names used to static properties that hold instance shorthands of a type, but not Singletons. When creating Singletons, prefer shared that is the current convention. In legacy code you can also find it as sharedInstance.

Impact on Unit Testing

As we saw in the last section, Singleton objects are usually held in static properties. And it's almost common sense in software engineering that making static calls in the middle of the business logic of your software is a bad practice.

class UserStorage {
    static let shared = UserStorage()

    private init() {}

    func saveUser(name: String) {
        print("Saving user: \(name) to persistent storage")
        // Saves the user...
    }

    func fetchUser(name: String) -> User? {
        // Fetches the user from the storage
    }
}

class UserManager {
    func registerUser(name: String) -> Bool {
        // Checking if the user exists already
        if let _ = UserStorage.shared.fetchUser(name: name) {
            print("User already exists")
            return false
        }

        UserStorage.shared.saveUser(name: name)
        print("User registered successfully")
        return true
    }
}

The above's piece of code introduces a tight coupling between the business logic of the app and the storage service.

Imagine that you have to write some unit tests the UserManager class. You have then two test cases:

Trying to register an existing user should fail.
Trying to register a new user should successfully save it.

Inside the testing environment, how could you simulate the scenario which there's already an user in the storage? You'd need to save it first:

struct UserTests {
    let userManager = UserManager()

    @Test("Test that registering an existing user should fail")
    func duplicateUserSaving() async throws {
        // Saving "John" for the first time
        let _ = userManager.registerUser(name: "John")

        // Saving "John" for the second time
        let secondRegistrationResult = userManager.registerUser(name: "John")

        #expect(secondRegistrationResult == false)
    }
}

If you're not familiar with the code above, I highly recommend you to read my post about Swift Testing, the new Apple's Testing Framework

The test above, despite possibly creating problems in CI/CD environments, probably will work locally. But then, if you create another test for other test case, you may face problems:

struct UserTests {
    let userManager = UserManager()

    @Test("Test that a duplicate user cannot be saved")
    func duplicateUserSaving() async throws {
        // ..
    }

    @Test("Test that a a new user can successfully be saved")
    func newUserSaving() async throws {
        let registrationResult = userManager.registerUser(name: "John")

        #expect(registrationResult == true)
    }
}

If the duplicateUserSaving test case runs first, and if it writes to a file in disk, the newUserSaving test may read from this storage and incorrectly fail. This means that your test is not atomic (one test case is interfering in the other).

Also, as mentioned before, the testing environment can possibly not have access to all the low-level API required to make the storage works. Keep in mind that some hardware resources are only available on a physical device and not in a simulated environment.

How to Create Testable Code with Singletons

We just saw that the usage of static code in general (Singletons included) can be bad for testing and decoupling. But that doesn't mean you cannot work around these problems. There are some robust strategies to have modular and testable code using Singletons. For that, we need to associate Singleton with another design pattern: Dependency Injection.

With Dependency Injection, you can make your business logic be coupled to an abstraction, and then change the Singleton instance to another thing that makes more sense depending on the context (a mock in testing environment, for example).

Firstly, you need to create the abstraction, we will use a protocol for that:

protocol UserStorage {
    func saveUser(name: String)
    func fetchUser(name: String) -> User?
}

Then, you adapt your Singleton to conform to your protocol. Let's say that our storage class was saving the data in a Realm database:

class RealmUserStorage: UserStorage {
    static let shared: UserStorage = RealmUserStorage()
    // ..
}

Now, you adapt your UserManager class to depend on the protocol instead of the Singleton. Note that by making the Singleton the default value in the initializer, it eliminates the need of specifying a value explicitly:

class UserManager {
    // Created a stored property for the storage object
    let userStorage: UserStorage

    // Receive it in the initializer, but with the Singleton as default
    init(userStorage: UserStorage = RealmUserStorage.shared) {
        self.userStorage = userStorage
    }

    func registerUser(name: String) -> Bool {
        // Calling the class property instead of directly the Singleton
        if let _ = userStorage.fetchUser(name: name) {
            print("User already exists")
            return false
        }

        // Calling the class property instead of directly the Singleton
        userStorage.saveUser(name: name)
        print("User registered successfully")
        return true
    }
}

// Even though the initializer can receive a value, if not passing an attribute I use the default storage system, that is Realm
let userManager = UserManager()

Now, you're able to mock the UserStorage behavior in a test environment, removing the dependency on the storage itself and testing only the Business Logic:

class MockUserStorage: UserStorage {
    var existingUserName = ""

    func saveUser(name: String) { }

    func fetchUser(name: String) -> User? {
        // Simulating a stored user
        if name == existingUserName {
            return User(name: name)
        }

        return nil
    }
}

And in your test environment, you can inject the mock in the UserManager object, like that:

struct UserTests {
    let userStorage: MockUserStorage
    let userManager: UserManager

    init() {
        userStorage = MockUserStorage()
        userManager = UserManager(userStorage: userStorage)
    }

    @Test("Test that a duplicate user cannot be saved")
    func duplicateUserSaving() async throws {
        let userName = "John"

        // Simulating an existing user
        userStorage.existingUserName = userName

        // Saving duplicate user
        let registrationResult = userManager.registerUser(name: userName)

        #expect(registrationResult == false)
    }
}

This way, you have a testable code that uses a Singleton. You also have the benefit of a modular code, if you want to change the RealmUserStorage in the future with a SQLiteUserStorage, CoreDataUserStorage or any other framework, you don't need to change anything in your business logic.

Best Practices

We said previously that FileManager.default and UserDefaults.standard cannot be considered Singletons since they are not the only instances of their types. You could guarantee that a Singleton in your code will be the only instance of its type by making its initializer private:

class RealmUserStorage: UserStorage {
    // The `init()` being private makes it visible only inside the class scope
    private init() {}

                                     // Here the initializer is vibisle
    static let shared: UserStorage = RealmUserStorage()
}

let anotherInstance = RealmUserStorage() // ❌ 'RealmUserStorage' initializer is inaccessible due to 'private' protection level

If any developer tries to initialize a new instance of RealmUserStorage, Xcode will prompt a build error, making sure that the type is only used from the Singleton.

Impact in Memory

A common usage for Singletons is in-memory caching. Imagine a collection of UI element in which the user navigate back and forth, and each element displays an image downloaded from the internet. You can have a caching system to avoid downloading the same image multiple times:

class ImageCache {
    static let shared = ImageCache() // Singleton instance

    private var cache: [String: UIImage] = [:]

    private init() {}

    func getImage(from urlString: String) async -> UIImage? {
        // Check if the image is already cached
        if let cachedImage = cache[urlString] {
            return cachedImage
        }

        // If not cached, attempt to download the image
        guard let image = await downloadImage(from: urlString) else {
            return nil
        }

        // Save the image in cache
        cache[urlString] = image

        return image
    }
}

This kind of implementation is very useful, but it can introduce so flaws to your app:

1. Increasing Memory Usage

The cache property, being a Dictionary, will hold the cached images for all the object lifecycle, and since it's a Singleton, that means all the app lifecycle. If several large images are cached, you may face slow perfomance or a stack overflow.

2. Data races

This piece of code above is not thread-safe. That means that multiple threads accessing the the Singleton state may receive undesired results. I talked more about data races and how to avoid then using actors in this post, take a look!

A simple solution, that would not require Actors, would be making the cache property of type NSCache:

private let cache = NSCache<NSString, UIImage>()

Then you replace:

// Retrieving cached image
let cachedImage = cache[urlString]

// Caching an image
cache[urlString] = image

With:

// Retrieving cached image
let cachedImage = cache.object(forKey: urlString as NSString)

// Caching an image
cache.setObject(image, forKey: urlString as NSString)

Using a NSCache brings several benefits: Swift automatically removes cached data in run-time if memory is low, the NSCache type is automatically thread-safe, and it don't create strong references to the keys, meaning that ARC automatically free space when the object key is not being referenced anywhere else.

For a more robust implementation, you could combine an actor with a NSCache property, allowing you to add logic as expiration and prefetching.

Conclusion

The Singleton pattern is useful for sharing state across an application but comes with potential drawbacks. To address these, we can apply Dependency Injection for better flexibility, testability, and maintainability.

Key takeaways:

Singletons are useful for shared state but can lead to tight coupling and hidden dependencies.
Dependency Injection helps decouple components and improve testability.
Using protocols instead of singletons enhances modularity and scalability.

By carefully applying the Singleton pattern and considering alternatives, you can write more maintainable and flexible Swift code.

Don't Panic: What Apple's iOS 18 SDK Update Really Means for Your App!

Raphael Martin — Fri, 07 Mar 2025 15:13:33 +0000

Introduction

Lately, I've seeing some posts in the Apple Development community, with an alarmist tone, about an Apple update that will happen in April 2025.
If you access the Submit your iOS apps to the App Store page, you can find the following instruction:

Starting April 2025, all iOS and iPadOS apps uploaded to App Store Connect must be built with the iOS 18 SDK.

I've seeing people mistakenly claim that starting April 2025, your iOS app needs to support iOS 18 as the minimum supported version, which is totally incorrect. You can still support older versions of iOS, and this post will explain why.

Understanding the Difference

iOS SDK

SDK stands for Software Development Kit, and the iOS one is a collection of tools, frameworks, and APIs provided by Apple that developers use to build iOS apps. It includes everything necessary to create, compile, and debug an app for iPhones and iPads, example:

Frameworks and APIs

UIKit
SwiftUI
URLSession

Compilers and Build Tools

LVVM Compiler, that translates Swift/Obj-C code into machine code

Debugging Tools

LLDB
Instruments
Xcode's debugger (the functionality of adding breakpoints)

iOS Deployment Target

The minimum iOS version that the app supports. It's a configuration that is set in Xcode, under the Target settings. In Xcode 16 for example, you can set the minimum supported iOS version to 15.

What changes then?

If your app supports at minimum iOS 17, for example, you'll see some differences between building it with the iOS SDK 17 and the iOS SDK 18:

Access to New APIs

You can access APIs that were release in iOS 18 when building with iOS SDK 18, but only if using the availability check:

if #available(iOS 18, *) {
    // Call some API method available in iOS 18 only
} else {
    // Fallback implementation
}

Deprecations

Apple may deprecate some APIs in newer SDKs. Deprecated APIs will continue to work for some time, but Apple could remove them in future iOS versions, requiring developers to migrate.

Performance Improvements

New SDK versions may include improvements in the compiler, building your app faster and/or creating smaller bundles. Also, security improvements and bug fixes can be present too.

How To Set It Up

If you want to update your project to conform to the Apple Store requirements, but you want to still support users in older OS versions, you just need to build your app in Xcode 16, and guarantee that the iOS Deployment Target is properly set:

Setting the iOS Deployment Target

On Xcode, click in your project on Project Navigator, select the target that you want to configure, then in the General tab, under Minimum Deployments select the desired iOS version.

Archiving and Submitting to Apple Store Connect manually

If you manually send your app to App Store Connect, after April you must do it through Xcode 16. By doing it, you are already guaranteeing that your app is built with iOS SDK 18.

Automated CI/CD Pipelines

If you have an automated pipeline, you'll need to upgrade your build environment. The steps for doing it will depend on which CI/CD provider you're using (e.g., GitHub Actions, GitaLab CI, Jenkins, Fastlane, or Xcode Cloud).
Here are some documentation that can help:

What Happens in April 2025?

Starting April 2025, if you try to submit an app built with iOS SDK 17 or older to App Store Connect, it will fail. To submit new releases after April 2025, you must build your app using Xcode 16 (or later) and the iOS 18 SDK.

If your last release was built in an older SDK, nothing will happen. Your app will still available in the store to be downloaded, and your current users will still be able to access it normally. You'll only need to update to submit new releases.

Why Does Apple Enforce SDK Upgrades?

Security

As already mentioned, new SDKs usually have security improvements compared to the previous ones. Enforcing the apps to update it is a way that Apple finds to keep a safer environment for the apps in their devices.

New APIs Adoption

It's also a good "motivation" to the engineers to start using new APIs included in new SDKs. And with a good adoption of new APIs, Apple can also deprecate older ones, creating a more modern development environment each time.

Conclusion

The requirement to use the iOS 18 SDK starting in April 2025 does not mean that apps must drop support for older iOS versions. Instead, it simply means that developers must build their apps using Xcode 16 or later. By understanding the difference between the iOS SDK and the iOS Deployment Target, you can ensure your app remains compatible with older iOS versions while meeting Apple's submission requirements.

If you're maintaining an app, now is a good time to prepare your development environment and CI/CD pipelines for the transition. Ensuring your project builds with Xcode 16 and the iOS 18 SDK will keep your app eligible for future submissions without affecting users on older devices.

Apple enforces these updates to improve security, encourage adoption of new APIs, and streamline the iOS development ecosystem. By staying informed and planning ahead, you can make the transition smoothly without unnecessary concerns.

Code Review: Best Practices

Raphael Martin — Fri, 28 Feb 2025 14:13:59 +0000

Code Review: Best Practices

Introduction

The Code Review process is an important part of the software development cycle, followed by most of the companies nowadays. The idea of having your code reviewed by a colleague or a lead can create mixed feelings in a developer: enthusiasm to be congratulated to a great work, or receive constructive feedback that will enlighten your knowledge, but also insecurity to have your work judged. Today we're going to see common challenges during Code Review and how to make it a better process to everyone.

Why Care About Code Review

It's easy to find good reasons for a project invest in a Code Review process in its development flow, but which are the advantages to you, the software engineer? Maybe you are facing it now as "one more bureaucratic step" in your daily work, but caring about making the process better could be a benefit for you:

Make it easier for the Reviewer: Having a structured and smart Code Review process makes it easier and faster to the reviewer (that can possibly be you).
Get PRs approved faster: If reviewing is an easy and fast task, your code will be approved faster, improving also the velocity that you deliver work to the end-user.
Receive better feedback: A good Code Review process allows the reviewer to focus their energy in analyzing your code, giving better feedback, avoiding losing time with unimportant tasks.

Writing Code That’s Easy to Review

Pushing code that is easy to be reviewed is not so different from writing high quality code. Focusing on clarity, minimizing complexity and consistency are key values that you should follow. However, some specific actions focusing in Code Review can be done.

1. Commit Frequently with Small, Atomic Changes

Commits should be atomic. That means that one commit should be as small as it can, indivisible, in a way that each one makes sense on its own. Frequent commits help create a rich history of the implementation. That way, the reviewer has the possibility of reviewing isolated changes, commit by commit, understanding better your reasoning process:

🚫 Avoid
✅ Prefer

2. Rich Commit Messages

Provide a brief, descriptive title and a detailed commit message. The title should be concise, while the message can include specifics about the changes made.

🚫 Avoid
🚫 Avoid
✅ Prefer

3. Visual Enhancements

3.1 Rich Screenshots

It's not uncommon that a reviewer doesn't have a deep understanding of what the feature you're working on is. Our code may be obvious to you but not to others. That said, adding evidence of what your change does in the software is a good way of giving context. Use visual elements like arrows and highlights to improve clarity.

Implemented fallback image for articles without image

Before	After

When static images are not enough, add videos to your PR description. Prefer them over GIFs, since with videos the reviewer can control the playback, making the understanding of the change better.

3.2 Committing IDE-handled files

Files that are managed by a software often are not human-friendly. And sometimes, we need to add them to a VCS. In Apple development with Xcode, for example, you need to add .pbxproj files to version control, and for the reviewer sometimes is hard to understand what a change in this file is:

It's recommendable adding screenshots of the IDE UI, indicating which changes were made that resulted in the file change, making the review process easier.

How to Review Code Effectively

In the role of the reviewer, there are several tips in how to make the process more efficient, positive and peaceful.

1. Read the PR description carefully

In the last section we talked about how to make a good PR to the reviewer, and you can notice that it takes some effort. The reviewer should reserve some time to carefully analyze all the info that the committer added to the PR in order to avoid mistakes. A detailed PR description is useless if the reviewer doesn't read it carefully.

2. Avoid Nitpicking

In software engineering is very common having several ways to do the same thing, and engineers usually have their preferences. Sometimes, the committer preference is different from the reviewer. If it's not something that violates a project pattern/convention, there's no need to ask it to be changed, example:

The Committer pushes:

func uppercased(string: String?) -> String {
    if let string {
        return string.uppercased()
    } else {
        return ""
    }
}

The Reviewer then suggests: > I don't like using else in returning functions. Please, change it to:

func uppercased(string: String?) -> String {
    if let string {
        return string.uppercased()
    }

    return ""
}

There's nothing wrong with the initial implementation, and the suggested change is just a matter of preference.

But not only equivalent code can be considered nitpicking. Analyzing the context of the project and the readability of the code also matters when judging if an implementation is good or not:

The Committer pushes:

func removeDuplicates(from array: [Int]) -> [Int] {
    return Array(Set(array))
}

The Reviewer then suggests: > Creating a Set from an Array does not maintain order and may not be the most efficient approach. I suggest you changing it to something similar to:

func removeDuplicates(from array: [Int]) -> [Int] {
    var seen: [Int: Bool] = [:]
    return array.filter { seen.updateValue(true, forKey: $0) == nil }
}

In the example above, even though the Reviewer is right about the initial code not keeping the array order and possibly having some overhead (in huge arrays), maybe for the purpose of where it's being used the order is not important, and no differences can be seen by the user using one or another algorithm (even though the second one is really faster, only a benchmark test could say that). If that's the case, keeping a more readable code is more important for the project in general rather than an insignificant perfomance improvement.

3. Prioritize doing reviews

Working with global teams in different timezones is becoming more and more common. It's very likely that a coworker that lives in the other side of the globe, sends a Pull Request to be reviewed by you in a moment that you are not working, and that's ok. But since you have a chance, do the pending reviews as soon as possible. Your colleague may be under pressure due to an urgent deadline, and having a PR reviewed fast can save his day.

4. Add references to your suggestions

A suggestion that seems obvious to you might not be clear to the committer. Adding links to documentation, or even pointing another place in the current project that has a similar implementation can bring a better understanding of what your suggestion is:

Given code:

class Settings {
    private let defaults = UserDefaults.standard

    var isDarkModeEnabled: Bool {
        get {
            return defaults.bool(forKey: "isDarkModeEnabled")
        }
        set {
            defaults.set(newValue, forKey: "isDarkModeEnabled")
        }
    }
}

🚫 Avoid a comment like:

You could use a property wrapper for that.

✅ Prefer:

What about using a property wrapper for that? https://docs.swift.org/swift-book/documentation/the-swift-programming-language/properties/#Property-Wrappers. You can also refer to DependencyContainer.swift:37 where we use a property wrapper to inject dependencies.

5. Praise good work

Code reviews aren't just for finding flaws—they're also a great opportunity to recognize good work. Sometimes a committer implements a very robust solution for a complex problem, and you identify that it was very clever. Don't lose the opportunity to praise them about it. This behavior creates a positive environment.

General Tips For A Better Process

We already covered best practices that the committer and the reviewer should follow. What about the process in general, things that affect both of the "roles" in this process?

1. Create a useful PR template

The quality of a Pull Request template can make the difference in Code Review. A bad one can be bureaucratic, inconsistent and hard to be read:

## Describe your change
<!-- Add your change description here -->

## Module affected
[ ] Home
[ ] Settings
[ ] Backend services

Imagine that your change doesn't apply to any of the three modules present in the PR template. The committer will have the work of either removing this section, or just ignoring it. This last option creating a polluted PR description, which will make the reviewer task harder, not easier.

PR templates should align with the project's reality, helping the committer create a rich description in a easier way, and not the opposite.

2. Create checklists

Another excellent idea, that could be combined with Creating a useful PR template, is creating checklists. You can define a set of tasks for both the committer and the reviewer to be performed before doing their "part of the job" in a Code Review process, and then add it to the PR template. Example:

**Commiter Checklist**
[x] Updated the CHANGELOG
[x] Added documentation to public API
[x] Passed the automated UI tests locally
[x] Moved the JIRA ticket to "In Review"

**Reviewer Checklist**
[ ] The committer checked the checklist properly
[ ] This PR follows the [Project Code Standards](repoaddress.com/code-standads-location)
[ ] Created Unit Tests

3. Automation

We previously covered that the reviewer should avoid Nitpicking. A good strategy to make it easier is to create automations for repetitive and mechanical tasks, such as formatting, styling standards and more.
Setting up a Git Hook that runs a linter, for example, can avoid that the reviewer reject a PR due to a bracket opened in the wrong line.
You can also setup automated pipelines to run code checking for bad smells or even to run unit tests.
Automating all the no-human part of the process gives more free time to the reviewer focus their energy in what really matters: the logic, perfomance and safety of the code.

Encouraging a Positive Code Review Culture

Creating a positive Code Review culture in a team is not easy. But you should be an actor that contributes to making it a valuable part of your project.
As a committer, you can face the reviews in your code as an opportunity for learning, being thankful to good suggestions received.
As a reviewer, you can use the review time to reflect about your project features, creating solid understanding of all parts of the software you work with, such as learning new stuff from good implementations of the other devs in your team.

Conclusion

A well-structured Code Review process is more than just a quality checkpoint—it’s an opportunity for learning, collaboration, and continuous improvement. By writing code that is easy to review, providing clear and detailed PR descriptions, and approaching reviews with a constructive mindset, both committers and reviewers can make the process more efficient and beneficial for everyone.

Ultimately, the goal of Code Review is not just to find mistakes but to build better software together. A positive and thoughtful review culture fosters knowledge sharing, strengthens team relationships, and enhances code quality in ways that benefit the entire project. By following these best practices, you can help turn Code Review into a rewarding experience rather than a bureaucratic hurdle.

How to Prevent Data Races in Swift with Actors

Raphael Martin — Fri, 21 Feb 2025 14:17:37 +0000

Introduction

At the WWDC 21, Apple introduced several new features to work with concurrency, and one of them were actors. With actors, protect mutable states, avoiding data races, became an easier task. Today we're going to explore actors, understand how Data Races occur, what we can do to prevent it with and without actors, and compare the differences

Data Races

A Data Race condition can happen when multiple threads are accessing a same memory address at the same time, and at least one of these access is a write operation. The problem of this situation is that a same algorithm, with same input, can give different results when executed multiple times, so you can't predict exactly what your code will really do.

To understand how does it happen, we need to go a little lower-level. While in the programming language counter.value += 1 seems to be one instruction, at CPU level we have 3 operations to perform this increment: Read (LOAD), Modify (ADD) and Write (STORE).

LOAD: First, the thread that is executing the increment will read the current value of the variable. That means copying its value from the RAM memory to some CPU memory (cache or registry);
ADD: After having the value loaded, the thread will execute the sum operation, storing the result in the CPU memory;
STORE: The final action that the thread performs is to write back the result value in the same memory address it read it before. Since those are 3 steps, having multiple threads executing them without any order control can lead to undesired results. Let's imagine 2 simultaneous threads performing this increment:

Time	Thread 1 (T1)	Thread 2 (T2)	`counter.value` in Memory
1	Read from `counter.value` address: `0`		`0`
2	Add `1` (Result: `1` in the CPU memory)	Read from `counter.value` address: `0`	`0`
3	Store `1` back to `counter.value`	Add `1` (Result: `1` in the CPU memory)	`1`
4		Store `1` back to `counter.value`	`1` (expected `2`, but the T2 started increment before T1 stored the incremented value)

In the situation above, T1 starts the execution before T2, but it only stores the result back to the memory after T2 already read it. So after both threads finished their execution, the counter.value is 1 instead of 2. This is called a race condition.

How to prevent it before actors

In Swift you have several ways to avoid data races. Let's explore an example using a Serial DispatchQueue for our previous example:

class SafeCounter {
    private var value = 0
    private let queue = DispatchQueue(label: "safeCounterQueue")

    func increment() {
        queue.sync {
            value += 1
        }
    }

    func getValue() -> Int {
        queue.sync { value }
    }
}

func run() {
    let counter = SafeCounter()

    DispatchQueue.concurrentPerform(iterations: 10) { _ in
        counter.increment()
    }

    print("Final value: \(counter.getValue())") // Always 10
}

run()

This updated code above solves the racing condition by using a Dispatch Queue. When you create a queue, you need to inform a label, that is used as an identifier by the OS for that specific queue. When you execute synchronous code in that queue (by using the sync function), the OS blocks any other thread that tries to execute instructions in that same queue until the first one ends its execution:

queue.sync { // Here the `safeCounterQueue` queue will be blocked
    value += 1
} // Here the `safeCounterQueue` queue will be unblocked

Let's see how it changes the operations executed by the CPU:

Time	Thread 1 (T1)	Thread 2 (T2)	`counter.value` in Memory
1	Tries to start an execution block in `safeCounterQueue` and succeeds since it's free.		`0`
2	Read from `counter.value` address: `0`	Tries to start an execution block in `safeCounterQueue` and fail since T1 is blocking it. Wait until it's unblocked.	`0`
3	Add `1` (Result: `1` in the CPU memory)	Waiting	0
4	Store `1` back to `counter.value`. Unblocks `safeCounterQueue`	Waiting	1
5		Read from `counter.value` address: `1`	1
6		Add `1` (Result: `2` in the CPU memory)	1
7		Store `2` back to `counter.value`. Unblocks `safeCounterQueue`	2

Precautions when working with locking mechanisms

We just saw how locking an execution in a queue can help with data races. But if misused, it can also cause another type of problem: deadlocks.

A deadlock occurs when you have two resources waiting for each other, closing a cycle. With GCD, it can happen when creating nested sync execution blocks in the same queue.

let queue = DispatchQueue(label: "deadlockQueue")

queue.sync {
    print("Task 1 started")

    // This causes a deadlock:
    queue.sync {
        print("Task 2 started") // ❌ This will never execute
    }

    print("Task 1 finished")
}

print("Code after queue.sync") // ❌ Never reached

This happens because the Task 1 locks the deadlockQueue. Inside its execution scope, Task 1 tries to start another sync block in the deadlockQueue, but it's locked by the Task 1 itself, so it will wait for the Task 1 finished its execution, which will never happen.

How actors handles parallel programming

Actors are data structures, as classes and structs, that were introduced in Swift 5.5. The actor objects are reference typed, as classes, but they don't accept inheritance, as structs. The difference from actors to other structures is that they have a built-in implementation to guarantee that only one thread is accessing its state at a time. Let's see how our Counter object would looks like if it was an actor:

actor Counter {
    var value = 0

    func increment() {
        value += 1
    }
}

As simple as that, this object is now thread-safe: only one thread at a time will be able to modify the value property (its state).
To make that possible, actors use an executor: an internal object that defines how parallel access should be enqueued. This executor is defined in runtime, so it's a black box to the developer. However, it's possible to create your own executor (even though it's very unlikely you'll need to do that).

All these built-in features of an actor have a price when using it: accessing (reading/updating) an actor state is always an asynchronous task, so you always need to do it inside an async context (a Task, for example) and use await.

Task {
    let counterValue = await counter.value

    if counterValue < 10 {
        await counter.increment()
    }
}

Let's see now our data race algorithm fixed used the Counter actor. We need to change a little bit the approach of launching parallel threads since actors requires the usage of async/await, but the idea is the same:

let counter = Counter()

Task {
    await withTaskGroup(of: Void.self) { group in
        for _ in 0..<10 {
            group.addTask {
                await counter.increment()
            }
        }
    }

    print(await counter.value)  // Always prints 10
}

In the example above, the async increment() function will suspend the execution of new operations until it's finished, so it guarantees that no other thread will be updating the same memory place.

Differences

1. Simple Syntax, Less Boilerplate

With all the built-in strategies to make an actor thread-safe, they become much simpler to write compared to older data structures, like classes and structs. Also, its syntax using async/await is compliant with modern Swift concurrency.

2. Deadlock Prevention

When using actors, Swift runtime automatically avoid deadlocks by ensuring that tasks are processed sequentially inside the actor, while in older approaches it's needed to handle this manually.

3. Perfomance

With GCD, serial queues block the execution of multiple threads, reducing the parallelism. Actors, in the other hand, uses a concept called cooperative multitasking, that suspend execution instead of blocking them, which causes a better CPU utilization. In general, using actors automatically leads to a better perfomance when talking about concurrency. However, for heavier tasks, using Locks (such as NSLock or pthread_mutex) let you write a more low-level code, which in very specific cases can be useful for high-performance threads management.

Actors Eliminates Data Races Entirely?

Even though using actors in Swift greatly reduces the risk of having a racing condition, it's still possible to have them using an actor. Let's an example:

Incorrect usage of async calls

If your app is updating an actor state in an asynchronous context and reading it in another one, you may face racing conditions:

actor Counter {
    private var value = 0

    func increment() { value += 1 }
    func getValue() -> Int { value }
}

let counter = Counter()

func unsafeIncrement() {
    Task { // Creates one async context that will be executed in a specific
        await counter.increment()
    }

    Task {  // Creates another async context, executed in another thread, possibly causing a racing
        print(await counter.getValue())
    }
}

for _ in 0..<10 {
    unsafeIncrement()
}

The code above should print in the console something like:

That's because each Task is executed by a different thread, in an uncertain time. So that way, even though you are using an actor, you can observe a data race.

Conclusion

Today we explored actors in Swift, a concurrency model designed to simplify thread safety by ensuring that only one task interacts with an actor’s state at a time. We discussed why actors are a great alternative to locks and serial queues (GCD), making concurrent code safer and more intuitive to the developer:

How actors protect mutable state from race conditions.
The interaction between actors and async/await, ensuring smooth concurrency handling.
Limitations and considerations, such as performance trade-offs.

We also covered that even though actors make concurrency in Swift easier and reduce the risk of data races, they are not a silver bullet. Understanding how they work is essential to create thread-safe code.

Mastering this knowledge, you can write safer, more maintainable concurrent code, making your Swift applications more robust and scalable.

Additional Resources

ViewCode with UIKit

Raphael Martin — Fri, 14 Feb 2025 13:54:18 +0000

Introduction

ViewCode is a UI building strategy commonly used in the Apple ecosystem development (iOS, tvOS, macOS and more) that consists in creating the UI programmatically. Xcode offers you the possibility of creating user interfaces with a tool called Interface Builder, but often developers choose to not use it and do everything with ViewCode. Today we're going to explore this concept, reasons for using ViewCode, and how to implement it.

Why choosing ViewCode over Interface Builder

In Xcode, you have the possibility of creating UI using Interface Builder. It is a tool that handles storyboards and .xib files, with drag & drop features, in an attempt of making UI building an easy and intuitive task, especially for beginners.

Xcode creates self-managed XML files with the screen content you created. As you can imagine, the content of these files aren't much human-readable (since Apple doesn't expect you to directly edit this files). Also, these files bring some metadata, such as version of the Interface Builder, version of Xcode and plugins used.

All these characteristics can lead to problems:

1. Version Control Management

Working in teams on projects that uses storyboards and/or *.xib*s can be very painful. That's because merging these files in a VCS is generally hard. If you and a colleague are editing the same file, when pushing to a git repository, for example, it's difficult to solve conflicts in the changed files, since, as I mentioned previously, these files are not meant to be read by the engineers.

2. Modularity and Reusability

With ViewCode it's pretty simple to create reusable components, since you can create a custom class for a specific component, and then use it in several places. Also, changing the original class automatically impacts all the places that use it. This task is not possible with Interface Builder

3. Navigation

When using storyboards, you can use segues to create the navigation logic of your app. As your project grows, navigation logic complexity increases exponentially.

4. Multiplatform support

When working in a project that supports multiple platforms, for example, iOS and macOS, using storyboards can be a very difficult task. That's because the structure of the files is different for each platform, and the compiler fails to build a project for a specific platform if it contains storyboards for other platforms. To make that work, you'll need to increase build logic complexity by adding conditions to determine whether include a file in the app bundle.

How to add UI programmatically

In UIKit, you can add UI components to your views by instantiating view objects and adding them through the UIView.addSubview() function.

class ViewController: UIViewController {
    override func viewDidAppear(animated: Bool) {
        let label = UILabel()
        label.text = "Hello World!"

        self.view.addSubview(label)
    }
}

You can also create a hierarchy by nesting views:

let containerView = UIView()
containerView.backgroundColor = .red

let label = UILabel()
label.text = "Hello World!"

containerView.addSubview(label)

self.view.addSubview(container)

But be aware: for some specific types of views, you may need to use a different function: addArrangedSubview.
In UIStackView objects, using this function is important since it doesn't just add your view as a child of the StackView, but it also arranges it. And by arranging, I mean positioning and sizing the child view based on the StackView properties, such as axis, alignment, distribution and spacing. Let's analyze a piece of code:

let stackView = UIStackView()
stackView.axis = .vertical
stackView.spacing = 10
stackView.alignment = .center
stackView.distribution = .equalSpacing  
stackView.backgroundColor = .yellow

for _ in 0..<4 {
    let label = UILabel()
    label.text = "Hello, World!"
    label.backgroundColor = .lightGray
    stackView.addArrangedSubview(label)
}

view.addSubview(stackView)

In the image above you can see that the labels are correctly vertically stacked, with a distance of 10p from each other, taking the same space. But if we change the addArrangedSubview function to addSubview, no label becomes visible inside the stack view:

You can also add Constraints to your layout by using the NSLayoutConstraint api. Let's add some constraints to a label, making it centered in a view:

let label = UILabel()
label.text = "Hello, World!"
// This line is important
label.translatesAutoresizingMaskIntoConstraints = false

// First add the view to the hierarchy
view.addSubview(label)

// Then add the constraints
label.centerXAnchor.constraint(equalTo: view.centerXAnchor).isActive = true
label.centerYAnchor.constraint(equalTo: view.centerYAnchor).isActive = true

To align a UILabel programmatically, you can use properties from UIView, such as centerXAnchor and centerYAnchor. They are of type NSLayoutAnchor, a type that has several constraint functions, allowing you anchoring your views where it's needed.

The constraint(equalTo:) function returns an object of type NSLayoutConstraint. We can hold this value in a variable, and conditionally enable/disable the constraint:

let horizontalLabelConstraint = label.centerXAnchor.constraint(equalTo: view.centerXAnchor)

if shouldAlignLabelOnCenter {
    horizontalLabelConstraint.isActive = true
}

Notice also that, on our first example with constraints, we are adding them after adding the label as a subview of view. That's because UIKit requires the component to be in the view hierarchy before applying constraints. Otherwise, you'll receive a runtime error:

If activating multiple constraints at same time, you can use the NSLayoutConstraint.activate() function, that receives an array of NSLayoutConstraints as argument, and set the isActive property to true in all of them:

NSLayoutConstraint.activate([
    label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
    label.centerYAnchor.constraint(equalTo: view.centerYAnchor),
])

Autoresizing Mask

We disable the translatesAutoresizingMaskIntoConstraints property (also known as tamic, a shorthand Xcode autocompletes when typing label.tamic) to ensure our explicit constraints work properly. Even though all developers use it, many of them don't know exactly why it's needed:

Before Auto Layout: In the early days of iOS development, screen sizes were fixed, making it feasible to position views using absolute X/Y coordinates. To provide some flexibility, UIKit introduced the Autoresizing Mask, a system that allowed child views to resize or reposition dynamically when their parent view changed size.
The Introduction of Auto Layout: With the launch of the iPhone 5, Apple introduced Auto Layout to support multiple screen sizes and aspect ratios. Instead of relying on autoresizing behavior, developers could now define explicit constraints to determine how views should be sized and positioned. To bridge the gap between the old and new systems, Apple introduced translatesAutoresizingMaskIntoConstraints, which automatically converts the Autoresizing Mask into Auto Layout constraints.
Why You Rarely Notice This in Interface Builder: When using Interface Builder, Xcode automatically sets translatesAutoresizingMaskIntoConstraints = false because it assumes you’ll define constraints manually. However, when creating views programmatically, this property is true by default to maintain compatibility with older UIKit behavior.

Summary:

The translatesAutoresizingMaskIntoConstraints property exists to allow the older Autoresizing Mask system to work with Auto Layout. However, when defining constraints programmatically, this conversion creates constraints that conflict with our custom constraints, leading to unintended behavior.

Best practices

Removing "completely" the dependency on Storyboards

The first thing you should do when starting a new ViewCode app is remove any storyboard usage from the default Xcode project. I mean, any possible usage. That's because for a very specific use case you may need to keep a storyboard: Launch Screen. It's recommendable to keep the LaunchScreen.storyboard for configuring a responsive launch screen to your app. In past you could use an image as launch screen, by adding it to your app assets catalog (.xcassets), but this option is deprecated in recent versions of Xcode.

Let take a brand new iOS app as an example. When creating one, select Storyboard as Interface (that will make our app use UIKit and not SwiftUI).

Now, you can delete the Main.storyboard file

On your Info.plist file, under Application Scene Manifest > Scene Configuration > Window Application Session Role > Item 0, delete the Storyboard Name entry.

In your target settings, go to Build Settings > Info.plist Values and remove the UIKit Main Storyboard File Base Name entry value (just select it and press Delete).

Finally, you need to programmatically set the first UIViewController of your app. For that, you should go to the SceneDelegate class, and in the scene(willConnectTo:) function, replace its content with the following piece of code:

guard let windowScene = (scene as? UIWindowScene) else { return }
self.window = UIWindow(windowScene: windowScene)
self.window?.rootViewController = ViewController()
self.window?.makeKeyAndVisible()

This creates a UIWindow object with the given scene, sets a root view controller, and makes it visible.

Before building and running your app, add some styling to the initial ViewController class to you recognize it and know that everything is working:

override func viewDidLoad() {
    super.viewDidLoad()

    view.backgroundColor = .white

    let label = UILabel()
    label.text = "Hello, World!"

    view.addSubview(label)

    NSLayoutConstraint.activate([
        label.centerXAnchor.constraint(equalTo: view.centerXAnchor),
        label.centerYAnchor.constraint(equalTo: view.centerYAnchor),
    ])
}

You should see a screen like that:

Lazy vars for UI Components

It's a good and common practice to use lazy vars initialized with an immediately invoked closure for your UI components when working with ViewCode. That's because with lazy vars, you consume the computing resources of initializing the view objects only when it's called, and with the closure you can perform some setup in the component when initialing it:

class ViewController: UIViewController {
    private lazy var label: UILabel = {
        let label = UILabel()
        label.text = "Hello, World!"
        label.textColor = .black
        label.translatesAutoresizingMaskIntoConstraints = false

        return label
    }()

    // ..
}

Note that I set several attributes to the label property when initializing, centralizing this setup logic in the object creation.

Work with protocols

You can also create a protocol to keep your UI code organized and concise. As we previously covered, constraints need to be set after adding the views to the hierarchy. A protocol can help you, for example, assure that you are doing these things in the correct order.

protocol ViewCode {
    func addViewHierarchy()
    func setupConstraints()

    func buildView()
}

extension ViewCode {
    func buildView() {
        addViewHierarchy()
        setupConstraints()
    }
}

Then you can adjust your ViewController class to make it conform to ViewCode, calling the buildView() function only, being sure that the views are being added first, and then the constraints:

class ViewController: UIViewController {
    private lazy var label: UILabel = {
        //..
    }()

    private lazy var button: UIButton = {
       //..
    }()

    private lazy var stackView: UIStackView = {
        //..
    }()

    override func viewDidLoad() {
        super.viewDidLoad()

        buildView()
    }
}

// MARK: ViewCode conformance
extension ViewController: ViewCode {
    func addViewHierarchy() {
        stackView.addArrangedSubview(label)
        stackView.addArrangedSubview(button)

        view.addSubview(stackView)
    }

    func setupConstraints() {
        NSLayoutConstraint.activate([
            stackView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
            stackView.leadingAnchor.constraint(equalTo: view.leadingAnchor),
            stackView.trailingAnchor.constraint(equalTo: view.trailingAnchor),
            stackView.bottomAnchor.constraint(equalTo: view.safeAreaLayoutGuide.bottomAnchor)
        ])
    }
}

In the example above, the protocol helps us to follow some of the best practices: assuring the correct order of adding views and adding constraints; separating responsibilities; improving readability.

You can also adapt your protocol to your project reality, as adding a function to styling, for example. This is just an initial idea.

Conclusion

In this article, we explored ViewCode, a UI-building approach that relies on writing layout code instead of using Interface Builder. We discussed why many developers prefer ViewCode over storyboards, highlighting its advantages in version control management, modularity, navigation, and multiplatform support.

We also covered the basics of creating UI programmatically in UIKit, including:

Adding views to the hierarchy using addSubview() and addArrangedSubview().
Applying constraints with Auto Layout and NSLayoutConstraint.
Understanding the role of translatesAutoresizingMaskIntoConstraints.

Additionally, we reviewed best practices for fully removing storyboards from an app, ensuring a clean ViewCode setup from project creation.

While ViewCode requires more manual effort than Interface Builder, it provides better scalability, maintainability, and flexibility for complex projects. By mastering these techniques, you can gain greater control over your UI and improve your development workflow.

Introduction to Swift Testing: Apple's New Testing Framework

Raphael Martin — Fri, 07 Feb 2025 13:45:07 +0000

Introduction

In September 2024, Apple released the macOS Sequoia 15, alongside Xcode 16. This new version of the IDE brings some new cool stuff, such as Swift 6 and the open-source unit testing framework Swift Testing, the latter being the subject of today's post.
The motivation behind introducing a new native way of writing tests in Swift is to overcome limitations of XCTest. Let's explore how Swift Testing tries to achieve it, and understand where and specially when you should start using it.

What Problems Does Swift Testing Solve?

Verbose and Boilerplate-heavy Syntax in XCTest

When creating tests with XCTest, a lot of boilerplate is needed in order to create any kind of test, even the simplest ones:

import XCTest

final class SumTest: XCTestCase {
    var calculator: Calculator?

    override func setUpWithError() throws {
        // Instantiate the needed objects
        calculator = Calculator()
    }

    override func tearDownWithError() throws {
        // Deallocate objects to free space in DevOps environments
        calculator = nil
    }

    func testSum() throws {
        // Unwraps optional value
        let calculator = try XCTUnwrap(self.calculator)

        // Assert that the `sum` function calculates correctly
        XCTAssertEqual(calculator.sum(number1: 2, number2: 2), 4)
    }
}

With Swift Testing, your test cases can be global functions, excluding the need of it placing it inside any kind of scope:

import Testing

@Test func sum() {
    let calculator = Calculator()

    #expect(calculator.sum(number1: 2, number2: 2) == 4)
}

Let's break down the piece of code above:

In the first line, we're importing the Testing package, that is the Swift Testing framework package. That allow us to use the @Test property wrapper and the #expect macro.
In the sum function declaration, we are adding the @Test wrapper. That makes Xcode understand that this function is a Test Case, and allows us to execute the test.
The #expect macro is very similar to XCTest XCTAssert() function. But differently from there, there's no variations such as XCTAssertEquals, XCTAssertNil, and etc. The reason for that is to simplify and improve semantics: reading expect 2 + 2 to be equals 4 is more "human" natural than assert equals: 2 + 2, 4. More about this topic in the next section.

Assertion semantics

As we previously saw, the #expect macro works similar to XCTAssert function. Like the older function, the new macro has a similar behavior: when an expectation fails, the test continues executing until it completes or throws an error:

struct Person {
    var name: String = ""

    init(name: String) {
        // missing property setting here
    }
}

@Test func example() {
    let person: Person? = Person(name: "John")

    #expect(person?.name == "John") // Here you'll see a failing expectation
    #expect(person != nil) // Swift Test will continue to verifying the expectations, and will pass this one
}

If you need to stop test execution when a specific expectation is not met, you can use the #require macro. Unlike #expect, this is a throwing function, which requires a try statement when calling it. It can also return a value when receiving an optional as argument.

@Test func example() throws {
    let person: Person? = Person(name: "John")

    try #require(person?.name == "John") // Here the execution will stop after failing the requirement

    #expect(person != nil)
}

Note that the testing function now needs to be annotated with throws since we are using a try statement, and now it will stop the execution when not matching a requirement.
The #require macro can also be used to unwrap optional values, failing the test if the value is nil, similar to what XCTUnwrap does:

@Test func example() throws {
    let company = companyFactory.build()

    // Company's owner is an Optional type. If its value is `nil`, the test will fail pointing exactly why
    let owner = try #require(company.owner)

    #expect(owner.name == "John")
}

Naming, conditional tests and behaviors

Giving meaningful names to your tests

It is a known good practice to give rich and descriptive names to your tests. That's because when reading a report, it's easier to identify what exactly in your app is not right when tests are failing:

import XCTest

final class ExampleTests: XCTestCase {

    func testThatWhenSearchingWithAirplaneModeOnErrorMessageShouldAppear() throws {
        // ...
    }
}

Even though it's a good practice, these big function names can be difficult to read in a codebase.
With Swift Testing you can solve this problem by setting the displayName attribute in the @Test macro:

@Test("Error message is displayed when searching with airplane mode on")
func noInternetMessageOnSearch() throws {
    // ...
}

This is how you'll see each of the tests in the Xcode Test Navigator:

Additionally, Swift Testing eliminates the need of starting your function with the test prefix, giving you more flexibility.

Conditionals

During the software development process, it's not uncommon to have tests that you temporarily don't want them to be executed. In XCTest you don't have any specific tool to make a single test case not being ran, so you need to use strategies as commenting code, or adding a return to the very first line of the test case, for example.

import XCTest

final class ExampleTests: XCTestCase {

    func testUnfinishedFeature() throws {
        // This feature is not completed yet and the test is failing
        return

        // Test implementation here
    }
}

With Swift Testing, you can use Traits to handle this kind of situation in a more elegant way. Let's explore some of them:

1. `.enabled(if: Bool)`

You can use this Trait to create conditional logic that decides whether the test case should or shouldn't be executed:

@Test("New Screen loads correctly", .enabled(if: Features.newScreenEnabled))
func newScreen() throws {
    // Test implementation
}

In this case above, we have an unfinished feature, and we already have a test case for it (if you're following TDD for example, that's very common). If you want to merge your code in a stable branch, but don't want the unfinished test case to be run in the DevOps environment, the enabled(if:) trait can be very useful.

2. `.disabled()`

With the .disabled() trait you can simply disable a test. This is useful when you have a failing test that isn't a priority to fix right away, so you can disable to your tests pass, and then fix it later:

@Test(.disabled()) func myMinorFailingTest() throws {
    // Test implementation
}

The .disabled() function also accepts a String argument to add a comment about why you're disabling this test, and it's very recommendable to use it:

@Test(.disabled("This is affecting less than 1% of the users, will be fixed in the next release"))
func myMinorFailingTest() throws {
// ...

Another excellent practice you could follow when disabling tests, is using the .bug() trait. This one is used to identify a known bug that will be addressed in future, and is already reported in some bug tracker tool:

@Test(
  .disabled("Affecting few users"),
  .bug("github.com/MyProjectRepo/issues/99999", "Incorrect message being displayed")
)
func myMinorFailingTest() throws {

Running your tests with a disabled test case like that should display to you a successful output:

◇ Test run started.
↳ Testing Library Version: 102 (arm64-apple-ios13.0-simulator)
◇ Suite ExampleTests started.
◇ Test example() started.
✘ Test myMinorFailingTest() skipped: "Affecting few users"
✔ Test example() passed after 0.001 seconds.
✔ Suite ExampleTests passed after 0.001 seconds.
✔ Test run with 2 tests passed after 0.001 seconds.

Look that the myMinorFailingTest() appears there as a skipped test, along the reason for it.

3. `@available(...)`

Another reason to avoid running tests is having features that requires specific OS versions, in a moment that you cannot guarantee that all the environments that run tests already uses that version. For this scenario, instead of a Trait, you can use a different macro with the @Test one:

@Test
@available(macOS 15, *)
func useNewAPIs() {
    // ...
}

Using this macro is better than, for example, adding a guard #available(...) else to your test implementation. That's because the @available macro will not check the OS availability in runtime, as the guard statement, and you'll have clearer logs and test outputs.

Behaviors

Another challenge you may have while creating tests is creating multiple similar test cases. That happens because sometimes you have an algorithm that, depending on the input, it may create different results, so you decide to test all the different possible inputs:

final class ExampleTests: XCTestCase {
    func testThatColorHelperCorrectlyDecodesFromRGB() throws {
        let pattern = "RGB(255, 0, 0)"
        let color = ColorHelper.from(string: pattern)
        XCTAssertEqual(color, .red)
    }

    func testThatColorHelperCorrectlyDecodesFromCMYK() throws {
        let pattern = "CMYK(0, 100, 100, 0)"
        let color = ColorHelper.from(string: pattern)
        XCTAssertEqual(color, .red)
    }

    func testThatColorHelperCorrectlyDecodesFromHSV() throws {
        let pattern = "HSV(0, 100, 100)"
        let color = ColorHelper.from(string: pattern)
        XCTAssertEqual(color, .red)
    }

    func testThatColorHelperCorrectlyDecodesFromHSL() throws {
        let pattern = "HSL(0, 100, 50)"
        let color = ColorHelper.from(string: pattern)
        XCTAssertEqual(color, .red)
    }

    func testThatColorHelperCorrectlyDecodesFromHex() throws {
        let pattern = "#FF0000"
        let color = ColorHelper.from(string: pattern)
        XCTAssertEqual(color, .red)
    }

With several tests like that, if you need to change anything in the ColorHelper, you'll need to update all your test cases. Maybe you're thinking that you could optimize the code above with a forEach:

func testThatColorHelperCorrectlyDecodesFromAllPatterns() throws {
    [
        "RGB(255, 0, 0)",
        "CMYK(0, 100, 100, 0)",
        "HSV(0, 100, 100)",
        "HSL(0, 100, 50)",
        "#FF0000"
    ].forEach {
        let color = ColorHelper.from(string: $0)
        XCTAssertEqual(color, .red)
    }
}

The problem with this approach is that when failing, you don't know which pattern is making the ColorHelper not decode the color properly, so you need to debug and investigate it. Also, after adding a possible a fix to it, you'll need to re-run the test for all inputs. If your test case perform some heavy task, you may need to wait for a long time to see if your fix works.

Swift Testing then brings the parameterized tests, a way to optimize this situation. To use it, you need to use the arguments Trait, and you also need to add an argument to your test function, like that:

@Test(arguments: [
    "RGB(255, 0, 0)",
    "CMYK(0, 100, 100, 0)",
    "HSV(0, 100, 100)",
    "HSL(0, 100, 50)",
    "#FF0000"
])
func colorHelper(pattern: String) {
    let color = ColorHelper.from(string: pattern)

    #expect(color == .red)
}

When running this test, you see the following result in Xcode:

It shows us that the test is passing for all arguments, except "#FF0000". So we can analyze the ColorHelper.from function and investigate why. After finding and fixing the problem, you can re-run the test only for that argument:

After seeing a successful result, you can run it for all arguments again, and then ship your code.

Performance

There's yet another advantage of using parameterized tests: Swift Testing uses Swift Concurrency to execute tests with different arguments in parallel, optimizing resources and time.

Hierarchy

Suites

Even though it's not needed, having your tests inside some scope is possible with Swift Testing. These scopes are called Suites. For creating one, you just need to add your test case functions to a class, struct or even an actor. But you can also explicitly add a @Suite macro, that we'll cover when it's useful more ahead. Let's see a simple example with a struct:

struct CalculatorTests {
    let calculator = Calculator()

    @Test func testSum() {
        #expect(calculator.sum(number1: 2, number2: 3) == 5)
    }

    @Test func testMultiply() {
        #expect(calculator.multiply(number1: 2, number2: 3) == 6)
    }
}

In this example, CalculatorTests is a Suite. Doing it allows you making two improvements: execute all tests inside the Suite at once, and sharing dependencies across different test cases (in this case the Calculator object) through stored properties, as you would do with XCTest. The difference here, with the possibility of adding them to a struct, you have an improvement in memory management, since structs are deallocated in the moment they get out of scope, different from reference types. I have a dedicated post about how Swift handles memory here, you can read it to go further in this subject.

Suites in Swift Testing can have stored properties, as we saw in our example, and they can also use init and deinit (this last only in reference types) to perform needed tasks before and after each test case (similar to XCTest setUp and tearDown functions). This part is important: for each test case, a new Suite is instantiated, avoiding two tests sharing a same state.

actor SuiteWithTwoTests {
    init() {
        print("SuiteWithTwoTests was initialized")
    }

    deinit {
        print("SuiteWithTwoTests was deinitialized")
    }

    @Test func testOne() {
        #expect(true)
    }

    @Test func testTwo() {
        #expect(true)
    }
}

Output of the tests above:

◇ Test run started.
↳ Testing Library Version: 102 (arm64-apple-ios13.0-simulator)
◇ Suite SuiteWithTwoTests started.
◇ Test testOne() started.
◇ Test testTwo() started.
SuiteWithTwoTests was initialized
SuiteWithTwoTests was initialized
SuiteWithTwoTests was deinitialized
SuiteWithTwoTests was deinitialized
✔ Test testOne() passed after 0.001 seconds.
✔ Test testTwo() passed after 0.001 seconds.
✔ Suite SuiteWithTwoTests passed after 0.001 seconds.
✔ Test run with 2 tests passed after 0.001 seconds.

Swift Testing allows you to create nested hierarchy as well, by creating scopes inside other scopes:

struct DateTests {
    @Test func formatting() {
        // ...
    }

    struct Coding {
        @Test func encodeDate() {
            // ...
        }

        @Test func decodeDate() {
            // ...
        }
    }
}

With this nested Suites, you can execute only the inner ones by executing the Coding suite, if you want, or maybe run all tests at once by executing the DateTests.

Comparison: Swift Testing vs. XCTest

Let's recap all the differences between Swift Testing and XCTest.

Discovery

XCTest: Name begins with "Test"
Swift Testing: @Test macro

Supported types

XCTest: instance methods of a XCTestCase class object
Swift Testing: instance methods of classes, structs or actors, static methods and global functions

Traits

XCTest: not supported
Swift Testing: used to conditionally enable or disable test cases, track known bugs (either per-test or per-suite) and run parameterized tests

Parallel execution

XCTest: Launch multi process in macOS or simulators
Swift Testing: Uses Swift Concurrency, running it in-process and supports physical devices such as iPhones and Apple Watches

Continuity after failing

XCTest: By default, it stops execution on failure, but allows you to control this behavior by changing the continueAfterFailure property value
Swift Testing: Have assertion functions with different behaviors, with #expect continuing after failing and #require stopping the execution

Migrating to Swift Testing

If you liked Swift Testing so far, you can already start using it in your project, either creating the new test cases in the new framework or refactoring the existing ones into it.

If your project doesn't support unit tests yet, to start using Swift Testing you should add a Testing Target to it. For that, in Xcode go to File > New > Target, select your platform and then "Unit Testing Bundle". Make sure not to select "UI Testing Bundle":

In the next screen, fill in your project info and select Swift Testing as your "Testing System". In Xcode 16 it will be the default.
In the new folder that will be created with the same name as your target, an example test file will be created. You can add more test files to this folder and start creating your Swift Testing test cases.

If you already support Unit Tests in your project with XCTest, this step is not needed: you can add Swift Testing tests to the same target you already have.

To create your first test, just create a new file, usually with the "Tests" suffix, import Testing and start adding test cases to it:

import Testing

@testable import MyAppModule // <- Replace here

@Test("Calculator sum function sums two numbers correctly") func sum() {
    // ...
}

Importing your app's module is important so the testing target can have visibility into your app's code. Replace "MyAppModule" with the name of your app's module. The @testable macro is also important, so the testing target can have visibility to internal properties/functions.

When rewriting XCTest tests to Swift Testing, Apple recommends creating global @Test functions when you have XCTest classes with only one test case, instead of creating a Suite with one single test:

Convert from:

// DateParserTests.swift
import XCTest

final class DateParserTests: XCTestCase {
    override func setUpWithError() throws {
        // ...
    }

    override func tearDownWithError() throws {
        // ...
    }

    func testThatDateIsCorrectlyParsed() throws {
        // ...
    }
}

To:

// DateParserTest.swift
import Testing

@Test("Date is correctly parsed") func parseDate() {
    // ...
}

Limitations

Even though Swift Testing brings several new cool features, some limitations should be considered before adopting it.

Swift Testing is available only for projects written in Swift 6 using Xcode 16. Also, it doesn't support UI automation(XCUIApplication) neither performance API (XCTMetric) yet, so for these kind of tests you should still using XCTest.

Swift Testing, as the name suggests, works only with Swift, so it does not support testing code written in Objective-C.

Running from Terminal

Swift Testing is highly integrated with Swift Package Manager (SPM). When creating a SPM package, you can easily run the package tests from terminal, with the following command:

swift test

Then, you should see the results like this:

[13/13] Linking LibWithSwiftTestingPackageTests
Build complete! (45.55s)
Test Suite 'All tests' started at 2025-01-31 11:30:49.785.
Test Suite 'All tests' passed at 2025-01-31 11:30:49.795.
     Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.010) seconds
◆  Test run started.
⮑ Testing Library Version: 102 (arm64e-apple-macos13.0)
◆  Test example() started.
✅ Test example() passed after 0.001 seconds.
✅ Test run with 1 test passed after 0.001 seconds.

Conclusion

Swift Testing is a cool new framework, and today we explored its features and differences from the existing XCTest framework for unit testing. More than just learn how to use a new technology, it's important to understand why it exists and which problems it solves. Also, it's important to understand pros and cons to evaluate whether migrating makes sense.
In general, Swift Testing brings far more advantages than disadvantages in my opinion, and I'm excited for a future where it is the default testing platform for most projects.

Also, Swift Testing is an open-source project, so you can fork its repo and start contributing yourself!

Additional Resources

Debugging Memory Leaks With Instruments in XCode

Raphael Martin — Fri, 31 Jan 2025 13:55:26 +0000

Introduction

Recently, we explored Memory Leaks and Retain Cycles in Swift, diving into their causes and how to prevent them. But sometimes, apps are shipped to production with some of this issues. As engineers, it's our job to find and fix these flaws. Today, we’ll learn how to identify, analyze, and fix memory leaks in existing apps using Xcode Instruments.

Using `deinit`

When ARC deallocate an object, the deinit lifecycle function of the object is called. If you’re unfamiliar with ARC, I recommend you reading my previous post about it here first.

If deinit is never being called, you know that the object is also never being deallocated:

class MyClass {
   init() {
      print("MyClass object was initialized")
   }

   deinit() {
      print("MyClass object was deallocated")
   }
}

var obj: MyClass? = MyClass() // Output: "MyClass object was initialized"
obj = nil                     // Output: "MyClass object was deallocated"

In the example above, you see in Xcode's console that the deinit is being correctly called, meaning the object was successfully deallocated.

Let's see an example with a retain cycle:

class Car {
    var name: String
    var driver: Driver?

    init(name: String, driver: Driver? = nil) {
        self.name = name
        self.driver = driver
    }

    deinit {
      print("`Car` was deallocated")
    }
}


class Driver {
    var name: String
    var car: Car?

    init(name: String, car: Car? = nil) {
        self.name = name
        self.car = car
    }

    deinit {
      print("`Driver` was deallocated")
    }
}

func createCarAndDriver() {
   var car: Car? = Car(name: "Ferrari", driver: nil)
   var driver: Driver? = Driver(name: "Enzo", car: nil)

   car?.driver = driver
   driver?.car = car
}

createCarAndDriver()

In the above's example, no messages will appear in Xcode’s console, which indicates that both objects are failing to being deallocated.

How to use it

In your current project, if the app gets laggy or crashes when navigating to a specific screen, for example, you can take a look in which objects are instantiated when presenting this view. Suspect that an object isn’t being deallocated? Add (if it hasn't yet) a deinit to the class definition, and log or breakpoint its call. This way you can find it there's really an issue with this object allocation.

Pros/Cons

This isn't the most pragmatic way of debugging memory leaks, and depends on trial and error. But, for simple cases (small projects or small code bases) it can be enough.

Use Instruments to Find Retain Cycles

While tracking deinit calls works for simpler cases, Instruments offers a more sophisticated way to identify memory leaks. It's a debugging tool with several templates to you find complex issues with you application, such as memory, network, and even specific tools for games. Let's see how to use Instruments to detect some leaks:

Creating a new Project: Firstly, we're going to create a new iOS project in Xcode to be our example. Ensure that on Platform you are selecting iOS and on Application App:
Project properties: Set the project's name and company identifier. Let's call it "DebugginRetainCycles", select "SwiftUI" for interface:
Adding the flawed objects: Go to the app's entrypoint file, that should be named DebuggingRetainCyclesApp.swift. Here you'll have a SwiftUI object that implements the App protocol. At the end of the file, copy and paste these Car and Driver objects from the previous example, and also the createCarAndDriver() function declaration.
Instantiating the objects: Add an initializer to the DebuggingRetainCyclesApp struct, and inside it call the createCarAndDriver() function. That will make our app allocate both objects at its first launch, creating a retain cycle.
Profile the app: In XCode select the menu Product > Profile, or just press cmd+I. Xxode will build your project and open the Instruments Template window. Pay attention that it can appear unfocused in your desktop:
Selecting the template: In this new window, select the Leaks template:
Record and Analyze: After selecting it, a simulator will be launched, and an Instruments window with the profiling result will appear. If Xcode already finished building the app, click on the "Record" button at the Instruments window, otherwise wait for Xcode finish the building process first, and then click in that button. This will make the simulator launch the app, and Instruments start tracking and recording the memory usage of the app.
Finding Leaks Existence: Now, you just should wait for some time and Instruments will give you a result of leaks found. In our case, we added the Retain Cycle direct to the launch of the app, but in a real scenario you may need to do some interaction with your app to simulate it (as navigating to a problematic screen). After performing the actions that you suspect that is causing a leak, wait for some time and the result should appear in the Leaks row, just below the Allocations one. In our case, just launching the app and waiting for about 20 seconds did the trick:
Detect Location: Select the Leaks row, and you'll see two leaked objects: Car and Driver. You can now stop recording the memory. Selecting one of them will display the Stack Trace panel in the right side, that tells you where in the code this object is being created. In Xcode, navigate to the indicated file, investigate the cause and fix it. In our case, we're fixing it by making the Driver.car reference weak. More about that in How To Prevent Retain Cycles?.
Testing the Fix: Profile the app again, by pressing cmd+I. After Xcode finishing the build process, start recording again in the Instruments window and wait for the Leaks result. You should see a successful message:

Repeating these same steps in a real-world project will show you a report of found leaks, with the proper Stack Trace, which can help you find the location, and consequently, the cause of the leak.

Write Test Cases

You can also use Unit Tests to validate the inexistence of retain cycles, and also guarantee that they will not be added in future, if you run tests periodically in your development proccess:

func testCarReferenceIsWeak() {  
    var person: Person? = Person(name: "Alice")  
    let car = Car(name: "Ferrari", driver: person)  
    XCTAssertEqual(car.driver, person) // Asserts that the driver is correctly set
    person = nil  
    XCTAssertNil(car.driver)           // Asserts that the object is correctly deallocated 
}

In this test case, we validate that the Person object successfully sets a Person as driver, and also successfully deallocate it when needed, ensuring that this class will not bring a retain cycle to your app.

Conclusion

Debugging memory leaks can be challenging, but using the right tools makes the process manageable. Today, we explored how to identify leaks using deinit, Instruments, and Unit Tests, ensuring your app maintains optimal memory management.

Bookmark this guide as a reference for the future. While I hope you don’t encounter memory leaks often, these steps will guide you when you do.

Design Patterns in Swift: Factory

Raphael Martin — Fri, 24 Jan 2025 15:37:59 +0000

The Factory Design Pattern

This is the first post of a series about Design Patterns! And we're starting with a very useful one for Swift applications: Factory.

This pattern consists in centralizing the object creation logic of your application in a proper place, benefiting from the abstraction concept.

If you're feeling a bit lost about abstraction, you can refer to my post about OOP in Swift.

Problem Context

When adding a new Design Pattern to your software, you should always think in which problem this pattern solves.
With Factory, we are usually trying to solve problems related to object creation, but not only it.

Coupled Lego bricks

Coupling

Imagine working on a new Social Network app, and in its first version it should supports textual posts only, that will be called Articles. So, you create a custom ArtcileView class, with everything that you need for each post:

class ArticleView: UIView {
    private lazy var contentLabel: UILabel = {
        // Defines the label attributes
    }()

    private lazy var likeButton: UIButton = {
        // Defines the button attributes
    }()

    init() {
        super.init(frame: .zero)
        setupView()
    }

    required init?(coder: NSCoder) {
        fatalError("init(coder:) has not been implemented")
    }

    private func setupView() {
        backgroundColor = .white

        // Add subviews
        addSubview(contentLabel)
        addSubview(likeButton)

        // Set up constraints
        setupConstraints()
    }

    private func setupConstraints() {
        // Set the constraints
    }

    @objc private func didTapLikeButton() {
        // Make request to service, saving that the current user liked this post
    }
}

In an implementation like that, all the logic related to the behavior of liking posts is centralized in the ArticleView. Your business logic now is tightly coupled to your view class.

In future, if you decide to implement image posts, with an ImageView for example, you'll need to duplicate the logic for the "like" action, and also add logic to determine which class to initialize:

class ContentViewManager {
    func createView(for contentType: String) -> UIView {
        if contentType == "article" {
            return ArticleView()
        } else if contentType == "image" {
            return ImageView()
        } else {
            fatalError("Unsupported content type: \(contentType)")
        }
    }
}

This kind of implementation has several problems, such as violation of Open/Closed Principle (OCP) and making testing harder.

What is the Factory Design Pattern?

Factory is a Design Pattern that uses factory methods to create different types of objects, that share a same more abstract type, without the need of specifying directly the concrete type of the desired object. So factories are similar to what we saw in the previous example with the ContentViewManager class, but without violating any SOLID principle and not coupling your logic.

To achieve that, Factory uses a lot the abstraction OOP concept. First, we need an abstract type to represent the objects we're trying to create. In Swift, usually protocols are used, but in other languages you can see abstract classes as well. Let's see how would it be in our Social Network app example:

protocol LikeablePost: UIView {
   func likePost()
}

class ArticleView: UIView, LikeablePost {
    // ...
}

class ImageView: UIView, LikeablePost {
    // ...
}

Then, you also need another abstract type (we're using a protocol again) for defining how your factories should looks like:

protocol PostFactory {
    func makePost() -> LikeablePost
}

Look that the return type of our makePost() function is our abstract type previously created. Now, we are able to create new factories every time we need to create new children of LikeablePost:

class ArtcileFactory: PostFactory {
    func makePost() -> LikeablePost { ArticleView() }
}

class ImageFactory: PostFactory {
    func makePost() -> LikeablePost { ImageView() }
}

Now, your object creation logic is open for extension, but closed for modification, since you don't need to change any existing implementation to add support for new types, just extend it.

How to instantiate a Factory

After creating the factories, now you need some logic to decide which factory you should use when needed. For that, you could create a Resolver:

class PostFactoryResolver {
    static func getFactory(for contentType: String) -> PostFactory {
        switch contentType {
        case "article":
            return ArticleFactory()
        case "image":
            return ImageFactory()
        default:
            fatalError("Unsupported content type: \(contentType)")
        }
    }
}

// Usage:
let factory = PostFactoryResolver.getFactory(for: "article") 
let postView = factory.makePost()

You may have noticed that this approach is very similar to what we had in our ContentViewManager, before implementing the Factory pattern. And that similarity can still violate the OCP since it will need changes when adding new types to the app. However, we have significant improvements compared to the previous implementation:

Isolation: the decision logic for creating the view objects is isolated from the business logic files.
Decoupling: the client code interacts only with the factories, and not with the views. Also, the views now are more testable since they are easy to mock.

A more robust approach

We can still achieve a fully OCP-compliant approach, using a combination of dynamic registration and dependency injection.
Dynamic Registration is the idea of registry object instances in a place with global visibility to be accessed by clients through an identifier. Here's an example:

class FactoryRegistry {
    private var factories: [String: PostFactory] = [:]

    func registerFactory(for contentType: String, factory: PostFactory) {
        factories[contentType] = factory
    }

    func getFactory(for contentType: String) -> PostFactory? {
        return factories[contentType]
    }
}

// Usage:
let registry = FactoryRegistry() 
// Register factories (can be done at app initialization or runtime)
registry.registerFactory(for: "article", factory: ArticleFactory())
registry.registerFactory(for: "image", factory: ImageFactory())

Then, we can use dependency injection to inject the desired factory in the needed class.


let post = await fetchPostFromAPI(withId: "ABC1234")

// `post.type` is a String that can be "article" or "image"
if let factory = registry.getFactory(for: post.type) { 
    let postView = factory.makePost() // Use `postView` here

    // Add the postView to the view hierarchy
} else { 
    print("No factory registered for this content type.") 
}

Now, adding a new content type doesn't require modifying any existing code, just register the new factory.

If in future, you need to support video posts, you'll just need to:

registry.registerFactory(for: "video", factory: VideoFactory())

Disadvantages

So far, we have explored how Factory is useful for decoupling, adding flexibility and in some cases, making testing easier. However there are some cons that should be considered when thinking about implementing it in your app:

1. Complexity

Even though the examples we explored here for the post views brought several benefits, you can see that the code is now more complex. We created several different new types, including protocols and classes, increasing the size of our code base.

2. Often Not "Self-Documenting"

Without an explicit documentation for it, or yet not using a good naming convention, factories can be hard to understand at first sight. That increases the learning curve for new team members, impacting the general team's performance.

3. Violations of OCP

As we saw today, without a more robust implementation (that brings more complexity), factories can lead to a violation of the Open/Closed Principle.

Conclusion

Today we went through common problems in Software Engineering regarding objects creation and coupling, how the Factory design pattern can help with it, how to implement it and also disadvantages to consider when choosing it.
I hope that adding this new Design Pattern to your toolkit will help you in your software development journey!

Retain Cycles and Memory Leaks in Swift

Raphael Martin — Fri, 17 Jan 2025 15:28:13 +0000

Memory Leaks

A memory leak can happen in your Swift application when it is allocating memory but failing to release it back to the OS when it's no longer needed. When coding in Swift (and even in Objective-C), with the level of abstraction that the language has, it's common that you don't think about memory management, but this behavior can lead you to performance issues, or in the worst scenarios to crashes. Today we'll review how and why it happens, and good strategies to debug and fix these problems.

Automatic Reference Counting (ARC)

Maybe you were just a kid, but in 2011 at the WWDC of that year, Apple announced the Automatic Reference Counting, or just ARC. You can find the video here.

Screenshot of the WWDC11 slides presentation introducing ARC

With ARC, Apple was trying to introduce an easier way to handle memory and avoid crashes in our apps. For that, ARC automatically (that's the A in the acronym) tracks and manages the memory usage of objects, deallocating them when it identify that it's not needed anymore.

With that explanation, it's easy to think that ARC works as a garbage collector, but you'll see below that this is NOT the case.

How it works

In Swift, every time you instantiate a reference type and sets it to a variable/constant, ARC will literally count (hence the 'C' in the acronym) the number of references to a specific instance.
If you set the same reference (not instantianting an equal value again) to another variable or constant, ARC will count one more reference to that instance.

class Person {
    let name: String
    init(name: String) {
        self.name = name
        print("\(name) is initialized")
    }
    deinit {
        print("\(name) is being deinitialized")
    }
}

var person1: Person? = Person(name: "Alice") // Reference count = 1
var person2 = person1                        // Reference count = 2

This counting value is stored in the Object's Header Metadata, in the Heap Memory.

Every time the execution of your code reaches an end of scope (as the end of a function, or the end of an if/else block, for example), ARC will automatically check all the new references made inside this scope, and reduce its value in the counter if it has no references for it:

func createPerson() {
   var person1: Person? = Person(name: "Alice") // Reference count = 1
   var person2 = person1                        // Reference count = 2
} // Reference count = 0, since 2 new references were made inside the scope

Or yet:

var person1: Person? = Person(name: "Alice") // Reference count = 1

func createPerson() {
   var person2 = person1 // Reference count = 2
} // Reference count = 1, since only 1 new reference was made inside the scope

ARC will not reduce the counting only when reaching an end of scope. It also controls the counting when explicitly deallocating an object:

var person: Person? = Person(name: "Alice") // Reference count = 1
person = nil                                // Reference count = 0

Every time a reference counting reaches 0, ARC free the space that this object was taking in memory, making it avaible for new allocations. That eliminates the need for a Garbage Collector, avoiding performance issues such as pauses for periodic GC cycles.

ARC will also count references when setting reference type objects to other object properties, creating a nested dependency:

class Person {  
    var name: String  
    var dog: Dog?

    init(name: String, dog: Dog?) {  
        self.name = name  
        self.dog = dog  
    }  
}  

class Dog {  
    var name: String

    init(name: String) {  
        self.name = name
    }  
}

func createPerson() {
   var alice = Person(name: "Alice", dog: nil) // Reference count to Alice = 1
   var fido = Dog(name: "Fido")                // Reference count to Fido = 1

   alice.dog = fido                            // Reference count to Fido = 2
} /* Here ARC will start reducing the counting

1. Reduce the `alice` reference count from 1 to 0, since it is not referenced anywhere else. This will trigger the deallocation of the `alice` object.
2. After `alice` is deallocated, the reference count of `fido` will be reduced from 2 to 1, since it was referenced in `alice.dog` but has no other references.
3. Finally, reduce the `fido` reference count from 1 to 0, triggering the deallocation of the `fido` object, as it is no longer referenced anywhere.

*/

Retain Cycles

Even though ARC helps us with memory management, its existence doesn't eliminate all the problems we could have while developing with Swift. The most common issue you may face in that area is a retain cycle.

How do Retain Cycles Happen in Swift?

Retain cycles can happen in Swift when at least two objects reference each other, closing a cycle. Here’s an example:

class Person {  
    var name: String  
    var dog: Dog?

    init(name: String, dog: Dog?) {  
        self.name = name  
        self.dog = dog  
    }  
}  

class Dog {  
    var name: String  
    var owner: Person?

    init(name: String, owner: Person?) {  
        self.name = name  
        self.owner = owner  
    }  
}

func createPersonAndDog() {
   var alice = Person(name: "Alice", dog: nil)
   var fido = Dog(name: "Fido", owner: nil)

   alice.dog = fido
   fido.owner = alice
} // Here ARC will fail to deallocate the references made inside the function

createPersonAndDog()

Differently from the previous example, here ARC will not be able to reduce the count for the alice object to 0, because it is referenced somewhere else: in the owner property of the fido object. And it also cannot reduce the fido counting to 0, because it's referenced in alice.dog. This is a Retain Cycle.

How to Prevent Retain Cycles in Swift Code?

In Swift, when you assign an instance of a reference type to anything (variable, constant or property), it creates a reference. But Swift has two types of references: the strong and weak ones. Strong references are the default, and every reference that you saw in this article's code snippets so far are the strong ones. To create weak references, you need to use one of the reserved words for it: weak or unowned. Let's take a look in the first one:

// `Person` class remains unchanged

class Dog {  
    var name: String  
    // Made this property weak
    weak var owner: Person?

    init(name: String, owner: Person?) {  
        self.name = name  
        self.owner = owner  
    }  
}

func createPersonAndDog() {
   var alice = Person(name: "Alice", dog: nil)
   var fido = Dog(name: "Fido", owner: nil)

   alice.dog = fido
   fido.owner = alice
}

createPersonAndDog()

Look that we changed var owner: Person? to weak var owner: Person?

Making the relation "Dog has an Owner" a weak one, solved the retain cycle. But how?

Making a reference weak is just telling to ARC: Please, do not count this reference. The count for it will always be 0, breaking the cycle. Let's analyze the code sequentially for a better understanding:

When we do alice.dog = fido, we create a strong reference to the Persons dog property, so ARC will count +1 there.
However, when we do fido.owner = alice, we are adding an owner to a weak reference (Dog has an owner), so ARC will ignore it and not count that alice is being referenced.
When the execution reaches the end of scope, ARC will check if it's possible to deallocate alice, and now it will be, since it's not referenced anywhere.
After deallocating it, nowhere else will reference fido, so ARC will decrease the reference counter of it to 0, and then deallocate it.

Now, both objects were deallocated, and you have more free space in memory for new allocations.

So, if you need one sentence that summarizes how to avoid a retain cycle, it would be: "When you have a cycle of dependencies, at least one of the references needs to be weak".

Precautions When Creating Weak References

Maybe you now have a question: "You told me that every time an object reference count reaches zero ARC deallocate it. And weak references do not increase the reference count. Why isn't it deallocated immediately after being created?".

And the answer for it is: "It will be. At least if you're doing it wrongly".

In this example above, the variable dogOwner is an weak one, which means that the count for it in ARC will always remain zero. So setting a value in it, that is not being referenced anywhere else, will take no effect.

So, in order to set values to weak references, you need to have this value set somewhere else, in a strong reference:

Weak are always Optionals

Another precaution that you should have when working with weak references is that they're always an Optional value:

As I previously mentioned, Swift has the unowned word for also creating weak references. You can use it the exact same way as weak, but with a difference: you don't need to specify that that variable has an optional value. But trust me, it still an Optional:

class Dog {
    var name: String
    unowned var owner: Person

What happens here is that the compiler does an automatic force unwrap to you, as you're adding an ! in everyplace you are using this variable. That's considered by many as a bad smell, and personally, I try to avoid using it.

Conclusion

Today, we explored memory management in Swift, understanding how ARC works, the causes of retain cycles, and strategies to avoid them. These are critical concepts to master and valuable practices to integrate into your development workflow.

Despite our best efforts to prevent memory leaks, unexpected issues can still arise, leading to flawed software. In the next #memorymanagement article, we will delve into How to Debug Memory Leaks with Instruments, Xcode's official tool for memory debugging. Stay tuned!

Forem: Raphael Martin

What Really Are The Differences Between SwiftUI and UIKit?

Introduction

What SwiftUI is not

So What Is It?

Commonly Mentioned Advantages of SwiftUI (That May Not Be True)

Declarative Syntax is Better

Xcode Preview

SwiftUI Is More Future-Proof

Reactivity

1. Binding vs Setting

2. You can write Reactive code in UIKit

What Being Declarative Really Means to SwiftUI

Updating the View

Reactivity

ViewModifiers vs properties of UIView objects

Diffing Algorithm

UIKit comparison: manual diffing

When identifiers are not stable

When identifiers are not unique

Runtime Render Decision

Conclusion

References

Swift Testing: My First Impressions

Introduction

Testing Asynchronous Code

Explicitly Failing Tests

Known Issue About Recording Tests Issues

Build Time Performance

Good News

Overall Opinion

Additional Resources

Creating a Network Layer with URLSession in Swift

Introduction

What is URLSession

Analyzing the code above:

Thread management

Why Creating a Separate Layer

Creating the Network Layer

API Client

Authentication

Creating the response model

Endpoint Model

Service Abstraction

Concrete Service

Error Handling

Cancellation

Testing

Additional Resources

Conclusion

Design Patterns in Swift: Singleton

What is Singleton

How to Create a Singleton

1. Creating a Globally-Visible Object in Swift

2. Creating a Singleton

3. Is Any static Property in a Type, That Holds an Instance of the Type Itself, a Singleton?

Impact on Unit Testing

How to Create Testable Code with Singletons

Best Practices

Impact in Memory

1. Increasing Memory Usage

2. Data races

Conclusion

Don't Panic: What Apple's iOS 18 SDK Update Really Means for Your App!

Introduction

Understanding the Difference

iOS SDK

Frameworks and APIs

Compilers and Build Tools

Debugging Tools

iOS Deployment Target

What changes then?

Access to New APIs

Deprecations

Performance Improvements

How To Set It Up

Setting the iOS Deployment Target

Archiving and Submitting to Apple Store Connect manually

Automated CI/CD Pipelines

What Happens in April 2025?

`ViewModifiers` vs properties of `UIView` objects

What is `URLSession`

3. Is Any `static` Property in a Type, That Holds an Instance of the Type Itself, a Singleton?

1. `.enabled(if: Bool)`

2. `.disabled()`

3. `@available(...)`