iOS development by tanaschita.com

Supporting Differentiate Without Color in SwiftUI

Sun, 11 Oct 2026 22:00:00 GMT

Color can make the state of an interface easy to recognize at a glance. But if color is the only difference between two states, that information may not be available to everyone.

In this article, we'll use SwiftUI's accessibilityDifferentiateWithoutColor environment value to add a second visual cue when the corresponding system setting is enabled.

Starting with a color-only status

Suppose we use a colored circle to show whether something is available:

Circle()
    .fill(isAvailable ? .green : .red)
    .frame(width: 28, height: 28)
    .accessibilityLabel(
        isAvailable ? "Available" : "Unavailable"
    )

The accessibility label communicates the state to assistive technologies such as VoiceOver, but the visible interface still relies entirely on the difference between green and red.

We can make the two states visually distinct by adding a checkmark or an xmark when the user asks the system to differentiate without color.

Reading the system preference

Users can enable Differentiate Without Color in the Settings app under Accessibility → Display & Text Size → Differentiate Without Color.

SwiftUI exposes that preference as a Boolean environment value:

@Environment(\.accessibilityDifferentiateWithoutColor)
private var differentiateWithoutColor

Because it is an environment value, SwiftUI updates views that read it when the setting changes.

Adding a second visual cue

We can now overlay a symbol when the preference is enabled:

struct AvailabilityIndicator: View {
    @Environment(\.accessibilityDifferentiateWithoutColor)
    private var differentiateWithoutColor

    let isAvailable: Bool

    var body: some View {
        Circle()
            .fill(isAvailable ? .green : .red)
            .frame(width: 28, height: 28)
            .overlay {
                if differentiateWithoutColor {
                    Image(systemName: isAvailable ? "checkmark" : "xmark")
                        .font(.caption.bold())
                        .foregroundStyle(.white)
                }
            }
            .accessibilityLabel(
                isAvailable ? "Available" : "Unavailable"
            )
    }
}

With the setting disabled, the indicator keeps its original appearance. With the setting enabled, its meaning no longer depends on distinguishing the two colors.

Depending on the interface, the additional cue can also be a text, different shapes, patterns or a change in position may communicate the distinction more clearly.

Designing beyond the preference

Depending on the design, it may also make sense to show the checkmark and xmark by default. This makes the states distinguishable without color for everyone and removes the need for a conditional adaptation.

accessibilityDifferentiateWithoutColor is useful when the additional visual cue works better as an alternative presentation, for example when symbols would otherwise add too much visual density to a compact interface.

Testing both appearances

We can use previews to compare the indicator with the preference disabled and enabled:

#Preview("Default appearance") {
    HStack(spacing: 20) {
        AvailabilityIndicator(isAvailable: true)
        AvailabilityIndicator(isAvailable: false)
    }
    .padding()
}

#Preview("Differentiate without color") {
    HStack(spacing: 20) {
        AvailabilityIndicator(isAvailable: true)
        AvailabilityIndicator(isAvailable: false)
    }
    .padding()
    .environment(\.accessibilityDifferentiateWithoutColor, true)
}

When testing the settings on a device or simulator, Xcode's Accessibility Inspector can override Differentiate Without Color as well, which makes it useful for checking several screens without repeatedly changing the system setting.

A grayscale color filter can reveal places that rely heavily on color, but it isn't a simulation of how every person with a color vision difference sees the interface. It is a useful additional check, not a replacement for providing another visual cue.

Conclusion

SwiftUI's accessibilityDifferentiateWithoutColor environment value tells us whether the user enabled the corresponding system setting. We can use it to provide an alternative presentation with symbols, shapes, text or other visual cues.

Adapting SwiftUI layouts for large Dynamic Type sizes

Sun, 04 Oct 2026 22:00:00 GMT

A layout that works well at the default text size can become cramped when Dynamic Type increases the content size. Supporting Dynamic Type therefore also means allowing the layout to grow or change its structure.

In this article, we'll adapt a task row that works horizontally at standard text sizes but becomes difficult to read at larger accessibility sizes. For an introduction to scaling system and custom fonts, check out the article on supporting Dynamic Type in SwiftUI.

Starting with a horizontal layout

Suppose a task row displays its title next to a due date:

HStack(alignment: .firstTextBaseline, spacing: 12) {
    Text(title)
        .font(.headline)
        .frame(maxWidth: .infinity, alignment: .leading)

    Label(dueDate, systemImage: "calendar")
        .font(.subheadline)
        .foregroundStyle(.secondary)
}
.padding()
.background(.quaternary, in: .rect(cornerRadius: 12))

At a standard text size, both pieces of information have enough horizontal space. At an accessibility size, the title and due date grow while still sharing the same row. The title may wrap into a narrow column even though it would remain easy to read if it could use the full width.

To solve this, we can place the due date below the title when an accessibility size is active.

Switching layout for accessibility sizes

SwiftUI exposes the current text size through the dynamicTypeSize environment value. Its isAccessibilitySize property tells us whether the user selected one of the larger accessibility categories.

We can use that value to choose between HStackLayout and VStackLayout:

private struct TaskRow: View {
    @Environment(\.dynamicTypeSize) private var dynamicTypeSize

    private var taskLayout: AnyLayout {
        if dynamicTypeSize.isAccessibilitySize {
            AnyLayout(
                VStackLayout(alignment: .leading, spacing: 8)
            )
        } else {
            AnyLayout(
                HStackLayout(alignment: .firstTextBaseline, spacing: 12)
            )
        }
    }

    var body: some View {
        taskLayout {
            Text(title)
                .font(.headline)
                .frame(maxWidth: .infinity, alignment: .leading)

            Label(dueDate, systemImage: "calendar")
                .font(.subheadline)
                .foregroundStyle(.secondary)
        }
        .padding()
    }
}

AnyLayout lets both layouts contain the same views. At standard sizes, the title and date remain next to each other. At accessibility sizes, the vertical layout gives each of them the full row width.

How AnyLayout works

Although AnyLayout is a type-erased layout, it doesn't erase the child views in the way that AnyView erases a view. It only hides whether the active layout algorithm comes from HStackLayout, VStackLayout or another type conforming to the Layout protocol.

The trailing closure still builds the Text and Label as the same child views. A type conforming to Layout receives a LayoutSubviews collection containing a proxy for each child, which it can measure and position. AnyLayout forwards those proxies to the wrapped layout algorithm. When the selected layout changes, SwiftUI therefore rearranges the existing children instead of replacing their view hierarchy, preserving their identity and state.

Choosing when to change the layout

A narrow device, a long localized title or additional row content might require the vertical layout at an earlier text size.

If the decision is primarily about the available width rather than the selected text size, ViewThatFits may be a better choice because it selects a layout based on which version fits. The article on building adaptive layouts with ViewThatFits covers that approach in more detail.

Testing at larger text sizes

We can preview the same row at different Dynamic Type sizes by changing the environment:

#Preview("Default text size") {
    TaskRow(
        title: "Prepare the accessibility audit article",
        dueDate: "Today"
    )
    .padding()
}

#Preview("Accessibility 3") {
    TaskRow(
        title: "Prepare the accessibility audit article",
        dueDate: "Today"
    )
    .padding()
    .environment(\.dynamicTypeSize, .accessibility3)
}

Conclusion

Supporting Dynamic Type doesn't end when text grows with the user's preferred size. The surrounding layout also needs to give that text enough room.

isAccessibilitySize and AnyLayout keep that solution compact: one environment value drives the decision, and the same child views are reused in both layouts without losing their identity or state.

Automating accessibility audits for SwiftUI apps with XCTest

Sun, 27 Sep 2026 22:00:00 GMT

Many standard SwiftUI views include accessibility support out of the box. However, custom layouts, styling and content can still lead to missing descriptions, insufficient contrast, clipped text or controls that are difficult to activate.

XCTest accessibility audits allow us to detect many of these issues automatically in a UI test. In this article, we'll look at how to do that. Let's jump in.

Adding an accessibility audit to a UI test

We can add accessibility audits to an Xcode UI test target using XCTest. The audit API is available on XCUIApplication, so it isn't available from a unit test or a Swift Testing test function.

To navigate to a specific screen reliably, the UI test needs stable identifiers. We assign them to the corresponding SwiftUI views using accessibilityIdentifier(_:), for example:

Text("Library")
    .accessibilityIdentifier("screen.library.title")

With identifiers in place, a first audit example may look as follows:

import XCTest

final class LibraryAccessibilityTests: XCTestCase {
    private var app: XCUIApplication!

    @MainActor
    override func setUpWithError() throws {
        app = XCUIApplication()
        app.launch()
    }

    @MainActor
    func testOverview() throws {
        app.tabBars.buttons["tab.library"].tap()
        XCTAssertTrue(
            app.staticTexts["screen.library.title"]
                .waitForExistence(timeout: 2)
        )

        try app.performAccessibilityAudit()
    }
}

performAccessibilityAudit() inspects the currently visible screen. If it finds an issue, the UI test fails and Xcode reports the affected element and audit type. We don't need to add a separate assertion.

By default, the method runs all applicable audit types. On iOS, these include checks for:

missing or insufficient element descriptions
small hit regions
insufficient contrast
inaccessible content that may need to be exposed as separate elements
clipped text
missing Dynamic Type support
invalid accessibility traits

The audit inspects the state currently presented by the app.

Auditing relevant screens and states

To cover different screens and states, we can use familiar UI testing techniques to navigate to each one before running the audit. For example, another test can open a book from the library and audit its detail screen:

@MainActor
func testBookDetails() throws {
    app.tabBars.buttons["tab.library"].tap()

    let book = app.buttons["library.book.swift-concurrency"]
    XCTAssertTrue(book.waitForExistence(timeout: 2))
    book.tap()

    XCTAssertTrue(
        app.staticTexts["screen.bookDetails.title"]
            .waitForExistence(timeout: 2)
    )

    try app.performAccessibilityAudit()
}

Waiting for the detail title before starting the audit prevents the test from accidentally inspecting the library while the transition is still in progress.

Useful cases are states that expose different content or interactions, for example:

an empty list and a populated list
a form before and after validation errors appear
loading, success and error states
sheets, alerts and menus
screens at important points in the main user workflows

Handling known audit issues

Sometimes an audit reports an issue that we have reviewed and knowingly accepted, for example while a design change is still pending. An audit can also occasionally report a false positive.

In those cases, we can use the optional issue handler to make an exception for that exact finding:

@MainActor
func testFeaturedBooks() throws {
    app.tabBars.buttons["tab.library"].tap()
    XCTAssertTrue(
        app.staticTexts["screen.library.featured.title"]
            .waitForExistence(timeout: 2)
    )

    try app.performAccessibilityAudit { issue in
        issue.auditType == .contrast &&
        issue.element?.identifier == "screen.library.featured.title"
    }
}

The handler returns true only for the accepted contrast issue on the featured title. Every other issue continues to fail the test.

Investigating issues with Accessibility Inspector

When an automated audit fails, Accessibility Inspector helps us inspect the issue interactively. We can open it from Xcode → Open Developer Tool → Accessibility Inspector, select the running app and switch to the Audits pane.

After running an audit for the current screen, we can:

select an issue to highlight the affected element in the app
inspect its accessibility label, value, traits and available actions
read the explanation and suggested fix
save the audit results as an HTML report

Accessibility Inspector uses the same kinds of checks as performAccessibilityAudit(), but it is better suited to understanding and debugging a reported issue. Automated UI tests are better suited to detecting when that issue returns later.

Understanding the limits of automated audits

Passing an audit doesn't guarantee that an app provides a good accessibility experience. An audit can detect a missing label, but it can't reliably decide whether the label is useful in context or whether the VoiceOver navigation order makes sense for the workflow.

Automated audits should therefore be complemented by testing the main workflows with assistive technologies such as VoiceOver.

Conclusion

XCTest accessibility audits give us a repeatable way to catch common accessibility regressions during development. By running them after navigating to meaningful screens and states, we can include accessibility checks in the regular UI test suite rather than relying on a one-time review before release.

When an audit fails, Accessibility Inspector helps us understand the affected element and resolve the issue. Together, automated audits and focused investigation provide fast feedback whenever a UI change introduces a common accessibility problem.

Parameterized tests and test organization with Swift Testing

Sun, 20 Sep 2026 22:00:00 GMT

As a test suite grows, we often end up writing multiple test functions that exercise the same behavior with slightly different inputs. Each test is simple on its own, but the repetition makes the whole suite harder to scan and maintain.

Swift Testing addresses this with parameterized tests. They let us pass a collection of arguments to one test function and create a separate test case for each argument. We can then use suites and tags to keep those cases organized as the project grows.

In this article, we'll look at how to:

Replace repetitive tests with a parameterized test.
Model more complex inputs as test cases.
Test combinations of multiple argument collections.
Organize tests with suites, nested suites and tags.
Keep parallel execution in mind when structuring a suite.

If you're new to the framework, you can start with this developer guide on Swift Testing, which covers test functions, expectations and the differences from XCTest.

Replacing repetitive tests with a parameterized test

Let's say our app contains a formatter that turns a title into a URL slug:

struct SlugFormatter {

    let separator: String

    init(separator: String = "-") {
        self.separator = separator
    }

    func format(_ title: String) -> String {
        title
            .lowercased()
            .replacingOccurrences(of: " ", with: separator)
    }
}

We could test several inputs by creating a separate test function for each one:

import Testing
@testable import ExampleApp

struct SlugFormatterTests {

    @Test func formatsSingleWord() {
        let result = SlugFormatter().format("Swift")
        #expect(result == "swift")
    }

    @Test func formatsMultipleWords() {
        let result = SlugFormatter().format("Swift Testing")
        #expect(result == "swift-testing")
    }

    @Test func formatsEmptyString() {
        let result = SlugFormatter().format("")
        #expect(result == "")
    }
}

The arrange and assertion logic is identical in all three tests. Only the input and expected output change. We can keep each pair together in a small test-case type:

struct SlugTestCase: Sendable {
    let title: String
    let expectedSlug: String
}

extension SlugTestCase {
    static let examples = [
        SlugTestCase(title: "Swift", expectedSlug: "swift"),
        SlugTestCase(title: "Swift Testing", expectedSlug: "swift-testing"),
        SlugTestCase(title: "", expectedSlug: "")
    ]
}

@Test(arguments: SlugTestCase.examples)
func formatsTitle(_ testCase: SlugTestCase) {
    let result = SlugFormatter().format(testCase.title)
    #expect(result == testCase.expectedSlug)
}

Swift Testing creates an individual test case for every element in the collection and passes that element to the test function. If one case fails, Xcode reports the corresponding argument, which makes the failing input easier to identify than a failure inside a manual loop.

As a shorter alternative, we can keep the inputs and expected outputs in separate collections and combine them with zip:

@Test(
    arguments: zip(
        ["Swift", "Swift Testing", ""],
        ["swift", "swift-testing", ""]
    )
)
func formatsTitle(_ title: String, expectedSlug: String) {
    let result = SlugFormatter().format(title)
    #expect(result == expectedSlug)
}

zip pairs the first title with the first expected slug, the second title with the second expected slug and so on. This gives us the same three test cases without introducing SlugTestCase. However, the two collections need to stay in the same order. A dedicated type keeps each input visibly next to its expected output and scales better when a test needs more values.

Testing more than one collection of arguments

We can also pass multiple collections to a parameterized test. Unlike zip, Swift Testing then uses the Cartesian product: every value from the first collection is paired with every value from the second.

This is useful when the same expectation applies to every combination. For example, suppose both editors and administrators should be able to edit every supported content type:

enum UserRole {
    case editor
    case administrator
}

enum ContentType {
    case article
    case video
}

@Test(
    arguments: [UserRole.editor, .administrator],
               [ContentType.article, .video]
)
func authorizedRoleCanEdit(_ role: UserRole, contentType: ContentType) {
    let result = Permissions().canEdit(contentType, as: role)
    #expect(result == true)
}

With two roles and two content types, Swift Testing creates four test cases. The expected result is explicit and doesn't need to be derived inside the test. If only particular roles and content types should be paired, zip or a dedicated test-case type would be a better fit than a Cartesian product.

Organizing tests in suites

Any Swift type that contains test functions acts as a test suite. We don't need to add @Suite when the type name already describes the group clearly:

struct SlugFormatterTests {
    @Test func formatsTitles() { ... }
    @Test func usesCustomSeparators() { ... }
}

Here, the suite groups two related behaviors of SlugFormatter, and that hierarchy is reflected in Xcode's Test navigator. As the suite grows, we can nest additional suite types to separate meaningful groups such as default formatting and custom separators.

The @Suite attribute becomes useful when we want to apply traits to the whole group or need a custom display name that adds information beyond the type name. We shouldn't add it only to repeat a name that is already clear in code.

Grouping related tests with tags

Suites create a source-level hierarchy: every test belongs to one place in that hierarchy. Tags provide an additional way to group tests across files and suites.

We first declare the tags as static members of Tag:

extension Tag {
    @Tag static var formatting: Self
    @Tag static var critical: Self
}

We can then apply them to an individual test:

@Test(
    .tags(.formatting, .critical),
    arguments: SlugTestCase.examples
)
func formatsTitle(_ testCase: SlugTestCase) {
    let result = SlugFormatter().format(testCase.title)

    #expect(result == testCase.expectedSlug)
}

Or we can apply a tag to a suite. Its tests and nested suites inherit that tag:

@Suite(.tags(.formatting))
struct SlugFormatterTests {
    // All tests in this suite inherit the formatting tag.
}

Tags are useful for categories that cross the suite hierarchy, such as critical tests, tests for a particular feature or tests that depend on a certain resource. Xcode can display and run tests by tag from the Test navigator.

Accounting for parallel execution

Swift Testing runs tests in parallel by default, including the individual cases of a parameterized test. This makes a large test suite faster, but it also means test cases shouldn't mutate shared state or rely on a particular execution order.

Swift Testing doesn't create one suite instance and call all test methods on it. For every test case, it first creates a new suite instance and then invokes the test method on that instance. In a parameterized test, this happens for every argument.

This means that formatter is initialized again for each test case in the following example:

struct SlugFormatterTests {
    let formatter = SlugFormatter()

    @Test(arguments: SlugTestCase.examples)
    func formatsTitle(_ testCase: SlugTestCase) {
        #expect(
            formatter.format(testCase.title) == testCase.expectedSlug
        )
    }
}

Independent test data is preferable to disabling parallelization. When tests must share a resource that can't safely be isolated, we can apply the .serialized trait:

@Suite(.serialized)
struct DatabaseMigrationTests {
    // Tests in this suite run one after another.
}

Applied to a suite, .serialized also affects its nested suites and parameterized test cases. It should be used deliberately: serialization can hide shared-state problems and slow the test suite, so isolating dependencies is usually the better long-term solution.

Conclusion

Parameterized tests let us describe a behavior once and verify it against many inputs. Each argument still becomes its own test case, so we keep focused diagnostics without duplicating the test logic.

For a maintainable test suite, we can use the different organization tools for different purposes:

Parameterized tests cover multiple inputs for the same behavior.
Suites group tests by feature or responsibility.
Nested suites divide a larger feature into meaningful behaviors.
Tags create groups that span multiple suites and files.

Together, these tools keep the suite easier to navigate while allowing us to add edge cases simply by extending an argument collection.

Building responsive and reliable search in SwiftUI

Sun, 13 Sep 2026 22:00:00 GMT

When building a search feature, we usually want results to update as the user types. To keep this interaction responsive and robust, we need to avoid sending unnecessary requests and ensure that only results for the current query reach the interface.

In this article, we'll use SwiftUI and Swift concurrency to debounce search input, cancel obsolete requests and prevent older responses from replacing newer results.

We'll build the solution in four steps:

Connect the search task to the current query.
Debounce the input before starting a request.
Prevent obsolete requests from publishing stale results.
Keep the loading and error states tied to the current search.

Step 1: Connecting the search task to the query

A first implementation might start a new task whenever the query changes:

struct SearchView: View {
    @State private var query = ""
    @State private var results: [SearchResult] = []

    let searchService: SearchService

    var body: some View {
        List(results) { result in
            Text(result.title)
        }
        .searchable(text: $query)
        .onChange(of: query) { _, newQuery in
            Task {
                results = try await searchService.search(for: newQuery)
            }
        }
    }
}

This starts an independent task for every change. Suppose the user types "cat", pauses briefly, and then continues with "cats". The request for "cats" might finish first, while the slower request for "cat" finishes afterward and overwrites the newer results.

This is an ordering race between asynchronous operations. The problem is that the final value depends on which request finishes last rather than which query is current.

To avoid leaving these independent tasks running, we can use SwiftUI's task(id:) modifier. It gives the search operation a lifecycle tied to the query:

.task(id: query) {
    results = try await searchService.search(for: query)
}

SwiftUI starts the task when the view appears. Whenever query changes, it cancels the previous task and starts a new one with the updated value. It also cancels the task when the view disappears.

Step 2: Debouncing the input

Without a debounce, every keystroke can start a request, even though the user hasn't finished entering the query yet. A debounce avoids this unnecessary work by waiting for a short period of inactivity before performing the search. We can implement it by sleeping at the start of the task:

.task(id: query) {
    do {
        try await Task.sleep(for: .milliseconds(300))
        results = try await searchService.search(for: query)
    } catch is CancellationError {
        // Expected when the query changes.
    } catch {
        // Handle the search error.
    }
}

Task.sleep(for:) responds to cancellation by throwing CancellationError. If the user types another character during those 300 milliseconds, SwiftUI cancels the sleeping task before it reaches the request. Only after the user pauses does the search begin.

This gives us debounce behavior using the task lifecycle that SwiftUI already manages. If an app already uses Combine, its debounce operator remains a valid alternative, as shown in the article on debouncing a SwiftUI search query with Combine.

Step 3: Preventing stale results

When query changes, task(id:) requests cancellation of the previous task by marking it as cancelled. It doesn't forcibly terminate the task at that exact point. Cancellation in Swift is cooperative: the code running inside the task needs to notice the request and respond to it.

Task.sleep(for:) notices cancellation and throws, which is why it works for our debounce. Many system APIs, including URLSession's async methods, behave similarly. When search(for:) uses only cancellation-aware operations, it will throw and the old task won't reach the result assignment.

However, our search service might perform additional work, bridge an older callback API or catch a cancellation error internally. It could then return a value even though SwiftUI has already cancelled its task. Task.checkCancellation() provides an explicit checkpoint before we update the interface:

let newResults = try await searchService.search(for: submittedQuery)

try Task.checkCancellation()
results = newResults

Task.checkCancellation() reads the cancellation state set by task(id:) and throws if this task is obsolete. It makes sure that an earlier cancellation request is respected before the task publishes its result. If we know that the complete search implementation always propagates cancellation, this additional check is defensive rather than strictly necessary.

We can add a second, explicit guard by capturing the query associated with the request and comparing it with the current query before publishing the result:

let submittedQuery = query
let newResults = try await searchService.search(for: submittedQuery)

try Task.checkCancellation()

guard submittedQuery == query else { return }

results = newResults

With task(id:) and a cancellation check, this comparison is usually redundant. It still documents an important rule at the point where shared UI state changes: a response may only update the results when it belongs to the current query. This is particularly useful if the surrounding task management changes later.

Step 4: Managing loading and error states

We can now combine empty-query handling, debouncing, cancellation and relevance checking in one method:

struct SearchView: View {
    @State private var query = ""
    @State private var results: [SearchResult] = []
    @State private var isLoading = false
    @State private var errorMessage: String?

    let searchService: SearchService

    var body: some View {
        Group {
            if isLoading {
                ProgressView()
            } else if let errorMessage {
                ContentUnavailableView(
                    "Search failed",
                    systemImage: "exclamationmark.triangle",
                    description: Text(errorMessage)
                )
            } else {
                List(results) { result in
                    Text(result.title)
                }
            }
        }
        .searchable(text: $query)
        .task(id: query) {
            await performSearch(for: query)
        }
    }

    private func performSearch(for rawQuery: String) async {
        let submittedQuery = rawQuery.trimmingCharacters(in: .whitespaces)

        isLoading = false
        errorMessage = nil

        guard !submittedQuery.isEmpty else {
            results = []
            return
        }

        do {
            try await Task.sleep(for: .milliseconds(300))

            isLoading = true
            let newResults = try await searchService.search(for: submittedQuery)

            try Task.checkCancellation()
            guard submittedQuery == query.trimmingCharacters(in: .whitespaces) else {
                return
            }

            results = newResults
            isLoading = false
        } catch is CancellationError {
            // A new task now owns the loading and result state.
        } catch {
            guard submittedQuery == query.trimmingCharacters(in: .whitespaces) else {
                return
            }

            errorMessage = error.localizedDescription
            isLoading = false
        }
    }
}

We set isLoading only after the debounce finishes, so quickly typing doesn't flash a progress indicator for every character. At the beginning of each new task, we reset the loading and error state left by the previous query.

The cancellation handler deliberately doesn't change any UI state. By the time an old task observes cancellation, a newer task may already be responsible for that state. Letting the old task set isLoading to false, for example, could hide the progress indicator while the current request is still running.

Conclusion

Besides debouncing requests while the user is typing, responsive search requires us to control which asynchronous operation is allowed to update the interface.

By connecting the work to query with task(id:), using a cancellable sleep as a debounce and validating the response before publishing it, we can keep the implementation compact while protecting it from stale results.

The same approach works whenever input can change faster than asynchronous work completes, such as autocomplete suggestions, remote form validation or filters that load data from a server. We can tie the task to the changing input, cancel obsolete work and verify its relevance before updating the UI.

Getting started with Live Activities in SwiftUI

Sun, 06 Sep 2026 22:00:00 GMT

Live Activities let users follow an ongoing event without repeatedly opening our app. They can show a public transport journey, a workout, an order's delivery status or any other information that changes over a limited period of time.

Although their interface is part of a widget extension, Live Activities are not regular widgets. They don't use a timeline provider. Instead, we start, update and end them from our app with ActivityKit, while WidgetKit and SwiftUI define how their current state is presented.

In this article, we'll build a small public transport journey tracker and update it locally from the app. This lets us focus on the basic structure before adding remote updates with push notifications.

Adding a Live Activity to the project

A Live Activity's SwiftUI interface lives in a widget extension. If the app doesn't have one yet, we can add a Widget Extension target in Xcode and select Include Live Activity.

We also need to enable Live Activities for the app target. In the target's Info settings, add Supports Live Activities and set it to YES. The corresponding Info.plist key is NSSupportsLiveActivities.

Separating fixed and changing data

Every Live Activity has an attributes type. Its stored properties describe information that stays fixed for the lifetime of the activity. A nested ContentState contains the values that can change:

import ActivityKit

struct JourneyAttributes: ActivityAttributes {
    struct ContentState: Codable, Hashable {
        var currentStop: String
        var nextStop: String?
        var progress: Double
    }

    let line: String
    let destination: String
}

The app and widget extension both need access to JourneyAttributes. We can place it in a separate Swift file and enable target membership for both targets.

The line and destination don't change during the journey, so they belong to JourneyAttributes. The current stop, next stop and progress will be replaced whenever the activity is updated, so they belong to ContentState. The next stop is optional because there isn't one after we reach the destination.

Apple limits the combined size of a Live Activity's static and dynamic data to 4 KB. The attributes and content state should therefore contain only compact values required to render the interface.

Building the Live Activity interface

Now that we've defined the data, we need to tell the system how the Live Activity should look. This interface belongs to the widget extension and is described by an ActivityConfiguration. We keep the configuration itself small by moving the Lock Screen and Dynamic Island presentations into separate helpers:

import ActivityKit
import SwiftUI
import WidgetKit

struct JourneyLiveActivity: Widget {
    var body: some WidgetConfiguration {
        ActivityConfiguration(for: JourneyAttributes.self) { context in
            JourneyLockScreenView(context: context)
        } dynamicIsland: { context in
            makeDynamicIsland(for: context)
        }
    }
}

The first closure builds the presentation used on the Lock Screen. Its context gives us access to both the fixed attributes and the current state. We pass that context to a dedicated view:

struct JourneyLockScreenView: View {
    let context: ActivityViewContext<JourneyAttributes>

    var body: some View {
        VStack(alignment: .leading, spacing: 12) {
            HStack {
                Label(context.attributes.line, systemImage: "tram.fill")
                Spacer()
                Text(context.attributes.destination)
                    .font(.callout.bold())
            }

            VStack(alignment: .leading, spacing: 4) {
                Text("Current: \(context.state.currentStop)")

                if let nextStop = context.state.nextStop {
                    Text("Next: \(nextStop)")
                        .foregroundStyle(.secondary)
                } else {
                    Text("Arrived")
                        .foregroundStyle(.secondary)
                }
            }

            ProgressView(value: context.state.progress)
                .tint(.green)
        }
        .padding()
        .foregroundStyle(.black)
        .activityBackgroundTint(.white)
        .activitySystemActionForegroundColor(.green)
    }
}

Building the Dynamic Island presentations

The Dynamic Island is the interactive area around the front-facing camera and sensors on supported iPhones. A Live Activity can use this area to show compact information while another app is open, and users can touch and hold it to reveal a larger presentation. On iPhones without a Dynamic Island, the Live Activity is still available on the Lock Screen.

The second closure must return a DynamicIsland. We can move it into a method on our widget:

private extension JourneyLiveActivity {
    func makeDynamicIsland(
        for context: ActivityViewContext<JourneyAttributes>
    ) -> DynamicIsland {
        DynamicIsland {
            DynamicIslandExpandedRegion(.leading) {
                Label(context.attributes.line, systemImage: "tram.fill")
                    .font(.headline)
            }

            DynamicIslandExpandedRegion(.trailing) {
                Text(context.state.progress, format: .percent.precision(.fractionLength(0)))
            }

            DynamicIslandExpandedRegion(.bottom) {
                VStack(alignment: .leading) {
                    Text(context.state.currentStop)

                    if let nextStop = context.state.nextStop {
                        Text("Next: \(nextStop)")
                            .foregroundStyle(.secondary)
                    } else {
                        Text("Arrived at \(context.attributes.destination)")
                            .foregroundStyle(.secondary)
                    }
                }
            }
        } compactLeading: {
            Text(context.attributes.line)
        } compactTrailing: {
            Text(context.state.progress, format: .percent.precision(.fractionLength(0)))
        } minimal: {
            Image(systemName: "tram.fill")
        }
    }
}

The Dynamic Island defines three additional presentations:

The expanded presentation appears when the user touches and holds the Dynamic Island.
The compact leading and trailing views appear on either side of the camera area.
The minimal presentation is used when more than one Live Activity is active.

If the extension uses a WidgetBundle, we need to add JourneyLiveActivity() to its body just like any other widget configuration.

Starting a Live Activity

We start a Live Activity from the app while it is in the foreground. For this local example, a view can keep a reference to the returned activity:

import ActivityKit
import SwiftUI

struct ContentView: View {
    @State private var activity: Activity<JourneyAttributes>?

    var body: some View {
        VStack(spacing: 16) {
            Button("Start journey") {
                startJourney()
            }
            .disabled(activity != nil)

            Button("Next stop") {
                Task {
                    await updateJourney()
                }
            }
            .disabled(activity == nil)

            Button("Arrive") {
                Task {
                    await endJourney()
                }
            }
            .disabled(activity == nil)
        }
        .buttonStyle(.borderedProminent)
        .padding()
    }

    private func startJourney() {
        guard ActivityAuthorizationInfo().areActivitiesEnabled else {
            return
        }

        let attributes = JourneyAttributes(
            line: "U8",
            destination: "Alexanderplatz"
        )
        let state = JourneyAttributes.ContentState(
            currentStop: "Hermannplatz",
            nextStop: "Kottbusser Tor",
            progress: 0.15
        )
        let content = ActivityContent(state: state, staleDate: nil)

        do {
            activity = try Activity.request(
                attributes: attributes,
                content: content,
                pushType: nil
            )
        } catch {
            print("Couldn't start journey: \(error)")
        }
    }
}

ActivityAuthorizationInfo tells us whether the user allows Live Activities. Activity.request creates one with its fixed attributes and its initial content. Passing nil as the push type is enough because this example only sends updates from the app.

Updating the current state

To update the presentation, we create a new content state and pass it to the activity:

private func updateJourney() async {
    guard let activity else {
        return
    }

    let state = JourneyAttributes.ContentState(
        currentStop: "Kottbusser Tor",
        nextStop: "Moritzplatz",
        progress: 0.4
    )
    let content = ActivityContent(state: state, staleDate: nil)

    await activity.update(content)
}

The system renders the Live Activity again with the new context.state. Updates aren't a way to run arbitrary code inside the widget extension: the extension receives the state and uses it to build the view.

For data that can become outdated, we can pass a staleDate. After that date, ActivityKit considers the content stale and makes this available to the presentation through context.isStale. The stale date doesn't fetch new data automatically.

Ending the Live Activity

A Live Activity represents a temporary event, so we should explicitly end it when that event is finished. We also provide a final state because the system may leave the ended activity visible on the Lock Screen for a while:

private func endJourney() async {
    guard let activity else {
        return
    }

    let finalState = JourneyAttributes.ContentState(
        currentStop: "Alexanderplatz",
        nextStop: nil,
        progress: 1
    )
    let finalContent = ActivityContent(
        state: finalState,
        staleDate: nil
    )

    await activity.end(
        finalContent,
        dismissalPolicy: .after(Date.now.addingTimeInterval(60))
    )

    self.activity = nil
}

The dismissal policy controls how long the completed activity remains visible. We can use .immediate, .default, or .after(_:). Here, it stays on the Lock Screen for one minute so the user can see that the destination has been reached.

In a larger app, we shouldn't rely only on an in-memory reference. Activity<JourneyAttributes>.activities gives us the currently running activities of this type, which lets us find them again after the app has been relaunched.

Local and remote updates

This example updates the Live Activity while code in our app is running. The Live Activity itself can't start a network request or continuously execute in the background.

For a real public transport journey, service and location updates would usually originate outside our app while it isn't running. ActivityKit supports this through specialized push notifications. That requires obtaining a push token and sending correctly structured updates through APNs, so it is best treated as a separate step after the local lifecycle is working.

Conclusion

A Live Activity consists of two closely related parts: an ActivityAttributes model shared between the targets, and an ActivityConfiguration in the widget extension that renders it. The app then uses ActivityKit to start the activity, replace its dynamic content and end it with a final state.

Once this local flow works, we can build on it with push updates, deep links and interactive controls without changing the core structure.

Managing toolbar visibility and overflow in SwiftUI

Sun, 30 Aug 2026 22:00:00 GMT

When a SwiftUI toolbar contains more actions than the available space can hold, the system decides which items remain visible and which ones move into the overflow menu. This becomes especially important when our app can run at different window sizes.

Starting with iOS 27, SwiftUI adds several APIs that let us communicate which actions matter most, which ones belong in the overflow menu, and which one should always remain visible.

If you're new to creating toolbars and placing their items, you can start with this guide to toolbars in SwiftUI. In this article, we'll focus specifically on making an existing toolbar adapt to limited space.

Prioritizing important toolbar items

By default, SwiftUI manages the visibility of toolbar items automatically. We can use the visibilityPriority modifier to tell the system which actions should remain visible for longer as the available space becomes smaller:

.toolbar {
    ToolbarItemGroup {
        Button("Undo", systemImage: "arrow.uturn.backward", action: undo)
        Button("Redo", systemImage: "arrow.uturn.forward", action: redo)
    }
    .visibilityPriority(.high)

    ToolbarItem {
        Button("Add", systemImage: "plus", action: addItem)
    }
}

In this example, SwiftUI prioritizes the Undo and Redo group over the Add button when all items no longer fit.

The available values are .low, .automatic and .high. A priority expresses the relative importance of an item; it does not reserve a fixed position or guarantee that the item is always visible.

Placing secondary actions in the overflow menu

Some actions do not need to take up toolbar space at all. We can put them inside a ToolbarOverflowMenu to make them available from the overflow menu regardless of how much room the toolbar has:

.toolbar {
    ToolbarOverflowMenu {
        Button("Duplicate", systemImage: "plus.square.on.square", action: duplicate)
        Button("Export", systemImage: "square.and.arrow.up", action: export)
        Button("Delete", systemImage: "trash", role: .destructive, action: delete)
    }
}

This is useful for secondary or less frequently used actions.

Keeping a critical action visible

For an action that should remain visible at all times, we can use the .topBarPinnedTrailing placement:

.toolbar {
    ToolbarItem(placement: .topBarPinnedTrailing) {
        Button("Share", systemImage: "square.and.arrow.up", action: share)
    }
}

The pinned item stays at the trailing edge of the top bar and does not move into the overflow menu.

Minimizing the toolbar while scrolling

We can also give scrollable content more room by minimizing the navigation bar when the user scrolls down:

ScrollView {
    LazyVStack {
        // Content
    }
}
.toolbarMinimizeBehavior(.onScrollDown, for: .navigationBar)

With this modifier, the navigation bar moves out of the way while scrolling down, and SwiftUI manages when it reappears. This behavior is independent of the visibility and overflow configuration of the toolbar items themselves.

Conclusion

Together, the toolbar APIs let us express the importance of each action while SwiftUI continues to handle the toolbar's layout across different sizes.

Presenting alerts and confirmation dialogs from identifiable data in SwiftUI

Sun, 23 Aug 2026 22:00:00 GMT

One possibility to control SwiftUI alerts and confirmation dialogs is with a Boolean binding. Starting with iOS 27, item-based alerts and confirmation dialogs are supported and provide an alternative by using an optional identifiable value as both the presentation state and its data.

Let's look how to use it.

Presenting an alert with a Boolean binding

Imagine we want to ask for confirmation before deleting a task. A Boolean-based implementation could look like this:

struct TasksView: View {
    @State private var taskToDelete: Task?
    @State private var isShowingDeleteAlert = false

    var body: some View {
        List(tasks) { task in
            Button("Delete \(task.title)") {
                taskToDelete = task
                isShowingDeleteAlert = true
            }
        }
        .alert("Delete task?", isPresented: $isShowingDeleteAlert) {
            Button("Delete", role: .destructive) {
                if let taskToDelete {
                    delete(taskToDelete)
                }
            }

            Button("Cancel", role: .cancel) {}
        } message: {
            if let taskToDelete {
                Text("Are you sure you want to delete \(taskToDelete.title)?")
            }
        }
    }
}

This requires two pieces of state: one to decide whether to present the alert and another to hold the task. Because taskToDelete is optional, we also need to unwrap it in both the action and the message. These values represent the same event, but they can get out of sync.

Presenting an alert from an identifiable item

When the data conforms to Identifiable, we can instead pass a binding to the optional item directly to the alert modifier:

struct Task: Identifiable {
    let id = UUID()
    let title: String
}

struct TasksView: View {
    @State private var taskToDelete: Task?

    var body: some View {
        List(tasks) { task in
            Button("Delete \(task.title)") {
                taskToDelete = task
            }
        }
        .alert("Delete task?", item: $taskToDelete) { task in
            Button("Delete", role: .destructive) {
                delete(task)
            }

            Button("Cancel", role: .cancel) {}
        } message: { task in
            Text("Are you sure you want to delete \(task.title)?")
        }
    }
}

Setting taskToDelete to a value presents the alert. SwiftUI passes that value into the actions and message closures, so we can use the selected task without optional unwrapping. When the alert is dismissed, SwiftUI sets the binding back to nil.

We now have a single source of truth:

taskToDelete == nil means that the alert is not presented.
A task stored in taskToDelete means that the alert is presented for that task.

This makes item-based presentation especially useful for alerts whose title, message, or actions depend on selected data.

Using the same approach with confirmation dialogs

Confirmation dialogs support the same item-binding pattern. We only need to replace the alert modifier:

.confirmationDialog(
    "Delete task?",
    item: $taskToDelete,
    titleVisibility: .visible
) { task in
    Button("Delete", role: .destructive) {
        delete(task)
    }
} message: { task in
    Text("Are you sure you want to delete \(task.title)?")
}

The item-based overloads for alerts and confirmation dialogs are available starting with iOS 27. For earlier versions, we still need to use the Boolean-based APIs.

Adding swipe actions to any SwiftUI scroll view

Sun, 16 Aug 2026 22:00:00 GMT

Until iOS 27, SwiftUI's swipeActions modifier worked with rows inside a List. Starting with iOS 27, we can also add swipe actions to views inside a ScrollView.

Let's look at how to do that.

Adding swipe actions to a List

In a List, we attach the swipeActions modifier directly to each row:

List {
    ForEach(tasks) { task in
        TaskRow(task: task)
            .swipeActions {
                Button("Delete", systemImage: "trash", role: .destructive) {
                    delete(task)
                }
            }
    }
}

SwiftUI's List provides the container behavior needed to reveal the action when the user swipes the row. Applying the same row modifier inside a regular ScrollView, however, is not enough.

Enabling swipe actions in a ScrollView

For a custom scroll view, we additionally apply the new swipeActionsContainer modifier to the ScrollView:

ScrollView {
    LazyVStack(spacing: 12) {
        ForEach(tasks) { task in
            TaskRow(task: task)
                .swipeActions {
                    Button("Delete", systemImage: "trash", role: .destructive) {
                        delete(task)
                    }
                }
        }
    }
    .padding()
}
.swipeActionsContainer()

The two modifiers have different responsibilities: swipeActions defines the actions for an individual view, while swipeActionsContainer enables the interaction for the surrounding scroll view.

Customizing swipe actions

The existing options for swipe actions work in the new container as well. For example, we can add actions to both edges and control whether a full swipe performs the first action:

TaskRow(task: task)
    .swipeActions(edge: .leading, allowsFullSwipe: false) {
        Button("Favorite", systemImage: "star") {
            favorite(task)
        }
        .tint(.yellow)
    }
    .swipeActions(edge: .trailing) {
        Button("Delete", systemImage: "trash", role: .destructive) {
            delete(task)
        }
    }

The action labels, roles, tints, edges, and full-swipe behavior are configured just as they are for a List row. The only new part is marking the parent ScrollView as a swipe actions container.

With this small addition, we can keep native swipe interactions while using LazyVStack or another custom scrollable layout.

Managing focus in SwiftUI with FocusState

Sun, 09 Aug 2026 22:00:00 GMT

SwiftUI provides the @FocusState property wrapper to observe and control focus in a view hierarchy. We can use it to focus a text field programmatically, move focus between fields, or remove focus to dismiss the keyboard.

In this article, we'll look at the different ways to represent focus and how to pass focus state between views.

Managing focus for a single view

When we only need to manage one focusable view, we can represent its focus state with a Bool:

struct NameView: View {
    @State private var name = ""
    @FocusState private var isNameFocused: Bool

    var body: some View {
        VStack {
            TextField("Name", text: $name)
                .focused($isNameFocused)

            Button("Edit name") {
                isNameFocused = true
            }
        }
    }
}

The focused(_:) modifier connects the text field to isNameFocused. The value changes to true when the text field receives focus and back to false when focus leaves it.

This connection also works in the other direction. Setting the value to true moves focus to the text field. Setting it to false removes focus.

Managing focus for multiple views

For multiple focusable views, a single Boolean is no longer enough because it cannot describe which view is focused. We can use an optional enum instead:

struct LoginView: View {
    private enum Field: Hashable {
        case email
        case password
    }

    @State private var email = ""
    @State private var password = ""
    @FocusState private var focusedField: Field?

    var body: some View {
        Form {
            TextField("Email", text: $email)
                .textContentType(.emailAddress)
                .submitLabel(.next)
                .focused($focusedField, equals: .email)
                .onSubmit {
                    focusedField = .password
                }

            SecureField("Password", text: $password)
                .textContentType(.password)
                .submitLabel(.done)
                .focused($focusedField, equals: .password)
                .onSubmit {
                    focusedField = nil
                }

            Button("Sign in") {
                validate()
            }
        }
    }

    private func validate() {
        if email.isEmpty {
            focusedField = .email
        } else if password.isEmpty {
            focusedField = .password
        } else {
            focusedField = nil
            signIn()
        }
    }
}

Each field is connected to its corresponding enum case using focused(_:equals:). When a field receives focus, focusedField is updated with that case. Assigning a case programmatically moves focus to the associated field.

The value is optional because focus can also be outside both fields. Setting it to nil removes focus from all views connected to this property and dismisses the keyboard.

Avoiding ambiguous focus bindings

Each focus value should identify one focus destination. Connecting the same enum case to multiple views makes programmatic focus ambiguous:

TextField("First name", text: $firstName)
    .focused($focusedField, equals: .name)

TextField("Last name", text: $lastName)
    .focused($focusedField, equals: .name)

When either field receives focus, focusedField becomes .name. But when we assign .name ourselves, SwiftUI cannot determine which field should receive focus. Using a separate enum case for each destination avoids this ambiguity.

Passing focus state to a child view

Sometimes the focusable control is extracted into a child view. In this case, we can pass the projected focus state as a FocusState.Binding:

struct ParentView: View {
    @FocusState private var isNameFocused: Bool

    var body: some View {
        NameField(isFocused: $isNameFocused)
    }
}

struct NameField: View {
    @State private var name = ""
    @FocusState.Binding var isFocused: Bool

    var body: some View {
        TextField("Name", text: $name)
            .focused($isFocused)
    }
}

This is useful when the child contains the view whose focus is represented by the property. The child attaches the binding to that view with the focused(_:) modifier, while the parent can still observe and change the focus.

Building a reusable API client with URLSession in Swift

Sat, 01 Aug 2026 22:00:00 GMT

URLSession is the foundation framework for loading data over the network in Swift. We can use it directly, but networking code can quickly become repetitive.

Most endpoints need the same steps: create a request, call URLSession, validate the HTTP response, decode JSON, and handle errors. Instead of repeating this flow for every endpoint, we can move the shared behavior into a small reusable API client.

In this article, we'll build a lightweight APIClient with URLSession and async/await.

Starting with a request

For very simple GET requests, URLSession provides data(from:), which only needs a URL. In most apps, data(for:) is more useful because it accepts a URLRequest.

With a URLRequest, we can configure details like the HTTP method, headers, timeout, cache policy, or request body:

let url = URL(string: "https://example.com/api/articles")!

var request = URLRequest(url: url)
request.httpMethod = "GET"
request.setValue("application/json", forHTTPHeaderField: "Accept")

let (data, response) = try await URLSession.shared.data(for: request)

The method returns a tuple containing the response body as Data and a URLResponse. Calling data(for:) also creates and resumes a data task internally, so we don't need to call resume() ourselves.

This already works, but the same pattern usually appears in many places. Let's move it into a reusable client.

Creating an API client

The first version of the client can take a URLRequest, load the data, validate the response, and decode the result.

First, let's define a small error type for response validation:

enum NetworkError: Error {
    case invalidResponse
    case invalidStatusCode(Int)
}

Next, we can define a lightweight endpoint type. It describes what is specific to one request, while the client owns shared configuration like the base URL and default headers.

enum HTTPMethod: String {
    case get = "GET"
    case post = "POST"
}

struct Endpoint {
    let path: String
    let method: HTTPMethod
    var headers: [String: String] = [:]
}

Now we can use it inside the client:

struct APIClient {
    let session: URLSession
    let decoder: JSONDecoder
    let baseURL: URL
    let defaultHeaders: [String: String]

    init(
        baseURL: URL,
        session: URLSession = .shared,
        decoder: JSONDecoder = JSONDecoder(),
        defaultHeaders: [String: String] = ["Accept": "application/json"]
    ) {
        self.baseURL = baseURL
        self.session = session
        self.decoder = decoder
        self.defaultHeaders = defaultHeaders
    }

    func send<Value: Decodable>(
        _ request: URLRequest,
        decode type: Value.Type = Value.self
    ) async throws -> Value {
        let (data, response) = try await session.data(for: request)
        try validate(response)

        return try decoder.decode(Value.self, from: data)
    }

    private func validate(_ response: URLResponse) throws {
        guard let httpResponse = response as? HTTPURLResponse else {
            throw NetworkError.invalidResponse
        }

        guard (200...299).contains(httpResponse.statusCode) else {
            throw NetworkError.invalidStatusCode(httpResponse.statusCode)
        }
    }

    func request(for endpoint: Endpoint) -> URLRequest {
        let url = baseURL.appending(path: endpoint.path)

        var request = URLRequest(url: url)
        request.httpMethod = endpoint.method.rawValue

        let headers = defaultHeaders.merging(endpoint.headers) { _, endpointValue in
            endpointValue
        }

        for (field, value) in headers {
            request.setValue(value, forHTTPHeaderField: field)
        }

        return request
    }
}

This gives the app one place for the repeated networking behavior. The client knows the base URL, applies shared headers, validates responses, and decodes the received data.

Why response validation matters

URLSession throws for transport-level errors, such as a failed connection or cancellation. An HTTP error status code is different. A 404 or 500 response is still a server response, so it will not automatically throw just because of the status code. This is why the client checks the HTTPURLResponse before decoding.

Loading decoded models

Now the client can return decoded models instead of raw Data.

For example, we might have an Article type:

struct Article: Decodable {
    let id: Int
    let title: String
}

Then an endpoint-specific function can create the request and ask the client to send it:

func loadArticles(client: APIClient) async throws -> [Article] {
    let endpoint = Endpoint(path: "/api/articles", method: .get)
    let request = client.request(for: endpoint)

    return try await client.send(request, decode: [Article].self)
}

At the call site, we can use the function from another async context:

do {
    let articles = try await loadArticles()
    // Update state with articles.
} catch {
    // Show an error state.
}

Adding endpoint-specific headers

The default headers are applied by the client. If an endpoint needs additional headers, or needs to override a default value, it can still provide its own headers.

Now loading articles becomes a little more focused:

let client = APIClient(baseURL: URL(string: "https://example.com")!)

let endpoint = Endpoint(
    path: "/api/articles",
    method: .get
)

let request = client.request(for: endpoint)
let articles = try await client.send(request, decode: [Article].self)

And if one endpoint needs a custom header, we can keep that local to the endpoint:

let endpoint = Endpoint(
    path: "/api/profile",
    method: .get,
    headers: ["Authorization": "Bearer token"]
)

Configuring URLSession

If we need more control, we can use a configured session instead of URLSession.shared:

let configuration = URLSessionConfiguration.default
configuration.timeoutIntervalForRequest = 30
configuration.timeoutIntervalForResource = 60
configuration.requestCachePolicy = .reloadRevalidatingCacheData

let session = URLSession(configuration: configuration)
let client = APIClient(
    baseURL: URL(string: "https://example.com")!,
    session: session
)

Since the client receives the session in its initializer, we can also pass a custom session in tests.

Cancellation

The async URLSession methods work naturally with Swift concurrency cancellation. If the task waiting for the request is cancelled, the underlying network request can be cancelled too.

For example, SwiftUI cancels work started with the task modifier when the view disappears:

struct ArticlesView: View {
    @State private var articles: [Article] = []

    var body: some View {
        List(articles, id: \.id) { article in
            Text(article.title)
        }
        .task {
            do {
                articles = try await loadArticles()
            } catch is CancellationError {
                // The request was cancelled because the result is no longer needed.
            } catch {
                // Show an error state.
            }
        }
    }
}

Cancellation is not necessarily an error the user needs to see. In many cases, it simply means that the result is no longer needed, for example because the view disappeared or a newer request replaced the old one.

Summary

URLSession gives us the low-level building blocks for networking, but a small API client can make the app code easier to maintain. By moving request sending, response validation, and JSON decoding into one place, each feature can focus on the endpoint it needs.

Understanding code signing and provisioning in iOS

Thu, 23 Jul 2026 22:00:00 GMT

When building an iOS app, we eventually need to run it on a real device, send it to testers, or distribute it through the App Store.

For that to work, the app has to be signed. Code signing tells the system who created the app and helps ensure that the app has not been changed after it was signed. Provisioning tells the system what the app is allowed to do and where it is allowed to run.

Xcode can manage most of this automatically, but it helps to understand what happens behind the scenes, especially when working in larger teams, CI environments, or projects with stricter release processes.

The mental model

The code signing setup can be divided into three main parts:

App target
- bundle identifier
- entitlements

Certificate
- signing identity
- private key

Provisioning profile
- App ID
- allowed certificates
- allowed entitlements
- distribution type
- devices, if needed

The app target defines what is being signed. The certificate identifies who signs it. The provisioning profile connects both sides by saying which App ID can be signed with which certificates, which entitlements are allowed, and where the app can run.

Signing works when these pieces match. If one of them is out of sync, Xcode cannot sign the app or iOS refuses to install it.

Certificates

A certificate identifies who is signing the app. It is issued by Apple and is connected to a private key stored in the keychain or managed by the signing system.

For iOS development, there are two common certificate categories:

development certificates for running and debugging apps on devices
distribution certificates for TestFlight, App Store, Ad Hoc, or other distribution workflows

When signing locally, the certificate alone is not enough. The machine also needs the matching private key. This is why copying only a certificate file to another Mac often does not fix signing problems. The private key has to be available too.

For many distribution workflows, Xcode can also use cloud-managed certificates. In that case, Apple manages the distribution certificate remotely and Xcode can sign through the Organizer distribution flow without requiring a local distribution certificate in the keychain.

App IDs

An App ID identifies the app in the Apple Developer account. It is connected to the app's bundle identifier, for example:

com.example.MyApp

The bundle identifier in Xcode has to match the App ID used for signing. If the app has extensions, each extension has its own bundle identifier and usually its own App ID as well.

The App ID is also where capabilities are enabled in the developer account. For example, if the app uses Push Notifications, Associated Domains, App Groups, iCloud, or Sign in with Apple, the App ID needs to support those capabilities.

Entitlements

Entitlements are values embedded into the signed app. They describe which protected capabilities the app wants to use.

In Xcode, we usually configure them in the Signing & Capabilities tab. Xcode then stores them in an .entitlements file and includes them when signing the app.

For example, an app using Associated Domains might include an entitlement like this:

<key>com.apple.developer.associated-domains</key>
<array>
    <string>applinks:example.com</string>
</array>

The important detail is that entitlements have to match the provisioning profile. If an entitlement is present in the app but not allowed by the profile, signing or installation can fail.

Provisioning profiles

A provisioning profile is the file that ties everything together. It says:

which App ID the app uses
which certificates are allowed to sign it
which entitlements are allowed
which distribution method it is for
which devices it can run on, if the profile is device-based

Provisioning profiles use the .mobileprovision file extension for iOS apps.

There are different profile types depending on what we want to do:

development profiles are used for running and debugging on devices
Ad Hoc profiles are used for distributing to registered devices
App Store profiles are used for App Store and TestFlight distribution

Development and Ad Hoc profiles include devices. App Store profiles do not, because App Store distribution is not limited to specific registered test devices.

Automatic signing

With automatic signing, Xcode creates and updates signing assets for us. We select a team in the Signing & Capabilities tab, enable Automatically manage signing, and Xcode handles the required App IDs, certificates, and provisioning profiles when possible.

This is usually the most convenient setup for local development. It is also a good default when the project is not doing anything unusual.

Automatic signing becomes especially helpful when adding capabilities. If we add a capability in Xcode, Xcode can update the App ID and provisioning profile so the app's entitlements continue to match the profile.

Manual signing

With manual signing, we create and select the signing assets ourselves. This means choosing the provisioning profile and certificate for each relevant target and build configuration.

Manual signing can be useful when:

a CI system needs predictable signing assets
a team wants tighter control over profiles and certificates
different configurations use different bundle identifiers
the app has multiple targets or extensions with separate provisioning needs

Manual signing also means we are responsible for keeping profiles up to date. If we add a capability, register a new device, or change the App ID, the provisioning profile may need to be regenerated and downloaded again.

How Xcode signs the app

When Xcode signs an app, it combines the build product with the selected signing identity and provisioning profile.

For the signing step to succeed, the important values have to match:

the app's bundle identifier has to match the App ID in the provisioning profile
the certificate has to be included in the provisioning profile
the app's entitlements have to be allowed by the provisioning profile
the profile type has to match the build or distribution workflow

If the app contains extensions, the same applies to each extension target. The app target and every extension target need their own matching signing setup.

Common signing problems

Many signing errors come from one of a few mismatches.

If Xcode says that a provisioning profile does not include a signing certificate, the selected certificate is not part of that profile. This can happen after regenerating certificates or switching machines.

If Xcode says that a capability is not supported by the provisioning profile, the App ID or profile does not include the entitlement used by the app. Regenerating the profile after enabling the capability usually fixes this.

If an app installs on one device but not another, the development or Ad Hoc profile may not include the second device. In that case, the device needs to be registered and the profile needs to be updated.

If CI fails while local builds work, the CI environment may be missing the private key, the provisioning profile, or access to automatic signing. In that case, either the signing assets need to be installed in CI, or the CI workflow needs permission to manage signing through Xcode or App Store Connect.

Summary

Code signing and provisioning are easier to reason about when we separate the responsibilities.

A certificate identifies who signs the app. An App ID identifies the app. Entitlements describe what the app wants to do. A provisioning profile connects those pieces and defines where the signed app can run.

Automatic signing lets Xcode manage most of this for us. Manual signing gives us more control, but also makes us responsible for keeping certificates, profiles, entitlements, bundle identifiers, and devices in sync.

Building widgets with WidgetKit and SwiftUI

Sun, 19 Jul 2026 22:00:00 GMT

Widgets give users a lightweight way to see useful information from an app without opening it first. A good widget is usually focused on one small job: showing today's progress, the next event, the current status, or a shortcut into a specific part of the app.

WidgetKit handles the system integration, scheduling, rendering, and configuration. We provide the data, decide when it should refresh, and build the view with SwiftUI.

Before building a widget, it helps to decide what information is useful at a glance. Widgets work best when they show a small amount of timely content or provide a shortcut to a focused action. If the user needs to make several decisions, the app itself is usually the better place for that flow.

In this article, we'll look at how to add a widget extension, configure a widget, provide timeline entries, and build the widget's SwiftUI view.

We'll use a simple quote widget as an example. The same structure can be applied to other types of widgets, such as a task summary, a weather overview, or a project status widget.

Adding a widget extension

A widget lives in its own app extension. To add one to an existing iOS app, we can use Xcode's Widget Extension template from File > New > Target and enter a name for the extension.

Xcode creates a new target with a widget entry point. The main widget type conforms to the Widget protocol and is marked with @main:

import SwiftUI
import WidgetKit

@main
struct ExampleWidget: Widget {
    var body: some WidgetConfiguration {
        // Return the widget configuration.
    }
}

The configuration describes what kind of widget we are building, which timeline provider supplies its data, and which SwiftUI view renders the widget.

Choosing a widget configuration

Static widgets

For many widgets, StaticConfiguration is enough. It works well when the widget does not need user-configurable options.

var body: some WidgetConfiguration {
    StaticConfiguration(
        kind: "com.example.QuoteWidget",
        provider: ExampleTimelineProvider()
    ) { entry in
        QuoteWidgetView(entry: entry)
    }
    .configurationDisplayName("Quote Widget")
    .description("Shows the latest quote of the day.")
    .supportedFamilies([.systemSmall, .systemMedium, .systemLarge])
}

Here, kind identifies the widget, the provider supplies its timeline entries, and the closure builds the SwiftUI view. The remaining modifiers define how the widget appears when users add or edit it.

Configurable widgets

If the widget should be configurable by the user, we can use AppIntentConfiguration instead. This is useful when the widget content depends on a selected project, category, account, or any other user-provided option.

var body: some WidgetConfiguration {
    AppIntentConfiguration(
        kind: "com.example.QuoteWidget",
        intent: QuoteWidgetIntent.self,
        provider: QuoteTimelineProvider()
    ) { entry in
        QuoteWidgetView(entry: entry)
    }
    .configurationDisplayName("Quote")
    .description("Shows a quote for the selected category.")
}

The configuration looks similar to the static one, but it also receives an intent type. The intent describes the values users can configure:

import AppIntents
import WidgetKit

enum QuoteCategory: String, AppEnum {
    case motivation
    case focus

    static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Category")

    static var caseDisplayRepresentations: [QuoteCategory: DisplayRepresentation] = [
        .motivation: "Motivation",
        .focus: "Focus"
    ]
}

struct QuoteWidgetIntent: WidgetConfigurationIntent {
    static var title: LocalizedStringResource = "Quote Widget"

    @Parameter(title: "Category")
    var category: QuoteCategory = .motivation
}

In this example, the user can choose between predefined quote categories when adding or editing the widget. The selected category is passed to the provider as part of the QuoteWidgetIntent configuration, so the provider can create entries for the chosen category.

For a more detailed walkthrough, check out the article on how to build a configurable widget with WidgetKit and SwiftUI.

Providing timeline entries

Widgets don't run continuously in the background. Instead, WidgetKit asks the timeline provider for entries and decides when to render them.

A timeline entry is a small model object that conforms to TimelineEntry. It must contain a date and can include any other values the widget view needs:

struct QuoteEntry: TimelineEntry {
    let date: Date
    let quote: String
}

For a static widget, the provider conforms to TimelineProvider:

struct ExampleTimelineProvider: TimelineProvider {
    func placeholder(in context: Context) -> QuoteEntry {
        QuoteEntry(date: Date(), quote: "Quote of the day")
    }

    func getSnapshot(in context: Context, completion: @escaping (QuoteEntry) -> Void) {
        let entry = QuoteEntry(date: Date(), quote: "Quote of the day")
        completion(entry)
    }

    func getTimeline(in context: Context, completion: @escaping (Timeline<QuoteEntry>) -> Void) {
        let entry = QuoteEntry(date: Date(), quote: "Small steps count.")
        let nextUpdate = Date().addingTimeInterval(60 * 60)
        let timeline = Timeline(entries: [entry], policy: .after(nextUpdate))

        completion(timeline)
    }
}

Let's look at the methods more closely:

placeholder(in:) provides a lightweight representation of the widget before real data is available.
getSnapshot(in:completion:) provides a single entry for previews and transient states.
getTimeline(in:completion:) provides one or more entries and a reload policy.

In practice, placeholder should be generic, while snapshot can use realistic sample or current data.

The reload policy is only a request. WidgetKit decides the exact refresh timing based on system conditions, so a widget should not depend on second-by-second updates.

For a configurable widget, the idea is the same, but the provider conforms to AppIntentTimelineProvider. Its snapshot and timeline methods receive the selected configuration, which lets us use values like configuration.category when creating the entries.

Building the widget view with SwiftUI

The widget view is a regular SwiftUI view, but it should stay focused and lightweight. It receives a timeline entry and renders the current state:

struct QuoteWidgetView: View {
    let entry: QuoteEntry

    var body: some View {
        Text(entry.quote)
            .font(.headline)
            .containerBackground(.background, for: .widget)
    }
}

Widgets can appear in different sizes and contexts. We can use the widgetFamily environment value to adapt the layout:

struct QuoteWidgetView: View {
    @Environment(\.widgetFamily) private var family

    let entry: QuoteEntry

    var body: some View {
        switch family {
        case .systemSmall:
            Text(entry.quote)
                .font(.headline)

        case .systemMedium:
            VStack(alignment: .leading) {
                Text("Quote")
                    .font(.caption)
                Text(entry.quote)
                    .font(.headline)
            }

        default:
            Text(entry.quote)
        }
    }
}

When possible, keep the view resilient. The widget might render with placeholder data, stale data, or in a smaller family than expected.

Because the widget view is built with SwiftUI, we can preview different entries and widget families in Xcode while adjusting the layout.

Opening the app from a widget

The simplest interaction is opening the app when the user taps the widget. To open a specific screen, the widget needs a URL that the app can handle. This can be a custom URL scheme like myapp://quote/today, or a universal link if the same destination should also open from outside the app.

For a single destination, we can attach a URL to a view in the widget hierarchy:

Text(entry.quote)
    .widgetURL(URL(string: "myapp://quote/today"))

In SwiftUI, the app can handle the URL with onOpenURL(perform:) and route the user to the matching screen:

@main
struct ExampleApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onOpenURL { url in
                    // Route to the matching screen.
                }
        }
    }
}

For widgets that show multiple tappable areas, we can use Link:

Link(destination: URL(string: "myapp://quote/today")!) {
    Text(entry.quote)
}

Adding interactive controls

On newer OS versions, widgets can also support simple interactions without launching the app. For example, a button can run an AppIntent to update shared app data.

Interactive widgets are best suited for small, predictable actions. If an action requires a longer flow, authentication, or more context, opening the app is usually the better experience.

Sharing data with the widget extension

Because the widget runs in a separate extension, it needs access to the data it displays. For simple values, this can be done with shared UserDefaults in an App Group. For larger or structured data, we can use a shared container or another persistence setup that both the app and widget extension can access.

Reloading widget timelines

When app data changes, we can ask WidgetKit to reload the widget's timeline:

WidgetCenter.shared.reloadTimelines(ofKind: "com.example.QuoteWidget")

To reload all timelines for the app's widgets, we can call:

WidgetCenter.shared.reloadAllTimelines()

This is useful after saving data that is displayed in the widget. Still, the system remains in control of the final refresh timing, so the widget should always display a reasonable state until the next update happens.

Summary

To build a WidgetKit widget, we create a widget extension, choose a configuration, provide timeline entries, and render the current entry with SwiftUI.

For simple widgets, StaticConfiguration and TimelineProvider are enough. For user-configurable widgets, AppIntentConfiguration and AppIntentTimelineProvider provide a modern way to model the configuration. From there, we can decide whether tapping the widget should open the app, or whether a small action can be handled directly with an AppIntent.

Keeping SwiftData behind a boundary

Sun, 12 Jul 2026 22:00:00 GMT

SwiftData integrates naturally with SwiftUI. It lets us build persistence into an app quickly, but it also makes it easy to mix persistence details directly into views.

In this article, we'll look at how we can create a boundary between the UI and the persistence layer when working with SwiftData.

A view can read from a ModelContext, use @Query, create model objects, insert them, delete them, and save the context. For a small prototype this can feel very convenient. In a real app, however, this kind of direct access can become one of the first places where responsibilities start to blur.

The direct version of a SwiftData-backed view often starts like this:

struct ItemListView: View {
    @Environment(\.modelContext) private var modelContext
    @Query private var items: [PersistedItem]

    var body: some View {
        List(items) { item in
            Text(item.timestamp, format: .dateTime)
        }
        .toolbar {
            Button("Add") {
                modelContext.insert(PersistedItem(timestamp: Date()))
            }
        }
    }
}

This is compact, and SwiftData makes the persistence work almost invisible. The tradeoff is that the view now knows quite a lot about how data is stored. If we later add validation, error handling, sorting rules, sync behavior, test data, or a different persistence strategy, the view might take on too many responsibilities.

To keep responsibilities clean, we can put a small persistence boundary between the UI-facing code and the storage. We can make the persisted type explicit:

@Model
final class PersistedItem {
    var id: UUID
    var timestamp: Date

    init(id: UUID = UUID(), timestamp: Date) {
        self.id = id
        self.timestamp = timestamp
    }
}

The UI-facing model can then be a plain value type:

struct Item: Identifiable, Equatable, Sendable {
    let id: UUID
    let timestamp: Date
}

PersistedItem tells us that this type belongs to the storage layer. Item is the value the feature works with. This makes the boundary visible in the code and reduces the chance that a persistence model slowly spreads through views, navigation state, previews, and tests.

The repository protocol can describe the feature's persistence needs without exposing SwiftData:

@MainActor
protocol ItemRepository {
    func fetchItems() throws -> [Item]
    func addItem(timestamp: Date) throws
}

The view model depends on this boundary instead of depending on SwiftData directly:

@MainActor
@Observable
final class ItemListViewModel {
    private let repository: any ItemRepository
    private(set) var items: [Item] = []

    init(repository: any ItemRepository) {
        self.repository = repository
    }

    func loadItems() throws {
        items = try repository.fetchItems()
    }

    func addItem() throws {
        try repository.addItem(timestamp: Date())
        try loadItems()
    }
}

Now the view can stay focused on presentation and user interaction. It displays viewModel.items and calls methods such as viewModel.loadItems() or viewModel.addItem(), but it no longer knows about ModelContext, fetch descriptors, or SwiftData insert calls.

The SwiftData-specific implementation moves into the repository:

@MainActor
final class ItemRepositoryImpl: ItemRepository {
    private let modelContext: ModelContext

    init(modelContext: ModelContext) {
        self.modelContext = modelContext
    }

    func fetchItems() throws -> [Item] {
        let descriptor = FetchDescriptor<PersistedItem>(
            sortBy: [SortDescriptor(\.timestamp, order: .forward)]
        )
        return try modelContext.fetch(descriptor).map { persistedItem in
            Item(id: persistedItem.id, timestamp: persistedItem.timestamp)
        }
    }

    func addItem(timestamp: Date) throws {
        modelContext.insert(PersistedItem(timestamp: timestamp))
        try modelContext.save()
    }
}

This stronger boundary comes with a tradeoff: we now have two types and mapping code between them. For very small prototypes, that can feel like extra work. In an app that is meant to grow, however, the advantages are often worth it:

PersistedItem makes it clear which type belongs to SwiftData.
Item can be a simple value type that is easier to pass around, compare, preview, and test.
Item can conform to Sendable, which fits better with Swift concurrency than passing persistence-managed reference objects through the app.
Migration concerns stay closer to the persistence layer.
The repository becomes the place where storage details, mapping, fetch descriptors, inserts, and saves are handled.

With a boundary in place, the view model can be tested with an in-memory or fake repository, previews can provide controlled data, and the persistence implementation can evolve in a controlled way.

Understanding Sendable in Swift

Sun, 05 Jul 2026 22:00:00 GMT

When working with Swift concurrency, we often pass values between tasks, actors, and async functions.

We may fetch data in one task, send it to another part of the app, update the UI, or ask an actor to store something for us. The part to watch out for here is that concurrent code can run at the same time.

If two parts of the program can access and mutate the same value at once, we can end up with a data race. Sendable helps Swift check whether values are safe to pass across concurrency boundaries, such as into a task or actor.

In this article, we'll look at what Sendable means in more detail, when Swift checks it, how to make our own types conform to it, and what to do when the compiler complains.

What is Sendable?

Sendable is a protocol that marks a type as safe to pass across concurrency boundaries.

A concurrency boundary is a place where data moves from one isolated context to another. For example, when we call a method on an actor, Swift may need to move values between the caller's context and the actor's isolated context:

actor UserStore {
    private var users: [User] = []

    func save(_ user: User) {
        users.append(user)
    }
}

let store = UserStore()
await store.save(user)

Here, user moves from the caller's isolation context into UserStore’s actor isolation. That is a concurrency boundary.

The compiler will check whether this value can be safely transferred. How strictly it does so depends on the Swift version and concurrency settings. In Swift 6 with strict concurrency enabled, Sendable violations are errors. In Swift 5 with the default settings, many of them are warnings.

For value types like structs and enums, this usually works without any extra code because Swift can infer sendability when all stored properties are sendable:

struct User {
    let id: UUID
    let name: String
}

Like many standard Swift types, UUID and String are sendable, and User does not contain shared mutable reference state.

We can also make this promise explicit by conforming to Sendable:

struct User: Sendable {
    let id: UUID
    let name: String
}

Adding Sendable documents the intent of the type and lets the compiler help us keep it safe over time. For example, if someone later adds a mutable reference-type property to User:

struct User: Sendable {
    let id: UUID
    let name: String
    var session: Session // ❌ compiler error if Session is not Sendable
}

If User itself becomes a mutable reference type, we also get a compiler error that says something like: Sending self.user risks causing data races. Let's look at how to handle reference types.

Sendable with classes

Classes need more care because they are reference types. When we pass a class instance around, we are passing a reference to the same object.

This can be safe if the class is immutable:

final class AppConfiguration: Sendable {
    let apiBaseURL: URL
    let featureFlags: [String: Bool]

    init(apiBaseURL: URL, featureFlags: [String: Bool]) {
        self.apiBaseURL = apiBaseURL
        self.featureFlags = featureFlags
    }
}

This class is final, all stored properties are immutable, and all stored properties are Sendable.

But a mutable class is different:

final class Session: Sendable {
    var token: String?
}

This is not safe. Two tasks could hold the same Session instance and mutate token at the same time.

In cases like this, we could reach for one of these options:

Make it a value type. If the type doesn't need reference semantics, changing it to a struct is often the simplest fix.
Make the class immutable. If mutation isn't needed after initialization, we can use let properties on a final class to satisfy the compiler.
Protect mutable state with an actor. When the type genuinely needs mutable state that is accessed from concurrent code, an actor is usually the cleanest solution.
Protect mutable state manually and use @unchecked Sendable. When neither of the above options fits, for example when wrapping a C library with its own thread-safety guarantees, we can take responsibility for synchronization ourselves.

Using an actor for mutable shared state

Actors are often the cleanest solution when a type owns mutable state that needs to be accessed from concurrent code.

Since actors protect their isolated state, we can move that state into one:

actor SessionStore {
    private var token: String?

    func updateToken(_ token: String) {
        self.token = token
    }

    func currentToken() -> String? {
        token
    }
}

Calls from outside the actor go through await, which gives Swift a safe place to coordinate access.

let sessionStore = SessionStore()

Task {
    await sessionStore.updateToken("abc")
    let token = await sessionStore.currentToken()
}

Actor instances themselves can be passed between concurrency domains because their mutable state is protected by actor isolation.

What is @Sendable?

Sendable applies to types. @Sendable applies to function types and closures.

A @Sendable closure is a closure that can safely be called from concurrent code. This means its captures must also be safe. We'll look at @Sendable in more detail in a separate article.

What about @unchecked Sendable?

Sometimes we know a type is safe, but the compiler cannot prove it.

This may happen with reference types that protect their state internally:

final class Counter: @unchecked Sendable {
    private let lock = NSLock()
    private var value = 0

    func increment() {
        lock.lock()
        defer { lock.unlock() }
        value += 1
    }

    func currentValue() -> Int {
        lock.lock()
        defer { lock.unlock() }
        return value
    }
}

The compiler sees mutable state and cannot verify that the lock is used correctly. By writing @unchecked Sendable, we take responsibility for that guarantee ourselves.

@unchecked Sendable should not be used just to make a compiler warning disappear. It does not make the type thread-safe. If the synchronization is wrong, the compiler will trust us anyway.

Conclusion

Using Sendable can feel strict at first, especially when enabling stricter concurrency checking in an existing project. But the warnings often point to real design questions around ownership, mutation, and shared state.

For most types, conformance requires little or no extra work: structs with sendable properties get it for free, and actors handle mutable shared state cleanly. The cases that require more thought are usually worth the attention.

Understanding privacy manifests in iOS

Sun, 28 Jun 2026 22:00:00 GMT

Many iOS apps include third-party dependencies, such as analytics SDKs, networking libraries or crash reporting tools. Some of these dependencies may collect data or access privacy-sensitive APIs.

Privacy manifests help make this behavior more explicit. In this article, we'll look at what privacy manifests are, how they relate to third-party SDKs and what required reason APIs mean for privacy declarations.

Let's dive in.

What is a privacy manifest?

A privacy manifest is a file that describes privacy-relevant behavior of an app or SDK in a standard format.

The file is called PrivacyInfo.xcprivacy and is added to the app target or to an SDK. It can declare information such as:

what types of data are collected
whether collected data is linked to the user
whether collected data is used for tracking
which required reason APIs are accessed

To add one in Xcode, we can select File -> New -> File and choose the App Privacy file template. Xcode creates a file named PrivacyInfo.xcprivacy, which should be included in the target membership of the app or SDK that declares the privacy behavior.

The privacy manifest itself does not collect data or change the runtime behavior of an app. It is a declaration file that helps describe what the app or SDK does from a privacy perspective.

For example, if an app sends a user’s email address to a backend for account functionality and uses UserDefaults for storing app settings, the manifest could contain entries like this:

<key>NSPrivacyTracking</key>
<false/>
<key>NSPrivacyCollectedDataTypes</key>
<array>
    <dict>
        <key>NSPrivacyCollectedDataType</key>
        <string>NSPrivacyCollectedDataTypeEmailAddress</string>
        <key>NSPrivacyCollectedDataTypeLinked</key>
        <true/>
        <key>NSPrivacyCollectedDataTypeTracking</key>
        <false/>
        <key>NSPrivacyCollectedDataTypePurposes</key>
        <array>
            <string>NSPrivacyCollectedDataTypePurposeAppFunctionality</string>
        </array>
    </dict>
</array>
<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
</array>

This example declares that the app does not use the collected data for tracking, collects an email address for app functionality and accesses the UserDefaults required reason API category.

In Xcode, the file can be edited as a property list, so we usually don't have to write the XML manually.

Privacy manifests and third-party SDKs

Privacy manifests are especially important for third-party SDKs because the privacy behavior of an app is not limited to its own source code.

If we integrate an analytics SDK, a crash reporting SDK, an authentication SDK or another dependency, that code may also collect data or access privacy-sensitive APIs. A privacy manifest makes this more visible by showing what the SDK declares and whether it matches how we use the SDK in the app.

Generating a privacy report in Xcode

After archiving an app, we can use Xcode to generate a privacy report.

The privacy report is a developer-facing summary. It helps us inspect the privacy declarations from the app and its embedded dependencies before submitting the app. This information can be used to keep the App Store privacy labels accurate.

Required reason APIs

Required reason APIs are APIs that Apple considers privacy-sensitive because they can potentially be used for fingerprinting.

Fingerprinting means collecting signals about a device or user and combining them to identify that user across apps or websites. Some APIs do not look obviously privacy-related at first, but can still reveal useful device-specific information when combined with other signals.

Examples of required reason API categories include:

file timestamp APIs
system boot time APIs
disk space APIs
active keyboard APIs
user defaults APIs

If an app or SDK uses one of these APIs, the privacy manifest must declare the API category and provide an approved reason for using it.

An example declaration for using UserDefaults might look like this:

<key>NSPrivacyAccessedAPITypes</key>
<array>
    <dict>
        <key>NSPrivacyAccessedAPIType</key>
        <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
        <key>NSPrivacyAccessedAPITypeReasons</key>
        <array>
            <string>CA92.1</string>
        </array>
    </dict>
</array>

Here, NSPrivacyAccessedAPICategoryUserDefaults declares the accessed API category, while CA92.1 is the approved reason code. In this case, CA92.1 means that the app accesses UserDefaults to read or write information that is only used by the app itself, for example local settings or preferences.

This is also relevant for third-party SDKs. Even if our own app code does not directly access a required reason API, an SDK might. In that case, the SDK's privacy manifest should declare that usage.

Getting started with Apple's Foundation Models framework

Sun, 21 Jun 2026 22:00:00 GMT

Apple's Foundation Models framework gives us access to language models directly through a native Swift API. In this article, we'll answer some of the questions that naturally come up when using it for the first time.

Let's jump in.

Getting started is surprisingly simple:

import FoundationModels

let model = SystemLanguageModel.default

guard case .available = model.availability else {
    print("Apple Intelligence not available on this device")
    return
}

do {
    let session = LanguageModelSession()
    let response = try await session.respond(to: "Suggest a name for a hiking app.")
    print(response.content)
} catch {
    print(error.localizedDescription)
}

That's all it takes to get a response.

Foundation Models requires an Apple Intelligence-capable device. This includes iPhone 15 Pro and newer, M-series iPads, and Apple Silicon Macs.

LanguageModelSession maintains conversation history across multiple calls, so we can build multi-turn interactions by reusing the same session instance.

Structured output

One area where Foundation Models becomes especially interesting is structured output. Using the @Generable macro, we can define the exact Swift type we expect and have the model generate instances of that type directly.

For example:

@Generable
struct AppNameSuggestion {
    let name: String
    let tagline: String
}

let session = LanguageModelSession()
let response = try await session.respond(
    to: "Suggest a name for a hiking app.",
    generating: AppNameSuggestion.self
)

print(response.content.name)     // e.g. "TrailQuest"
print(response.content.tagline)  // e.g. "Every path, perfectly planned."

The model generates a valid instance of AppNameSuggestion directly, with no JSON parsing or string extraction involved.

Where does the model run?

By default, Foundation Models uses Apple's on-device model. Nothing is sent to a server and the framework continues to work without an internet connection. This makes it a particularly interesting option for privacy-sensitive features.

In iOS 27, Apple expanded Foundation Models with support for Apple's server-side Private Cloud Compute (PCC) models, accessible through the same API. PCC offers a larger context window and reasoning support, but requires an internet connection and has a daily usage limit. It is currently only available to apps enrolled in the App Store Small Business Program with fewer than 2 million total first-time downloads.

Can we use third-party models through the same API?

With iOS 27, Foundation Models can work with third-party model providers. Providers can ship Swift packages that conform to the LanguageModel protocol. Once a model is created, we can pass it into LanguageModelSession and continue using the same session API.

The exact setup depends on the provider. For example, a cloud model usually still requires provider-specific configuration such as an API key, model identifier, or account setup. The benefit is that the rest of the app can continue to work with LanguageModelSession instead of being tightly coupled to one provider.

A third-party model might be configured as follows:

import FoundationModels
import ClaudeForFoundationModels

let model = ClaudeLanguageModel(name: .sonnet4_6, auth: .apiKey(...))
let session = LanguageModelSession(model: model)
let response = try await session.respond(to: "...")
print(response.content)

How good are the responses?

It depends on the task. The on-device model is significantly smaller than models like GPT-4 or Claude. For focused, well-scoped tasks it performs well for example for summarizing short text, classifying or tagging content, extracting structured data or generating short suggestions.

For broader reasoning, general world knowledge, or nuanced writing, it will fall short of larger cloud models. The model is not designed to compete with those larger models, it's designed to be fast, private, and always available.

Conclusion

Foundation Models makes it easy to add AI-powered features without signing up for a third-party API, managing keys, or sending user data to a server.

For complex reasoning or broad world knowledge, a larger cloud model is still the better choice. But for focused tasks where privacy and offline support matter, it's one of the most practical options iOS developers currently have.

Async cleanup with defer in Swift

Sat, 13 Jun 2026 22:00:00 GMT

Swift's defer statement is useful for cleanup logic. It guarantees that a block of code runs when the current scope exits, regardless of whether execution completes normally, throws an error, or returns early.

Before Swift 6.4, we couldn't perform asynchronous operations directly inside a defer block. Starting with Swift 6.4, it is possible.

The limitation of defer without async support

Consider a function that opens a resource and needs to close it once the work is finished:

func processFile() async throws {
    let file = try await openFile()

    defer {
        file.close()
    }

    try await process(file)
}

This works as long as cleanup is synchronous. However, many modern APIs are asynchronous. If closing the file requires an await, the code above no longer works:

defer {
    await file.close() // Compiler error on Swift version < 6.4
}

To solve the compiler error, we had to move the cleanup logic elsewhere:

let file = try await openFile()

do {
    try await process(file)
    await file.close()
} catch {
    await file.close()
    throw error
}

Besides introducing duplication, this makes the cleanup logic less obvious because it is separated from the resource acquisition.

Async cleanup with defer

With defer supporting asynchronous operations, we can keep acquisition and cleanup next to each other:

func processFile() async throws {
    let file = try await openFile()

    defer {
        await file.close()
    }

    try await process(file)
}

The cleanup operation is now guaranteed to run when the scope exits, while still supporting asynchronous work.

Note on actor isolation

A defer block inherits the actor isolation of its enclosing scope. If the surrounding function runs on @MainActor, the cleanup code inside defer also runs on @MainActor.

Understanding composition in SwiftUI

Sun, 07 Jun 2026 22:00:00 GMT

When working with SwiftUI, we constantly compose views from other views.

A Text view can be placed inside a VStack, a VStack can be embedded in a NavigationStack, and an entire screen can become a child of another view. This ability to build complex user interfaces from smaller building blocks is one of the core ideas behind SwiftUI.

Let's take a closer look at why this works.

Everything is a view

Whether we create a simple Text view:

Text("Hello World")

or a more complex container:

VStack {
    Text("Title")
    Text("Subtitle")
}

both conform to the View protocol. This means SwiftUI can treat simple and complex views in exactly the same way. From the framework's perspective, both examples are simply views.

The same principle applies to custom views. Everything participates in the hierarchy through the same abstraction.

One thing that makes this work in practice is @ViewBuilder, a result builder that allows us to write multiple child views inside a closure without explicit return statements. It's what makes the familiar SwiftUI syntax possible and what allows containers like VStack to accept multiple views as children.

A tree of views

One way to think about a SwiftUI interface is as a tree.

For example:

NavigationStack {
    VStack {
        Text("Title")

        HStack {
            Text("Author")
            Spacer()
            Text("Date")
        }
    }
}

creates a hierarchy similar to:

NavigationStack
└── VStack
    ├── Text
    └── HStack
        ├── Text
        ├── Spacer
        └── Text

Each node in the tree is itself a view. Some views are simple leaf nodes such as Text or Spacer. Others act as containers that group multiple child views together.

Because they all conform to the same protocol, SwiftUI can traverse and update the hierarchy in a uniform way.

The Composite pattern

This idea is closely related to the Composite pattern in software design, a design pattern where individual objects and groups of objects are treated through the same abstraction.

In SwiftUI:

Text acts as a leaf
containers such as VStack and HStack act as composites
both conform to View

As a result, complex user interfaces can be built from smaller pieces without requiring different APIs for individual views and groups of views.

Why composition matters

Composition is one of the main reasons SwiftUI scales so well. To see why, consider a screen built as a single large view:

struct ArticleListView: View {
    let articles: [Article]

    var body: some View {
        List(articles) { article in
            VStack(alignment: .leading) {
                Text(article.title)
                    .font(.headline)
                Text(article.author)
                    .font(.subheadline)
                Text(article.date)
                    .font(.caption)
                    .foregroundStyle(.secondary)
            }
        }
    }
}

As the row grows more complex, the entire screen becomes harder to read and the row layout becomes impossible to reuse elsewhere. Extracting it into its own component solves both problems:

struct ArticleRowView: View {
    let article: Article

    var body: some View {
        VStack(alignment: .leading) {
            Text(article.title)
                .font(.headline)
            Text(article.author)
                .font(.subheadline)
            Text(article.date)
                .font(.caption)
                .foregroundStyle(.secondary)
        }
    }
}

struct ArticleListView: View {
    let articles: [Article]

    var body: some View {
        List(articles) { article in
            ArticleRowView(article: article)
        }
    }
}

Each component now has a single responsibility, and ArticleRowView can be reused in a search results screen, a featured section, or anywhere else that needs to display an article.

This is composition in practice: breaking interfaces into small focused views and combining them into larger structures.

Why SwiftUI doesn't just store child views

At this point, we might wonder why SwiftUI uses concepts such as View, some View, and @ViewBuilder instead of a simpler approach like:

protocol View {
    var children: [any View] { get }
}

Rather than storing view hierarchies as collections of child views, SwiftUI uses Swift's type system to represent much of the hierarchy at compile time. For example, when we write:

VStack {
    Text("Title")
    Text("Subtitle")
    Image(...)
}

the @ViewBuilder transforms the child views into a concrete type that becomes part of the view hierarchy itself. Multiple child views are represented as tuple-based view content, simplified such as:

TupleView<(Text, Text, Image)>

Unlike an array of any View, the resulting type still contains information about the exact child views that make up the hierarchy. With this type information available, the framework can reason about the structure of the hierarchy more efficiently and preserve type safety throughout the view tree.

This also helps explain why some View fits SwiftUI so well. Each view's body produces a specific concrete type, but that type can quickly become long and implementation-specific. By returning some View, we tell the compiler that the body returns one specific view type, without having to name that type explicitly.

This tuple-based design also had an interesting historical consequence. Early SwiftUI versions only supported up to ten direct child views inside a @ViewBuilder closure, because each possible child count required its own explicit implementation. If we needed more, we had to split the children into another container, such as Group:

VStack {
    Text("1")
    Text("2")
    // ...

    Group {
        Text("11")
        Text("12")
    }
}

As Swift evolved, in part through variadic generics introduced in Swift 5.9, this limitation was lifted. Modern SwiftUI can represent arbitrarily large groups of child views without requiring Group as a workaround.

Conclusion

Composition is one of the foundational ideas behind SwiftUI.

By treating simple views, custom components, and entire view hierarchies through the same View abstraction, SwiftUI makes it easy to build complex interfaces from small reusable building blocks.

Under the hood, the framework goes even further by representing much of the hierarchy through Swift's type system. While most of these details remain invisible in day-to-day development, understanding them helps explain why SwiftUI's compositional model feels both flexible and powerful.

Registering for push notifications in SwiftUI

Sun, 31 May 2026 22:00:00 GMT

Push notifications allow us to inform users about updates even when they are not actively using the app.

Before an iOS app can receive remote notifications, we first need to register the app with Apple Push Notification service (APNs). This process includes requesting notification permission from the user, registering with APNs, and handling the generated device token.

In this article, we'll look at how to set up push notification registration in a SwiftUI app.

Let's dive in.

Overview

To register for push notifications, we need to:

enable the push notifications capability
request notification permission
register with APNs
handle the generated device token

Let's go through each step.

Enabling the push notifications capability

To enable push notifications, we first need to add the Push Notifications capability to the app target.

In Xcode, open the Signing & Capabilities tab and add the Push Notifications capability. This configures the required entitlement for the app and enables communication with APNs.

Requesting notification permission

Before the app can display notifications, the user needs to grant permission.

We can request authorization using UNUserNotificationCenter:

import UserNotifications

func requestNotificationPermission() async throws -> Bool {
    try await UNUserNotificationCenter.current().requestAuthorization(
        options: [.alert, .badge, .sound]
    )
}

The authorization options define which notification features the app would like to use:

.alert: display alerts
.badge: update the app icon badge
.sound: play sounds

In practice, it is usually best to request permission in context, for example when the user enables a feature that benefits from notifications, instead of immediately on app launch.

Checking existing authorization status

Before prompting, it's worth checking whether the user has already made a decision. This avoids redundant permission requests and lets us call registerForRemoteNotifications() directly if permission has already been granted:

func configureNotifications() async throws {
    let center = UNUserNotificationCenter.current()
    let settings = await center.notificationSettings()

    switch settings.authorizationStatus {
    case .notDetermined:
        let granted = try await center.requestAuthorization(options: [.alert, .badge, .sound])
        if granted {
            await registerForRemoteNotifications()
        }
    case .authorized, .provisional:
        await registerForRemoteNotifications()
    default:
        break
    }
}

@MainActor
func registerForRemoteNotifications() {
    UIApplication.shared.registerForRemoteNotifications()
}

Registering with APNs

Once permission has been granted, we can register the app with APNs:

UIApplication.shared.registerForRemoteNotifications()

This starts the registration process with Apple Push Notification service.

If registration succeeds, iOS generates a device token and passes it back to the app.

Integrating an AppDelegate in SwiftUI

Even in SwiftUI apps, remote notification registration callbacks are still delivered through the app delegate.

To integrate an app delegate into a SwiftUI app, we can use UIApplicationDelegateAdaptor:

@main
struct ExampleApp: App {
    @UIApplicationDelegateAdaptor(AppDelegate.self)
    private var appDelegate

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

Receiving the device token

Once registration succeeds, the app delegate receives the generated device token:

final class AppDelegate: NSObject, UIApplicationDelegate {

    func application(
        _ application: UIApplication,
        didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data
    ) {
        let tokenString = deviceToken.map { String(format: "%02.2hhx", $0) }.joined()
        print("Device token: \(tokenString)")

        // Send tokenString to your server
    }
}

The device token is provided as Data, so we need to convert it to a hex string before sending it to a backend. The snippet above maps each byte to a zero-padded two-digit hex representation and joins them into a single string, which is the format most push notification services expect.

The token itself uniquely identifies the app installation on the device. In most cases it is forwarded to a backend server, which then uses it to send push notifications through APNs.

Handling registration failures

If registration fails, iOS calls a different app delegate method:

func application(
    _ application: UIApplication,
    didFailToRegisterForRemoteNotificationsWithError error: Error
) {
    print("Failed to register: \(error)")
}

This can happen, for example, if push notifications are unavailable on the device or if the simulator is used.

Testing push notification registration

Notification permissions and notification handling can both be tested in the simulator.

Xcode allows us to simulate remote notifications by sending .apns payload files to the app. This is useful for testing notification UI, payload handling, and navigation flows during development.

However, the simulator is not fully registered with Apple Push Notification service in the same way as a physical device. For example, real APNs delivery and production device token workflows should still be tested on actual hardware.

A note on device tokens

Device tokens are not guaranteed to stay the same forever.

For example, they can change after:

reinstalling the app
restoring a device backup
switching devices

Because of this, apps should treat the device token as dynamic and keep the backend updated whenever a new token is received.

A note on provisional authorization

There is an additional authorization option worth knowing about: .provisional. It allows the app to deliver quiet notifications to Notification Center without showing the standard permission prompt upfront. The user can then decide whether to keep receiving notifications or turn them off.

While this can be useful for certain strategies, it is worth testing carefully. Provisional notifications are delivered quietly by default, and the exact upgrade path to prominent notifications can feel less predictable across iOS versions and user settings.

Working with the Keychain in iOS

Sun, 24 May 2026 22:00:00 GMT

When developing iOS apps, we often need to persist sensitive user data such as passwords, authentication tokens, or cryptographic keys.

For this type of data, storing values in plain files or UserDefaults is usually not appropriate. Instead, iOS provides the Keychain Services API, which stores sensitive data in an encrypted and system-managed database.

In this article, we'll look at how the Keychain API works and how to save, retrieve, update, and delete keychain items in Swift.

Let's dive in.

A note on the API design

The Keychain Services API is a C-based API, which makes it feel less modern compared to many Swift APIs.

In practice, many apps wrap the API in a small Swift abstraction or use a third-party library to simplify common operations.

That said, understanding the underlying query structure is still valuable because most abstractions are ultimately built on top of the same API.

Understanding keychain queries

The Keychain Services API is based around queries.

A keychain query is a dictionary of key-value pairs that describes:

the type of item we want to work with
how the item can be identified
additional configuration or access options
the data itself

The same query structure is used for saving, reading, updating, and deleting items.

Saving keychain items

For example, to store a password in the keychain, we first create a query describing the item we want to save:

let query: [CFString: Any] = [
    kSecClass:  kSecClassGenericPassword,
    kSecAttrService: "com.app.service",
    kSecAttrAccount: username,
    kSecValueData: passwordData]

Let's break this down.

1. Defining the item type `kSecClass: kSecClassGenericPassword`

kSecClass defines the type of keychain item we want to store. In this case, we use kSecClassGenericPassword for storing a password. Other available types include:

kSecClassInternetPassword to store Internet passwords.
kSecClassCertificate to store certificates.
kSecClassKey to store cryptographic keys.
kSecClassIdentity to store identities.

The item type determines which attributes are available for the query.

2. Defining a namespace `kSecAttrService: "com.app.service"`

A string that namespaces your keychain items, typically the app's bundle identifier or a specific service name. This is important for avoiding collisions when multiple items share the same account name.

3. Defining item attributes `kSecAttrAccount: username`

Attributes are used to identify the item and provide additional metadata.

In this example, kSecAttrAccount stores the username associated with the password.

We can additionally provide extra query arguments to configure how the keychain item behaves. For example kSecAttrAccessible: kSecAttrAccessibleWhenUnlocked, which controls when the item can be accessed. kSecAttrAccessibleWhenUnlocked ensures that the item is only accessible while the device is unlocked.

4. Providing the sensitive data `kSecValueData: passwordData`

The sensitive value itself is stored using kSecValueData. The value must be provided as Data.

Adding the item to the keychain

Once the query is ready, we can store the item using SecItemAdd:

let status = SecItemAdd(query as CFDictionary, nil)
guard status == errSecSuccess else {
    throw KeychainError.errorWithStatus(status)
}

The method returns a status code indicating whether the operation succeeded.

One error to watch our for is the error errSecDuplicateItem, which occurs when an item with the same attributes already exists. We can handle this by checking for that status and calling SecItemUpdate instead (see the update section below), or by deleting the old item before adding the new one.

Retrieving keychain items

To read a password from the keychain, we can create another query:

let query: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.app.service",
    kSecAttrAccount: username,
    kSecReturnData: true]

The key difference is kSecReturnData: true which tells the Keychain API that we want the stored value returned.

We can then retrieve the item using SecItemCopyMatching:

var result: CFTypeRef?
let status = SecItemCopyMatching(query as CFDictionary, &result)

guard status != errSecItemNotFound else {
    throw KeychainError.noPassword
}
guard status == errSecSuccess else {
    throw KeychainError.errorWithStatus(status)
}
guard let passwordData = result as? Data else {
    throw KeychainError.unexpectedPasswordData
}

Once we have the data, we can convert it back into a String:

let password = String(data: passwordData, encoding: .utf8)

Updating keychain items

To update an existing item, we first define a query that identifies the item and then provide the updated values separately:

let query: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.app.service",
    kSecAttrAccount: username
]
let attributes: [CFString: Any] = [
    kSecValueData: newPasswordData
]
let status = SecItemUpdate(query as CFDictionary, attributes as CFDictionary)

The query identifies which item should be updated, while the attributes dictionary contains the new values.

Deleting keychain items

Deleting an item uses the same query-based approach:

let query: [CFString: Any] = [
    kSecClass: kSecClassGenericPassword,
    kSecAttrService: "com.app.service",
    kSecAttrAccount: username
]
let status = SecItemDelete(query as CFDictionary)

If the operation succeeds, the item is permanently removed from the keychain.

Understanding basic animations in SwiftUI

Sat, 16 May 2026 22:00:00 GMT

SwiftUI provides built-in support for animations. In many cases, adding animations only requires attaching an animation to a state change.

There are two common ways to do this:

animation(_:value:) view modifier for animations when a certain state value changes
withAnimation(_:_:) global function which we can use to apply state changes and create animations for all views affected by them

In this article, we'll look at how both approaches work and when to use each of them.

Let's dive in.

Animating a view with `animation(_:value:)`

The animation(_:value:) view modifier is useful when we need to animate a view every time a specific value changes. We can use it as follows:

@State private var color = Color.brown

var body: some View {
    Button("Change color") {
        color = color == .brown ? .mint : .brown
    }
    .padding(20)
    .background(color)
    .foregroundStyle(.white)
    .animation(.easeInOut, value: color)
}

The modifier does not animate the value itself. The value parameter defines which state change should trigger the animation. Whenever the value of color changes, SwiftUI animates all affected updates.

This type of animation is often referred to as an implicit animation because the view automatically animates when the specified state changes.

We can also disable animation for a view by passing nil:

.animation(nil, value: color)

This is handy when we want to opt a specific view out of an animation that would otherwise be inherited from a parent.

Animating state changes with `withAnimation`

Instead of attaching the animation to a view, we can also explicitly animate state changes by using the withAnimation global function:

@State private var color = Color.brown

var body: some View {
    Button("Change color") {
        withAnimation(.easeInOut) {
            color = color == .brown ? .mint : .brown
        }
    }
    .padding(20)
    .background(color)
    .foregroundStyle(.white)
}

In this approach, the animation is applied to all view updates caused by the state changes inside the withAnimation closure.

Reacting when an animation finishes

withAnimation additionally provides a completion handler (iOS 17+), so we can run code once the animation settles:

withAnimation(.easeInOut) {
    color = color == .brown ? .mint : .brown
} completion: {
    print("Color animation finished")
}

This is useful for chaining animations or triggering follow-up actions after a transition completes.

Choosing between both approaches

Both approaches can often achieve the same visual result, but they are useful in different situations.

animation(_:value:) works well when a specific view should always animate in response to a particular state change.

withAnimation is often the better choice when multiple state changes should animate together or when we want more explicit control over when animations occur.

How to present a local HTML file in SwiftUI

Sun, 03 May 2026 22:00:00 GMT

When developing iOS apps, we sometimes need to display a locally stored HTML file, for example static help pages, terms and conditions, or release notes bundled with the app. For a long time, the only way to do this in SwiftUI was to wrap Apple's WKWebView using UIViewRepresentable. Starting with iOS 26, Apple introduced a native WebView for SwiftUI.

In this article, we'll look at both approaches:

iOS 26+: the native WebView and WebPage from WebKit for SwiftUI
iOS 14+: the classic WKWebView + UIViewRepresentable approach for broader compatibility

iOS 26+: Using the native WebView

At WWDC 2025, Apple introduced a native WebView for SwiftUI. To use it, import WebKit alongside SwiftUI.

Loading a local file directly

The simplest way to show a local HTML file is to resolve its bundle URL and pass it straight to WebView:

import SwiftUI
import WebKit

struct HTMLView: View {
    let fileName: String

    var body: some View {
        if let url = Bundle.main.url(forResource: fileName, withExtension: "html") {
            WebView(url: url)
        }
    }
}

This works well for simple HTML files. If the file references additional local resources such as stylesheets or images, using WebPage provides more control over how the content is loaded.

Using WebPage for more control

For anything beyond a static display, reading the page title, tracking load progress, or modifying the HTML before showing it, we can use the WebPage class. WebPage is an Observable object that represents and controls the web content:

import SwiftUI
import WebKit

struct HTMLView: View {
    let fileName: String
    @State private var page = WebPage()

    var body: some View {
        WebView(page)
            .onAppear {
                guard let url = Bundle.main.url(
                    forResource: fileName,
                    withExtension: "html"
                ) else { return }
                page.load(URLRequest(url: url))
            }
    }
}

Because WebPage conforms to Observable, we can read its properties directly in our view. For example, showing a loading indicator while the page loads:

var body: some View {
    VStack {
        if page.isLoading {
            ProgressView()
        }
        WebView(page)
    }
    .onAppear {
        guard let url = Bundle.main.url(
            forResource: fileName,
            withExtension: "html"
        ) else { return }
        page.load(URLRequest(url: url))
    }
}

Loading local assets

If our HTML file references local resources such as a stylesheet or images, we can load the HTML as a string and pass Bundle.main.resourceURL as the baseURL. This tells the web view where to resolve relative paths, so local assets load correctly:

.onAppear {
    guard let url = Bundle.main.url(
        forResource: fileName,
        withExtension: "html"
    ) else { return }

    guard let htmlString = try? String(contentsOf: url, encoding: .utf8) else { return }

    page.load(html: htmlString, baseURL: Bundle.main.resourceURL)
}

If we need to process the HTML string programmatically before showing it, we can use the same approach.

Showing the view in a sheet

And here's an example on how we can show the view in a sheet:

@State private var isTermsSheetPresented = false
@State private var page = WebPage()

var body: some View {
    Button("Terms & Conditions") {
        isTermsSheetPresented.toggle()
    }
    .sheet(isPresented: $isTermsSheetPresented) {
        NavigationStack {
            WebView(page)
                .navigationTitle(page.title)
                .navigationBarTitleDisplayMode(.inline)
                .onAppear {
                    guard let url = Bundle.main.url(forResource: "terms", withExtension: "html") else { return }
                    page.load(URLRequest(url: url))
                }
        }
    }
}

iOS 14+: Using WKWebView with UIViewRepresentable

If the app targets iOS versions earlier than iOS 26, we'll need to use WKWebView wrapped in a UIViewRepresentable.

Creating the wrapper

Since WKWebView is a UIView subclass, we first create a SwiftUI-compatible wrapper:

import SwiftUI
import WebKit

struct LegacyHTMLView: UIViewRepresentable {
    let fileName: String

    func makeUIView(context: Context) -> WKWebView {
        return WKWebView()
    }

    func updateUIView(_ webView: WKWebView, context: Context) {
        guard let url = Bundle.main.url(forResource: fileName, withExtension: "html") else { return }
        webView.load(URLRequest(url: url))
    }
}

Loading local assets

If the HTML file references local assets such as a stylesheet or images, we can use loadFileURL(_:allowingReadAccessTo:) instead of load(_:). This grants the web view read access to the parent directory so relative paths resolve correctly:

func updateUIView(_ webView: WKWebView, context: Context) {
    guard let url = Bundle.main.url(forResource: fileName, withExtension: "html") else { return }
    webView.loadFileURL(url, allowingReadAccessTo: url.deletingLastPathComponent())
}

Modifying the HTML before displaying it

If we need to modify the HTML content programmatically before showing it, we can use loadHTMLString(_:baseURL:). Passing the file's URL as the baseURL ensures that relative references still work:

func updateUIView(_ webView: WKWebView, context: Context) {
    guard let url = Bundle.main.url(
        forResource: fileName,
        withExtension: "html"
    ) else { return }

    guard var htmlString = try? String(contentsOf: url, encoding: .utf8) else { return }

    // Modify the HTML string before displaying
    htmlString = htmlString.replacingOccurrences(of: "{{version}}", with: "2.0")

    webView.loadHTMLString(htmlString, baseURL: url)
}

Using the view in a sheet

And this is how we can use the view in a sheet:

@State private var isTermsSheetPresented = false

var body: some View {
    Button("Terms & Conditions") {
        isTermsSheetPresented.toggle()
    }
    .sheet(isPresented: $isTermsSheetPresented) {
        LegacyHTMLView(fileName: "terms")
    }
}

Bringing it together

Displaying local HTML in SwiftUI can be implemented in different ways depending on the deployment target.

For newer iOS versions, the native WebView provides a clean and fully SwiftUI-based solution. For broader compatibility, WKWebView wrapped in UIViewRepresentable remains a reliable approach.

We can use a conditional check to get the best of both:

var body: some View {
    if #available(iOS 26, *) {
        HTMLView(fileName: fileName)
    } else {
        LegacyHTMLView(fileName: fileName)
    }
}

Both approaches allow us to display bundled HTML files and handle more advanced use cases such as modifying content or loading local resources.

How to implement pagination with SwiftUI's List view

Sun, 26 Apr 2026 22:00:00 GMT

When working with larger datasets, loading everything at once is often unnecessary. In many cases, we want to fetch an initial page of results and then load more content as the user scrolls.

SwiftUI's List works well for this pattern. By combining it with asynchronous loading and a small amount of pagination state, we can build a predictable infinite scrolling experience without much code.

In this article, we’ll look at how to implement pagination with List by loading the next page once the user reaches the end of the list.

Let's dive in.

Approach overview

Pagination can be implemented in different ways. In this article, we focus on infinite scrolling, where new content is loaded automatically as the user reaches the end of the list.

A simple and effective way to achieve this is to add a dedicated "loading row" at the bottom of the list.

When this row becomes visible, we trigger the next page request.

Implementing the list

We start by rendering the current items and conditionally adding the loading row:

List {
    ForEach(viewModel.items, id: \.id) { item in
        ListItemView(item: item)
    }

    if viewModel.isMoreDataAvailable {
        lastRowView
    }
}

The key idea here is that the loading row is only shown when more data can be loaded.

Triggering pagination

The loading row is responsible for triggering the next page request when it appears on screen:

var lastRowView: some View {
    ZStack {
        switch viewModel.paginationState {
        case .isLoading:
            ProgressView()

        case .error(let error):
            ErrorView(error)
        }
    }
    .frame(height: 50)
    .onAppear {
        viewModel.loadMoreItems()
    }
}

When the user scrolls to the end of the list, this row becomes visible and its onAppear modifier is triggered.

This is the moment where we load the next page.

Managing pagination state

The loading row also gives us a clear place to represent the current pagination state. For example, we can show a progress indicator while loading or display an error view with a retry option when the request fails.

This makes the behavior predictable and easy to extend.

The implementation of loadMoreItems() should ensure that repeated onAppear calls do not start multiple pagination requests before the previous one has finished.

Conclusion

Using a dedicated loading row is a simple and predictable way to implement pagination with SwiftUI's List.

By triggering the next page when this row becomes visible, we can build an infinite scrolling experience that is easy to understand and extend.

Building a draggable bottom sheet in SwiftUI

Sun, 19 Apr 2026 22:00:00 GMT

Some apps, such as Apple Maps or Google Maps, use a draggable bottom sheet to let users switch between the main content, for example a map, and additional information presented in a sheet.

In this article, we'll look at how to build a draggable bottom sheet that works together with a scroll view and still allows interaction with the underlying content.

Example of a draggable bottom sheet.

Let's jump in.

Implementing the bottom sheet

To be more precise, what we'd like to achieve is:

the sheet has multiple states such as collapsed, medium and expanded
the sheet is not fully dismissable by user interaction
the user can interact with the contents of the underlying content such as a map
dragging the sheet works together with a scroll view used to display its content

We can implement the described behaviour by using SwiftUI's sheet combined with presentationDetents:

struct ContentView: View {
    @State private var showingBottomSheet = true

    var body: some View {
        MapView()
            .sheet(isPresented: $showingBottomSheet) {
                ScrollView {
                    // Add content of the bottom sheet here.
                }
                .interactiveDismissDisabled()
                .presentationDetents([.height(50), .medium, .large])
                .presentationBackgroundInteraction(
                    .enabled(upThrough: .large)
                )
            }
    }
}

Let's break this down.

Understanding detents

Detents define the different heights the sheet can snap to.

.presentationDetents([.height(50), .medium, .large])

In this example:

.height(50) represents a collapsed state
.medium is a partially expanded state
.large expands the sheet to full height

By combining these, we create a sheet that can move between multiple states depending on the user's interaction.

Controlling dismissal behavior

By default, sheets can be dismissed by dragging them down. In this case, we don't want that default behavior:

.interactiveDismissDisabled()

This ensures that the sheet stays visible and behaves more like a persistent UI element rather than a modal.

Enabling background interaction

One important aspect of the sheet is that the user can still interact with the underlying content, for example a map.

.presentationBackgroundInteraction(
    .enabled(upThrough: .large)
)

This allows interaction with the content behind the sheet while it's not fully covering it.

Working with scroll views

To display content inside the sheet, we typically use a ScrollView.

SwiftUI automatically coordinates the scrolling behavior with the sheet’s dragging behavior:

when the scroll view is scrolled, it handles the gesture
when it reaches the top, dragging continues to move the sheet

This coordination is built into the system and does not require additional steps from our side.

Adding a drag indicator

To make the interaction more discoverable, we can show a drag indicator:

.presentationDragIndicator(.visible)

This provides a visual hint that the sheet can be dragged.

Limitations

One limitation of this approach is that the sheet is always presented above the entire view hierarchy.

This means it will also cover elements such as a tab bar. If more control over layering is required, for example to place content above the sheet, a custom implementation may be necessary.

How to test in-app purchases locally using StoreKit

Tue, 07 Apr 2026 22:00:00 GMT

When working with in-app purchases, testing different purchase scenarios is an important part of development. This includes handling successful transactions, failures, and subscription renewals.

StoreKit provides a local testing environment that allows us to simulate in-app purchases during development. This makes it possible to test purchase flows, subscriptions, and edge cases without connecting to App Store Connect.

In this article, we'll look at how to set up StoreKit testing and how to use it effectively during development.

Let's dive in.

Overview

To test in-app purchases locally, we need to:

Create and configure a StoreKit configuration file
Enable StoreKit testing in Xcode
Simulate purchases and manage transactions

Before going through the setup, it helps to understand what the configuration file represents.

Understanding StoreKit configuration files

A StoreKit configuration file (.storekit) defines the products and subscription behavior we want to simulate locally.

Instead of communicating with the App Store, StoreKit reads this configuration and returns simulated responses. This allows us to test purchase flows in a controlled and predictable environment.

Xcode supports two types of configuration files:

Local configuration: Defined entirely in Xcode. Useful when setting up products for the first time or testing new scenarios.
Synced configuration: Linked to App Store Connect. Reflects the products configured for an existing app.

The key difference is that local configurations are fully editable, while synced configurations mirror App Store Connect and cannot be modified directly.

Creating a StoreKit configuration file

To create a configuration file, Xcode provides a built-in template.

StoreKit configuration file template.

When naming the configuration file, it can be helpful to use a descriptive name such as StoreKitConfigurationLocal.storekit, especially if multiple configurations are used.

After creating the file, we can start defining products.

Configuring a local StoreKit file

In a local configuration file, we can manually add products and define their behavior.

Locally configure in-app purchase options.

Using the + button, we can add consumables, non-consumables, auto-renewable subscriptions and non-renewing subscriptions.

For each product, we can define the product identifier, pricing and subscription duration if applicable.

This allows us to simulate realistic purchase scenarios.

Configuring a synced StoreKit file

If products are already set up in App Store Connect, we can create a synced configuration file.

Adding a synced StoreKit configuration file.

During creation, we select the app and team to sync with. Xcode then mirrors the existing configuration.

Synced files are useful for testing production setups, but they cannot be edited directly. If needed, we can convert them into local configurations.

Enabling StoreKit testing in Xcode

Once the configuration file is ready, we need to attach it to our app.

StoreKit testing is enabled through the current scheme. In the scheme editor, we select the configuration file:

Enabling StoreKit testing in Xcode.

From this point on, all StoreKit requests are resolved using the selected configuration file instead of the App Store.

If we want to disable local testing, we can set the configuration back to None.

Testing purchase flows

With StoreKit testing enabled, we can trigger purchases directly in the app.

From our code’s perspective, nothing changes. StoreKit behaves as if it were communicating with the App Store, but responses are generated locally.

This allows us to test successful purchases, failed transactions, subscription renewals, expired subscriptions and more. Because everything runs locally, tests are fast and repeatable.

Managing transactions

Xcode provides tools to inspect and control transactions during testing.

Xcode's transaction manager

We can open the transaction manager from the bottom toolbar when the configuration file is open or via Debug → StoreKit → Manage Transactions in Xcode's menu.

From here, we can reset purchases, simulate refunds, test subscription renewals or cancellations. This makes it possible to reproduce edge cases that are difficult to test using the App Store sandbox.

Conclusion

StoreKit testing allows us to simulate in-app purchases directly in Xcode without relying on external systems.

By defining products in a configuration file and attaching it to our app, we can test purchase flows quickly, reproduce edge cases, and significantly reduce the feedback loop during development.

Once this setup is in place, working with in-app purchases becomes fast and predictable. Before releasing an app, it is still important to test against the App Store sandbox to validate real-world behavior.

Working with files and directories in iOS

Sun, 05 Apr 2026 22:00:00 GMT

When developing an iOS app, we often need to persist data that doesn't naturally fit into a database or UserDefaults. This can include images, exported files, cached responses, or other user-generated content.

iOS provides a well-defined structure for storing files inside an app’s sandbox. Understanding how these directories work, and how to interact with them, allows us to build predictable and maintainable file handling into our apps.

Let's jump in.

Understanding the app sandbox

Each iOS app operates within its own sandbox directory. For security reasons, our app can only access files inside this container, unless explicit permission is granted (for example when accessing photos or documents).

The sandbox is divided into two main areas:

Bundle container

Contains the app bundle (.app) with all bundled resources such as images, localization files, or JSON files. This directory is read-only at runtime.

Data container

Contains all files created and managed by the app. This is where we read and write data during runtime.

Inside the data container, there are three important directories:

Documents: Used for user-generated content.
Library: Used for app-specific data that should not be directly exposed to the user.
tmp: Used for temporary files that can be deleted by the system at any time.

Let's take a closer look at the most relevant directories.

The Documents directory

The Documents directory is intended for user-generated content. This includes anything a user might create, edit, or explicitly interact with, such as images, videos, or exported files.

We can freely create subdirectories here to organize content.

The system also provides a Documents/Inbox directory, which is used when other apps hand over files to our app. Files in this directory can be read and deleted, but not modified in place.

The Library directory

The Library directory contains data used internally by the app. The most relevant subdirectories are:

Library/Application Support: Used for files the app needs to function, such as configuration files or stored data that should not be visible to the user.
Library/Caches: Used for cached data that can be recreated if needed. The system may remove these files to free up disk space.

Accessing directories

So far, we’ve looked at where files live inside the app sandbox. The next step is accessing these locations in code.

In iOS, file locations are represented by URL. Instead of working with string paths, we use these URLs as references to files and directories. We can access common directories directly through URL:

let documentsURL = URL.documentsDirectory
let cachesURL = URL.cachesDirectory
let applicationSupportURL = URL.applicationSupportDirectory

These URLs point to the corresponding locations inside our app's data container. Under the hood, these values are resolved using FileManager. If we need more control, we can fall back to:

let directoryURL = try FileManager.default.url(
    for: .applicationSupportDirectory,
    in: .userDomainMask,
    appropriateFor: nil,
    create: false
)

In most cases, however, the URL APIs are sufficient and keep the code more concise.

Reading and writing files

Once we have a directory URL, we can create a file URL by appending a file name, and then use it to read or write data.

let fileURL = directoryURL.appendingPathComponent("fileName.json")

To write data:

try data.write(to: fileURL)

To read data:

let data = try Data(contentsOf: fileURL)

Creating directories

We can create custom subdirectories to organize files:

let customDirectoryURL = directoryURL.appendingPathComponent("directoryName")

try FileManager.default.createDirectory(
    at: customDirectoryURL,
    withIntermediateDirectories: false,
    attributes: nil
)

If the directory already exists, this call will throw an error. In practice, we either check beforehand using fileExists(atPath:) or handle the error accordingly.

Accessing bundled resources

So far, we've only looked at files that are created and managed by our app at runtime.

In addition to that, we often need to read files that are shipped with the app, such as configuration files or sample data. These files live in the app bundle, which is part of the read-only bundle container.

To access them, we can use the Bundle type:

let url = Bundle.main.url(forResource: "nameOfTheResource", withExtension: "json")

Once we have the file URL, we can read it just like any other file:

let data = try Data(contentsOf: url)
let configuration = try jsonDecoder.decode(Configuration.self, from: data)

The key difference is that bundled resources are read-only, while files in the data container can be both read and written.

Managing file backups

By default, files stored in the Documents directory and in Library/Application Support are included in iCloud backups.

In some cases, this is not what we want. For example, cached or downloadable data can be recreated and does not need to be backed up.

To control this behavior, we can attach metadata to a file URL.

In iOS, file URLs can store additional resource values that describe how the system should treat a file. One of these values determines whether a file is included in backups.

We can update this value using URLResourceValues:

var resourceValues = URLResourceValues()
resourceValues.isExcludedFromBackup = true
try url.setResourceValues(resourceValues)

By setting isExcludedFromBackup to true, we tell the system that the file should not be included in iCloud backups.

This is especially useful for files in the Caches directory or any data that can be recreated if needed.

Changing runtime state with LLDB while debugging iOS apps

Sun, 29 Mar 2026 22:00:00 GMT

When developing an iOS app, we often need to bring the app into a very specific state, for example when reproducing bugs or testing edge cases.

LLDB provides a powerful way to achieve that: we can modify values at runtime using the expression command, without touching our source code or restarting the app.

Let's take a look at how this works.

Modifying values from the console

When our app pauses at a breakpoint, we can use Xcode's console to change a variable to a state we need.

Let's imagine, we are trying to fix a bug that only is reproducable for birds that have a critically endangered conservation state. When a breakpoint hits the relevant line, let's at first print the bird's conservationStatus in Xcode's console:

(lldb) po bird.conservationStatus.title
"endangered"

Since we'd like to test the app with a different conservationStatus, we can use the expr (or its shorthand p) command to change it:

(lldb) p bird.conservationStatus = .cr

When printing the conservationStatus again, we get:

(lldb) po bird.conservationStatus.title
"critically endangered"

From here, we can continue execution and observe how the app behaves under this modified state.

This is especially useful when a bug only appears under rare conditions that are otherwise difficult to reproduce.

When this approach is useful

In practice, this is not the only way to approach these situations. In many cases, we might simply hardcode a value directly in the code to reach the desired state and avoid committing that change. This approach is often more explicit and easier to reason about, especially when working with Swift's type system.

Modifying state with LLDB becomes useful in situations where reproducing a specific state is otherwise time-consuming or difficult.

For example, we might already be several screens deep in a navigation flow and want to test a specific edge case. Instead of restarting the app and navigating back to the same point, we can modify the state directly at the breakpoint:

expr result = .error

This approach is also helpful when experimenting with different values during debugging. Instead of repeatedly changing code and rebuilding, we can quickly explore different scenarios:

expr config.isEnabled = false

Limitations

While this technique is powerful, there are a few important limitations:

Constants (let) cannot be modified: attempting to assign a new value will result in an error.
Value types may behave unexpectedly: when working with structs, we are mutating a copy in some contexts. The change may not propagate as expected.
SwiftUI state isn't always mutable this way: properties like @State may not respond reliably to LLDB mutations.

Automating changes with breakpoint actions

When reproducing a bug, we sometimes want a variable to always have a certain value without typing the command every time in the console.

In this case, we can use a breakpoint action.

Set a breakpoint at the relevant location
Right-click the breakpoint and choose Edit Breakpoint
Add an action of type Debugger Command
Enter the command:

expr bird.conservationStatus = .cr

Enable Automatically continue after evaluating actions.

Now, every time the breakpoint is hit, LLDB applies the change and continues execution immediately. This allows us to consistently reproduce a specific scenario without interrupting the flow.

Migrating to String Catalogs in iOS

Sun, 22 Mar 2026 23:00:00 GMT

Many existing iOS projects still rely on Localizable.strings and Localizable.stringsdict files for localization. String Catalogs provide a more integrated workflow by allowing Xcode to manage localization keys automatically.

In this quick tip, we'll look at how to migrate an existing project to String Catalogs.

Why migrate to String Catalogs?

Before migrating, it's worth understanding what actually improves.

With traditional .strings files:

keys are added manually
unused keys can accumulate over time

String Catalogs improve this by:

automatically detecting localization keys in code
providing a visual editor in Xcode
tracking states such as new, stale, and needs_review

For many projects, this reduces maintenance effort.

If a project uses third-party localization tools or services, it's worth verifying that they support String Catalogs before migrating.

Backward compatibility

When considering a migration, backward compatibility is often a concern.

String Catalogs are fully backward compatible. During the build process, Xcode converts the catalog back into .strings and .stringsdict files. This means existing APIs and runtime behavior remain unchanged.

Xcode's automatic migration

Xcode provides built-in support for migrating existing localization files. To migrate, simply right-click on the Localizable.strings file and select Migrate to String Catalog.

Xcode will:

move existing keys into a .xcstrings file
preserve translations for all languages
convert pluralization rules automatically

Migrating over time

Migrating incrementally is possible and can work well when introducing clear boundaries.

Instead of converting the default Localizable.strings setup all at once, a practical approach is to create additional String Catalogs for new features. For example, we might create a catalog such as Checkout.xcstrings (instead of Localizable.xcstrings) and explicitly use it in code.

Text("checkout.title", tableName: "Checkout")

This way:

existing keys remain in Localizable.strings
new keys are added to Checkout.xcstrings
both systems can coexist without duplicating keys

The important detail is that keys are only added to a specific String Catalog when that table is explicitly used in code. This makes it possible to migrate feature by feature over time.

Working with String Catalogs in iOS projects

Sun, 15 Mar 2026 23:00:00 GMT

Localization is an essential part of many iOS apps. Prior to String Catalogs, developers managed localized strings using Localizable.strings and Localizable.stringsdict files. While this approach works well, it requires manual maintenance and can easily lead to missing or outdated localization keys.

String Catalogs simplify this workflow by integrating localization management directly into Xcode. In this article, we'll look at how String Catalogs work in practice. Let's jump right in.

What is a String Catalog?

A String Catalog is a file with the extension .xcstrings, typically named Localizable.xcstrings.

Contrary to Localizable.strings and Localizable.stringdict files, a String Catalog manages all translations in a single structured file. Inside Xcode, the catalog provides a dedicated editor where we can view and manage all localized strings across supported languages.

Internally, a String Catalog is stored as JSON. A simplified example might look like this:

{
  "sourceLanguage": "en",
  "strings": {
    "loginButton.title": {
      "localizations": {
        "de": {
          "stringUnit": {
            "state": "translated",
            "value": "Einloggen"
          }
        },
        "en": {
          "stringUnit": {
            "state": "translated",
            "value": "Login"
          }
        }
      }
    }
  },
  "version": "1.0"
}

Automatic detection of localizable strings

One of the most convenient features of String Catalogs is Xcode's automatic detection of localized strings.

Whenever the project is built, Xcode scans the codebase for known localization APIs and automatically adds detected keys to the String Catalog.

For example, when using SwiftUI's Text view with Text("loginButton.title"), Xcode automatically creates a new entry for us.

Once the entry is created, translations can be added directly in the catalog editor.

For cases where localized strings need to be passed around in code, the LocalizedStringResource type can be used to maintain automatic detection.

Manual management of localized strings

In some cases, Xcode cannot detect keys, for example when they are constructed dynamically:

Text("loginButton." + state)

Since Xcode cannot determine the final key during compilation, these strings will not appear automatically in the String Catalog. In such cases, entries must be added manually.

When we switch an entry to manual management, Xcode will no longer modify or remove it automatically.

Managing String Catalog entries manually

Manual management can be useful when:

localization keys are generated dynamically
strings are shared across multiple modules
keys are intentionally kept even if not currently referenced in code

Understanding String Catalog states

String Catalog entries can appear in different states depending on how they are used in the project. For example:

new - the string was detected but has not yet been translated.
needs_review - indicates that a translation should be checked again.
stale - the string is no longer referenced in the code.
translated - all required translations are available.

When Xcode marks an entry as stale, it means the key is no longer detected in the codebase.

Stale state

At this point, the entry can either be removed or switched to manual management.

The needs_review state can be set manually to indicate that a translation should be checked again, for example when the source text changes:

Mark a string for review

Practical tip: renaming localization keys

When working with localization keys, it's common that naming conventions evolve over time. For example, we might decide to rename a key like loginButton.title to something more structured such as login.button.title.

A straightforward approach would be to simply update the key in the codebase:

Text("login.button.title")

However, when doing this, Xcode treats the new key as a completely new entry. The old key will be marked as stale, while the new key appears as new.

This means all translations associated with the old key would need to be copied manually to the new one.

A more practical approach is to rename the key directly in the String Catalog editor in Xcode. When renaming a key from within the catalog, Xcode updates the references in the codebase automatically while keeping the existing translations intact:

Refactoring keys

This allows us to refactor localization keys without losing translations or creating duplicate entries.

How to use custom names for Swift properties when decoding JSON data

Sun, 08 Mar 2026 23:00:00 GMT

Swift's Codable protocol makes it straightforward to convert JSON data into native Swift types and vice versa. In some cases, however, we may want to customize how JSON keys map to Swift properties.

For example, the JSON returned by an API might use different naming conventions than our Swift models, or it might contain keys that we want to ignore.

Let's look at how to customize this behavior.

Types conforming to Codable can declare a nested enumeration called CodingKeys that conforms to the CodingKey protocol. The cases of this enumeration define which properties participate in encoding and decoding.

By default, Swift expects the case names to match the property names.

Assume we receive the following JSON response from a server:

{
  "username": "user123",
  "validated": true
}

And we want to map it to the following Swift type:

struct User: Codable {

    let username: String
    let isValidated: Bool
}

In this example, the JSON key validated does not match our Swift property name isValidated.

To map the JSON key to our property, we can define a custom CodingKeys enum:

struct User: Codable {

    let username: String
    let isValidated: Bool

    enum CodingKeys: String, CodingKey {
        case username
        case isValidated = "validated"
  }
}

By assigning a raw value to a case, we explicitly tell Swift which JSON key corresponds to the property.

During decoding, the value of the JSON key validated will now be assigned to the isValidated property of the User struct.

Implementing Passkeys in iOS with AuthenticationServices

Sun, 01 Mar 2026 23:00:00 GMT

Passkeys are credentials built to eliminate security problems like weak or reused passwords, credential leaks and phishing attacks.

In this article, we'll look at what passkeys are, how they work conceptually, and how to integrate them into an iOS app using Apple's AuthenticationServices framework.

What are passkeys?

Passkeys are a passwordless authentication method based on public-key cryptography. Instead of storing a password on a server, passkeys use:

A private key, securely stored on the user's device.
A public key, stored on the server.

When signing in, the server sends a cryptographic challenge. The device signs it using the private key, and the server verifies the signature using the public key.

The private key is securely retained on the device and synced with other devices, for example via iCloud Keychain.

Under the hood, passkeys are built on the WebAuthn and FIDO2 standards. As iOS developers, however, we do not need to implement those protocols manually, the system handles that for us.

How passkeys work in an iOS app

On iOS, passkeys are implemented using the AuthenticationServices framework.

There are two main flows:

Registration - creating a new passkey.
Authentication - signing in using an existing passkey.

In both cases, the backend plays a crucial role. It must:

Generate cryptographic challenges
Store public keys
Verify signed responses

The iOS app acts as a client in the WebAuthn flow.

Registering a passkey

A typical "sign up with passkey" flow looks like this:

The user enters an identifier (for example an email) on the sign-up screen.
The app asks the backend to start passkey registration.
The backend returns a registration challenge and a stable user handle (a backend-generated user ID).
iOS creates the passkey and returns attestation data.
The app sends the attestation back to the backend, which verifies it and creates the account.

The same flow also works when a user is already signed in and wants to add a passkey as an additional login method.

After obtaining a challenge from the server, we can create an authentication request which presents a sheet to the user asking to create a new credential:

let provider = ASAuthorizationPlatformPublicKeyCredentialProvider(
    relyingPartyIdentifier: "example.com")

let registrationRequest = provider.createCredentialRegistrationRequest(
    challenge: challenge, displayName: email, userID: userID)

let authController = ASAuthorizationController([platformKeyRequest])
authController.delegate = self
authController.presentationContextProvider = self
authController.performRequests()

The relyingPartyIdentifier must match the associated domain configured via the Associated Domains capability.

When the user confirms with Face ID or Touch ID, the system creates a new key pair and returns a credential. In the delegate callback:

func authorizationController(
    controller: ASAuthorizationController,
    didCompleteWithAuthorization authorization: ASAuthorization
) {
    if let credential = authorization.credential
        as? ASAuthorizationPlatformPublicKeyCredentialRegistration {

        let credentialID = credential.credentialID
        let clientDataJSON = credential.rawClientDataJSON
        let attestationObject = credential.rawAttestationObject

        // Send these values to backend for verification
    }
}

The backend then verifies the registration and stores the public key.

Authenticating with a passkey

The login flow is similar. The only difference is, that we now create an assertion request instead of a registration request:

let request = credetialProvider.createCredentialAssertionRequestWithChallenge(challenge)

When providing an assertion request to the controller and the user has one or more credentials on the device, the device displays a sheet with the list of credentials to choose from. If there aren't any credentials on the device, we get an error. In this case, we can ask the user to register.

Based on the credential that is passed into authorizationController(controller:didCompleteWithAuthorization:), we can determine the request type and take further steps.

func authorizationController(
    controller: ASAuthorizationController,
    didCompleteWithAuthorization authorization: ASAuthorization
) {
    switch authorization.credential {
    case let registration as ASAuthorizationPlatformPublicKeyCredentialRegistration:
        // Send attestation data to backend (finish registration)

    case let assertion as ASAuthorizationPlatformPublicKeyCredentialAssertion:
        let signature = assertion.signature
        let clientDataJSON = assertion.rawClientDataJSON
        let authenticatorData = assertion.rawAuthenticatorData
        let credentialID = assertion.credentialID

        // Send signature and related data to backend (finish login)

    default:
        break
    }
}

For authentication, the backend verifies the signature using the stored public key. If valid, the user is signed in.

Preventing forgotten database migrations with automated tests in iOS

Sat, 21 Feb 2026 23:00:00 GMT

When working with persistence in iOS apps, schema changes are inevitable. For example when adding, removing or modifying properties, renaming attributes, changing relationships, or refactoring model structures.

On a clean install, the database is created with the newest schema so everything works. Existing users, however, already have a store created with an older schema. If the app cannot migrate that store, startup may fail. Ensuring that migrations are validated automatically can prevent breaking existing installations.

In this article, we'll look at a strategy to automatically detect migration errors before shipping.

Migrations across common frameworks

Different frameworks such as SwiftData, Core Data, Realm, or manual solutions like GRDB and SQLite, handle migrations slightly differently.

Some frameworks attempt to infer certain schema changes automatically and support lightweight migrations. Others always require explicit migration logic. The level of automation varies, but the risk of forgetting a required migration remains.

What does a meaningful migration test need to prove?

A migration test should answer the following question: Can the current app version open a database created by a previous version?

In manual testing, this is done by installing a published app version and then trying to update to the new app version that contains schema changes. To automate this in a test, we'll use the same principle.

Testing with a database from a previous version

The idea is the following:

Add a baseline database file created with an older app version to the test target.
Copy that file into a temporary directory during a test.
Attempt to open it using the current persistence stack.
Fail if opening throws an error.

Conceptually, a test might look like this:

import Testing

@Test
func previousStoreCanBeOpened() throws {
    let storeURL = try copyBaselineStoreToTemporaryDirectory()
    let container = makeProductionPersistentContainer(storeURL: storeURL)

    try container.loadPersistentStores()
}

If a migration is missing or incompatible, loading the store throws an error and the test fails.

To cover both the full migration chain and the most realistic upgrade path, a strategy can be to maintain two baseline stores:

A store created several versions ago (tests the entire chain)
A store from the last released version (tests a common upgrade path)

Maintaining the "last release" store introduces additional effort, since it needs to be updated after each shipped schema change. Whether this is worth it depends on the project. For teams that already perform thorough manual upgrade testing, keeping a single older baseline may provide sufficient safety.

How do I create a database file?

The easiest way to create such a file is to run the app and let it create its database naturally. After that, the database file can be copied from the simulator or device container and added to the test target.

The exact file depends on the persistence framework:

with Core Data, it is typically a .sqlite file (and possibly its -wal and -shm companions).
with SwiftData, it is also backed by SQLite and follows the same structure.
with Realm, it is a .realm file.

On the iOS simulator, the database can usually be found inside the app container under:

~/Library/Developer/CoreSimulator/Devices/<DeviceID>/data/Containers/Data/Application/<AppID>/

Can the baseline store be generated automatically?

Updating and replacing the baseline store after a schema change does involve some manual work. At first glance, it might seem cleaner to generate the baseline store automatically during the test run instead of maintaining fixture files. Conceptually, that could look something like this:

import Testing

@Test
func migrationFromPreviousSchemaSucceeds() throws {
    let oldStoreURL = try createStoreWithPreviousSchema()
    try openStoreWithCurrentSchema(at: oldStoreURL)
}

It's easy to automate creating a store file. The hard part is creating it with an older schema.

To programmatically generate a "v2 store", the test must still have access to the "v2 model definition". For example, in Core Data, that usually means keeping older .xcdatamodel versions around and loading them explicitly. In Realm, we would need to keep the older objects somehow.

So it introduces maintenance work of a different kind:

Older model versions must remain in the project and stay consistent with what was actually shipped.
Tests need a reliable way to load a specific historical model version.

Because of that, in most cases, storing baseline files is the clearer and easier solution.

How to build a simple CLI tool using Swift

Sun, 15 Feb 2026 23:00:00 GMT

When working on iOS projects, we often need small automation tools. Maybe to run scripts in CI, automate repetitive tasks, process files or interact with APIs. While bash or Python are common choices, using Swift can be a great alternative, especially if you're already comfortable with it.

In this article, we'll build a simple command-line tool using Swift. Let's dive in.

What we're going to build

To make things practical, we'll build a small developer utility which prints the latest Xcode version. The goal is to be able to run:

swift run devtools latest-xcode

and get a result such as:

Xcode (Apple Silicon): 26.3

Our tool will:

fetch release data from a public JSON endpoint
decode the response using Codable
print the latest Xcode version

This small example will already demonstrate the core building blocks of many real-world automation tools such as structured commands, argument parsing and async networking.

Creating an executable Swift package

Swift Package Manager can generate an executable project for us:

mkdir devtools
cd devtools
swift package init --type executable

The package name is derived from the folder name (devtools).

We can already run it:

swift run

In the folder, the files Package.swift and devtools.swift were created for us. The folder can be opened with an IDE such as Xcode for implementation.

Adding argument parsing

For structured arguments and built-in help output, Apple provides an official package called Swift Argument Parser. We can add it to Package.swift as follows:

dependencies: [
    .package(
        url: "https://github.com/apple/swift-argument-parser.git",
        from: "1.3.0"
    )
],
targets: [
    .executableTarget(
        name: "devtools",
        dependencies: [
            .product(
                name: "ArgumentParser",
                package: "swift-argument-parser"
            )
        ]
    )
]

Defining the command structure

Now we can replace the generated code in devtools.swift with a structured command setup:

import ArgumentParser
import Foundation

@main
struct DevTools: AsyncParsableCommand {

    static let configuration = CommandConfiguration(
        abstract: "Developer utilities.",
        subcommands: [LatestXcodeCommand.self]
    )
}

struct LatestXcodeCommand: AsyncParsableCommand {

    static let configuration = CommandConfiguration(
        commandName: "latest-xcode",
        abstract: "Print the latest Xcode version."
    )

    func run() async throws {
        print("TODO: Here, we will fetch and show the latest Xcode version.")
    }
}

This way, we define a root command (devtools) that can host multiple subcommands and define LatestXcodeCommand as a sub command.

Now, we can already run swift run devtools --help which will print available sub commands, in our case latest-xcode. And we can already try out swift run devtools latest-xcode, which will currently print our TODO: .. statement from the run method.

Fetching and showing the latest Xcode version

Apple provides a public endpoint to fetch xcode release data: https://xcodereleases.com/data.json. First, we define a struct which represents the relevant data of the json:

struct XcodeRelease: Decodable {
    let name: String
    let version: Version
    let dateOrder: Int

    struct Version: Decodable {
        let number: String
    }

    enum CodingKeys: String, CodingKey {
        case name
        case version
        case dateOrder = "_dateOrder"
    }
}

The fetch method inside LatestXcodeCommand might then look as follows:

func fetchReleases() async throws -> [XcodeRelease] {
    let url = URL(string: "https://xcodereleases.com/data.json")!
    let (data, response) = try await URLSession.shared.data(from: url)

    guard let http = response as? HTTPURLResponse,
            (200..<300).contains(http.statusCode)
    else {
        throw URLError(.badServerResponse)
    }
    return try JSONDecoder().decode([XcodeRelease].self, from: data)
}

Note:
If you opened the package in Xcode, make sure to select the executable scheme (e.g. devtools) and run it on My Mac. Otherwise, Xcode might try to build it for iOS, which can lead to availability errors when using Swift concurrency.

Now, we can use it inside the run method:

struct LatestXcodeCommand: AsyncParsableCommand {

    func run() async throws {
        let releases = try await fetchReleases()

        guard let latest = releases
            .sorted(by: { $0.dateOrder > $1.dateOrder })
            .first
        else {
            throw ValidationError("No release found.")
        }

        print("\(latest.name): \(latest.version.number)")
    }
}

This command fetches Xcode release data, sorts them by date and prints the newest one. To keep it simple, the current command does not filter for stable releases.

Now, when running swift run devtools latest-xcode again, we'll get our desired result:

Xcode (Apple Silicon): 26.3

Building a standalone binary

So far, we have been running the tool using the debug mode. To generate an optimized standalone binary, we can create a release build:

swift build -c release

This produces a compiled executable located at:

.build/release/devtools

The generated file is a native macOS executable. It does not require Xcode to run. Only the Swift runtime, which is already available on macOS systems with Xcode installed.

We can now copy the executable anywhere or use it in CI pipelines. For example after copying it to /usr/local/bin, the command will be globally available:

devtools latest-xcode

Conclusion

With Swift Package Manager and Swift Argument Parser, building clean and maintainable CLI tools in Swift is straightforward. In just a few steps, we created a structured CLI, argument parsing, async networking and JSON decoding.

How to use SwiftUI Coordinators to communicate with UIKit

Sun, 08 Feb 2026 23:00:00 GMT

When building SwiftUI apps, we sometimes still need UIKit. Maybe we're integrating an older code base or using system controllers that don't yet have a native SwiftUI equivalent.

In those cases, we can wrap UIKit views or view controllers using UIViewControllerRepresentable. But as soon as delegates or callbacks are involved, we need a way to communicate back to SwiftUI. That's where coordinators come in.

Let's look at a practical example.

The goal

Suppose we want to use Apple's DataScannerViewController to scan QR codes. At the time of writing, DataScannerViewController does not have a native SwiftUI equivalent yet.

From SwiftUI, we want to:

present the scanner
scan a code
pass the scanned value back to SwiftUI state

Wrapping the view controller

To embed a UIKit view controller inside SwiftUI, we conform to UIViewControllerRepresentable:

struct ScannerView: UIViewControllerRepresentable {

    @Binding var code: String?

    func makeUIViewController(context: Context) -> DataScannerViewController {
        let controller = DataScannerViewController(
            recognizedDataTypes: [.barcode(symbologies: [.qr])]
        )
        return controller
    }

    func updateUIViewController(_ uiViewController: DataScannerViewController, context: Context) {
    }
}

Now we can present it like any other SwiftUI view:

struct ContentView: View {
    @State private var code: String?
    @State private var showingScanner = false

    var body: some View {
        VStack {
            Text(code ?? "")
            Button("Scan QR code") {
                showingScanner = true
            }
        }
        .sheet(isPresented: $showingScanner) {
            ScannerView(code: $code)
        }
    }
}

So far, the code binding we pass into the scanner view never gets updated by it. To be able to do that, we need to setup the scanner view controller's delegate at first.

Why we need a coordinator

UIKit delegates require a reference type (class). But SwiftUI views are structs. So our ScannerView cannot directly act as the delegate.

SwiftUI solves this mismatch by providing coordinators which act as small bridge objects that:

conform to delegates
receive UIKit callbacks
forward data back to SwiftUI

Creating a coordinator

Every representable can define a nested Coordinator type and a makeCoordinator() method:

struct ScannerView: UIViewControllerRepresentable {

    @Binding var code: String?

    func makeCoordinator() -> Coordinator {
        Coordinator(code: $code)
    }

    class Coordinator {
        @Binding var code: String?

        init(code: Binding<String?>) {
            _code = code
        }
    }
}

SwiftUI keeps this coordinator alive for the lifetime of the representable.

Conforming to the delegate

We can then extend the coordinator to serve as DataScannerViewControllerDelegate:

class Coordinator: DataScannerViewControllerDelegate {

    @Binding var code: String?

    init(code: Binding<String?>) {
        _code = code
    }

    func dataScanner(_ dataScanner: DataScannerViewController, didAdd addedItems: [RecognizedItem], allItems: [RecognizedItem]) {
        guard let item = allItems.first else { return }
        switch item {
        case .barcode(let code):
            code = code.payloadStringValue
        default: break
        }
    }

}

Now the coordinator receives scan results and updates the binding.

Connecting everything

Finally, we assign the delegate inside makeUIViewController:

func makeUIViewController(context: Context) -> DataScannerViewController {
    let controller = DataScannerViewController(
        recognizedDataTypes: [.barcode(symbologies: [.qr])]
    )

    controller.delegate = context.coordinator
    try? controller.startScanning()

    return controller
}

context.coordinator gives us the instance SwiftUI created earlier.

Migrating to the Observation framework in SwiftUI

Sun, 01 Feb 2026 23:00:00 GMT

SwiftUI's current state-of-the-art approach to state observation is the Observation framework. It uses the macro system in Swift to transform Swift types into observable state.

In this article, we'll look at how Observation differs from the older ObservableObject and @Published pattern, and how to migrate existing SwiftUI code step by step.

How Observation differs conceptually

Observation isn't just a syntax change, it introduces property-level tracking.

Unlike ObservableObject, which broadcasts change notifications for the entire object, Observation tracks access to individual properties. SwiftUI only updates views when a property they actually read changes.

This reduces unnecessary updates and makes view invalidation more precise.

Migration steps

Observation comes with a @Observable macro which automatically adds observation support to a Swift type. To start using it, the following migration steps are required:

Replace ObservableObject with @Observable macro
Replace @StateObject with @State
Replace @ObservedObject with @Bindable
Replace @EnvironmentObject with @Environment

Not all projects will need every step, but these changes cover the most common migration paths from ObservableObject-based code.

Let's look at these steps in more detail.

1. Replace `ObservableObject` with `@Observable` macro

To replace ObservableObject with the @Observable macro, we need to remove conformances to ObservableObject, remove all @Published annotations, add @ObservationIgnored where needed and apply the Observable macro instead.

Here is an example:

/// BEFORE
class UserViewModel: ObservableObject {
    @Published var name: String?
    @Published var email: String?

    var authenticationService: AuthenticationService
}

/// AFTER
@Observable class UserViewModel {
    var name: String? = nil
    var email: String? = nil

    @ObservationIgnored
    var authenticationService: AuthenticationService
}

Properties marked with @ObservationIgnored are excluded from observation and do not trigger view updates. This is an important migration detail that may easily be missed.

2. Replace `@StateObject` with `@State`

Before the Observation framework, we used @State for value types and @StateObject for reference types to let SwiftUI update views whenever changes occured. With Observation, both types are covered by @State:

/// BEFORE
struct UserView: View {
    @StateObject var viewModel = UserViewModel()

    var body: some View {
        ...
    }
}

// AFTER
struct UserView: View {
    @State var viewModel = UserViewModel()

    var body: some View {
        ...
    }
}

3. Replace `@ObservedObject` with `@Bindable`

Before the Observation framework, we used @Binding for value types and @ObservedObject for reference types to create two-way bindings. With Observation, we use @Binding for value types and @Bindable for reference types:

// BEFORE
struct UserView: View {
    @ObservedObject var viewModel: UserViewModel

    var body: some View {
        ...
    }
}

// AFTER
struct UserView: View {
    @Bindable var viewModel: UserViewModel

    var body: some View {
        ...
    }
}

If you want to better understand when and why @Bindable is required, check out this article on how @Bindable works in SwiftUI.

4. Replace `@EnvironmentObject` with `@Environment`

Instead of the @EnvironmentObject property wrapper, the Observation framework uses the @Environment property wrapper to pass objects down the view hierarchy:

// BEFORE
struct UserView: View {
    @EnvironmentObject var viewModel: UserViewModel

    var body: some View {
        ...
    }
}

// AFTER
struct UserView: View {
    @Environment(UserViewModel.self) private var viewModel

    var body: some View {
        ...
    }
}

Migrating incrementally and understanding these conceptual changes helps avoid subtle issues and keeps SwiftUI state predictable as projects evolve.

A visual cheat sheet of Combine operators

Sun, 25 Jan 2026 23:00:00 GMT

This article provides a visual cheat sheet of common Combine operators, with a diagram for each one to illustrate how values flow through a pipeline. The diagrams focus on the most commonly used operators.

Note: The diagrams below are generated using SwiftUI. If you're interested in how they are built, you can find the source code on GitHub.

How to use String Catalogs for pluralization in Swift

Sun, 18 Jan 2026 23:00:00 GMT

String Catalogs provide a type-safe way to handle plural forms across languages. In this article, we look at how to define pluralized strings in String Catalogs and how to use them from Swift without manual formatting or conditional logic.

Let's jump in.

Defining pluralized strings in a String Catalog

To define a pluralized string, we start by creating a localization key as usual, for example:

applesSelection.title

To enable pluralization, we right-click the key-value pair in the String Catalog and choose “Vary by Plural”.

Xcode then automatically generates the required plural categories for the current language. What remains is adjusting the translations for the different plural cases. For example:

%lld apple // For one
%lld apples // For other

The format specifier (%lld) tells the localization system that this string expects a numeric value, which will later drive pluralization.

Which plural forms are shown depends on the language. Some languages only require one and other, while others define additional categories.

Using the pluralized string in Swift and SwiftUI

Once a plural variable is defined, Xcode generates a typed accessor for the localized string. We can use it as follows:

Text(.applesSelectionTitle(1))

Outside SwiftUI, we can use the same accessor:

let text = String(localized: .applesSelectionTitle(5))

In both cases, the value we pass determines which plural form is selected for the current locale. There is no string interpolation and no conditional logic in code, the localization system handles everything.

Memory management in Combine

Sun, 11 Jan 2026 23:00:00 GMT

Combine allows us to model asynchronous workflows declaratively. Publishers emit values, subscribers react to them, and operators connect everything into a clear pipeline.

What's easy to overlook is that Combine also introduces a specific ownership model. If we don't understand who holds references to whom, objects may live longer than expected, or never be released at all.

Let's look at how memory management works in Combine.

The ownership model in Combine

When we subscribe to a publisher using operators like sink or assign, Combine creates:

a subscriber
an AnyCancellable, which represents the subscription's lifetime

A simple rule of thumb is:

Whoever owns the AnyCancellable owns the subscription.

As long as the cancellable exists, the subscription remains active.

How retain cycles appear in Combine

Let's look at the following example:

var cancellable: AnyCancellable?

func startTimer() {
    cancellable = Timer.publish(every: 1, on: .main, in: .default)
        .autoconnect()
        .sink { _ in
            self.tick()
        }
}

This creates a retain cycle:

self → cancellable → subscriber → closure → self

An important thing to understand is that a retain cycle not always leads to a memory leak.

Why a retain cycle does not always become a memory leak

A retain cycle is a structural issue: two or more objects hold strong references to each other, forming a cycle. A memory leak is a behavioral problem: an object remains in memory longer than intended and can never be released.

These two concepts are related, but they are not the same. A retain cycle can cause a memory leak, but only if nothing ever breaks the cycle.

For example, if the publisher completes, Combine tears down the subscription, so the closure gets released. This is why retain cycles caused by short-lived subscriptions do not turn into memory leaks.

Examples of short-lived publishers are network requests, Just, Future, finite sequences. In these cases, the retain cycle exists only temporarily and resolves itself automatically.

Long-lived subscriptions are different

Some publishers never complete on their own:

timers
NotificationCenter publishers
subjects
continuous streams

With these publishers, the retain cycle remains in place until we explicitly break it.

If we never cancel the subscription and capture self strongly, the cycle becomes a real memory leak.

Cancellation breaks the cycle

Explicit cancellation has the same effect as completion.

When we cancel a subscription or release the AnyCancellable, Combine tears down the subscription and releases the subscriber and closure.

func stopTimer() {
    cancellable = nil
}

With this in place the retain cycle still exists while the timer is running. Once cancelled, the cycle is resolved. This is an important distinction: the code does create a retain cycle, but it does not necessarily leak. Of course, we risk a memory leak, for example when forgetting to call stopTimer.

Using weak self

To avoid retain cycles entirely, we can capture self weakly:

.sink { [weak self] _ in
    self?.tick()
}

This breaks the cycle proactively. When self is deallocated, the subscription is cancelled automatically. This approach is especially important for long-lived subscriptions where cancellation is not guaranteed.

In practice:

If we capture strongly, we must guarantee cancellation
If cancellation is uncertain, weak captures are safer

In practice, using [weak self] is often the safest default, especially when the lifetime of a subscription is unclear or may change over time.

Storing Swift structs in UserDefaults

Sun, 04 Jan 2026 23:00:00 GMT

UserDefaults is often the first place we reach for when we want to persist small pieces of data. It's simple, built into the system, and works well for basic types like strings, numbers, and booleans.

But what if we try to store a Swift struct in UserDefaults. Let's look at how to do that.

What UserDefaults can store by default

Out of the box, UserDefaults only supports data types which are also supported by property lists. Those are:

Bool
Float
Double
Int
String
URL
Date
Data

We can also store arrays and dictionaries but only if their elements are one of the types listed above.

Storing a struct in UserDefaults

When we try to store a Swift struct in UserDefaults, the compiler does not complain:

struct Content {
    let title: String
}

let content = Content(title: "Some title")

let userDefaults = UserDefaults.standard
userDefaults.set(content, forKey: "content")

However, once we run the app, it crashes with the following exception:

Exception: Attempt to insert non-property list object for key content

To store a Swift struct in UserDefaults, we need to convert it to one of the supported types. One common approach is to use Codable and encode the struct into Data:

struct Content: Codable {
    let title: String
}

if let contentData = try? JSONEncoder().encode(content) {
    userDefaults.set(contentData, forKey: "content")
}

To read the stored data, we can use a JSON decoder:

if let contentData = userDefaults.data(forKey: "content"),
    let content = try? JSONDecoder().decode(Content.self, from: contentData) {
    print(content)
}

This pattern is easy to implement. But it comes with an important caveat.

Why the Codable approach is error-prone

The biggest issue with this approach appears when our model changes.

If we later modify Content, for example by renaming a property, changing its type or by adding another property, the JSON decoder will not be able to decode a previously saved object.

Unlike a database-based storage, there's no built-in migration mechanism. Since we don't get any compiler hints or errors when changing the struct, this kind of storage may easily lead to bugs or lost data.

An alternative: storing properties individually

If we want more control and resilience to future changes, we can store individual properties instead of encoding the entire struct:

func writeContent(_ content: Content) {
    userDefaults.set(content.title, forKey: "contentTitle")
    userDefaults.set(content.amount, forKey: "contentAmount")
}

func readContent() -> Content {
    let title = userDefaults.string(forKey: "contentTitle") ?? ""
    let amount = (userDefaults.object(forKey:) as? Int) ?? 0
    return Content(title: title, amount: amount)
}

With this approach, we gain flexibility:

We can add or remove properties without breaking decoding
We can provide sensible default values
Renaming properties becomes much safer

The trade-off is a bit more manual work, but in return, we get more predictable behavior as our app evolves.

Understanding date decoding strategies when working with JSON in Swift

Sun, 28 Dec 2025 23:00:00 GMT

Working with JSON in Swift is usually straightforward. Until dates enter the picture. APIs rarely agree on a single date format, and a mismatch between what the backend sends and what JSONDecoder expects can lead to confusing decoding failures.

Swift gives us several date decoding strategies to handle this. Let's take a closer look.

The default behavior

By default, JSONDecoder uses the .deferredToDate strategy which is Apple's own date format.

This strategy only works if the JSON value is encoded in a very specific way. For example, when decoding data that was also encoded by JSONEncoder. An example is 695980776.16554499.

For most APIs, this default is not useful and usually results in a decoding error. So in almost all real-world scenarios, we explicitly choose a decoding strategy.

Decoding timestamps

A common format is a numeric timestamp. If the backend sends seconds since 1970:

{
  "createdAt": 1698787200
}

we can use:

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .secondsSince1970

If the value is in milliseconds instead:

{
  "createdAt": 1698787200000
}

we can switch to:

decoder.dateDecodingStrategy = .millisecondsSince1970

As long as the backend is consistent, these strategies are simple, fast, and reliable.

ISO 8601 dates

Another very common format is ISO 8601:

{
  "createdAt": "2023-11-01T12:00:00Z"
}

Swift provides a built-in strategy for this as well:

decoder.dateDecodingStrategy = .iso8601

This works for many APIs, but it’s worth noting that the built-in ISO 8601 parser is somewhat strict. Variations like fractional seconds or slightly different timezone representations may cause decoding to fail. That’s often the moment where custom strategies become necessary.

Using a custom date formatter

When the date format doesn't match any built-in strategy, we can decode dates using a custom DateFormatter.

For example, given this JSON:

{
  "createdAt": "2023-11-01 14:30:00"
}

we can configure the decoder like this:

let formatter = DateFormatter()
formatter.dateFormat = "yyyy-MM-dd HH:mm:ss"
formatter.locale = Locale(identifier: "en_US_POSIX")
formatter.timeZone = TimeZone(secondsFromGMT: 0)

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .formatted(formatter)

Setting the locale and time zone explicitly is important here. Without it, decoding can behave differently depending on the user's device settings.

When one format is not enough

Some APIs return different date formats in different fields, or even within the same field over time. In those cases, we can use a .custom strategy:

decoder.dateDecodingStrategy = .custom { decoder in
    let container = try decoder.singleValueContainer()
    let string = try container.decode(String.self)

    let formatters: [DateFormatter] = [
        isoFormatter,
        fallbackFormatter
    ]

    for formatter in formatters {
        if let date = formatter.date(from: string) {
            return date
        }
    }

    throw DecodingError.dataCorruptedError(
        in: container,
        debugDescription: "Invalid date format: \(string)"
    )
}

This keeps the complexity in one place and prevents needing to parse individual fields separately.

Understanding SwiftUI's Grid container

Sun, 21 Dec 2025 23:00:00 GMT

SwiftUI's Grid gives us a way to build two-dimensional layouts without using nested HStack/VStack combinations. The grid aligns items based on columns determined by the content we place inside rows.

Let's look at how it works and when to prefer it over stack combinations.

Grid is a two-dimensional layout where:

Each GridRow represents one horizontal row.
Each element inside a row creates or fills a column.
Columns align automatically across rows.

So if the first row contains three elements, and the second row contains only two, SwiftUI still reserves a third column, keeping everything aligned.

Let's look at an example:

var body: some View {
    Grid(horizontalSpacing: 20, verticalSpacing: 20) {
        ForEach(animals, id: \.id) { animal in
            GridRow(alignment: .top) {
                Text(animal.name)
                    .gridColumnAlignment(.trailing)
                Image(systemName: animal.imageSystemName)
                    .gridColumnAlignment(.center)
                Text(animal.description)
                    .gridColumnAlignment(.leading)
            }
        }
    }
}

Here, each row is aligned with the gridColumnAlignment modifier. This results in the following view:

Grid container example.

So a grid is basically a structured HStack/VStack combination - with the important difference for the shared column alignment. So if we want column alignment across multiple rows without manual geometry, Grid is the view to go.

Grid also provides the possibility to let a cell span multiple columns using gridCellColumns(_:). This allows us to create layouts where certain elements such as section headers or wide images stretch across the full row while others remain aligned to their individual columns.

It is worth mentioning, that Grid does not automatically wrap elements to the next line. SwiftUI will place all items in a single row unless we manually create rows. The grid is column-aligned, not space-aware. SwiftUI currently doesn’t provide a built-in flowing grid container.

Adding text input actions to iOS push and local notifications

Sun, 14 Dec 2025 23:00:00 GMT

Interactive notifications let users take action without opening the app. In addition to being able to add custom actions to notifications, we also have the option to add a notification action that allows custom text input. This is especially useful for quick replies, feedback, or short form responses without forcing users to open the app.

In this article, we'll walk through how to create text input actions, how to register the required categories, and how to handle the user's response in a SwiftUI app.

Defining a text input action

A text input action is represented by a UNTextInputNotificationAction. This action displays a text field inside the notification UI:

let howManyGlassesInputAction =  UNTextInputNotificationAction(
        identifier: NotificationAction.howManyGlasses.rawValue,
        title: "How many glasses of water did you drink?",
        options: [],
        textInputButtonTitle: "Add",
        textInputPlaceholder: "Number of glasses")

Once defined, this action behaves just like any other notification action and needs to be registered inside a notification category.

Creating a category

Notification actions always belong to a notification category. Each delivered notification specifies which category it belongs to, and iOS uses that to decide which actions to display.

We can now create a category that includes our text input action:

let drinkingRemiderCategory = UNNotificationCategory(
    identifier: NotificationCategory.drinkingReminder.rawValue,
    actions: [doneAction, notThirstyAction, howManyGlassesInputAction],
    intentIdentifiers: [],
    options: .customDismissAction)

Registering a category

To encapsulate all notification-related logic, we can create a dedicated NotificationService class that is responsible for:

Creating and registering notification categories
Handling text input responses
Requesting authorization (not part of this article)

import UserNotifications

class NotificationService: NSObject, UNUserNotificationCenterDelegate {

    func setup() {
        UNUserNotificationCenter.current().delegate = self
        registerCategories()
    }

    private func registerCategories() {
        // Create actions and categories

        // Register the category
        UNUserNotificationCenter.current().setNotificationCategories([drinkingReminderCategory])
    }
}

We can then use this service in a SwiftUI app as follows:

@main
struct MyApp: App {

    private let notificationService = NotificationService()

    init() {
      notificationService.setup()
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

Now, every time a notification with the configured id is delivered, the text input action is shown to the user.

Handling the response

When a user chooses the text input action and provides an input, the text is included in the response object delivered to our app. To access it, we can map the response to the UNTextInputNotificationResponse type that has the property userText.

func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) {
    switch response.actionIdentifier {
    case NotificationAction.howManyGlasses.rawValue:
        if let userInput = (response as? UNTextInputNotificationResponse)?.userText {
            // Handle text input
        }
    default:
        break
    }
    completionHandler()
}

This method also belongs in NotificationService, keeping all notification handling in one focused place.

How to avoid retain cycles when working with tasks in Swift

Sun, 07 Dec 2025 23:00:00 GMT

Swift's concurrency system gives us a clean, readable way to express asynchronous work using async/await and tasks. Since we are capturing values when working with tasks, it's important to understand how memory management works here to avoid potencial retain cycles.

In this article, we look at how tasks hold on to references and where retain cycles might appear.

Whenever we create a task, for example through Task {}, Swift captures any values we reference inside the task body. These captures are strong by default.

This means:

A task keeps its captured values alive until the task completes.
If we capture self strongly, and self also holds a reference to the task, we create a retain cycle.
But importantly, this cycle lasts only for the lifetime of the task.

Let's look at a concrete example:

class ImageLoader {
    private var task: Task<Void, Never>?

    func load() {
        task = Task {
            await loadImage()
        }
    }

    func loadImage() async {
        // ...
    }
}

What happens here is:

the ImageLoader instance strongly retains the task (because task is a stored property)
the task strongly retains its closure,
the closure strongly retains self (because we call downloadImages())

So, while the task is running, we do have a retain cycle:

ImageLoader → Task → ImageLoader

However, tasks have an important difference from classic stored completion handlers: a task releases its closure once the task finishes.

This means:

In this example, the cycle lasts only for as long as the image is loading.
When the task completes, it drops its closure and therefore releases self.

If we prefer to avoid even this temporary cycle, we can capture self weakly with [weak self] but for short-lived tasks it is usually optional.

Where retain cycles become memory leaks

Temporary retain cycles are rarely an issue, but with permanent ones we may run into memory leaks. This happens when all three are true:

We store the task (as a property).
The task's closure captures self strongly.
The task never finishes or finishes much later than we expect.

This can appear in long-running loops or stream processing:

class MessageListener {
    private var task: Task<Void, Never>?

    func start() {
        task = Task { [weak self] in
            for await message in await messages.stream() {
                guard let self else { return }
                self.handle(message)
            }
        }
    }

    func handle(_ message: Message) { }
}

In this example, the loop may run indefinitely. Without [weak self], the task keeps self alive, and self keeps the task alive, forming a classic retain cycle.

Using a weak capture breaks this cycle and ensures that the task naturally terminates once the listener goes out of scope.

Understanding associated domains in iOS

Sun, 30 Nov 2025 23:00:00 GMT

Associated domains create a secure, system-managed connection between an iOS app and its matching website, allowing us to support features like universal links, shared web credentials with password auto fill or app clips.

All of these rely on the same mechanism: an apple-app-site-association file on the website + an associated domains entitlement in the app.

In this artile, we walk through how the system works and how to configure everything correctly.

What associated domains are

In simple terms, associated domains allow iOS to verify: "This website and this app belong together."

Once verified, we can implement features such as:

Universal Links: let us route specific URLs directly into the app instead of opening them in a browser. If the app is installed, we can navigate the user to the appropriate screen immediately. If it is not installed, the URL opens on the website as usual.
Shared Web Credentials with Password AutoFill: our app can access authentication information a user previously saved in iCloud Keychain while using the connected website. When a user has already signed in on the web, the app can request the username and password and fill them automatically
App Clips: an app clip is a lightweight version of the iOS application offering users access to certain functionality. It lets users complete a quick task like renting a bike or ordering food - even before installing the full app.

Setting this up requires two parts:

A JSON file (apple-app-site-association) hosted on the website
A matching entitlement inside the app

Creating and configuring an associated domain file

The first step requires creating a file named apple-app-site-association without an extension and configuring it by using the JSON format. Its top-level structure typically contains keys for the services we want to support:

{
  "applinks": {},
  "webcredentials": {},
  "appclips": {}
}

A example configuration for universal links might look as follows:

{
  "applinks": {
    "details": [
      {
        "appIDs": ["APPIDPREFIX.com.tanaschita.exampleApp"],
        "components": [
          {
            "/": "birds"
          }
        ]
      }
    ]
  }
}

It tells iOS that any URL of this website whose path begins with /birds should be handled by our app.

Adding the associated domain file to the related website

After configuring the association file the way we need, the second step is to place it into the website's .well-known directory:

https://<domain>/.well-known/apple-app-site-association

The file's URL should match the format shown above. The file:

must be served over HTTPS
must not have a .json extension
should be served with a JSON content type, which Apple expects when parsing

Adding an associated domain entitlement to the iOS app

Next, we can add the entitlement to our app:

Open the app target in Xcode.
Navigate to Signing & Capabilities.
Add Associated Domains.

Inside the capability, we can add entries using this format:

applinks:example.com
webcredentials:example.com
appclips:example.com

Enabling alternate mode for testing

Apps request apple-app-site-association files from an Apple-managed content delivery network (CDN) instead directly from the web server. The CDN regularly connects to the web server to obtain the latest version.

During development, the web server might be not publicly reachable yet. To still be able to test, we can enable the alternate mode feature to bypass the CDN and connect directly to the server by adding the following configuration:

applinks:example.com?mode=developer

Checkout this article using associated domains alternate mode to learn more.

Using associated domains alternate mode during development

Sun, 23 Nov 2025 23:00:00 GMT

When working with associated domains, for example to support universal links, shared web credentials, or App Clips, iOS fetches the apple-app-site-association (AASA) file through Apple's CDN, not directly from the server where the file is hosted.

This works well in production, but during development it can be inconvenient: changes to the file may take a while to propagate, and local or staging servers might not be publicly reachable at all.

To make development easier, Apple offers an alternate mode.

In this mode, iOS bypasses the CDN and talks directly to our server. We can enable it by modifying the associated domains entries in Xcode.

Let's say we have the following associated domain configured:

applinks:example.com

During development, we can add a mode parameter, for example:

applinks:example.com?mode=developer

To use developer mode, the device must also opt in. On the device, we enable Settings → Developer → Associated Domains Development.

Additionally, for developer mode to work, the app needs to be signed with a development provisioning profile.

Only with all of these in place (the ?mode=developer suffix in Xcode, the developer toggle on the device and signing with a development provisioning profile), changes to the AASA file become visible immediately, and we can even test against local or staging environments as long as they are reachable from the device.

Available alternate modes

developer: works on devices in developer mode and with apps signed using a development profile.
managed: intended for enterprise environments on devices enrolled in Mobile Device Management (MDM). Useful when organizations control device policies.
developer+managed: a combination of the two. Direct fetching is enabled only when the device is both in developer mode and managed by MDM.

Bridging completion handlers to Swift's async/await

Sun, 16 Nov 2025 23:00:00 GMT

Before Swift introduced structured concurrency and async/await, most asynchronous APIs in iOS used completion handlers. While many system frameworks have since adopted native async functions, we still often encounter callback-based APIs.

To integrate those with Swift’s modern concurrency model, we can bridge them using continuations. Let's look at how to do that.

What continuations do

Every time we call await, the current code suspends by creating a continuation that captures the state at the point of suspension. When an awaited function completes, the captured state is recreated from the continuation and the original code resumes. This all happens behind the scenes when we use existing async functions.

To create our own async functions, we can use so called continuation functions. Continuation functions give us control over suspending and resuming a function.

Let's see how to do that.

Using `withCheckedContinuation`

Let's look at a simple example. Suppose we have an API that loads data using a completion handler:

func load(completion: (Int) -> Void) {
    ...
}

We can bridge it to Swift concurrency like this:

func load() async -> Int {
    return await withCheckedContinuation({ continuation in
        load() { result in
            continuation.resume(returning: result)
        }
    })
}

In the example above, we use Swift's withCheckedContinuation function to suspend and then call resume after we get a result from our completion handler function. Resuming from a continuation must happen exactly once.

Besides withCheckedContinuation(), there are other continuation functions we can use:

withCheckedThrowingContinuation()
withUnsafeContinuation()
withUnsafeThrowingContinuation()

Using `withCheckedThrowingContinuation`

If our callback reports errors, we can use the throwing version instead. For example, if we have:

func load(completion: (Result<Int, Error>) -> Void) {
}

We can wrap it into an async throws function as follows:

func load() async throws -> Int {
    return try await withCheckedThrowingContinuation({ continuation in
        load() { result in
            switch result {
            case .success(let successResult):
                continuation.resume(returning: successResult)
            case .failure(let error):
                continuation.resume(throwing: error)
            }
        }
    })
}

This lets us use the try await syntax when calling the function.

Using `withUnsafeContinuation()` and `withUnsafeThrowingContinuation()`

Both functions, withUnsafeContinuation() and withUnsafeThrowingContinuation() behave the same as withCheckedContinuation() and withCheckedThrowingContinuation(). The only difference is that while checked continuations perform runtime checks for missing or multiple resume operations, unsafe continuations don't.

Checked continuations are generally safer and preferred for most cases.

Transforming AsyncStream with Swift Async Algorithms

Sun, 09 Nov 2025 23:00:00 GMT

When we explored how we can use AsyncStream to implement reactive-style listening patterns, we also talked about one of its limitations: Swift's standard library doesn’t include many operators for transforming or combining asynchronous values.

That's where the Swift Async Algorithms package comes in. It extends the AsyncSequence protocol with operators like debounce, throttle, merge, and combineLatest, bringing Combine-like expressiveness to Swift concurrency.

Let's look at how this works.

Why it's not part of the Swift standard library (yet)

The Swift Async Algorithms package is developed and maintained by Apple as part of the official Swift open-source project: https://github.com/apple/swift-async-algorithms.

Apple uses these standalone "incubation" packages to evolve and stabilize new APIs before locking them into the language. Once a package's design has matured, it may eventually become part of Swift itself.

So to use it, we currently need to add it to our project, for example via Swift Package Manager.

Useful operators the package provides

The Swift Async Algorithms package includes many familiar operators from the reactive programming world, built to fit into Swift's async/await model. Here are some examples:

debounce(for:clock:) - delays emissions until a pause in values
throttle(for:clock:) - limits how often new values are emitted
merge(::) - merges multiple async sequences into one
combineLatest(::) - emits pairs of the latest values from two sequences
zip(::) – pairs values from two sequences positionally
buffer(policy:) - controls how to handle slow consumers
chain(::) - sequences two async sequences one after another
latest(::) - keeps only the most recent value from each source

Because AsyncStream conforms to AsyncSequence, all operators in Swift Async Algorithms automatically work with it.

Example: Debouncing user input

Let's look at a common use case: debouncing text input to avoid triggering too many requests while a user types:

searchTask = Task {
    for await query in await searchInput.stream()
        .debounce(for: .seconds(0.5), clock: .continuous)
        .removeDuplicates()
    {
        await performSearch(for: query)
    }
}

Here, searchInput is the AsyncPassthrough we have built in this article.

With this setup, when the user types into a search field, performSearch only fires once the user stops typing for half a second. This pattern mirrors Combine's .debounce operator.

Example: Combining streams

Another area where reactive programming shines is combining multiple streams. Let's see how the merge operator can be applied:

import AsyncAlgorithms

let numbers = AsyncStream<Int> { continuation in
    Task {
        for i in 1...3 {
            continuation.yield(i)
            try await Task.sleep(for: .milliseconds(300))
        }
        continuation.finish()
    }
}

let letters = AsyncStream<String> { continuation in
    Task {
        for char in ["A", "B", "C"] {
            continuation.yield(char)
            try await Task.sleep(for: .milliseconds(500))
        }
        continuation.finish()
    }
}

Task {
    for await value in merge(numbers, letters) {
        print("Received:", value)
    }
}

The result is an interleaved async sequence that emits values as they arrive.

Beyond operators: AsyncChannel

In addition to operators, the package also provides new async types such as AsyncChannel. We'll explore it in a follow-up article.

Understanding Task and Task.detached in Swift concurrency

Sat, 01 Nov 2025 23:00:00 GMT

When we explored structured and unstructured tasks, we saw a small example of using Task {} vs. Task.detached {}.

In this article, we'll go a bit deeper and look at how the two differ, and when it makes sense to use each.

Staying in context with Task

When we create a regular Task, it inherits context from where it's started.

That means:

If we’re inside an actor, the new task runs on that actor.
If the parent task has a certain priority or is cancelled, that state is inherited.

For example:

actor DataService {
    func refresh() {
        Task {
            await updateCache()
        }
    }
}

Here, updateCache() runs inside the actor. We don't need to think about isolation or thread safety, Swift takes care of that.

Creating an independent task with Task.detached

Task.detached starts a completely independent task. It doesn't inherit any context: not actor isolation, not priority, not cancellation.

In some cases, we can offload work from an actor so that it stays responsive. Actors process one piece of work at a time, so if we want to perform longer operations that don't depend on the actor's state, we can run them outside the actor's executor:

actor UserService {
    private let secureStore: SecureStore

    func clear() {
        Task.detached { [secureStore] in
            await secureStore.clearTokens()
        }
    }
}

Here, the actor becomes available immediately after starting the detached task.

However, this only works if secureStore is safe to call from outside the actor, for example, if they are actors themselves or thread-safe.

When detaching doesn't help

The example above works because the detached task doesn't touch the actor's state. But if we try to access it, we lose the benefit:

actor DataService {
    func refresh() {
        Task.detached { [weak self] in
            guard let self else { return }
            await self.updateCache()
        }
    }

    private func updateCache() async { ... }
}

This compiles, but it's effectively the same as using a regular Task. The detached task runs independently, then immediately hops back into the actor to do its work. So there's no real advantage here, we could have used a regular Task instead.

Also, it's a common misconception that Task.detached is necessary to make a task "keep running". That's not the case. Once a normal task is created outside structured concurrency, it already runs independently. A detached task doesn’t change that behavior. For example:

class DataService {
    func startWork() {
        Task {
            await doLongRunningWork()
        }
    }
}

This task will continue until it completes or is cancelled explicitly. Replacing it with Task.detached changes nothing in practice.

So if our goal is simply to start background work that finishes on its own, a normal Task is usually enough.

Understanding task cancellation and lifetimes in Swift concurrency

Sun, 26 Oct 2025 23:00:00 GMT

Swift's concurrency system gives us different ways to create and manage asynchronous work: some tasks are automatically tied to a scope, while others run independently. This distinction determines how long a task lives, whether it's automatically cancelled, and who is responsible for cleaning it up.

In this article, we'll look at how cancellation works in structured concurrency, what changes when we move to unstructured or detached tasks, and how to manage task lifetimes safely.

Structured tasks

In Swift, structured concurrency ties the lifetime of async work to the scope where it was created.

When we, for example, use async let, withTaskGroup, or SwiftUI's .task modifier, the system automatically cancels work when that scope ends.

For example, a Task started by SwiftUI through .task { ... } is automatically cancelled when the view disappears:

struct ContentView: View {
    @State private var text = ""

    var body: some View {
        Text(text)
            .task {
                text = await loadTitle()
            }
    }
}

When the view leaves the hierarchy, SwiftUI cancels the task.

The same applies to async let or withTaskGroup inside an async function:

func load() async throws -> [String] {
    async let a = loadUser()
    async let b = loadPosts()
    async let c = loadSettings()

    return try await [a, b, c]
}

Here, all three child tasks are bound to the scope of load(). When the load() function finishes, either successfully or with an error, or gets cancelled, all three async child tasks are cancelled as well.

This automatic cleanup is what makes structured concurrency predictable.

Unstructured and detached tasks

When we manually create a task using Task { ... } outside of a structured scope (for example, in a non-async method), the lifetime is no longer managed for us. The task runs independently until it completes, or until we explicitly cancel it.

To be able to cancel a task, we can store it:

class DataService {
    private var task: Task<Void, Never>?

    func startWork() {
        task = Task {
            await loadData()
        }
    }

    func cancelWork() {
        task?.cancel()
    }
}

An important thing to note here is that calling cancel() doesn't immediately stop the task, it only sets a cancellation flag that async operations can check. Swift does not forcibly terminate running work. Instead, async calls and loops can choose when to respect that flag.

Some system functions, such as URLSession.shared.data(from:) or Task.sleep(for:), automatically check for cancellation and throw a CancellationError. For our own async code, we can check manually using Task.checkCancellation() or Task.isCancelled.

Swift also provides a second kind of unstructured task: Task.detached. While a regular Task { ... } inherits the caller's priority, actor context, or cancellation state (if any), a detached task runs completely independently. In our example above, using Task.detached would behave the same in practice. But in other contexts, for instance when working inside actors or structured scopes, these differences can lead to noticeably different behavior. We'll look at the nuances between Task and Task.detached in an upcoming article.

Not every unstructured or detached task needs to be cancelled manually. If the task is doing something finite, for example performing a single network request, it will just run to completion.

Long-running tasks

Where manual cancellation becomes important is with long-lived work. In those cases, the task doesn't naturally end on its own.

For example, when working with AsyncStream, we may have code that listens to updates as follows:

Task {
    for await update in await service.updates {
        print("Received:", update)
    }
}

This task will keep running indefinitely, until either the stream finishes or the task is cancelled. In cases like this, it's a good idea to either use a structured task or store the task in a property to be able to stop it when needed.

It's also good to know how AsyncStream behaves on cancellation: when the task is cancelled, the consuming side of the stream stops receiving values because AsyncStream internally checks for cancellation and drops any values sent to a terminated continuation. However, the producing side (the code yielding values into the stream) doesn't automatically stop. It will keep running unless we handle cleanup explicitly.

When working with long-lived tasks like streaming updates, it's important to decide where a task's lifetime should end: either automatically through structure, or explicitly through stored references and manual cancellation.

Comparing Combine's subjects with AsyncStream in Swift

Sun, 19 Oct 2025 22:00:00 GMT

Combine's subjects such as PassthroughSubject or CurrentValueSubject have long been the go-to way to implement reactive observer patterns across an app. They provide a clear way to publish and observe values across different layers of an architecture.

With Swift concurrency, we now have another way to represent values that arrive over time: AsyncStream. In this article, we'll look at how it works, how it compares to Combine, and when it makes sense to switch.

The Combine way

A PassthroughSubject is a simple Combine publisher. It emits values to all current subscribers, often used to send updates, for example from a service:

final class DataService {
    let values = PassthroughSubject<String, Never>()

    func load() {
        someAsyncCall() { [weak self] result in
            self?.didUpdate.send("New data loaded \(result)")
        }
    }
}

To observe updates, we subscribe using Combine’s .sink method:

class DataViewModel {
    private var cancellables = Set<AnyCancellable>()
    private let service = DataService()

    init() {
        service.values
            .receive(on: DispatchQueue.main)
            .sink { [weak self] value in
                // received a new value
            }
            .store(in: &cancellables)
    }
}

This setup works great in apps already built around Combine. The framework takes care of threading and synchronization for us, automatically delivering updates on the main queue when needed. Each subscription is cancellable through AnyCancellable, making cleanup predictable and safe. Combine also provides a rich set of operators like map, debounce, and combineLatest, allowing us to transform, coordinate, and throttle asynchronous values with minimal code. And through SwiftUI's .onReceive, Combine integrates naturally into the view layer.

The concurrency-native alternative: AsyncStream

AsyncStream provides a lightweight, concurrency-native way to emit values over time. It fits naturally into Swift's structured concurrency model and can be used as an alternative to Combine's subjects in systems which does not need the full reactive possibilities Combine provides.

When using AsyncStream, we need to be aware of that it does not handle thread safety or subscription management automatically, and cancellation behaves differently than in Combine. Used with care, it can be an elegant replacement for simple "publish and listen" flows.

Let's look at a simple example:

actor DataService {
    private var continuations: [UUID: AsyncStream<String>.Continuation] = [:]

    var updates: AsyncStream<String> {
        let id = UUID()
        return AsyncStream { continuation in
            continuations[id] = continuation
            continuation.onTermination = { [weak self] _ in
                Task { await self?.removeContinuation(id) }
            }
        }
    }

    func load() async {
        let result = await someAsyncCall()
        for continuation in continuations.values {
            continuation.yield("New data loaded \(result)")
        }
    }

    private func removeContinuation(_ id: UUID) {
        continuations[id] = nil
    }
}

To consume values, we can use for await:

let service = DataService()

Task {
    for await update in service.updates {
        print("Received:", update)
    }
}

Task {
    await service.load()
}

Let's unpack what's happening:

When we create an AsyncStream we pass in a closure which gets called once per consumer. Inside that closure, Swift gives us an AsyncStream.Continuation. We can think of that continuation as a pipe into the consumer's for await loop. We can send (yield) values into it, and the consumer will receive them one by one.
Since we can have multiple consumers, we save these continuations in an array: one continuation per active subscriber.
When we later call yield we're broadcasting the new value to every consumer who’s currently listening. Each continuation represents an active for await loop somewhere in the app.
If one of those subscribers stops consuming the stream (for example, its task is cancelled), the stream’s onTermination closure is called. That's when we remove that continuation from the array. That keeps our list clean and prevents sending values into closed streams.

We use an actor here because actors serialize access to shared mutable state. Without it, accessing the continuations collection from multiple concurrent tasks could lead to race conditions.

Reusing AsyncStream

If we find ourselves creating many small streams, we can wrap this pattern in a lightweight helper, similar to a PassthroughSubject, but based on AsyncStream:

actor AsyncPassthrough<Value> {
    private var continuations: [UUID: AsyncStream<Value>.Continuation] = [:]

    func stream() -> AsyncStream<Value> {
        let id = UUID()
        return AsyncStream { continuation in
            continuations[id] = continuation
            continuation.onTermination = { [weak self] _ in
                Task { await self?.removeContinuation(id) }
            }
        }
    }

    func send(_ value: Value) {
        for continuation in continuations.values {
            continuation.yield(value)
        }
    }

    private func removeContinuation(_ id: UUID) {
        continuations[id] = nil
    }
}

Usage can look as follows:

let messages = AsyncPassthrough<String>()

Task {
    for await msg in await messages.stream() {
        print("Received:", msg)
    }
}

Task {
    await messages.send("Hello")
    await messages.send("World")
}

What about CurrentValueSubject?

If we need the behaviour of a CurrentValueSubject to hold and publish the latest value, we could build something similar as follows:

actor CurrentValue<Value> {
    private var value: Value
    private let passthrough = AsyncPassthrough<Value>()

    init(_ initial: Value) { value = initial }

    func updates() async -> AsyncStream<Value> {
        await passthrough.stream()
    }

    func set(_ newValue: Value) async {
        value = newValue
        await passthrough.send(newValue)
    }

    func get() -> Value { value }
}

Here, we store the latest value in a property and expose a stream that emits it whenever it changes. This pattern gives us both current state (get()) and an async sequence of updates (updates).

Using AsyncSequence operators

Since AsyncStream conforms to AsyncSequence, we can also use the same sequence operators Swift provides, such as map, filter or prefix. For example:

Task {
    for await update in await service.updates
        .filter { !$0.isEmpty }
        .map { $0.uppercased() }
        .prefix(3)
    {
        print("Received:", update)
    }
}

This applies basic transformations directly to the stream: we filter out empty updates, convert them to uppercase, and only take the first three results.

While these basic operators cover many common cases, they don’t replace the depth of Combine’s reactive toolset. Features like debounce, merge, or combineLatest are often essential when coordinating multiple streams or handling user-driven events. In those scenarios, Combine still provides a richer and more expressive way to work with asynchronous data flows.

Note on cancellation

When a task consuming the stream is cancelled, Swift automatically calls the continuation's onTermination handler. This means cancellation happens for free in many structured contexts, such as SwiftUI's .task modifier. However, when we manually create tasks outside of SwiftUI, we need to manage cancellation ourselves.

We'll explore this distinction in an upcoming article.

Wrapping up

AsyncStream doesn't replace Combine. For complex reactive data flows, Combine currently remains the more powerful framework. For lightweight "publish and listen" patterns, AsyncStream can be used as an alternative.

When SwiftUI automatically applies the glass look and when it doesn’t

Sun, 12 Oct 2025 22:00:00 GMT

Since iOS 18, buttons, toolbars, and other controls can appear in Apple's new glass button style. What's interesting is that SwiftUI sometimes applies this effect automatically, depending on where a view is placed. In this article, we'll look at when that happens, when it doesn't.

Automatic glass style in toolbars

The most visible case of automatic glass styling happens in toolbars. When we use system placements like .confirmationAction, .cancellationAction, or .automatic, SwiftUI automatically applies the new .glass style to buttons placed there.

.toolbar {
    ToolbarItem(placement: .confirmationAction) {
        Button("Save", action: save)
    }
    ToolbarItem(placement: .cancellationAction) {
        Button("Cancel", action: cancel)
    }
}

Even though we never set .buttonStyle(.glass), both buttons adopt the glass appearance.

At the moment, there’s no official way to opt out. Applying .buttonStyle(.plain) or changing the layout does not remove the glass styling.

When glass doesn't appear in toolbars

The only remaining place in toolbars where the automatic glass style does not apply is the .principal placement. This slot is meant for titles or custom content and keeps its regular appearance, even if it contains buttons:

.toolbar {
    ToolbarItem(placement: .principal) {
        HStack {
            Text("Title Text")
            Image(systemName: "leaf")
            Button("Action", action: {})
        }
    }
}

Buttons outside toolbars

Outside toolbars, buttons do not get the glass style automatically. A standard Button in a normal view does not adopt any automatic glass styling, we have to apply it ourselves if we want the look:

VStack(spacing: 20) {
    Button("Add", action: add)
    Button("Glass Add", action: add)
        .buttonStyle(.glass)
}

How to add custom actions to iOS push and local notifications in SwiftUI

Sun, 05 Oct 2025 22:00:00 GMT

By default, an iOS notification just shows an alert, and tapping it opens the app. But we can also make notifications interactive by adding custom actions, for example, letting users mark a task as done, snooze a reminder, or open the app directly from the notification.

In this article, we'll look at how to create, register, and handle these actions using SwiftUI.

Let's jump in.

What are notification actions?

Notification actions are the buttons that appear below a notification's text. When a users taps on an action, depending on how we configure the action, the app can either run code silently in the background or open into the foreground if the user should see something. This makes actions perfect for lightweight interactions like "Mark as done" or "Later", without disrupting the user.

To add custom actions to a notification, we need to:

Define and register custom actions & categories at launch
Request notification permission (alert, sound, badge)
Implement the delegate method to handle the user’s chosen action
Assign category identifiers when scheduling local or sending remote notifications

Let's go through these steps.

Defining and registering categories and actions

Each notification action is represented by UNNotificationAction (or UNTextInputNotificationAction for inline replies). Actions are grouped into categories, represented by UNNotificationCategory.

Here's how we can define and register actions:

class NotificationsService {

    init() {
        registerActions()
    }

    private func registerActions() {
        let doneAction = UNNotificationAction(
            identifier: NotificationAction.done.rawValue,
            title: "Done", options: [])

        let notThirstyAction = UNNotificationAction(
            identifier: NotificationAction.notThirsty.rawValue,
            title: "Not thirsty", options: [])

        let category = UNNotificationCategory(
            identifier: NotificationCategory.drinkingReminder.rawValue,
            actions: [doneAction, notThirstyAction], intentIdentifiers: [], options: .customDismissAction)

        UNUserNotificationCenter.current().setNotificationCategories([category])
    }
}

enum NotificationCategory: String {
    case drinkingReminder
}

enum NotificationAction: String {
    case done
    case notThirsty
}

If we do want the app to open when a button is tapped, we can add the .foreground option when defining the action.

Asking for notification permission

At app level, we create our service and ask the user for notification permission:

@main
struct NotificationActionsApp: App {
    private var notificationsService = NotificationsService()

    var body: some Scene {
        WindowGroup {
            ContentView()
                .onAppear {
                    notificationsService.requestAuthorization()
                }
        }
    }
}

class NotificationsService {
    ...

    func requestAuthorization() {
        UNUserNotificationCenter.current()
            .requestAuthorization(options: [.alert, .sound, .badge]) { granted, _ in
                print("Notifications authorized: \(granted)")
            }
    }
}

Handling responses

When the user taps an action, the system launches our app (in the background if needed) and calls the delegate.

To keep all notification handling centralized, we can register our service to be the delegate:

class NotificationsService: NSObject, UNUserNotificationCenterDelegate {
    override init() {
        super.init()
        registerActions()
        UNUserNotificationCenter.current().delegate = self
    }

    ...

    func userNotificationCenter(
        _ center: UNUserNotificationCenter,
        didReceive response: UNNotificationResponse,
        withCompletionHandler completionHandler: @escaping () -> Void
    ) {
        switch response.actionIdentifier {
        case NotificationAction.done.rawValue:
            print("User tapped Done")
        case NotificationAction.notThirsty.rawValue:
            print("User tapped Not thirsty")
        default:
            break
        }
        completionHandler()
    }
}

Attaching the category to a notification

Now we can use the actions in a notification. To use it on a local notification, we set the categoryIdentifier on UNMutableNotificationContent to tell the system which set of actions to display for that notification:

let content = UNMutableNotificationContent()
content.title = "Stay hydrated"
content.body = "It's time for a glass of water"
content.sound = .default
content.categoryIdentifier = NotificationCategory.drinkingReminder.rawValue

When the notification is delivered, iOS looks up that category and automatically shows the corresponding action buttons.

We can schedule the notification as usual:

let trigger = UNTimeIntervalNotificationTrigger(timeInterval: 5, repeats: false)
let request = UNNotificationRequest(identifier: UUID().uuidString, content: content, trigger: trigger)
try await UNUserNotificationCenter.current().add(request)

To use the category on a remote notification, the server can include the identifier in the payload.

{
  "aps": {
    "alert": {
      "title": "Stay hydrated",
      "body": "It's time for a glass of water"
    },
    "sound": "default",
    "category": "drinkingReminderCategory"
  }
}

Structuring universal links in iOS

Sun, 28 Sep 2025 22:00:00 GMT

Universal links are a powerful way to create experiences between a website and an iOS app. As an app grows and supports more types of universal links, managing them can become complex without proper structure.

In this article, we'll look at a simple architecture that keeps universal link handling clean, testable, and easy to extend. Let's dive in.

Handling a universal link usually means parsing the incoming URL, extracting parameters and routing to the right part of the app. To represent a universal link, we can use an enum which acts as the source of truth for every universal link our app understands:

enum UniversalLink {
    /// Example: https://www.example.com/mobile-app/recipes
    /// Switches to the recipes tab.
    case recipes

    /// Example: https://www.example.com/mobile-app/recipe?id=64ba8b48a92d44eb4e0ef89e
    /// Opens a specific recipe.
    case recipe(id: String)

    /// Example: https://www.example.com/mobile-app/profile?to=settings
    /// Opens a detail view inside the profile tab.
    case profile(ProfileUniversalLinkDestination)
}

enum ProfileUniversalLinkDestination: String {
    case settings
    case favorites
}

This keeps the list of supported links visible in one place, enforces type safety, and makes it clear which parameters belong to which link.

For links with more complex payloads we can go beyond simple strings or enums. For example:

struct RecipeUniversalLinkPayload: Equatable {
    let id: String
    let referrer: String?
}

enum RecipeUniversalLinkPayload {
    case recipe(RecipeUniversalLinkPayload)
}

If we need to support many related links (for example, several different links inside a recipes domain), we can also group them:

enum UniversalLink {
    case recipes(RecipesUniversalLink)
}

enum RecipesUniversalLink {
    case list
    case detail(id: String)
}

Centralize parsing

To centralize all URL parsing logic in one place, we can use a failable or throwing initializer:

extension UniversalLink {
    init?(from url: URL) {
        guard let components = URLComponents(url: url, resolvingAgainstBaseURL: false) else { return nil }
        guard let path = components.path.split(separator: "/").map(String.init).last else { return nil }

        switch path {
        case "recipes":
            self = .recipes
        case "recipe":
            if let id = components.queryItems?.first(where: { $0.name == "id" })?.value {
                self = .recipe(id: id)
            } else {
                return nil
            }
        case "profile":
            ...
        default:
            return nil
        }
    }
}

Instead of just returning nil, we could alternatively throw a concrete error to be able to show or log a specific error description.

Integrating with routing

Once we have a parsed UniversalLink, we need to integrate it with our app's navigation system. If you're using a router-based architecture (as described in this article on using NavigationPath with TabView), the integration becomes straightforward:

.onOpenURL { url in
    if let link = UniversalLink(from: url) {
        switch link {
        case .recipes:
            appRouter.navigateTo(tab: .recipes)

        case .recipe(let id):
            appRouter.navigateTo(tab: .recipes)
            appRouter.recipesRouter.navigateTo(route: .detail(id: id))

        case .profile(let destination):
            appRouter.navigateTo(tab: .profile)
            appRouter.profileRouter.navigateTo(destination)
        }
    }
}

Testing universal links

With this approach, we can ensure quality with unit testing which becomes straightforward. We can test each link type independently:

func testRecipeUniversalLink() {
    let url = URL(string: "https://www.example.com/mobile-app/recipe?id=123")!
    #expect(UniversalLink(from: url) == .recipe(id: "123"))
}

We can write similar tests for each link type to guarantee that URLs are interpreted correctly.

Cancelling async tasks in SwiftUI

Sun, 21 Sep 2025 22:00:00 GMT

Sometimes we want to cancel async work when certain events happen. A typical example is when a user navigates away from a screen while a network request is still loading. If the result is no longer relevant, we might want the request to stop.

SwiftUI helps us here by tying tasks to the lifecycle of views, which means cancellation often happens automatically. In other cases, we may still want explicit control or even prevent SwiftUI from cancelling the task.

Let's look at both.

A common way to start async work in SwiftUI is with the task modifier. It runs as soon as the view appears and is automatically cancelled as soon as the view disappears:

struct ContentView: View {
    @State private var items: [Item] = []

    var body: some View {
        List(items) { item in
            Text(item.title)
        }
        .task {
            items = await loadItems()
        }
    }
}

In this example, if the user leaves the screen before the data arrives, SwiftUI cancels the work and any awaited functions respect that cancellation.

Cancellation does not "unsend" a network request that has already left the device, the server will still process it. But it prevents any further code inside the task from continuing once the cancellation flag is set. For example, if loadItems() checks for cancellation or performs multiple awaits, it stops earlier.

Sometimes, we want to repeat the work whenever a certain input changes. SwiftUI offers a variant of the same modifier for that: task(id:). It runs once when the view appears, and again every time the id value changes. The old task is cancelled automatically before a new one starts.

struct SearchView: View {
    @State private var results: [Result] = []
    @State private var query = ""

    var body: some View {
        VStack {
            TextField("Search", text: $query)
            List(results) { result in
                Text(result.title)
            }
        }
        .task(id: query) {
            results = try await search(for: query)
        }
    }
}

This allows us, for example, to handle search or filtering scenarios. The task is cancelled when the user types the next letter, and a new one starts with the updated query. An important note is that each keystroke still triggers a network request. In a real app we would normally add a debounce or delay to avoid flooding the server.

Because Swift concurrency is structured, cancellation automatically propagates down into all awaited calls. If we are running long-running loops or multiple awaits, it can be useful to explicitly check for cancellation using try Task.checkCancellation() or to handle CancellationError in our error handling. For example:

func loadItems() async throws -> [Item] {
    var all: [Item] = []
    for page in 1...10 {
        try Task.checkCancellation()
        let batch = try await fetchPage(page)
        all.append(contentsOf: batch)
    }
    return all
}

Sometimes we want a task to continue even after the view disappears. For example, when loading data into a shared cache or database that other parts of the app will use.

In that case, we can start a task in a long-lived type, like this:

class DataService {
    func load() {
        Task {
            let data = await api.load()
            await cache.save(data)
        }
    }
}

Because this task isn't tied to a view, SwiftUI will not cancel it when a screen disappears.

If, however, we also want to manually cancel this work (for example, if the user logs out or explicitly cancels a download), we can keep a reference to the task so we can call cancel():

class DataService {
    private var task: Task<Void, Never>?

    func startWork() {
        task = Task {
            await doSomeWork()
        }
    }

    func cancelWork() {
        task?.cancel()
    }
}

This way we can integrate manual cancellation into workflows that go beyond the lifetime of a single view. For even finer control, Swift provides withTaskCancellationHandler which lets us run cleanup code when cancellation happens.

How to manage app lifecycle events in SwiftUI

Sun, 14 Sep 2025 22:00:00 GMT

SwiftUI views don't just react to their own lifecycle, they can also respond to changes in the state of the entire app. An app might move from active to background, or become inactive when interrupted by a phone call. SwiftUI exposes these transitions through the scenePhase environment value.

The scenePhase environment tells us whether the app is currently .active, .inactive, or .background. By observing it with .onChange, we can easily run code in response to these changes.

@Environment(\.scenePhase) private var scenePhase

var body: some View {
    SomeView()
        .onChange(of: scenePhase) { newPhase in
            if newPhase == .active {
                someService.refresh()
            } else if newPhase == .background {
                someService.save()
            }
        }
}

This makes it straightforward to refresh data when the app comes back to the foreground, or to persist state when the app is backgrounded.

Each state has its own meaning:

.active: the app is running in the foreground and fully interactive.
.inactive: the app is still in the foreground but not receiving input. This can happen briefly during interruptions like an incoming phone call or when the user pulls down Control Center.
.background: the app is no longer visible.

In legacy code, you may encounter it being used with UIKit notifications to observe lifecycle changes:

.onReceive(NotificationCenter.default.publisher(for: UIApplication.willEnterForegroundNotification)) { _ in
    viewModel.update()
}

This approach and scenePhase both let us respond when the app comes back to the foreground. The main difference is that onReceive hooks into UIKit's notification system, while scenePhase is SwiftUI’s built-in, declarative alternative.

Understanding SwiftUI's liquid glass button styles

Tue, 02 Sep 2025 22:00:00 GMT

With SwiftUI's liquid glass styles, views and buttons take on a translucent, layered appearance starting in iOS 18. In this article, we'll look at the different ways to apply these effects, what each approach gives us, and where their limitations are.

Let's start with a regular button:

Button("Add", action: addItem)

By default, SwiftUI renders this with the system’s standard button style: a text label with minimal decoration that adapts to context. We can of course apply our own ButtonStyle to fully customize it.

When we instead apply the .glass style, the button is wrapped in a translucent, frosted layer:

Button("Add", action: addItem)
    .buttonStyle(.glass)

The style adds depth and makes the button feel like it is floating above the background. It also comes with system behaviors such as a bounce animation when pressed. With this style, we can use modifiers like .tint to apply an accent color, but other modifiers such as .padding do not change its appearance because the system fully owns the layout.

A button's appearance when using the .buttonStyle(.glass) modifier.

Additionally to .glass, there is also a more prominent variant .glassProminent designed to stand out more strongly for primary actions. Note: At the time of writing, this variant is not available in Xcode 26.0 beta and will not compile yet.

Alongside these button styles, SwiftUI also provides the .glassEffect() modifier. Unlike .glass, this is a more basic and flexible effect that can be applied to any view:

Text("Hello")
    .padding()
    .glassEffect()

This simply gives the view a translucent background. It does not add padding, pressed animations, or toolbar integration. That flexibility makes it useful for creating branded buttons or custom views with a glass look, but the extra styling is up to us.

Good to know is also, when we place buttons inside a SwiftUI Toolbar, SwiftUI may automatically render them with glass styles depending on placement and context:

.toolbar {
    ToolbarItem(placement: .confirmationAction) {
        Button("Save", action: save)
    }
}

In many cases, these buttons are styled as glass by default. This means we sometimes get glass-styled buttons without explicitly asking for them. At the moment there is no supported way to opt out of this behavior, so when we place buttons in toolbar slots such as confirmation or cancellation actions, they will always adopt the system's glass style.

It is worth noting that glass buttons are not a replacement for custom ButtonStyles. If we need branded, app-specific buttons, or dynamic state-driven appearances, custom styles are still the right tool. But when we want to lean on the system look and embrace Apple’s evolving aesthetic, the glass styles are a quick way to get there.

Switching Swift Package Manager dependencies between versioned and local development

Sun, 31 Aug 2025 22:00:00 GMT

When we extract parts of an app into a Swift package to share between projects, we usually consume that package in our iOS projects through Swift Package Manager with a version tag. This setup works well for sharing and reusing code, since each project depends on a clear versioned release. But when we need to make changes in the package itself, creating a new tag for every experiment quickly becomes impractical. For those cases, we can temporarily switch the package dependency in Xcode from a versioned source to a local path.

In Xcode, we normally add the package via a Git URL and a version rule, for example a minimum version like from: 1.2.0. While developing, we can open the project’s Package Dependencies settings, remove the versioned reference, and add the same package again using the Add Local... option. This points the dependency directly to the local folder where the package is checked out.

With this setup, any changes we make in the local package sources are immediately reflected in the app project. This allows us to develop and test the updates without pushing commits or tagging new versions. Once the changes are finalized, we can tag a new release of the package and switch the dependency back to the versioned Git URL in Xcode. This way, the project continues to depend on stable versions while still allowing quick iteration during development.

How to use async/await in synchronous Swift code with tasks

Sun, 24 Aug 2025 22:00:00 GMT

When working with async/await in Swift, we might need to call async/await methods or properties from synchronous contexts. Since those contexts don't allow the await keyword directly, we need a way to bridge the gap. That's where tasks come in.

Let's jump in and look at an example.

Let's say we have an async function that fetches some data:

func fetchData() async -> String {
    ...
}

Now, we want to call it when the user taps on a button inside a SwiftUI view.

struct ContentView: View {
    var body: some View {
        Button("Load Data") {
            await fetchData()
        }
    }
}

With this in place, we get the compiler error async call in a function that does not support concurrency. A button's action is synchronous, so await doesn't work directly. To solve it, we can wrap the call inside a Task:

struct ContentView: View {
    var body: some View {
        Button("Load Data") {
            Task {
                await fetchData()
            }
        }
    }
}

A Task starts running immediately after creation, and it lets us use await inside otherwise synchronous code. We don't need to hold on to it unless we want extra control (like cancellation).

This pattern is useful in many places where async code meets synchronous APIs. For example, in app lifecycle methods such as application(\_:didFinishLaunchingWithOptions:) in AppDelegate, we can use the same Task { ... } approach to call async methods like requesting push notification permissions.

Tasks give us a clean and lightweight way to bridge between Swift's structured concurrency and existing synchronous code.

My new book on architecture & design patterns for iOS

Mon, 18 Aug 2025 22:00:00 GMT

I finally finished my second book 🥳

It's about iOS architecture and design patterns - a topic that has challenged me and shaped the way I think when writing code. Excited (and a bit nervous) to share it.

The book is a practical guide to essential architectural principles and design patterns for iOS development. It covers strategies for building maintainable apps with Swift and SwiftUI, including dependency injection, navigation, common patterns, and modularization.

To learn more about it, check out the books section of this site.

How to create a custom reusable toolbar in SwiftUI

Mon, 11 Aug 2025 22:00:00 GMT

When building navigation bars and toolbars in SwiftUI, we'll often want to keep the same look and functionality across multiple screens. Instead of copying and pasting the same toolbar code everywhere, we can abstract the toolbar into a reusable component.

SwiftUI's ToolbarContent protocol is perfect to do that. In this guide, we'll create a custom reusable toolbar, apply it via a ViewModifier, and add a convenient view extension for a one-line API.

The following example creates a navigation bar with a custom back button and a title:

struct SomeCustomToolBarContent: ToolbarContent {

    let title: String

    @Environment(\.presentationMode) var presentationMode

    var body: some ToolbarContent {
        ToolbarItemGroup(placement: .navigationBarLeading) {
            Button(action: {
                presentationMode.wrappedValue.dismiss()
            }) {
                Image("someCustomBackButtonImage")
            }
        }
        ToolbarItem(placement: .principal) {
            Text(title)
                .font(titleFont)
                .foregroundColor(titleColor)
        }
    }
}

To use it, we can use SwiftUI's toolbar modifier as follows:

someView
    .toolbar {
        SomeCustomToolBarContent(title: "SomeTitle")
    }
    .navigationBarBackButtonHidden(true)
    .navigationBarShadow()

We can go a step further to add even more abstraction by creating a custom view modifier:

struct SomeCustomToolBarModifier: ViewModifier {

    let title: String

    func body(content: Content) -> some View {
        return content
            .toolbar {
                SomeCustomToolBarContent(title: title)
            }
            .navigationBarBackButtonHidden(true)
            .navigationBarShadow()
    }
}

With that in place, we can now apply the toolbar as follows:

someView
    .modifier(SomeCustomToolBarModifier(title: "SomeTitle"))

To make the call above even shorter, we could additionally create a View extension:

extension View {
    func someCustomToolbar(title: String) -> some View {
        return self.modifier(SomeCustomToolBarModifier(title: title))
    }
}

Now, we are able to apply the toolbar with the following call:

someView
    .someCustomToolbar(title: "SomeTitle")

How to use the @available attribute in Swift

Sun, 03 Aug 2025 22:00:00 GMT

In Swift, we have the possibility to add attributes to our code to give the compiler more information. One of those attributes is @available which we can use to make our code only available for certain Swift language versions or platforms.

Let's take a look at how to do that.

Attributes in Swift

In general, an attribute in Swift is always specified with the @ symbol followed by the attribute's name and optionally its arguments enclosed in parentheses. For example:

@objc
class SomeClass: NSObject {}

or with arguments:

@available(iOS 15.0, *)
func doSomething() {}

The @available attribute

The @available attribute lets us define the availability of functions, types, properties, and other declarations across specific platforms or Swift versions. This is especially useful when deprecating APIs, renaming methods, or introducing platform- or version-specific features.

The @available attribute always has two or more arguments, separated by a comma. For example:

@available(*, unavailable, renamed: "updateCategories")
func update() {
}

In the above example, we declare the update method as not available on any platform because it was renamed to updateCategories.

Calling the update method will now fail with a compiler error:

update() has been renamed to updateCategories()

Arguments of @available attribute

Let's look at the arguments of the @available attribute in more detail.

The first argument is always a platform or language name, for example iOS, iOSApplicationExtension, swift. Alternatively, we can use an asterisk * to indicate that the availability applies to all platforms.

The remaining arguments can appear in any order:

unavailable - to indicate that a declaration isn't available on the specified platform
introduced: <version number> - to specify the first version in which a declaration was introduced
deprecated: <version number> - to specify the first version when a declaration was deprecated
obsoleted: <version number> - to specify the first version when a declaration was obsoleted and can no longer be used
message: <message> - to provide a message for the compiler to display when emitting a warning or error
renamed: <new name> - to provide a new name

The <version number> consists of one to three positive integers separated by periods, for example:

@available(iOS, introduced: 17.0)
struct Content {
}

This makes Content available starting from iOS 17.0. It won't be available in earlier versions. If we want to use certain code paths on older versions as well, we can use an if #available check to conditionally execute code based on platform version at runtime:

if #available(iOS 17.0, *) {
    // Content is available here
} else {
    // Fallback to some other code
}

Combination of @available attributes

We can combine multiple availability declarations as follows:

@available(swift, introduced: 5.10)
@available(iOS, introduced: 17.0)
struct Content {
}

This makes Content available only if both Swift version is at least 5.10 and the app is running on iOS 17.0 or later.

Shorthand syntax

In case that only an introduced argument is used, we can simplify using a shorthand syntax:

@available(swift 5.10)
@available(iOS 17.0)
struct Content {
}

This is equivalent to the previous example, just written using the shorthand syntax.

Overview on Accessibility Nutrition Labels for iOS development

Sun, 27 Jul 2025 22:00:00 GMT

At WWDC25, Apple introduced Accessibility Nutrition Labels. These labels appear on the App Store and give users a summary of which accessibility features an app supports.

As developers, we can declare if our app supports specific accessibility features such as VoiceOver, Dynamic Type etc. In this article, we'll go through exisiting Accessibility Nutrition Labels and how to support them.

Let's jump in.

VoiceOver

VoiceOver is a screen reader, which helps users navigate through the app without seeing the screen. For native UI elements, SwiftUI already provides VoiceOver support out of the box. But in many cases, we still need some manual work to improve the Voiceover experience, for example by providing appropriate accessibilityLabels and traits for custom controls, grouping views, and more.

To learn more about supporting Voiceover accessibility, check out this article on supporting VoiceOver in SwiftUI.

Voice Control

Voice Control is an iOS accessibility feature that allows users to control their device and interact with apps entirely by voice. It's especially helpful for users with reduced mobility or dexterity, enabling them to navigate, tap buttons, scroll, and dictate text using only their voice.

When Voice Control is enabled, users can speak commands to interact with UI elements, and the system overlays numbers or names on tappable elements that users can reference in their commands. Most of the work to make an app accessible to Voice Control overlaps with VoiceOver support, ensuring all interactive elements have clear labels and are reachable through accessibility navigation.

Larger Text

On iOS devices, users can increase text size globally in the devices settings to make texts more visible and comfortable to read. We can support this in our app by supporting Dynamic Type and optimize our apps to be readable with large size settings.

To learn more, check out this article on how to support Dynamic Type in SwiftUI.

Dark Interface

Dark Interface support helps users with light sensitivity to reduce discomfort when using an app. If our app isn’t dark by default for all common tasks, we can support this feature by adding Dark Mode support.

To learn more, check out this article on how to support dark mode in SwiftUI.

Differentiate Without Color Alone

Supporting this feature ensures that the app doesn't exclude users who may not be able to perceive all colors. We can communicate states and values through additional visual cues such as text, icons, shapes or patterns.

SwiftUI also lets us respond to the system's Differentiate Without Color setting. To learn more, check out the article on supporting Differentiate Without Color in SwiftUI.

Using the Grayscale Color Filter under Accessibility → Display & Text Size → Color Filters can help reveal places that rely on color alone. It is a useful additional check, but not a simulation of every color vision difference.

Sufficient Contrast

The goal of this feature is to support low-vision users. We can use the Color Contrast Calculator tool which can be opened through Xcodes's Accessibiltiy Inspector and check if our values pass the contrast test.

To learn more, check out this article on supporting sufficient contrast accessibility with Xcode's Color Contrast Calculator.

Reduced Motion

The goal of supporting the Reduced Motion setting is to support users who are sensitive to visual motion. Motion sensitivity can cause discomfort such as nausea, dizziness, or headaches, especially when animations include scaling, spinning, or rapid movement.

Users can enable this setting in the iOS Settings app under Accessibility → Motion → Reduce Motion. SwiftUI provides the accessibilityReduceMotion environment value, which we can use to check whether Reduced Motion is enabled.

To learn more, check out this article on supporting Reduced Motion accessibility setting in SwiftUI.

Captions

Captions provide a text-based alternative to spoken content, supporting users who are deaf or hard of hearing. To support this feature, we can ensure that our video content includes caption tracks, for example by using .srt files or embedding caption metadata directly in the media and reflect users settings.

On iOS, system video players like AVPlayerViewController automatically support captions when available in the media file.

Users can enable system-wide captions in the iOS Settings under Accessibility → Subtitles & Captioning. To check if the user has enabled captions we can use UIAccessibility.isClosedCaptioningEnabled. To respond to changes at runtime, we can observe UIAccessibility.closedCaptioningStatusDidChangeNotification via NotificationCenter. As of iOS 18, there is no SwiftUI environment value for this setting.

Audio Descriptions

Audio descriptions provide spoken narration of visual content for users who are blind or have low vision. These descriptions typically explain important visual information, such as actions, settings, or scene changes.

To support this feature, we can include separate audio tracks with descriptive narration, and ensure our media player allows users to select those tracks if available. Apple's AVPlayer supports audio description tracks out of the box, provided they are embedded in the media asset.

Using defer in Swift to manage state cleanup

Sun, 20 Jul 2025 22:00:00 GMT

When working with async code, we often need to manage UI state before and after an operation. A common example is showing and hiding a loading indicator.

In Swift, we can use the defer statement to ensure that cleanup code runs when the current scope exits, regardless of how we exit, successfully or due to an error.

Let's look at a typical use case.

func fetch() async {
    isLoading = true
    defer { isLoading = false }

    do {
        articles = try await service.fetchArticles()
    } catch {
        self.error = error.localizedDescription
    }
}

In this example, we want to show a loading indicator while fetching data and hide it afterward. The defer block ensures that isLoading = false is always called when the function completes, whether it finishes normally or throws an error.

Without defer, we would achieve the same result in different ways. For example by setting isLoading = false in multiple places:

func fetch() async {
    isLoading = true

    do {
        articles = try await service.fetchArticles()
        isLoading = false
    } catch {
        self.error = error.localizedDescription
        isLoading = false
    }
}

Or by placing it once at the bottom of the function:

func fetch() async {
    isLoading = true

    do {
        articles = try await service.fetchArticles()
    } catch {
        self.error = error.localizedDescription
    }

    isLoading = false
}

Both approaches work, especially in small functions like this. But as a function grows, it's easy to introduce subtle bugs. For example, if we add a new return somewhere, or if the task is cancelled during an await, we could accidentally skip resetting the state.

That's where defer helps. It guarantees that the block will run when the surrounding scope exits, in all of the following cases:

The function runs normally to the end
An error is thrown
There's an early return
The task is cancelled during an await call

By centralizing cleanup logic with defer in one place, we reduce the chance of mistakes and make our code more robust, especially in async or error-prone contexts.

Supporting Reduced Motion accessibility setting in SwiftUI

Sun, 13 Jul 2025 22:00:00 GMT

Let's look at how we can support Reduced Motion in our iOS apps.

Users can enable this setting in the iOS Settings app under Accessibility → Motion → Reduce Motion. If enabled, users may also choose to Prefer Cross-Fade Transitions, which replaces more intense system animations with simple fade transitions, for example, when opening or closing apps.

We can respect this setting by reducing or disabling non-essential animations in our apps, especially those that serve decorative or transitional purposes.

SwiftUI provides the accessibilityReduceMotion environment value, which we can use to check whether Reduced Motion is enabled:

@Environment(\.accessibilityReduceMotion) private var reduceMotion

With this, we can conditionally modify animations based on the user’s preference:

struct AnimatedLogo: View {
    @Environment(\.accessibilityReduceMotion) private var reduceMotion

    var body: some View {
        Image(systemName: "star.fill")
            .rotationEffect(reduceMotion ? .zero : .degrees(360))
            .animation(
                reduceMotion ? nil : .linear(duration: 1).repeatForever(autoreverses: false),
                value: reduceMotion
            )
    }
}

In this example, if Reduce Motion is enabled, the animation is disabled entirely. Otherwise, the image spins continuously.

We could also consider switching to simpler transition styles, like using .opacity instead of .scaleEffect or .offset, to respect the user's preference while maintaining functional transitions.

Note: If we also wanted to check whether Prefer Cross-Fade Transitions is enabled, we can use UIAccessibility.prefersCrossFadeTransitions. There's currently no environment value available for that setting in SwiftUI.

Supporting sufficient contrast accessibility with Xcode's Color Contrast Calculator

Sun, 06 Jul 2025 22:00:00 GMT

Supporting sufficient color contrast helps users with low vision distinguish text, icons, and UI elements more easily. To verify if our color choices meet accessibility guidelines, we can use Xcode’s built-in Color Contrast Calculator.

The Color Contrast Calculator is part of the Accessibility Inspector. It can be opened via the menu bar under Xcode → Open Developer Tool → Accessibility Inspector, then choosing Window → Show Color Contrast Calculator.

Here, we can pick foreground and background colors using the color pickers in the calculator or use the color picker tool to sample from any part of our running app.

Xcode's Color Contrast Calculator

The contrast ratio will update after changing a color and show whether the chosen colors pass the contrast accessibility guidelines.

How to support Dynamic Type accessibility in SwiftUI

Sun, 29 Jun 2025 22:00:00 GMT

Dynamic Type allows users to increase or decrease the size of text in apps based on their reading preferences. This can be configured in the iOS Settings under Accessibility → Display & Text Size → Larger Text.

Supporting Dynamic Type ensures that our app remains readable and accessibible to more users. In this article, we'll look at how to support Dynamic Type in a SwiftUI app.

Let's jump in.

Using system fonts

When we're using SwiftUI's built-in text styles like .body, .headline, or .title, Dynamic Type is automatically supported:

Text("hello")
    .font(.body)

These styles scale according to the user’s preferred content size category and follow the system's typographic hierarchy.

Using custom fonts

We can also use custom fonts with scaling. Here's a simple example:

Text("hello")
    .font(.custom("SomeCustomFont", size: 24))

As of iOS 14 and later, this version will also scale automatically with the system's text size setting.

When using custom fonts, we can specify a relative text style:

Text("hello")
    .font(.custom("SomeCustomFont", size: 24, relativeTo: .title))

Without the relativeTo parameter, it defaults to .body. Setting it gives us more control over how strongly the font reacts to the user's text size setting, for example a .title will grow more aggressively than .body.

Adapting layout with @ScaledMetric

Supporting Dynamic Type isn't just about text - it may affect other layout settings like spacing, padding etc. To adapt layout values like padding or spacing, we can use the @ScaledMetric property wrapper:

@ScaledMetric(relativeTo: .body) var padding: CGFloat = 10

Text("Hello")
    .padding(scaledPadding)

This value will scale just like .body would, which helps maintain proportional spacing and a visually balanced layout as text grows.

Opting out of scaling

In rare cases, we might want a text element to stay at a fixed size regardless of the user's text size setting. For example, in tight UI elements where scaling might cause layout issues. In these cases, we can use fixedSize:

Text("Hello")
    .font(.custom("SomeCustomFont", fixedSize: 20))

However, fixed-size text may become unreadable for some users and should only be used where truly necessary.

Scaling the font is only one part of supporting larger text. When growing content no longer fits its original structure, we can also adapt the SwiftUI layout for accessibility text sizes.

Using WebKit with SwiftUI to manage web content

Sun, 22 Jun 2025 22:00:00 GMT

Starting with iOS 17, WebKit provides new tools to integrate web content directly within SwiftUI. Two key types introduced are WebView and WebPage, both of which enable us to display and interact with web content within SwiftUI views.

In this article, we’ll cover the basics of these types, highlighting when to use each. Additionally, we'll look at how to support iOS versions prior to iOS 17.

Let's jump in.

Using WebView

The WebView type combined with the URL parameter is the most direct way to display web content in a SwiftUI app. The WebView handles the job of loading and displaying a web page.

For example:

struct ContentView: View {

    var body: some View {
        WebView(url: url)
    }
}

It's great for static content or when we don't need to interact with the page.

Working with WebPage

For more control over web content, we can use WebPage to load and control the web content and interact with it programmatically. WebPage is particularly useful when we need to react to events like navigation changes, run JavaScript on the page, or track the state of the page.

Here is an example setup:

struct ContentView: View {
    @State private var page = WebPage()

    var body: some View {
        WebView(page)
    }
}

We can now interact with the page and the web view will update accordingly if changes occur.

For example, we can load web content with a URLRequest:

page.load(urlRequest)

Or we can load HTML content directly:

page.load(html: htmlString, baseURL: baseUrl)

Or to load data:

page.load(webArchiveData, mimeType: "application/x-webarchive", characterEncoding: .utf8, baseURL: baseURL)

Additionally, we can use WebPage's currentNavigationEvent property to track the navigation state of a page such as when a page starts loading, redirects, when it's done, or if it encounters an error.

It also allows us to run JavaScript functions within the web page by using the callJavaScript API. This can be useful for tasks like extracting information from the page or modifying the content dynamically.

Supporting versions prior to iOS 17

Since WebKit's native SwiftUI integration with WebView and WebPage is available only starting with iOS 17, we can use WKWebView and bridge it with SwiftUI using UIViewRepresentable for earlier versions.

import SwiftUI
import WebKit

struct WebView: UIViewRepresentable {
    var url: URL

    func makeUIView(context: Context) -> WKWebView {
        let webView = WKWebView()
        return webView
    }

    func updateUIView(_ uiView: WKWebView, context: Context) {
        let request = URLRequest(url: url)
        uiView.load(request)
    }
}

In this example, we create a WebView struct that conforms to UIViewRepresentable. This allows us to integrate WKWebView into a SwiftUI view hierarchy.

struct ContentView: View {
    var body: some View {
        WebView(url: url)
    }
}

When supporting both, you can use conditional checks to apply the correct implementation based on the iOS version.

WWDC 2025 summary of Apple's platforms state of the union talk for iOS developers

Wed, 11 Jun 2025 22:00:00 GMT

This article summarizes the key announcements for iOS developers from Apple's Platforms State of the Union talk at WWDC 2025.

Let's jump in.

Liquid Glass Design

Apple introduced Liquid Glass, a new design element with the goal to enhance the depth and fluidity of UI components in iOS, iPadOS, and macOS. It is applied to many native UI components such as buttons, navigation bars, and toolbars.

When we recompile our apps with Xcode 26, most system components will automatically adopt the Liquid Glass design. UI elements such as TabView, NavigationSplitView, and toolbars will update without requiring any changes on our part.

A new API for handling toolbars, navigation bars, and custom controls allows for more precise control over how these elements appear and behave. For example, custom controls can now be embedded in a glassEffect modifier to apply the new dynamic effects that Liquid Glass introduces.

Apple also provides a way to opt-out or disable the effect on a per-view basis until we fully adapt to the new material.

App Icons & Icon Composer

Along with Liquid Glass, Apple introduced new icon designs, with support for two new modes: clear mode and tint mode. Clear mode allows the icon to fully showcase the Liquid Glass material, while tint mode offers a more colorful look, with different light and dark variants.

To streamline the creation of these new icons, Apple introduced Icon Composer. This tool helps us create multi-layered app icons, optimize transparency, and preview the final icon in different states before using it in our apps.

Apple Intelligence API

Apple expanded its Apple Intelligence capabilities with the introduction of the Foundation Models framework. This framework gives us access to on-device machine learning models for tasks such as text extraction, summarization, and dynamic content generation.

One key feature within this framework is Guided Generation, which enables us to generate structured data types based on user input. This is particularly useful for creating apps with dynamic, data-driven content that adapts to user preferences or inputs.

By using these on-device models, we can offer AI-powered features in our apps without requiring an internet connection, ensuring both speed and privacy for the end user.

Xcode 26

Xcode 26 introduces several useful features. One of them the integration of ChatGPT directly within the IDE, allowing for code completion and natural language interaction directly within Xcode.

Swift 6.2

Swift 6.2 introduces updates aimed at improving performance and memory management.

Inline arrays: Swift now supports inline arrays, allowing us to store small arrays on the stack instead of the heap. This reduces memory overhead and improves performance, particularly in performance-critical parts of our apps.
Span type: A new memory-safe span type is introduced, making it easier to work with contiguous blocks of memory. This provides an alternative to using raw pointers, improving safety when interacting with low-level data or C libraries.
Concurrency improvements: Swift now includes a new concurrent attribute that allows us to offload tasks to background threads more easily

SwiftUI updates

SwiftUI continues to evolve with several updates aimed at improving app performance and expanding capabilities.

Web content support: With the new WebView component, we can now integrate web content directly into SwiftUI apps. Using WebPage, we can observe and control web content from within our app.
Rich text editing: We can now use AttributedString when working with TextEditor. This is useful for apps that require text formatting while editing, such as note-taking or messaging apps.
Performance improvements: SwiftUI has introduced idle prefetching to improve the performance of lists and tables. By preloading data during idle times, this feature reduces latency and makes scrolling through large datasets feel smoother and more responsive.

VisionOS updates

Apple continues to develop visionOS, the operating system for spatial computing. There are new updates for creating 3D and AR experiences. One of the main updates is support for shared spatial experiences, where multiple users can interact with the same virtual objects in a shared physical space.

Adding navigation buttons to the keyboard in SwiftUI

Sat, 07 Jun 2025 22:00:00 GMT

When building forms with multiple textfields in SwiftUI, it can improve user experience by adding navigation buttons above the keyboard to allow users to navigate between these textfields more easily. Let's look at how we can implement this.

Setting up the basic text fields

To be able to control which textfield is currently focused, we can use the @FocusState property:

struct FormView: View {
    @FocusState private var focusedField: Field?

    enum Field: Hashable {
        case name, address, mail, phone ...
    }

    var body: some View {
        VStack {
            TextField("textfield.name".localized, text: $name)
                .focused($focusedField, equals: .name)

            // more textfields

            Spacer()
        }
    }
}

The @FocusState property is used to bind the focus of each text field to a corresponding case in the Field enum. This allows us to shift the focus programmatically.

Adding navigation buttons to the toolbar

Next, we can add the navigation buttons above the keyboard using the toolbar() modifier:

var body: some View {
    VStack {
        // TextField setup...

        Spacer()
    }
    .toolbar {
        ToolbarItemGroup(placement: .keyboard) {
            Button(action: moveToPreviousField) {
                Image(systemName: "chevron.up.circle.fill")
            }
            .padding(.leading)

            Button(action: moveToNextField) {
                Image(systemName: "chevron.down.circle.fill")
            }
            .padding(.trailing)
        }
    }
}

These buttons are placed in the .keyboard toolbar, which is displayed above the keyboard when a text field is active. By default, the buttons are placed on opposite sides of the toolbar. To move them together or to one side, we can wrap them in an HStack combined with a Spacer.

Handling the focus transitions

Now, we can add the logic for moving between fields:

private let fields: [Field] = [.name, .address, .mail, phone]

private func moveToPreviousField() {
    if let currentIndex = focusedField.flatMap({ fields.firstIndex(of: $0) }) {
        let previousIndex = (currentIndex - 1 + fields.count) % fields.count
        focusedField = fields[previousIndex]
    }
}

private func moveToNextField() {
    if let currentIndex = focusedField.flatMap({ fields.firstIndex(of: $0) }) {
        let nextIndex = (currentIndex + 1) % fields.count
        focusedField = fields[nextIndex]
    }
}

This approach will automatically scale when more textfields are added in the future. The modulo operation (%) is a way to ensure that the index stays within the bounds of the array, even when navigating past the first or last element.

Understanding toolbars in SwiftUI

Sun, 01 Jun 2025 22:00:00 GMT

SwiftUI's toolbar() modifier allows us to add items to various toolbars, such as the navigation bar, bottom bar, and even above the keyboard or in modal views. Depending on the configuration of the ToolbarItem and the platform, the system places the items accordingly.

In this article, we'll explore how to use the toolbar() modifier in SwiftUI and how to place toolbar items in different parts of our app's UI. Let's jump in.

Toolbar items in the bottom bar

The .bottomBar placement is commonly used for actions that need to be available at the bottom of the screen, such as navigation controls, context actions, or any items that should be easily accessible when the user is at the bottom of the interface.

Here's an example of how to add toolbar items to the bottom bar:

var body: some View {
    NavigationStack {
        Text("Hello, world!")
            .toolbar {
                ToolbarItem(placement: .bottomBar) {
                    Button("action1", action: {})
                }
                ToolbarItem(placement: .bottomBar) {
                    Button("action2", action: {})
                }
            }
    }
}

The above example results in the following:

Toolbar items in bottom bar.

If only one toolbar item is added, it will automatically be centered.

Toolbar items in the navigation bar

`.principal` placement

The .principal placement allows us to place a toolbar item in the center of the navigation bar, often used for search fields or custom titles.

var body: some View {
    NavigationStack {
        contentView
        .navigationBarTitleDisplayMode(.inline)
        .toolbar {
            ToolbarItem(placement: .principal) {
                SearchView(text: $viewModel.searchText)
            }
        }
    }
}

This places a search view in the center of the navigation bar, replacing the title.

Toolbar item with a .principal placement.

`.navigationBarTrailing` and `navigationBarLeading` placement

The .navigationBarTrailing and .navigationBarLeading placements place the toolbar items in the trailing or leading edge of the navigation bar.

They replace the deprecated .navigationBarItems() modifier which was used before for the same purpose.

var body: some View {
    NavigationStack {
        contentView
        .navigationTitle("Title")
        .navigationBarTitleDisplayMode(.inline)
        .toolbar {
            ToolbarItem(placement: .navigationBarTrailing) {
                SortButton()
            }
            ToolbarItem(placement: .navigationBarTrailing) {
                FilterButton()
            }
        }
    }
}

Resulting in:

Toolbar items with a .navigationBarTrailing placement.

Changing the placement to .navigationBarLeading places the item in the leading edge of the navigation bar.

Toolbar item with a .navigationBarLeading placement.

When placing multiple toolbar items with the same placement, we can use a ToolbarItemGroup to avoid repetition.

.toolbar {
    ToolbarItemGroup(placement: .navigationBarTrailing) {
        SortButton()
        FilterButton()
    }
}

Toolbar items above keyboard

Another toolbar item placement possibility is .keyboard which places items above the keyboard when presented. This is especially useful for adding "Previous" and "Next" buttons when interacting with text fields.

Toolbar items above keyboard.

Toolbar items in modal views

Further placement options are .confirmationAction, .destructiveAction and .cancellationAction that we can use in toolbars presented by a modal view, for example when using the sheet() modifier.

var body: some View {
    NavigationStack {
        Text("Sheet")
        .toolbar {
            ToolbarItem(placement: .confirmationAction) {
                Button("Confirm", action: {})
            }
            ToolbarItem(placement: .destructiveAction) {
                Button("Delete", action: {})
            }
            ToolbarItem(placement: .cancellationAction) {
                Button("Cancel", action: {})
            }
        }
    }
}

Resulting in:

Toolbar items in modal view.

Learn to build adaptive layouts with SwiftUI's ViewThatFits container.

Sun, 25 May 2025 22:00:00 GMT

SwiftUI's ViewThatFits container helps us build adaptive layouts by allowing us to provide multiple views while automatically picking the first one which fits into available space.

Let's directly jump into an example to see how the container works.

Consider a scenario where you need to display a list of messages. If a message fits within a single line, we just display it fully. If it doesn't fit, we want to show a truncated version and a "more" button to open the full message. Something like this:

As we can see above, the first message fits into the available space, so we don't need the button. The second line only shows a part of the message with a button to show the full message.

To achieve this result, the ViewThatFits comes in handy. We just need to provide two different views, one that only contains the text and one that contains the text and the button. The ViewThatFits container will automatically pick the right one for us.

var body: some View {
    VStack(alignment: .leading, spacing: 10) {
        ForEach(messages, id: \.self) { message in
            HStack() {
                Image(systemName: "info.circle.fill")
                ViewThatFits {
                    Text(message)
                        .fixedSize()
                    HStack {
                        Text(message)
                            .lineLimit(1)
                        Button("more") {
                            // Present full message
                        }
                    }
                }
            }
        }
    }
}

In this example:

The first view is a Text view with the .fixedSize() modifier, ensuring the text is not truncated.
The second view is an HStack containing a truncated Text view and a "more" Button.

ViewThatFits evaluates these views in order and selects the first one that fits within the available space. If the first view doesn't fit, it proceeds to the next one. This approach allows for dynamic and responsive layouts.

ViewThatFits determines which view to display based on the "ideal size" of each child view. The ideal size refers to the size a view would occupy if it had unlimited space. By default, ViewThatFits considers both horizontal and vertical axes when evaluating the ideal size. However, we can specify which axis to consider by using the in: parameter. In our case, we are looking for a horizontal evaluation:

ViewThatFits(in: .horizontal) {
    Text(message)
        .fixedSize()
    HStack {
        Text(message)
            .lineLimit(1)
        Button("more") {
            // Present full message
        }
    }
}

In this case, ViewThatFits will only consider the horizontal axis when determining which view to display.

Understanding LLDB print commands for iOS debugging with Xcode

Sun, 18 May 2025 22:00:00 GMT

LLDB is a powerful tool for exploring and debugging iOS applications at runtime.

When we set a breakpoint in our code, Xcode pauses the app and gives us a few ways to inspect the current state. We can either use the variable viewer in Xcode's sidebar or enter LLDB commands directly in the console.

To inspect variables through LLDB, we typically use three print commands:

v for direct memory inspection
p for evaluated expressions
po for object descriptions

Let's walk through how each one works and when to use them.

LLDB command v

The v command is an alias for frame variable. It reads what's currently in memory and prints an LLDB-formatted summary of the value. Xcode uses this command behind the scenes for its variable viewer.

(lldb) v bird

(ExampleApp.Bird) bird = {
  name = "kea"
  conservationStatus = en
}

This command is fast and safe because it doesn't compile or evaluate any expressions. It only works with stored properties - computed properties or function calls will result in an error:

(lldb) v bird.conservationStatus.title

error: "title" is not a member of "(ExampleApp.ConservationStatus) bird.conservationStatus"

LLDB command p

The p command is an alias for expression. Unlike v, it compiles and executes code on the spot, which means we can evaluate expressions, access computed properties, and call functions.

(lldb) p bird

(ExampleApp.Bird) $R2 = {
  name = "kea"
  conservationStatus = en
}

For a computed variable:

(lldb) p bird.conservationStatus.title
(String) $R3 = "endangered"

LLDB command po

The po command is also an evaluated expression, but it prints a human-readable description of the object instead of the LLDB-formatted structure. Internally, it calls expression --object-description.

If the object conforms to CustomDebugStringConvertible, po uses the custom debug description we provide.

extension Bird: CustomDebugStringConvertible {
    var debugDescription: String {
        return "The bird \(name) is \(conservationStatus.title)"
    }
}

Which results in the following:

(lldb) po bird

▿ The bird kea is endangered
  - name : "kea"
  - conservationStatus : ExampleApp.ConservationStatus.en

If no custom description is provided, po falls back to the system’s default.

Conclusion

In most cases, using p or po gives us the most flexibility. They evaluate expressions and work with computed properties and methods. However, they do add a bit of runtime overhead since they compile and execute code.

If we're dealing with timing-sensitive code, such as multithreading bugs or race conditions, it may be better to use the v command. It doesn't disturb the execution environment as much because it doesn't evaluate code, just reads memory.

For these situations, we can even set breakpoints that don't pause the app. In Xcode's breakpoint editor, we can enable the option to Automatically continue after evaluating actions and log the output with v, so we can debug without affecting the timing.

Scheduling notifications with time, calendar, and location triggers in iOS

Sun, 11 May 2025 22:00:00 GMT

The UserNotifications framework provides several flexible ways to schedule local notifications, depending on when and how we want them to be delivered.

In this guide, we'll walk through the three main types of triggers available for local notifications:

Time interval triggers – fire after a set number of seconds
Calendar triggers – fire at a specific date and time
Location triggers – fire when the user enters or exits a geographic region

Let's jump in.

Time interval trigger

A time interval trigger is the simplest option. It fires after a fixed amount of time has passed, making it perfect for short-term reminders or countdowns. For example, to trigger a notification 10 minutes from now, we would use:

import UserNotifications

let trigger = UNTimeIntervalNotificationTrigger(timeInterval: 10 * 60, repeats: false)

Calendar trigger

A calendar trigger allows us to schedule notifications based on specific dates and times or repeating intervals. This is ideal for recurring reminders, like daily health checks or weekly meeting reminders. For example, we can trigger a notification every morning at 7:30 with the following code:

var dateComponents = DateComponents()
dateComponents.hour = 7
dateComponents.minute = 30
let trigger = UNCalendarNotificationTrigger(dateMatching: dateComponents, repeats: true)

This trigger provides a lot of flexibility, as we can match on any combination of date components, like weekday, month, or year, to precisely control when notifications are delivered.

Location trigger

A location trigger is a more context-aware option that fires when a user enters or exits a specified geographic region. For example, we can trigger a notification when a user exits a 20 km radius around Leipzig's city center:

import CoreLocation

let center = CLLocationCoordinate2D(latitude: 51.3396955, longitude: 12.3730747)
let region = CLCircularRegion(center: center, radius: 20 * 1000, identifier: "leipzig")
region.notifyOnEntry = false
region.notifyOnExit = true

let trigger = UNLocationNotificationTrigger(region: region, repeats: false)

With the notifyOnEntry and notifyOnExit properties, we can control whether the app should deliver notifications when the user enters, exits, or both. Keep in mind that location triggers require location permissions and can be affected by power-saving modes.

Working with Xcode configuration files

Sun, 04 May 2025 22:00:00 GMT

In this article on creating and managing multiple app environments in Xcode, we learned, how to set up environments such as debug, staging, and release when developing an iOS app.

In this article, we'll explore an approach by using Xcode configuration files (.xcconfig) to define environment-specific values.

Let's dive in.

Creating configuration files

The first step is to create a .xcconfig file for each build configuration by selecting File → New → File and using the Configuration Settings File template.

For example, we could create:

Debug.xcconfig
Staging.xcconfig
Release.xcconfig

By default, each file starts empty.

Connecting configuration files to build configurations

We can activate the configuration files in the Info tab of our project:

Connecting configuration files.

Here, we can select the corresponding .xcconfig file for each configuration.

Adding values to configuration files

Now, we can define values such as feature flags or app display names. For example:

Debug.xcconfig

APP_DISPLAY_NAME = ExampleApp Debug
FEATURE_X_ENABLED = YES

Staging.xcconfig

APP_DISPLAY_NAME = ExampleApp Staging
FEATURE_X_ENABLED = YES

Release.xcconfig

APP_DISPLAY_NAME = ExampleApp
FEATURE_X_ENABLED = NO

💡 Note: Don't use quotation marks for strings, even if they contain spaces. Values like YES and NO are treated as strings. Also, Xcode may interpret // in http:// as a comment—use https:/$()/dev.api.com as a workaround.

Accessing configuration values in code

To read these values in code, we first reference them in our Info.plist:

<key>FEATURE_X_ENABLED</key>
<string>$(FEATURE_X_ENABLED)</string>

Then access them in Swift:

Bundle.main.object(forInfoDictionaryKey: "FEATURE_X_ENABLED")

Creating and managing multiple app environments in Xcode

Sat, 03 May 2025 22:00:00 GMT

After getting on overview on Xcode's build configuration concepts, we can take the next step: adding and managing multiple environments like debug, staging, and release.

Let's walk through the process step by step.

Adding a new build configuration

Xcode already provides Debug and Release configurations by default. To add a custom one (like Staging), we open the project editor, go to the Info tab, and click the + button in the Configurations section.

We can duplicate the Debug configuration and name the new one Staging.

Adding a new configuration.

Creating schemes for each environment

To easily run and test each configuration, we can create separate schemes by opening Manage Schemes from the scheme dropdown and duplicate the default scheme for each environment we want to support (e.g. Staging, Release).

Managing schemes in Xcode.

💡 It's usually best to duplicate the existing scheme. This copies over all relevant settings (like build, test, and archive actions), so we only need to change the build configuration. Creating a scheme from scratch is also possible, but it requires manual setup and is better suited for workflows which are structurally different.

Duplicating a scheme in Xcode.

After duplicating, we rename the schemes accordingly and edit each one to use the matching build configuration for Build, Run, Test, and so on.

Editing a scheme.

Customizing build settings per configuration

Now that our configurations are in place, we can assign different values for each. This is useful for:

App bundle identifiers
App icons
Display names
Version suffixes

For example, we can adjust the bundle identifier for each configuration by searching for it in the build settings tab:

Customizing build settings for each configuration.

Adding user-defined build settings

For environment-specific variables such as API URLs or feature flags, we can either configure them in build settings or create a wrapper type to check the current environment in code and return custom values based on that. For example:

struct BuildConfiguration {
    enum Environment: String {
        case debug = "Debug"
        case staging = "Staging"
        case release = "Release"
    }

    let environment: Environment

    init() {
        let rawValue = Bundle.main.object(forInfoDictionaryKey: "Environment") as? String ?? "Debug"
        environment = Environment(rawValue: rawValue) ?? .debug
    }
}

Alternatively, we can use Xcode configuration files (xcconfig) to manage large sets of build settings in one central file.

➡️ Continue reading: Working with Xcode configuration files.

Understanding Xcode targets, schemes and build configurations

Fri, 02 May 2025 22:00:00 GMT

When we develop an iOS application, we usually need to support multiple environments like debug, staging, and release. The first step in that process is understanding how Xcode organizes our project into targets, schemes, and configurations.

Let's walk through these concepts together.

When we create a new Xcode project, it automatically includes:

An app target
Two test targets
A default scheme
Two build configurations: Debug and Release

Configuration of a new Xcode project

This gives us a strong starting point, but to add more environments and customize behavior, we first need to understand the roles of each component.

What is a target?

Xcode projects contain targets, which specify how a product is built. Each target has its own build settings and phases. Targets can override settings defined at the project level.

Think of a target as a blueprint for building something specific in an app project. For example, we might have one target for the main iOS app, and another for a Share Extension or a Watch app. Each target defines how that specific product is built, including source files, resources, and its own build settings.

What is a scheme?

An Xcode scheme defines how Xcode builds, runs, tests, archives, and profiles our app. It also controls which build configuration is used for each action.

We can think of a scheme like a shortcut. It tells Xcode what to build and how to run it for different actions. For example, we can create a scheme called ExampleApp Staging that runs the app using a staging backend and another scheme called ExampleApp Release for the production environment.

Each scheme is linked to a target and lets us assign which build configuration it should use when running or testing.

What is a build configuration?

A build configuration tells Xcode how to build a target. Each one has its own set of build settings.

By default, Xcode gives us two:

Debug: fast builds, debug info included
Release: optimized builds, no debug info

We can add more, like Staging, to test production-like environments.

What's next?

By combining targets with schemes and build configurations, we can fully control our build pipeline for each environment.

➡️ Continue reading: Creating and managing multiple app environments in Xcode.

Bridging interfaces with the Adapter pattern in Swift

Sun, 27 Apr 2025 22:00:00 GMT

Sometimes, we adopt libraries or frameworks that don't match our app's internal abstractions. Or, as our architecture evolves, existing components no longer fit with newer code cleanly. Instead of rewriting working code, we can adapt it with the Adapter pattern.

Let's look at how to do it with a practical example.

Let's say our app expects a SearchService protocol that defines how search functionality should work across different parts of the app:

protocol SearchService {
    func search(query: String) async throws -> [SearchResult]
}

But we're integrating a third-party SDK with the following interface:

class ThirdPartySearch {
    func runSearch(term: String, completion: @escaping ([Any]) -> Void) {
        // ...
    }
}

The SDK's API uses different method names, a completion handler instead of async/await, and returns untyped results.

Here's how we can bridge that gap:

class ThirdPartySearchAdapter: SearchService {
    private let thirdPartySearch = ThirdPartySearch()

    func search(query: String) async throws -> [SearchResult] {
        try await withCheckedThrowingContinuation { continuation in
            thirdPartySearch.runSearch(term: query) { rawResults in
                let results = rawResults.compactMap { $0 as? SearchResult }
                continuation.resume(returning: results)
            }
        }
    }
}

Now, we can use ThirdPartySearchAdapter anywhere a SearchService is expected.

The Adapter pattern helps us preserve encapsulation and maintain clean separation between domains, making our code more resilient to change.

How to persist navigation state in SwiftUI

Sun, 20 Apr 2025 22:00:00 GMT

When building multi-screen apps in SwiftUI, preserving where a user left off can improve the user experience. One of the key advantages of SwiftUI's NavigationPath is that it's serializable. As long as all data types in the path conform to Codable, we can save and restore the navigation state.

This allows us to persist the navigation stack across app launches or even sync state between devices.

Let's look at how to do that.

Making our routes codable

To persist a NavigationPath, every element that goes into it must conform to both Hashable and Codable. If, for example, we used a router based approach to work with NavigationPath, it can look as follows:

enum Route: Hashable, Codable {
    case search
    case detail(id: String)
}

Encoding and storing navigation state

Once the route type is Codable, we can encode the navigation path and store it using a persistence mechanism such as UserDefaults or the file system.

For example:

// Encode navigation path
if let encodedPath = try? JSONEncoder().encode(navigationPath) {
    UserDefaults.standard.set(encodedPath, forKey: "savedNavigation")
}

For larger or sensitive data, we could use the file system or Keychain instead.

Restoring the navigation stack

To restore navigation, we can retrieve the encoded path and decode it back into a NavigationPath:

if let data = UserDefaults.standard.data(forKey: "savedNavigation"),
   let decodedPath = try? JSONDecoder().decode(NavigationPath.self, from: data) {
    navigationPath = decodedPath
}

We can perform this restoration early in the app lifecycle, for example when initializing a router.

Limitations to keep in mind

While persisting navigation state can be powerful, there are a few important things to consider. First, only types that conform to Codable can be stored in a NavigationPath.

Second, our route definitions must remain stable over time. If we modify the structure of a route, for example by adding or removing enum cases, previously saved navigation data may no longer decode properly.

Finally, we should be mindful of what data we include in our routes. Associated values should be lightweight and safe to persist, especially if using mechanisms like UserDefaults for persistence.

Using NavigationPath with TabView in SwiftUI

Sun, 13 Apr 2025 22:00:00 GMT

When building complex iOS applications, we often need to combine tab-based navigation with stack-based navigation. In SwiftUI, this means integrating TabView with NavigationStack. A common challenge in this scenario is managing navigation state properly across multiple tabs while maintaining independent navigation flows.

Let's look at one possible solution. We'll create a central app router to coordinate navigation and give each tab its own router and NavigationPath. This way, we will gain full control of the navigation, allowing for clean separation of concerns, deep linking support, and a more modular design.

Designing the app router

We'll start by creating an app-wide router, which allows us to switch between tabs and go to any place in our iOS application.

Here is an example implementation:

@Observable
class AppRouter {
    var searchRouter = SearchRouter()
    var settingsRouter = SettingsRouter()
    var selectedTab = Tab.search.rawValue

    func navigateTo(tab: Tab) {
        selectedTab = tab.rawValue
    }
}

enum Tab: Int {
    case search = 0
    case settings = 1
}

The AppRouter is responsible for holding the currently selected tab and routers for each tab's navigation flow.

Creating per-tab routers

Since each tab needs it's own navigation stack, we create a separate router for each tab. A tab router owns a NavigationPath and defines the types of views (routes) that can be pushed onto the navigation stack.

For example:

@Observable
class SearchRouter {
    var navigationPath = NavigationPath()

    enum Route: Hashable {
        case detail(itemId: String)
    }

    func navigateTo(route: Route) {
        navigationPath.append(route)
    }
}

In the example above, we defined the router for a search flow, where a user can navigate to a detail view after searching for an item.

Putting it together with TabView and NavigationStack

With the AppRouter and individual tab routers in place, we can wire everything together inside our root view:

struct RootTabView: View {
    @State private var appRouter = AppRouter()

    var body: some View {
        TabView(selection: $appRouter.selectedTab) {
            SearchRootView(router: appRouter.searchRouter)
                .tabItem { Label("Search", systemImage: "magnifyingglass") }
                .tag(Tab.search.rawValue)

            SettingsRootView(router: appRouter.settingsRouter)
                .tabItem { Label("Settings", systemImage: "gearshape") }
                .tag(Tab.settings.rawValue)
        }
    }
}

Each tab's root view receives its associated router.

Navigating within a tab

Here's what the root view for the search tab could look like:

struct SearchRootView: View {
    @Bindable var router: SearchRouter

    var body: some View {
        NavigationStack(path: $router.navigationPath) {
            SearchView()
                .navigationDestination(for: SearchRouter.Route.self) { route in
                    switch route {
                    case .detail(let itemId):
                        DetailView(itemId: itemId)
                    }
                }
        }
    }
}

By binding NavigationStack to the router.navigationPath, we give the search tab its own independent navigation history.

Navigating to specific views

With the setup shown above, we have now full control of the navigation in our app. For example, we can use it to handle universal links as follows:

.onOpenURL { url in
    if let universalLink = UniversalLink(from: url) {
        switch universalLink {
        case .detail(let itemId):
            appRouter.navigateTo(tab: Tab.search)
            appRouter.searchRouter.navigateTo(route: .detail(itemId: itemId))
        // Handle other cases.
        }
    }
}

This logic switches to the correct tab and then updates that tab's navigation path to push the appropriate view.

Wrapping up

Using NavigationPath with TabView in SwiftUI is a powerful way to manage complex navigation scenarios. By assigning each tab its own NavigationPath, we avoid the pitfalls of shared navigation state and gain the ability to support deep linking, preserve user context, and scale navigation logic cleanly.

Testing remote iOS push notifications in a simulator with simctl

Sat, 05 Apr 2025 22:00:00 GMT

Testing remote push notifications in iOS has traditionally been challenging. Developers often lack access to the production server responsible for sending notifications, and since remote notifications are not natively supported in the iOS simulator, a physical device is usually required to receive a valid push notification token.

However, Apple provides a command-line tool called simctl that allows developers to simulate push notifications directly in the simulator, making testing much easier.

Let's look at how to do that.

Creating and storing an .apn file

The first step to simulate a push notification in a simulator is creating and storing an .apn file. The file contains the JSON notification payload that the app would normally receive from a server.

Here's an example test.apn file:

{
  "aps": {
    "alert": "Hello world",
    "sound": "default",
  }
  "categoryId": "1234"
}

The above example includes an alert message and a sound notification.

Simulating a push notification with simctl

simctl is a command-line tool that allows control of the iOS simulator. With Xcode installed, simctl is accessible through the xcrun command.

The easiest way to send a simulated notification is by following these steps:

Run the app that supports and handles push notifications in a simulator.
Open the terminal.
Navigate to the directory containing the test.apn file.
Run the following command:

xcrun simctl push booted <bundle-identifier> test.apn

Replace <bundle-identifier> with your app's bundle identifier (e.g., com.example.MyApp).

After executing the command, you should see the push notification appear in the simulator, just as it would on a physical device.

Advanced usage

We can target specific simulators rather than just the booted one. First, list available simulators:

xcrun simctl list devices

Then, we can use the device UUID instead of "booted":

xcrun simctl push <device-uuid> <bundle-identifier> test.apn

Testing different notification scenarios

Once the setup is working, we can test various scenarios by modifying the test.apn file, for example:

Deep linking: By adding a url key to test how the iOS app handles notification-based deep links.
Action buttons: By adding an action key to test interactive notifications.
Custom data: By including additional payload data to test how the iOS app processes it.

For a full list of notification payload options, check out Apple’s official payload key reference.

Building a dependency injection framework

Mon, 31 Mar 2025 22:00:00 GMT

Dependency injection (DI) is a powerful design pattern that helps us create more modular, testable, and maintainable code. There are many excellent third-party DI frameworks available for Swift. While these tools save us from a lot of manual work, they also abstract away many of the challenges involved in dependency injection.

Understanding how these frameworks work under the hood can give us deeper insight into the design patterns and principles behind them. In this article, we will build our own lightweight DI container to gain a deeper understanding on how DI containers work by solving common dependency management problems such registering and resolving dependencies dynamically, handling object lifecycle, creating a property wrapper for easy-to-use resolution and more.

Let's jump in.

Designing our DI container

Our minimal DI container should be able to:

Register dependencies so that they can be resolved later.
Resolve dependencies dynamically, ensuring that instances are created when needed.
Manage lifecycles, whether they should be created anew each time or persist as singletons.
Inject dependencies easily by using a property wrapper for automatic resolution.

Our framework will have two main components:

A DIContainer for registering and resolving dependencies
A @Injected property wrapper for easy usage

To start, we'll create a simple DIContainer class that allows us to register and retrieve dependencies. The basic idea is to store a mapping between a type and a factory function that produces an instance of that type. When a dependency is requested, the container will invoke the corresponding factory function to return an instance.

Implementing the DI container

Let's begin with a simple version of our DI container:

public class DIContainer {
    private var factories: [String: Any] = [:]

    func register<T>(_ type: T.Type, factory: @escaping () -> T) {
        let key = String(describing: type)
        factories[key] = factory
    }

    func resolve<T>(_ type: T.Type) -> T? {
        let key = String(describing: type)
        guard let factory = factories[key] as? () -> T else { return nil}
        let instance = factory()
        return instance
    }
}

This implementation allows us to register dependencies using a factory closure and resolve them by type. For instance, we can register a NetworkService like this:

let container = DIContainer()
container.register(NetworkServiceProtocol.self, factory: { NetworkService() })

let networkService = container.resolve(NetworkServiceProtocol.self)

Each time we call resolve(), a new instance is created. However, for dependencies that should persist throughout the application's lifecycle, such as a shared network service, we need to introduce singleton support.

Adding dependency lifetimes

Different dependencies have different lifecycle requirements. Some should be instantiated each time they are requested, while others should persist across multiple resolutions. To handle this, we can introduce a DependencyLifetime enum to distinguish between transient and singleton lifetimes.

public enum DependencyLifetime {
    case singleton
    case transient
}

Now, we modify our DIContainer to store singleton instances separately and respect the chosen lifetime when resolving dependencies:

public class DIContainer {
    static let shared = DIContainer()

    private var factories: [String: Any] = [:]
    private var singletons: [String: Any] = [:]
    private var lifetimes: [String: DependencyLifetime] = [:]

    private init() {}

    func register<T>(_ type: T.Type, factory: @escaping () -> T, lifetime: DependencyLifetime) {
        let key = String(describing: type)
        factories[key] = factory
        lifetimes[key] = lifetime
    }

    func resolve<T>(_ type: T.Type) -> T? {
        let key = String(describing: type)
        guard let lifetime = lifetimes[key] else { return nil }

        switch lifetime {
        case .transient:
            guard let factory = factories[key] as? () -> T else { return nil }
            return factory()
        case .singleton:
            if let instance = singletons[key] as? T {
                return instance
            }
            guard let factory = factories[key] as? () -> T else { return nil }
            let instance = factory()
            singletons[key] = instance
            return instance
        }
    }
}

Now, we can create singleton dependencies when needed:

container.register(NetworkServiceProtocol.self, factory: { NetworkService() }, lifetime: .singleton)

Using a property wrapper for dependency injection

To simplify dependency resolution, we can introduce a property wrapper that automatically resolves dependencies when accessed:

@propertyWrapper
public struct Injected<T> {
    private var dependency: T

    public init() {
        guard let dependency = DIContainer.shared.resolve(T.self) else {
            fatalError("No dependency registered for \(T.self)")
        }
        self.dependency = dependency
    }

    public var wrappedValue: T {
        return dependency
    }
}

This property wrapper provides a declarative way to inject dependencies and automatically resolves dependencies from the container. For example:

class UserService {
    @Injected var networkService: NetworkServiceProtocol
}

Putting it all together - a usage example

To demonstrate our DI framework in action, let’s set up an application where we define dependencies, register them in the container, and inject them where needed.

First, we define the protocols and implementations:

protocol NetworkServiceProtocol {
    func fetchData() -> String
}

class NetworkService: NetworkServiceProtocol {
    func fetchData() -> String {
        return "Real network data"
    }
}

class MockNetworkService: NetworkServiceProtocol {
    func fetchData() -> String {
        return "Mock network data"
    }
}

class UserService {
    @Injected var networkService: NetworkServiceProtocol

    func loadProfile() {
        let data = networkService.fetchData()
        print(data)
    }
}

Next, we configure our container at application startup:

@main
struct ExampleApp: App {

    init() {
        DIContainer.setup()
    }

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

extension DIContainer {
    static func setup() {
        let container = DIContainer.shared
        container.register(NetworkServiceProtocol.self, factory: { NetworkService() }, lifetime: .singleton)
        container.register(UserService.self, factory: { UserService() }, lifetime: .singleton)
    }
}

Now, we can use dependency injection, for example, in a view model:

@Observable
class UserViewModel {
    @ObservationIgnored @Injected var userService: UserService
}

When working with the @Observable framework, it's important to mark injected dependencies with @ObservationIgnored. This prevents SwiftUI from tracking changes to the dependency, which would lead to unnecessary re-renders. Since dependencies like userService typically don't change in a way that affects the view, excluding them from observation ensures that only the state relevant to the UI is observed, improving performance and reducing unnecessary updates.

Finaly thoughts

In this article, we looked at the code idea of a DI container to better understand some concepts behind DI containers. While this implementation covers the basics, there are several areas for improvement, such as better key handling, thread safety, error handling, additional lifecycle options and more.

Public-key cryptography with CryptoKit for iOS

Sun, 23 Mar 2025 23:00:00 GMT

Public-key cryptography, also known as asymmetric cryptography, is a cornerstone of modern security. It ensures secure communication, authentication, and data integrity across IT systems and networks.

For iOS developers, Apple provides built-in security with TLS encryption and digital signing when communicating over HTTPS. However, when dealing with sensitive user data, authentication, or offline encryption, additional layers of security might be necessary.

In this article, we'll explore how public-key cryptography works and how CryptoKit simplifies its implementation in iOS applications.

Public-key cryptography basics

Public-key cryptography is based on a pair of linked keys:

A public key (which can be freely shared)
A private key (which must remain secret)

Anyone can use the public key to encrypt messages, but only the holder of the private key can decrypt them. This makes it ideal for secure messaging, authentication, and digital signatures.

A crucial aspect of public-key cryptography is that deriving the private key from the public key is computationally infeasible. This ensures secure communication even if an attacker intercepts the public key.

Public-key cryptography use cases

Common public-key cryptography use cases are encryption and digital signatures.

Use case: Digital signatures

A digital signature proves that a message was sent by a specific party and has not been altered. This is essential for secure messaging, online transactions, and authentication systems.

In more detail, it works as follows:

The sender hashes the message to create a message digest (a fixed-length fingerprint of the data).
The digest is then encrypted with the sender's private key, creating a digital signature.
The recipient decrypts the signature with the sender's public key to retrieve the digest.
The recipient hashes the original message and compares the digests.
If they match, the message is authentic and untampered.

Use case: Encryption

Although public keys can be used to encrypt messages, they are typically used for secure key exchange in combination with symmetric encryption which is faster and more efficient for large data.

For example, when a user connects to a secure server, public-key cryptography is used to securely exchange a symmetric key that is then used for encrypting communication.

Public-key algorithms supported by CryptoKit

CryptoKit supports Elliptic Curve Cryptography (ECC), which is more efficient than traditional RSA encryption.

P256/P384/P521 (NIST curves) – Widely used, standardized, and compliant with government security standards.
Curve25519 – More efficient and resistant to certain attacks (e.g., side-channel attacks). It's often recommended for modern applications due to its performance and simplicity.

For most applications, Curve25519 is the best choice unless compliance with NIST standards is required.

Using CryptoKit

Now, let's see how to implement public-key cryptography in Swift using CryptoKit.

1. Creating a key pair with CryptoKit

Creating a private-public key pair with CryptoKit is as simple as:

let privateKey = Curve25519.Signing.PrivateKey()
let publicKey = privateKey.publicKey

To send the public key, we can convert it to Data by using its rawRepresentation property:

let publicKeyData = publicKey.rawRepresentation

If we want to use P256 instead of Curve25519, we simply swap the algorithm:

let privateKey = P256.Signing.PrivateKey()

2. Signing with CryptoKit

We can create a digital signature using the private key:

let signature = try privateKey.signature(for: messageDigest)

On signature, we can again use its rawRepresentation property to get a Data type for server communication.

Verifying a received signature is similarly simple:

let isValid = publicKey.isValidSignature(signature, for: messageDigest)

Conclusion

With just a few lines of Swift code, CryptoKit allows us to generate key pairs, create digital signatures, and verify them, all while benefiting from Apple's optimized and secure cryptographic implementations.

Understanding existentials and primary associated types in Swift

Sun, 16 Mar 2025 23:00:00 GMT

Existentials are useful when working with protocols that have associated types. In Swift, protocols with associated types cannot be used as standalone types because their concrete type is unknown at compile time. To work around this, Swift allows us to use existentials (any Protocol) to enable type erasure and store different conforming types in a single collection.

Let's explore how they work in practice.

Let's consider an example where we'll create a system to manage different geometric shapes such as circles, rectangles or triangles and calculate their areas. Each shape conforms to a common protocol Shape which defines a method for calculating the area:

protocol Shape {
    associatedtype Parameters
    func area(with parameters: Parameters) -> Double
}

Here, the Parameters associated type will be different for each shape. For example, the parameters for a circle might be the radius, while the parameters for a rectangle could be its width and height.

Implementing concrete shapes

Let's define two shape implementations: Circle and Rectangle.

struct Circle: Shape {
    struct CircleParameters {
        let radius: Double
    }

    func area(with parameters: CircleParameters) -> Double {
        return Double.pi * parameters.radius * parameters.radius
    }
}

struct Rectangle: Shape {
    struct RectangleParameters {
        let width: Double
        let height: Double
    }

    func area(with parameters: RectangleParameters) -> Double {
        return parameters.width * parameters.height
    }
}

Following the same structure, we could define more shapes, such as Triangle.

Storing shapes in a collection

If we try to store different shapes in an array using the Shape protocol directly, we run into a compiler error:

// Compiler error: Protocol 'Shape' can only be used as a generic constraint because it has Self or associated type requirements.
var shapes: [Shape] = [Circle(), Rectangle(), Triangle()]

Swift does not allow storing values of a protocol with associated types in a collection unless their concrete types are known at compile time. This is where where existentials come into play:

var shapes: [any Shape] = [Circle(), Rectangle(), Triangle()]

Now, Swift allows different implementations to coexist in the same array, but with the trade-off of losing static type information. This means we don't know the specific type of each shape at compile time. To work around this, we must cast the shapes back to their concrete types before calling their methods.

let circleParameters = Circle.CircleParameters(radius: 10)
let rectangleParameters = Rectangle.RectangleParameters(width: 5, height: 8)

for shape in shapes {
    if let circle = shape as? Circle {
        print("Circle area: \(circle.area(with: circleParameters))")
    } else if let rectangle = shape as? Rectangle {
        print("Rectangle area: \(rectangle.area(with: rectangleParameters))")
    }
}

While this works, it introduces runtime type checking and casting, which can be error-prone.

Using primary associated types

To reduce the need for type casting, Swift provides primary associated types, allowing us to specify associated types explicitly when working with existentials:

protocol Shape<Parameters> {
    associatedtype Parameters
    func area(with parameters: Parameters) -> Double
}

Now, we can use Shape<CircleParameters> to define a concrete type when working with the protocol. However, for heterogeneous collections, we still need to use any without a concrete associated type.

While primary associated types help restore lost type information, they do not introduce additional trade-offs when used with any. Instead, they extend the flexibility of existentials, allowing us to specify associated types when needed while still leveraging any for heterogeneous collections.

Understanding structural identity in SwiftUI

Sun, 09 Mar 2025 23:00:00 GMT

Unlike traditional UI frameworks where we manually track and update UI elements, SwiftUI automatically refreshes views when state changes. However, redrawing everything would be inefficient. This is where structural identity comes in - it allows SwiftUI to determine which views actually need to be redrawn, optimizing performance.

Let's jump in and look at how this works.

What is structural identity?

When a state change occurs in SwiftUI, the framework reconstructs the entire view hierarchy. This might sound inefficient at first, but it's actually remarkably optimized, because SwiftUI views are lightweight value types (structs) and most importantly, because SwiftUI uses structural identity to avoid unneeded redrawings.

Structural identity is SwiftUI's way of recognizing whether a view before and after a state change is fundamentally the same view. When SwiftUI identifies views as structurally identical, it preserves their state and redraws only the parts that have changed.

A view's structural identity is determined by:

Its type
Its position in the view hierarchy
The identity of its ancestors

Update vs. redraw in SwiftUI

While the terms update and redraw may sound interchangeably, they refer to different processes:

Update: SwiftUI reinitializes the view evaluating the body property, while preserving state. This happens every time a state change occurs.
Redraw: This is when SwiftUI sends rendering instructions to the GPU, updating the pixels on the screen. Just because a view is reinitialized doesn't mean it will be redrawn.

Structural identity in action

Consider this example:

struct ExampleView: View {
    @State private var isOn = true

    var body: some View {
        VStack {
            Text("Is on: \(isOn ? "yes": "no")")
            Button("Switch") {
                isOn.toggle()
            }
            if (isOn) {
                BottomViewOn()
            } else {
                BottomViewOff()
            }
        }
    }
}

When a user taps the "Switch" button:

The isOn state variable changes.
SwiftUI rebuilds the view hierarchy. That means ExampleView is reinitialized, and SwiftUI preserves the state isOn.
Using structural identity, SwiftUI recognizes that Text and Button are fundamentally the same views as before.
Since the Text view's content has changed, it gets redrawn.
The Button view remains untouched because its content and structure haven't changed.
What happens with BottomViewOn and BottomViewOff? When isOn changes, one view is removed from the hierarchy, and the other one is newly created. And any internal state within BottomViewOn or BottomViewOff is lost when switching between them.

How to persist state across both views?

If we want to keep state in BottomViewOn and BottomViewOff, we could:

Extract their state to the parent view e.i. manage it externally or
Use structural identity by making the following changes:

ZStack {
    BottomViewOn()
        .opacity(isOn ? 1 : 0)
        .accessibilityHidden(!isOn)
    BottomViewOff()
        .opacity(isOn ? 0 : 1)
        .accessibilityHidden(isOn)
}

Instead using an if-else condition, we now keep both views in the hierarchy preserving structural identity.

Structural identity in lists

In SwiftUI, structural identity also plays an important role in lists. When using a List view, SwiftUI requires each item to have a unique identifier, either by conforming to Identifiable or by specifying an id key path. This allows SwiftUI to track individual items even when their order changes, preventing unnecessary redraws. Using unique IDs such as database IDs is a good practice because relying on indices or non-unique properties can lead to incorrect updates, glitches, or unexpected UI behavior when modifying the list dynamically.

SwiftUI as a black box

SwiftUI hides much of its inner workings, making it feel like a black box. SwiftUI decides what to update and redraw behind the scenes, so we can only experiment to understand its behavior. Many hope SwiftUI will be open-sourced someday, giving us a clearer look inside.

Understanding the Bindable property wrapper in SwiftUI

Sun, 02 Mar 2025 23:00:00 GMT

When working with Apple's Observation framework, understanding how different property wrappers manage state is essential for building apps with SwiftUI.

In this article, we'll focus on @Bindable, a property wrapper that allows child views to create bindings to properties inside an @Observable model.

Let's start with an example where two views share the same view model:

import Observation

@Observable
class UserViewModel {
    var name: String?
    var age: Int?
}

struct ParentView: View {
    @State private var userViewModel = UserViewModel()

    var body: some View {
        VStack {
            Text(userViewModel.name ?? "")
            ChildView(userViewModel: $userViewModel)
        }
    }
}

struct ChildView: View {
    let userViewModel: UserViewModel

    var body: some View {
        VStack {
            Text(userViewModel.name ?? "")
            Button(action: {
                userViewModel.age += 1
            }, label: {
                Text("Increment age")
            })
        }
    }
}

Why no property wrapper is needed here

In the example above, ChildView does not use any property wrapper to reference userViewModel. Since UserViewModel is marked as @Observable, SwiftUI automatically tracks changes and updates dependent views when properties change. Thus, there's no need to use @Bindable in this scenario.

When do we need @Bindable?

While direct property access works in many cases, certain UI components, such as TextField, require bindings to modify a value. Consider the following scenario:

struct ChildView: View {
    let userViewModel: UserViewModel

    var body: some View {
        VStack {
            // Compiler error: Cannot find '$userViewModel' in scope
            TextField("Enter name", text: $userViewModel.name ?? "")
        }
    }
}

When we try to pass in a property of our model to a child view which needs a binding, we'll get the compiler error "Cannot find '$userViewModel' in scope".

And that's where the @Bindable property wrapper comes into play. @Bindable allows us to create bindings to properties that are part of a model:

struct ChildView: View {
    @Bindable var userViewModel: UserViewModel

    var body: some View {
        VStack {
            TextField("Enter name", text: $userViewModel.name ?? "")
        }
    }
}

Now, TextField can modify userViewModel.name, and SwiftUI will properly update the view hierarchy.

Quick guide on home screen quick actions for SwiftUI

Sun, 23 Feb 2025 23:00:00 GMT

Quick actions allow us to give users access to our app's functionality directly from the home screen, when they touch and hold the app icon.

For example, the native iOS Photos app offers quick actions to jump directly to recent photos, favorites, or search.

Quick actions of the native iOS Photos app.

Let's look at how we can implement quick actions in our own apps.

Adding quick actions

There are two ways to create quick actions:

Static quick actions – defined in the app's Info.plist, these are best for features that do not rely on app state.
Dynamic quick actions – created programmatically, these adapt to app state or user data.

Static quick actions

Static quick actions are straightforward to define. For instance, a "Favorites" action can be added by including the following configuration in the Info.plist:

<key>UIApplicationShortcutItems</key>
<array>
    <dict>
        <key>UIApplicationShortcutItemType</key>
        <string>favoritesAction</string>
        <key>UIApplicationShortcutItemIconSymbolName</key>
        <string>heart</string>
        <key>UIApplicationShortcutItemTitle</key>
        <string>Favorites</string>
    </dict>
</array>

Here’s what each key represents:

UIApplicationShortcutItemType – A unique identifier for the action, used later when handling the action.
UIApplicationShortcutItemIconSymbolName – Specifies an SF Symbol for the action’s icon.
UIApplicationShortcutItemTitle – Displays the action’s title.

To add a subtitle, include the UIApplicationShortcutItemSubtitle key. Titles and subtitles can be localized using a InfoPlist.strings file:

<key>UIApplicationShortcutItemTitle</key>
<string>QUICK_ACTION_FAVORITES_TITLE</string>

With a matching key in the InfoPlist.strings:

"QUICK_ACTION_FAVORITES_TITLE" = "Favorites";

Dynamic quick actions

Dynamic quick actions are created programmatically and offer flexibility. For instance, we could add a "Favorites" action only if the user has saved favorites:

func updateShortcutItems() {
    guard !favorites.isEmpty else {
        UIApplication.shared.shortcutItems = []
        return
    }

    let favoritesAction = UIApplicationShortcutItem(
        type: "favoritesAction",
        localizedTitle: "Favorites",
        localizedSubtitle: nil,
        icon: UIApplicationShortcutIcon(systemImageName: "heart"),
        userInfo: [:])
    UIApplication.shared.shortcutItems = [favoritesAction]
}

This method can be called whenever the app enters the background to keep the quick actions up-to-date.

var body: some Scene {
    @Environment(\.scenePhase) private var scenePhase

    WindowGroup {
        ContentView()
    }
    .onChange(of: scenePhase) { (newScenePhase) in
        if newScenePhase == .background {
            updateShortcutItems()
        }
    }
}

Handling quick actions

Currently, SwiftUI does not offer a direct way to handle quick action events. Instead, we use UIKit's SceneDelegate to manage these interactions.

It provides the windowScene(_:performActionFor:completionHandler:) delegate method which is called when the app is currently in the background and a user selects a quick action.

If the app isn’t already loaded, it’s launched and the shortcut item is passed in through the connectionOptions parameter of the scene(_:willConnectTo:options:) delegate method.

class SceneDelegate: NSObject, UIWindowSceneDelegate {

    func windowScene(_ windowScene: UIWindowScene, performActionFor shortcutItem: UIApplicationShortcutItem, completionHandler: @escaping (Bool) -> Void) {
        handleShortcutItem(shortcutItem)
        completionHandler(true)
    }

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        if let shortcutItem = connectionOptions.shortcutItem {
            handleShortcutItem(shortcutItem)
        }
    }

    func handleShortcutItem(_ shortcutItem: UIApplicationShortcutItem) {
        if shortcutItem.type == "favoritesAction" {
            // Show favorites
        }
    }
}

In the handleShortcutItem method, we check the shortcut item's type property to determine which quick action was tapped.

To learn more about the SceneDelegate, check out the article on how to use the SceneDelegate in SwiftUI.

When debugging quick home screen actions from an app launch, we need a way to quit the app without loosing Xcode's debugger. Check out the article on how to debug iOS features that require app start from external actions to find out how to do that.

How to use SceneDelegate in SwiftUI

Sun, 16 Feb 2025 23:00:00 GMT

SwiftUI simplifies app development by abstracting away much of the boilerplate code associated with UIKit. However, certain features, such as handling home screen quick actions, still require SceneDelegate from UIKit.

This article is a guide to using SceneDelegate in a SwiftUI-based application. Let's jump in.

To incorporate SceneDelegate in a SwiftUI app, follow these steps:

1. Create a SceneDelegate class

Add a new Swift file and define your SceneDelegate class. The example below shows an exampe of the SceneDelegate for handling home screen quick actions:

class SceneDelegate: NSObject, UIWindowSceneDelegate {

    func windowScene(_ windowScene: UIWindowScene, performActionFor shortcutItem: UIApplicationShortcutItem, completionHandler: @escaping (Bool) -> Void) {
        handleShortcutItem(shortcutItem)
        completionHandler(true)
    }

    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        if let shortcutItem = connectionOptions.shortcutItem {
            handleShortcutItem(shortcutItem)
        }
    }

    func handleShortcutItem(_ shortcutItem: UIApplicationShortcutItem) {
        if shortcutItem.type == "favoritesAction" {
            // Show favorites
        }
    }
}

2. Define the AppDelegate

We need an AppDelegate to connect the SceneDelegate with the app’s lifecycle. Create an AppDelegate.swift file:

class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        configurationForConnecting connectingSceneSession: UISceneSession,
        options: UIScene.ConnectionOptions
    ) -> UISceneConfiguration {
        let configuration = UISceneConfiguration(name: "Default Configuration", sessionRole: connectingSceneSession.role)
        configuration.delegateClass = SceneDelegate.self
        return configuration
    }
}

It ensures that the system uses our SceneDelegate when creating new scenes.

3. Modify the SwiftUI App structure

The final step is connecting the AppDelegate to the SwiftUI app lifecycle by modifying the main app file as follows:

import SwiftUI

@main
struct MyApp: App {
    // Integrate the AppDelegate
    @UIApplicationDelegateAdaptor(AppDelegate.self) private var appDelegate

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}

With a setup of @UIApplicationDelegateAdaptor as shown above, SwiftUI instantiates the delegate automatically and calls the delegate’s methods in response to life cycle events.

Implementing Face ID authentication in SwiftUI

Sun, 09 Feb 2025 23:00:00 GMT

Apple's Local Authentication framework enables us to implement biometric authentication, such as Face ID and Touch ID, allowing users to securely access sensitive app data. In this article, we’ll explore how to integrate Face ID using Swift and SwiftUI.

Let's jump in.

Setting up LocalAuthentication framework

As a first step, we need to add the NSFaceIDUsageDescription key in the app’s Info.plist file. This key is mandatory, and without it, the system will prevent Face ID from being used. The value should clearly describe why Face ID access is required.

After that, we can import and use the LocalAuthentication framework, which provides access to biometric authentication functions and error handling.

import LocalAuthentication

Checking if biometry is available

Before authenticating the user, an essential step is to check if biometrics are available on the device:

func isAuthenticationAvailable() -> Bool {
    let context = LAContext()
    var error: NSError?

    return context.canEvaluatePolicy(.deviceOwnerAuthentication, error: &error)
}

The value deviceOwnerAuthentication includes passcode authentication if biometry is not available.

Starting the authentication process

Once we know authentication is available, we can initiate the process by calling the evaluatePolicy method, which prompts the user to authenticate.

context.evaluatePolicy(.deviceOwnerAuthentication, localizedReason: reason) { (success, error) in
    DispatchQueue.main.async {
        if success {
            // Authentication succeeded.
        } else {
            // Handle the error (e.g., user canceled, authentication failed).
        }
    }
}

Integrating with SwiftUI views

To integrate biometric authentication into a SwiftUI app, we can call the authentication function within a SwiftUI view:

struct ContentView: View {
    @State private var isAuthenticated = false

    var body: some View {
        VStack {
            if isAuthenticated {
                Text("Welcome to your secure data!")
            } else {
                Button("Authenticate") {
                    authenticate()
                }
            }
        }
    }

    private func authenticate() {
        authService.authenticate { success, error in
            if success {
                isAuthenticated = true
            } else {
                // Handle error
            }
        }
    }
}

Handling errors

Authentication may fail due to various reasons, such as the user canceling the prompt or the system being unable to recognize the face. We can handle these errors by evaluating the error as follows:

if let error = error as? LAError {
    switch error.code {
    case .userCancel:
        // Handle user cancellation
    case .authenticationFailed:
        // Handle failed authentication
    default:
        // Handle other errors
    }
}

Testing the authentication on a simulator

To test the authentication flow, we don't necessarily need a device. We can simulate success and failure directly in simulator by choosing Features -> Face ID in the menu and then selecting the behaviour we want to simulate.

Good to know

The iOS app never gains any access to the actual authentication data like fingerprint images. It is stored by an isolated security processor called Secure Enclave, which manages this data out of reach even for the operating system.

So when we ask the Local Authentication framework to evaluate, the framework asks the Secure Enclave to carry out the operation. Afterwards, we only receive a Boolean result and an optional error indicating success or failure.

SF Symbols guide for SwiftUI and UIKit

Sun, 02 Feb 2025 23:00:00 GMT

SF Symbols is Apple's library of vector-based icons that integrate seamlessly into iOS, providing a unified look across Apple platforms. Each symbol is vector-based, meaning it scales smoothly at different sizes and weights, making it ideal for modern app design.

In this guide, we’ll explore how to incorporate SF Symbols into SwiftUI and UIKit projects, from adding basic icons to customizing their scale, weight, and color.

Downloading the SF Symbols app

We can browse the full SF Symbols collection using the SF Symbols app, available for free from Apple's developer site. This app allows us inspect all available symbols in different weights and scales, and copy the symbol names to use in our code.

Using SF Symbols in iOS

Adding SF Symbols is straightforward in both SwiftUI and UIKit. It's is as simple as using an Image view with the systemName initializer:

SwiftUI

Image(systemName: "cloud.moon.rain")

UIKit

UIImage(systemName: "cloud.moon.rain")

Customizing SF Symbols

One of the strengths of SF Symbols is their ability to adapt to different styles, including scale, weight, and color.

1. Adjusting scale and weight

To adjust size and weight, we can use the font modifier on the image:

SwiftUI

Image(systemName: "cloud.moon.rain")
    .font(Font.system(size: 60, weight: .bold))

In UIKit, we can use the UIImage.SymbolConfiguration type. The applying method can be used to combine different configurations into one:

UIKit

var config = UIImage.SymbolConfiguration(weight: .bold)
config = config.applying(UIImage.SymbolConfiguration(font: .systemFont(ofSize: 42.0))

let image = UIImage(systemName: "cloud.moon.rain", withConfiguration: config)

2. Applying colors

SF Symbols support different layers, allowing us to control colors for each layer using various rendering modes:

Monochrome: Applies a single color to the entire symbol.
Hierarchical: Assigns different opacities to each layer, creating a subtle depth effect.
Palette: Assigns colors to each layer, creating a multicolored look.
Multicolor: Uses Apple’s intrinsic colors to enhance symbol meaning in supported icons.

For example, the cloud.moon.rain symbol consists of three layers: the clouds, the moon and the rain are each represented by one layer. Let's see how each rendering mode affects its appearance.

Monochrome applies a single color to the entire symbol:

SwiftUI

Image(systemName: "cloud.moon.rain")
      .foregroundColor(.teal)

UIKit

UIImage(systemName: "cloud.moon.rain")?.withTintColor(.systemTeal)

Hierarchical applies one color to the symbol, but using different opacity for each layer:

SwiftUI

Image(systemName: "cloud.moon.rain")
    .foregroundColor(.teal)
    .symbolRenderingMode(.hierarchical)

UIKit

UIImage.SymbolConfiguration(hierarchicalColor: .systemTeal)

Palette applies two or more colors to the symbol, using one color per layer. Specifying two colors for a symbol with three levels will use the same color for the secondary and tertiary layer.

SwiftUI

Image(systemName: "cloud.moon.rain")
      .foregroundStyle(.teal, .purple, .yellow)

UIKit

UIImage.SymbolConfiguration(paletteColors: [.systemTeal, .systemPurple, .systemYellow])

Multicolor applies system-defined intrinsic colors to some symbols to enhance meaning. It will not have an effect on every symbol.

SwiftUI

Image(systemName: "calendar.badge.plus")
      .foregroundColor(.teal)
      .symbolRenderingMode(.multicolor)

UIKit

UIImage.SymbolConfiguration.preferringMulticolor()

Integrating SF Symbols with Text

SF Symbols are designed not to be only used as standalone icons, but also together with text.

SwiftUI

Label("Welcome", systemImage: "tortoise")

UIKit

let attachment = NSTextAttachment()
attachment.image = UIImage(systemName: "tortoise")

let attributedString = NSMutableAttributedString(attachment: attachment)
attributedString.append(NSAttributedString(string: "Welcome"))

Additionally to sizing symbols with fonts, we can configure their scale that sets the symbols size compared to its neighboring text. Available scales are: .small, .medium and .large.

SwiftUI

.imageScale(.large)

UIKit

UIImage.SymbolConfiguration(scale: .large)

Checking symbol availability

Not all symbols are supported in every iOS version. Use the SF Symbols app to check each symbol’s compatibility with different iOS versions. Symbols introduced in later iOS versions may require alternative options or fallbacks.

If some symbol is not available for our iOS version, we can export it from the SF Symbols app as an SVG template and bundle it with our iOS app. Note that it makes the symbol available, but not the additional rendering modes.

Creating custom symbols

If we need a unique icon that SF Symbols doesn’t offer, Apple allows custom symbols. Custom symbols can maintain the same scalability and adaptability as native SF Symbols if created correctly. Check out Apple's guide on creating custom symbol images for more details.

Learn to debug iOS features that require app start from external actions in Xcode

Sun, 26 Jan 2025 23:00:00 GMT

Debugging iOS features that require app starts from external actions - such as deep linking or home screen quick actions - can be challenging. By default, when running an app in Xcode, the debugger automatically attaches itself. However, once the app is killed on the simulator or device, the debugger detaches, making it difficult to test features that require the app to be launched from an external action.

Xcode offers a solution: the "Wait for executable to be launched" scheme option. This allows us to attach the debugger to the app even when launching it manually.

Steps to enable the debugger for manual launch

To activate the Wait for executable to be launched feature:

Edit the scheme:

Go to the Xcode menu and select Product > Scheme > Edit Scheme.

Enable the setting:

Under the Info tab in the Launch section, select the option: "Wait for executable to be launched".

Run the app:

Start running the app in Xcode. The app won’t automatically launch as it typically does. Instead, Xcode will pause and wait for us to manually launch the app from the simulator or device.

Debugging Features After Manual Launch

Once the app is manually launched, Xcode will automatically attach the debugger. This setup is especially useful for testing:

Deep Linking / Universal Links: Tap a deep link to launch the app and verify the flow.
Home Screen Quick Actions: Trigger an action and ensure the app behaves as expected.

By keeping the debugger attached during these scenarios, we can use breakpoints, inspect variables, and view console logs to diagnose any issues.

Customizing the appearance of the NavigationStack title in SwiftUI

Sun, 19 Jan 2025 23:00:00 GMT

When working with NavigationStack, we have the possibility to customize the appearance of the navigation bar, including the title. This article explores two approaches to creating custom titles using SwiftUI’s navigationBarTitleDisplayMode(_:) and toolbar(content:) modifiers.

Let's jump in.

The Default Title Behavior

In NavigationStack, a title is displayed when the navigationTitle(_:) modifier is used. By default, the system employs a large title that transitions to an inline title when scrolling:

NavigationStack {
    VStack {
        // Content...
    }
    .navigationTitle("Inline Title")
}

If we want to move beyond the default behavior, we can use the following customization techniques.

Customizing with `navigationBarTitleDisplayMode(_:)`

The navigationBarTitleDisplayMode(_:) modifier lets us control how the navigation title appears. Setting the mode to .inline ensures that the title remains compact and inline at all times, even when scrolling. This creates a consistent look across the app, particularly for minimalistic designs.

NavigationStack {
    VStack {
        // Content...
    }
    .navigationTitle("Inline Title")
    .navigationBarTitleDisplayMode(.inline)
}

Adding Custom Title Views with `toolbar(content:)`

To fully customize the appearance of the navigation title, the toolbar(content:) modifier allows replacing the default title with any SwiftUI view. By specifying a ToolbarItem with a placement of .principal, we can override the default title and insert completely custom layouts:

NavigationStack {
    VStack {
        // Content...
    }
    .navigationTitle("Custom Title")
    .navigationBarTitleDisplayMode(.inline)
    .toolbar {
        ToolbarItem(placement: .principal) {
            Image(systemName: "photo.fill")
                .font(.title)
                .foregroundColor(.blue)
        }
    }
}

Instead of an Image, we can use any SwiftUI view.

How to use cryptographic hash functions in CryptoKit for iOS security

Sun, 12 Jan 2025 23:00:00 GMT

Cryptographic hash functions are essential tools in secure application development, commonly used for verifying data integrity, securely storing passwords, and generating unique identifiers. Apple's CryptoKit framework offers a range of hashing functions that are efficient, secure, and easy to implement within Swift.

In this guide, we’ll explore how to work with CryptoKit’s hash functions, such as SHA-256 and SHA-512, to improve the security of your iOS apps.

What is a cryptographic hash function?

A cryptographic hash function generates a fixed-length hash (or digest) from input data of any size. This hash acts like a digital fingerprint, uniquely identifying the input without revealing the original data. Key features of a secure cryptographic hash function include:

one-way function - meaning that it's practically irreversible
deterministic - meaning that the same message always results in the same hash value
unique - meaning that it's practically not possible to find two different messages with the same hash value

These characteristics make hash functions ideal for storing hashed passwords, validating data integrity, and ensuring message authenticity.

For example, when a user enters a password into our app to login, we hash the password and send it to the server for verification. The passwords stored on the server are also computed hash values of the original passwords. This way, we never store the original password or send it over the network but still are able to verify it.

Hash functions in CryptoKit

CryptoKit provides several hashing algorithms, the main two algorithms are:

SHA-256: A commonly used 256-bit hash function providing a secure balance between performance and cryptographic strength.
SHA-512: A 512-bit version of SHA, offering a higher level of security, typically used for applications requiring greater protection.

For most iOS applications, SHA-256 is a preferred choice because of its strength and efficiency.

Let's look at how we can hash a password with the SHA-256 algorithm:

func hashPassword(_ password: String) -> String {
    let hash = SHA256.hash(data: Data(password.utf8))
    return hash.compactMap { String(format: "%02x", $0) }.joined()
}

The compactMap line in this function is used to convert each byte in the SHA-256 hash into a hexadecimal String representation, returning a single, readable hash string.

Preparing for a technical iOS job interview with questions and answers in 2025 - book preview

Mon, 06 Jan 2025 23:00:00 GMT

I just released a new book version of Preparing for a technical iOS job interview - with over 200 questions & answers including a new chapter on Architecture & Design Patterns.

This preview provides one example question and answer for every main chapter of the book. You can also download a preview here to see the full outline of the book.

Introduction

Having been a freelance iOS developer for over 10 years, I participated in quite a few hiring interviews for various projects and have also been in a position of leading the technical interviews myself.

With this book, I'd like to give you a guide for technical iOS questions you might be asked in such an interview for an iOS hiring position. It can also be used to get an overview on different iOS development topics and be an inspiration for deepening and expanding your knowledge on your iOS journey.

Each chapter starts with a questions overview that allows you to check your knowledge without seeing the answers. All questions are numerated so you can quickly find the answer if needed. The following topics are covered:

Chapter: Swift

Being the main programming language for the iOS platform, a deep knowledge in Swift is expected from an iOS developer. This chapter provides questions and answers on Swift and general programming language concepts.

Example question & answer:

Swift is a type-safe language. What does type safety mean, and why is it important?

Type safety means that the compiler enforces rules to prevent type errors by ensuring values are used consistently with their declared types. For example, if we declare a variable as an Int, we cannot assign a String value to it. The compiler checks for type mismatches during compilation and provides errors, helping developers catch and fix issues early in the development process.

This feature improves code reliability and reduces runtime errors because many potential bugs are identified before the app runs. Type safety also enhances code readability and maintainability, as the expected data types are clear from the code.

var age: Int = 10
age = "ten" // Compiler error: Cannot assign a value of type 'String' to a variable of type 'Int'

By enforcing type safety, Swift encourages robust and predictable programming practices, making code safer and easier to debug.

Chapter: SwiftUI

SwiftUI is Apple's main framework for building user interfaces for iOS. This chapter provides questions and answers on the main aspects of SwiftUI.

Example question & answer

Why is it advisable to avoid using AnyView in SwiftUI when possible?

SwiftUI uses a concept called structural identity, where it relies on a view's type to efficiently determine when the view should be updated.

AnyView is a type-erased wrapper that can hold any SwiftUI view. However, since it erases the view's type information, it diminishes SwiftUI's ability to efficiently track and update the view. This can lead to reduced performance, especially in complex view hierarchies.

Therefore, it is advisable to avoid using AnyView whenever possible to maintain the performance benefits of SwiftUI's structural identity.

Chapter: Xcode

Being the main iOS development tool, a confident usage of Xcode is expected from an iOS developer. This chapter provides questions and answers on working and debugging with Xcode.

Example question & answer

What is the purpose of a build scheme in Xcode?

An Xcode build scheme organizes the settings and configurations for development actions such as building, running, testing, profiling, and archiving a project. A scheme determines which targets to build and how they are built, allowing developers to manage workflows efficiently.

Only one scheme can be active at a time. Developers can customize default schemes or create new ones to handle specific tasks, such as creating different builds (e.g., debug or release) or passing unique launch arguments for testing.

Chapter: Combine

The Combine framework is Apple’s native solution for handling asynchronous events and data streams in Swift. It enables developers to write functional reactive code, streamlining tasks like chaining, transforming, and combining data. This chapter provides questions and answers on Combine and on functional reactive programming concepts in general.

Example question & answer

What is the difference between a subject and a publisher in Combine?

In Combine, a publisher emits values over time and can finish or fail with an error. A subject is a type of mutable publisher, meaning it can actively send new values after its initialization.

Essentially, subjects are a way to manually control the flow of values in a publisher, whereas regular publishers emit values automatically based on their data source.

Chapter: Server Communication

Server communication is part of almost every iOS application. This chapter provides questions and answers on general computer networking concepts and on specific iOS networking topics.

Example question & answer

What is OAuth, and why is it used?

OAuth is an open protocol for secure authorization, allowing users to grant third-party services limited access to their resources without sharing credentials.

The core idea is the use of access tokens as intermediaries. When a third-party app requests access to a user's resources, it obtains an access token from the main service through a secure flow. This token grants limited permissions, ensuring:

The user's credentials (e.g., password) remain private and are not shared with the third party.
Access can be revoked at any time without affecting the user's main account.

OAuth enhances security and user control over data sharing across applications and services.

Chapter: Concurrency

This chapter focuses on Swift's concurrency model with async/await. It also provides questions and answers on more low-level technologies like Grand Central Dispatch and Operations. Since they were used in iOS applications before async/await, knowledge around these technologies may be required for an iOS position.

Example question & answer

What is the role of the await keyword in Swift's asynchronous programming?

TThe await keyword in Swift enables asynchronous functions to suspend execution until the result of another asynchronous function or task becomes available. This allows developers to write asynchronous code in a sequential and readable manner while the system manages underlying complexities, such as pausing and resuming execution. By combining async and await, Swift ensures clarity and efficiency in handling concurrent operations.

Chapter: Persisting Data

Persisting pieces of data is required in many applications. Apple offers solutions to store data for different scenarios. This chapter contains questions and answers on persistence technologies and frameworks such as File System, UserDefaults, SwiftData and Core Data.

Example question & answer

What is migration in SwiftData, and how does it handle schema changes?

Migration in SwiftData ensures that changes to data models in new app versions do not lead to data loss. SwiftData handles this by transitioning between schema versions through migration plans. Developers can define versioned schemas, specify migration sequences, and choose between lightweight migrations or custom transformations as needed.

This process helps maintain data integrity while evolving the app's data structure.

Chapter: Security

Many applications need to manage some kind of sensitive user data. To ensure a high level of security, Apple provides different technologies to be used by developers. This chapter provides questions and answers on specific security-related iOS technologies such as keychain or shared web credentials, as well as general cryptography concepts.

Example question & answer

What are use cases of a hash function?

Cryptographic hash functions have various security applications, such as:

Digital Signatures: Ensuring the integrity of signed data.
Message Authentication: Verifying the authenticity of messages.
Password Verification: Protecting stored passwords.

For instance, in password verification, instead of storing plain passwords, the server stores their hash values. When a user logs in, the app hashes the entered password and sends it for comparison. This approach ensures that the original password is neither stored nor transmitted, enhancing security.

Chapter: Architecture & Design Patterns

Architectural principles and design patterns are the foundation of robust, maintainable, and scalable iOS applications. This chapter explores key architectural concepts and widely used design patterns in iOS development, providing practical examples and insights into their strengths and weaknesses.

Example question & answer

What are the strengths and weaknesses of the MVVM pattern in iOS development?

The MVVM pattern in iOS development separates UI concerns from business logic by introducing a ViewModel that acts as an intermediary between the Model and View.

This structure makes code more maintainable, testable, and reusable, as it reduces tight coupling between components. MVVM aligns particularly well with SwiftUI’s declarative nature, where state management and bindings are core features.

However, it can add complexity and require additional boilerplate, particularly in small or simple apps where the benefits may not outweigh the costs. MVVM is most effective in medium-to-large applications with more intricate UI and logic, where clear separation of concerns is crucial.

Chapter: Automated Testing

Testing is an important part in every software development process. Apple offers tools to write unit, UI and performance tests for iOS applications. This chapter provides questions and answers on general testing concepts and specific iOS testing tools.

Example question & answer

What are parameterized tests when working with Swift Testing?

Swift Testing supports parameterized tests allowing us to run the same test logic multiple times with different input values:

@Test(arguments: ["a", "b", "c"])
func example(input: String) {
    ...
}

Machine Learning

Machine learning becomes an increasingly important part of software development and engineering jobs. Machine learning techniques are used to build models that can learn patterns in data and make predictions or decisions without being explicitly programmed to do so. These models are used in a variety of applications, including image and speech recognition, natural language processing and recommendation systems. This chapter provides questions and answers on general machine learning concepts and on how to integrate machine learning into an iOS application.

Example question & answer

What are some examples of tasks than can be solved with the Natural Language framework out of the box?

The Natural Language framework is a machine learning framework that allows us to process and analyze natural language text. With the Natural Language framework, we can solve a wide range of natural language processing tasks, for example:

recognizing the language of a text
finding synonyms or similar sentences of a given text
identify and extract named entities from text, such as people, organizations, and locations
part-of-speech tagging, i.e. tagging each word in a piece of text with its part of speech, such as noun, verb, adjective, etc.

Working with Legacy Code: UIKit

With SwiftUI slowly pushing UIKit into the background, UIKit is still part of many existing iOS applications. A deep knowledge of UIKit may be required for an iOS position. This chapter provides questions and answers around key aspects of UIKit.

Example question & answer

What is the concept behind intrinsic content size of a UIView?

Intrinsic content size represents the amount of space a view needs to display its content. A view can have an intrinsic content height, width or both.

For example, the intrinsic content size of a UILabel will be the size of the text it contains.

Not all views have an intrinsic content size. When defining a custom view, we are able to decide if it has an intrinsic content size depending on how we setup the view's constraints.

Working with Legacy Code: Objective-C

Objective-C is becoming more and more obsolete after Swift was released in 2014. However, with existing apps written in Objective-C still out there, knowledge on Objective-C may be required for an iOS position. This chapter provides questions and answers on Objective-C basics and the interoperability between Swift and Objective-C.

Example question & answer

What is an implementation file in Objective-C?

An implementation file contains the actual implementation for an Objective-C class. It implements all methods defined in the header file and also contains private properties and methods.

The syntax to declare a class implementation looks as follows:

SomeClass.m

#import "SomeClass.h"

@implementation SomeClass
// implement public methods
// define & implement private properties and methods
@end

This article is a preview of the book Preparing for a technical iOS job interview - with over 200 questions & answers.

Understanding opaque types and protocols with associatedtype in Swift

Sun, 05 Jan 2025 23:00:00 GMT

Protocols with associatedtype or Self requirements often bring challenges when used as parameters or return types in Swift. Historically, developers needed to rely on generics to work around these limitations, leading to sometimes complex code.

This article will show how to use opaque types to simplify interactions with such protocols.

As an example, let's look at a protocol with an associated type.

protocol Store {
    associatedtype Item
    func persist(item: Item)
}

Because of the associatedtype, the protocol does not have a fully determined concrete type until we provide a specific implementation. This makes it impossible to use the protocol directly as a parameter or return type without triggering a compile-time error.

For example, writing the following function results in an error:

func cleanup(store: Store) {
    // Error: Protocol 'Store' can only be used as a generic constraint because it has Self or associated type requirements.
}

To work around this, we could define the function as a generic:

func cleanup<T: Store>(store: T) {
}

While this works, it introduces complexity. By using opaque types, we can simplify:

func cleanup(store: some Store) {
    // Simplified function declaration.
}

The opaque declaration is basically syntactic sugar for the equivalent generic code. The compiler will automatically infer the concrete parameter type without needing us to write the generic code.

Getting started with UI Testing for SwiftUI

Sun, 29 Dec 2024 23:00:00 GMT

To ensure that our app's user interface behaves correctly during various user actions, iOS provides the XCTest framework for creating UI tests.

In this guide, we'll walk through writing UI tests for a SwiftUI application, including how to query UI elements and interact with them.

Let's jump in.

Introduction to XCTest for UI Testing

XCTest enables developers to write unit tests, performance tests, and UI tests.

When writing UI tests, we simulate user behavior to verify that the app’s interface functions as expected. UI tests help confirm that specific elements are displayed correctly and respond as intended to user actions.

XCTest provides tools to query the view hierarchy and interact with UI elements programmatically, ensuring reliability in our application’s design and functionality.

Preparing for UI Testing

When creating a new SwiftUI application, we can include a UI testing target by selecting the Include Tests option during project setup. This automatically creates a UI testing target in Xcode.

Alternatively, for existing projects, we can manually add a UI testing target by selecting File > New > Target > UI Testing Bundle from Xcode’s menu.

Setting up the Test Class

To write a UI test, we use a Swift class that extends XCTestCase. Xcode creates a sample test file when a UI testing target is added. Below is an example of the generated code:

import XCTest

class ExampleAppUITests: XCTestCase {

    override func setUpWithError() throws {
        continueAfterFailure = false
    }

    override func tearDownWithError() throws {
    }

    func testExample() throws {
        let app = XCUIApplication()
        app.launch()
    }
}

Xcode runs every method that starts with the word test as a separate test. We can already try out and run the testExample method which simply launches the app.

We can either run all tests by selecting Product > Test or run a specific test with the play button next to the test method name. If the test target compiles without errors and the testExample gets a green checkmark, we are ready to go.

The anatomy of a `XCTestCase` test class

A test class typically contains the following:

setUpWithError: This method is called before each test and is used to set up the initial state.
tearDownWithError: This method runs after each test and can be used for cleanup.

Here’s an example that configures the test environment:

override func setUpWithError() throws {
    continueAfterFailure = false
    let app = XCUIApplication()
    app.launchArguments = ["isRunningUITests"]
    app.launch()
}

Using launch arguments like "isRunningUITests", we can prepare the app for testing by clearing data, mocking responses, or bypassing login flows.

In our app code, we can access arguments with the ProcessInfo class:

if ProcessInfo.processInfo.arguments.contains("isRunningUITests") {
    // Prepare application for UI tests.
}

Querying UI elements

To interact with UI elements, we use the XCUIApplication class, which provides methods to locate elements in the app’s hierarchy. Elements can be queried by their accessibility identifiers.

For example, to access a button with the identifier loginButton:

let loginButton = app.buttons["loginButton"]

The XCUIElementTypeQueryProvider provides a lot of different queries such as alerts, checkBoxes, collectionViews, datePickers, images, otherElements, scrollViews, searchFields, staticTexts, toolbarButtons etc..

SwiftUI views allow us to assign accessibility identifiers using the accessibilityIdentifier modifier. Here’s an example:

Button("Login", action: {
    // Login
})
.accessibilityIdentifier("loginButton")

Simulating user actions

XCTest provides various methods to simulate user actions, such as taps, swipes, and text input. For example:

loginButton.tap()

Other common interaction methods include:

doubleTap()
scroll()
swipeUp()
swipeRight()
pinch(withScale:velocity:)
typeText(_:)

Verifying state in a UI test

To verify whether an expected element is on the screen, we can use the same macros as in unit testing such as XCTAssert and XCTAssertTrue:

XCTAssertTrue(loginButton.exists)

Here’s an example for testing a login screen:

func testLogin() throws {
    let app = XCUIApplication()
    app.launchArguments = ["isRunningUITests"]
    app.launch()

    let loginButton = app.buttons["loginButton"]
    XCTAssertTrue(loginButton.waitForExistence(timeout: 2))
    loginButton.tap()

    let usernameField = app.textFields["usernameInputField"]
    XCTAssertTrue(usernameField.waitForExistence(timeout: 2))
    usernameField.tap()
    usernameField.typeText("user")

    let passwordField = app.secureTextFields["passwordInputField"]
    XCTAssertTrue(passwordField.exists)
    passwordField.tap()
    passwordField.typeText("password")

    let submitButton = app.buttons["submitButton"]
    XCTAssertTrue(submitButton.exists)
    XCTAssertTrue(submitButton.isEnabled)
    submitButton.tap()
}

The waitForExistence(timeout:) method assures we don't get any test failures due to animations where views might need some time to appear on the screen.

Recording a UI test

Xcode provides the possibility to record a UI test.

For that, click inside a UI test method and select Editor > Start recording UI test. The app will start and generate UI testing code for us as we interact with the app.

The recording might be helpful in some cases and is fun to play around with, but the generated code will need readjustments and improvements in most cases, so it might be more productive to just directly writing it down.

Accessibility Inspector

A helpful tool when it comes to UI testing is the Accessibility Inspector. Open it by selecting Xcode > Open Developer Tool > Accessibility Inspector in Xcode's menu.

The Accessibility Inspector shows us different accessibility values when we select a UI element in our app. We can use it to get the accessibility identifiers for the UI tests or to determine which elements require accessibility identifiers.

Creating a particles snow effect with SpriteKit and SwiftUI

Sun, 22 Dec 2024 23:00:00 GMT

Apple’s SpriteKit framework is widely used for building 2D games, but it’s also a great tool for adding visual effects to any iOS app.

In this article, we are going to take a look into SpriteKit's particle emitter to create a snow effect and combine it with a SwiftUI view.

Let's dive in.

Step 1: Adding a SpriteKit particle file

SpriteKit provides an easy-to-use particle editor to create effects like snow, fire, and smoke. Here’s how you can set up a snow particle file:

In Xcode, create a new file using File > New > File.
Select Resource > SpriteKit Particle File.
Choose the snow particle emitter template from the options.

Xcode's particles editor

The built-in particle editor allows us to customize the properties of the particle emitter to achieve the desired snow effect. For example, we can adjust the particle birth rate, lifetime, speed, and texture.

Step 2: Creating a custom SpriteKit scene

In SpriteKit, a scene (SKScene) acts as the root container for all visual content in a 2D space. Think of it as a stage where various elements like sprites, shapes, and particle effects are added as nodes to create a complete visual experience. Each scene can be thought of as a separate screen or a distinct part of your app's interface, handling its own rendering and animations.

We'll set up a SnowScene where our snow particle emitter will live, acting as the primary node that holds all the other content for our snowfall effect.

class SnowScene: SKScene {

    let snowEmitterNode = SKEmitterNode(fileNamed: "snow.sks")

    override func didMove(to view: SKView) {
        guard let snowEmitterNode = snowEmitterNode else { return }
        snowEmitterNode.particleSize = CGSize(width: 50, height: 50)
        snowEmitterNode.particleLifetime = 2
        snowEmitterNode.particleLifetimeRange = 6
        addChild(snowEmitterNode)
    }

    override func didChangeSize(_ oldSize: CGSize) {
        guard let snowEmitterNode = snowEmitterNode else { return }
        snowEmitterNode.particlePosition = CGPoint(x: size.width/2, y: size.height)
        snowEmitterNode.particlePositionRange = CGVector(dx: size.width, dy: size.height)
    }
}

In this code:

We create an SKEmitterNode using the particle file and add it to the scene using addChild().
The particle properties, such as particleLifetime and particleLifetimeRange, are configured to control how long each snow particle stays on the screen.
The didChangeSize(_:) method is overridden to reposition the snow emitter when the view size changes, ensuring the snow falls across the entire width of the screen.

Step 3: Integrating SpriteKit with SwiftUI

Now that we have a SnowScene set up, we can add it to a SwiftUI view using SpriteView. This allows us to integrate the particle effects into SwiftUI components.

struct ContentView: View {
    var scene: SKScene {
        let scene = SnowScene()
        scene.scaleMode = .resizeFill
        scene.backgroundColor = .clear
        return scene
    }

    var body: some View {
        ZStack {
              Image("background")
                .resizable()
                .aspectRatio(contentMode: .fill)
                .ignoresSafeArea()
              SpriteView(scene: scene, options: [.allowsTransparency])
                .ignoresSafeArea()
                .frame(minWidth: 0, maxWidth: .infinity, minHeight: 0, maxHeight: .infinity)
            }
    }
}

In this example:

The backgroundColor of the scene is set to .clear, allowing the background image to show through.
SpriteView is configured with the .allowsTransparency option to render the particles over the SwiftUI view.
The ZStack ensures the background image and the snow effect are layered correctly.

Step 4: Customizing the snow effect

You can further enhance the snow effect by experimenting with the properties in the particle editor or modifying them programmatically. Here are a few customization tips:

Particle Size and Lifetime: Adjust particleSize and particleLifetime to simulate different snowfall conditions, such as light flurries or heavy snow.
Speed and Direction: Use particleSpeed and emissionAngle to control how fast the snow falls and its direction.
Color and Blend Mode: Change particleColor and blendMode to achieve unique visual styles, like glowing or shimmering snowflakes.

With a bit of customization, you can adapt this approach for different particle effects, like rain or confetti, to create a wide range of visual experiences.

How to unit test async/await functions in Swift

Sun, 15 Dec 2024 23:00:00 GMT

In this article, we'll cover the basics of unit testing async/await functions, showing how to write test cases for functions that may or may not throw errors.

Let's jump in.

With async/await, unit testing asynchronous code in Swift got easier and shorter compared to testing asynchronous code with completion handlers.

We don't need to setup and handle an XCTestExpectation anymore. All we have to do is to mark the test function with async and call await on the async call.

Let's look at an example:

import XCTest

class FibonacciSequenceTests: XCTestCase {

    func testFibonacciSequence() async {
        let result = await fibonacciSequence(count: 7)
        XCTAssertEqual([0, 1, 1, 2, 3, 5, 8], result)
    }
}

In this test, the fibonacciSequence(count:) function is asynchronous, so we simply mark the test function with async and use await when calling the function. This eliminates the need for managing expectations or manually waiting for the result.

For async functions that may throw an error, we can handle them using the try keyword.

func testFibonacciSequence() async {
    let result = try? await fibonacciSequence(count: 7)
    XCTAssertNotNil(result)
    XCTAssertEqual([0, 1, 1, 2, 3, 5, 8], result)
}

Alternativaly, we can mark our test function with throws:

func testFibonacciSequenceWithErrorHandling() async throws {
    let result = try await fibonacciSequence(count: 7)
    XCTAssertEqual(result, [0, 1, 1, 2, 3, 5, 8])
}

In this version, if fibonacciSequence(count:) throws an error, the test will automatically fail.

If we need to handle specific error cases, we can also use a do-catch block:

func testFibonacciSequenceThrowsError() async throws {
    do {
        let _ = try await fibonacciSequence(count: -1)
        XCTFail("Expected an error for negative count, but no error was thrown")
    } catch FibonacciError.invalidCount {
        // Success! The expected error was thrown.
    } catch {
        XCTFail("Unexpected error thrown: \(error)")
    }
}

Understanding opaque types in Swift

Sun, 08 Dec 2024 23:00:00 GMT

Swift is a type-safe language, meaning every variable and constant has a defined type that the compiler checks to prevent type-related errors. While this is beneficial, there are times when complex return types make function signatures lengthy and harder to read, especially when working with protocols or generics.

Opaque types offer a powerful solution. By returning an opaque type instead of an explicit type, we can hide the exact underlying type of a value while maintaining type safety.

In this article, we’ll walk through what opaque types are, how to use them, and when they’re most useful in Swift programming.

What is an opaque type?

In Swift, an opaque type is represented by the some keyword, which we place before a type in a function’s return signature. By using some, we specify that a function returns a type that conforms to a given protocol without revealing the exact underlying type:

func shape() -> some Shape {
    return Circle()
}

Practical uses of opaque types

Simplifying complex return types

In SwiftUI, opaque types allow us to hide specific view types. This is beneficial because SwiftUI views often contain complex types that are nested or generic.

func loginView() -> some View {
    VStack {
        Text(...)
        Button(...)
    }
}

Here, the function hides the exact type of the view, allowing flexibility and avoiding a complex return type.

Combining with protocols with associated types

Protocols with associated types aren’t always usable as standalone types. For instance:

protocol Container {
    associatedtype Item
    func getItem() -> Item
}

func makeContainer() -> Container {
    // This won’t work, as Container has an associated type.
}

In the example above, we cannot just return Container, since it has an associated type. Instead, we can use an opaque type to specify that the function returns a type conforming to Container, without needing to specify the associated type:

func makeContainer() -> some Container {
    return // Return a concrete type conforming to Container
}

Limitations of opaque types

Opaque types provide great flexibility, but there are some limitations:

Single Concrete Type: Opaque types only work when a function returns a single concrete type. We cannot return multiple different types as opaque types within the same function.
No External Type Information: Since the exact type is hidden, the caller cannot make assumptions about the underlying type—only that it conforms to the declared protocol.

For example, if we try to return multiple different types, we’ll get a compiler error:

func shape() -> some Shape {
    if someCondition {
        return Circle()
    } else {
        return Square() // Error: Return type must be the same
    }
}

To resolve this, both branches of the function must return the same concrete type.

Supporting universal links in a SwiftUI application

Sun, 24 Nov 2024 23:00:00 GMT

Universal Links allow iOS apps to open specific pages in response to standard web URLs. When users tap a universal link, they are redirected to a specific part of an iOS application if installed. If the app is not installed, the link opens in a browser, allowing the connected website to handle it.

In this article, we'll explore how to set up Universal Links in a SwiftUI application. We’ll go through the configuration steps required on the web and within Xcode, as well as how to handle Universal Link navigation in SwiftUI.

Let's jump in.

To support universal links, the following steps are required:

Creating and configuring an Apple App Site Association (AASA) file.
Adding the AASA file to the related website.
Adding an associated domains entitlement to the iOS app.
Implement code to handle Universal Links in the app.
Test the universal links implementation.

Let’s dive into each step in detail.

1. Creating and configuring an Apple App Site Association (AASA) file

The Apple App Site Association file is a file called apple-app-site-association without an extension in JSON format. Let's look at an example for universal links support:

{
   "applinks":{
      "details":[
         {
            "appIDs":[
               "APPIDPREFIX.com.tanaschita.exampleApp"
            ],
            "components":[
               {
                   "/": "birds",
               },
               {
                   "?": "status",
               }
            ]
         }
      ]
   }
}

In this file:

appIDs specifies which app can handle the links, in the format <YOUR_TEAM_ID>.<bundleID>.
components specifies URL patterns that the app can handle.

In the example, the app will handle any URL that matches the /birds path and uses a query with status as a key, for example:

https://example.com/birds?status=active

If no path or pattern is specified, it defaults to *, matching all URLs under the domain.

2. Adding the AASA file to the related website

The apple-app-site-association file should be hosted at:

https://yourdomain.com/.well-known/apple-app-site-association

Make sure the file is accessible without any redirects, as iOS will attempt to download it directly from this location.

3. Adding an associated domains entitlement to the iOS app

In Xcode, open your project’s target settings.
Under the Signing & Capabilities tab, click the + Capability button.
Add the Associated Domains capability.

In the Associated Domains section, we can add the domains configured in the AASA file. The format is applinks:yourdomain.com. For example:

applinks:example.com

This tells iOS that our app can handle Universal Links for https://example.com.

Note: To enable the Associated Domains entitlement, our app must be signed with a provisioning profile that supports this capability. A paid Apple Developer Program membership is required to configure entitlements and provisioning profiles.

4. Implement code to handle Universal Links in the app.

SwiftUI provides the onOpenURL method which is called when a user taps on a universal link our app supports.

Here’s how to set up .onOpenURL in a SwiftUI view:

ContentView()
.onOpenURL { url in
    // change state based on the provided URL
}

The url parameter provides access to the URL’s components, including path and query, enabling us to navigate to the appropriate screen within the app based on the link.

To implement routing, check out this article on how to use NavigationPath for routing in SwiftUI.

5. Testing universal links

Universal Links only work on a physical device, not the simulator. To test a universal link, we can save it another app, for example in a notes app, and tap on it from there to check if the app opens and routes as planned.

How to use a Connectable publisher in Combine

Sun, 17 Nov 2024 23:00:00 GMT

When working with publishers in Combine, there are situations where we need precise control over when values start emitting. By default, Combine publishers begin emitting as soon as they are created, which can lead to subscribers missing some values if they aren't connected in time.

This is where Combine’s ConnectablePublisher comes in. A ConnectablePublisher holds off emitting values until its connect() method is called, giving us more control over when subscribers start receiving values.

Let's look at an example.

let publisher = Just(5)

subscriber1 = publisher.sink { newValue in
    print(newValue)
}

DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
    self.subscriber2 = publisher.sink { newValue in
        print(newValue)
    }
}

Here, subscriber2 misses the emitted value 5 because the Just publisher emits it immediately, and subscriber2 subscribes too late.

Solving the issue with `ConnectablePublisher`

To ensure both subscribers receive the value, we can convert the publisher to a ConnectablePublisher by calling makeConnectable() and controlling when it starts emitting values using the connect() method:

let publisher = Just(5).makeConnectable()

subscriber1 = publisher.sink { newValue in
    print(newValue)
}

DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
    self.subscriber2 = publisher.sink { newValue in
        print(newValue)
    }
    self.connection = publisher.connect()
}

Now, the publisher will only emit the value after connect() is called, ensuring both subscribers receive the value.

How to automatically connect with first subscriber

If we want a ConnectablePublisher to start emitting values right after the first subscriber subscribes, it provides the autoconnect() method.

self.timerSubscriber = Timer.publish(every: 5, on: .main, in: .default)
    .autoconnect()
    .sink() { date in
        print (date)
    }

In the example above, the publish method of Timer returns a ConnectablePublisher. By calling autoconnect() the timer starts sending date values as soon as we subscribe.

How to identify data in Lists and ForEach in SwiftUI

Sun, 10 Nov 2024 23:00:00 GMT

In SwiftUI, creating dynamic and responsive views often involves generating content from collections of data using List and ForEach.

To efficiently manage these dynamic views, SwiftUI needs a reliable way to identify each item in the collection. When the data is uniquely identifiable, SwiftUI can easily track changes, remove items, and insert new views. This is where the Identifiable protocol and the \.self key path come into play.

In this article, we’ll explore how to use Identifiable to provide unique identifiers for custom data types and when to rely on \.self to identify simple types like strings.

Using the `Identifiable` protocol for custom types

For custom data types, the simplest way to give SwiftUI a unique identifier is to make your data model conform to the Identifiable protocol. The protocol requires a single property id, which must be unique for each instance of the type.

Here’s an example:

struct Book: Identifiable {
    let id = UUID()  // Unique identifier
    let title: String
    let author: String
}

List(books) { book in
    VStack {
        Text(book.title)
        Text(book.author)
    }
}

In this case, Book conforms to Identifiable by providing a unique id property (a UUID in this case). SwiftUI can now easily track and identify each Book in the list by referencing the id property, making the UI updates efficient and reliable.

Using `\.self` for simple data types

But what if we’re working with a collection of types like String, Int, or Double, which don’t inherently conform to Identifiable? In these cases, we can tell SwiftUI to use the entire value as the identifier by using the \.self key path.

Here's an example using an array of strings:

let fruits = ["Apple", "Banana", "Cherry"]

ForEach(fruits, id: \.self) { fruit in
    Text(fruit)
}

By specifying id: \.self, we are telling SwiftUI that each String in the fruits array is unique based on its value. SwiftUI will treat each string as a unique identifier, allowing the framework to correctly manage the views corresponding to each fruit.

Using \.self works well for simple types, but the values must be unique. If two items in the collection have the same value, SwiftUI will get confused, potentially causing issues.

A reliable way to ensure uniqueness is to wrap each item in a struct that includes a unique id, like a UUID. This approach not only prevents rendering issues but also improves the stability of your SwiftUI views, as each item is uniquely identifiable, even if the values themselves are duplicated. Wrapping simple values also makes it easier to add additional properties in the future if needed.

Dynamic colors in SwiftUI

Sun, 03 Nov 2024 23:00:00 GMT

Dynamic colors allow our iOS app to automatically adapt its color scheme based on user preferences, such as light and dark mode.

In this article, we will explore how to implement dynamic colors in SwiftUI using both asset catalogs and programmatic approaches.

Using the asset catalog for dynamic colors

One way to define dynamic colors in SwiftUI is through the asset catalog. This allows us to specify different colors for light and dark modes without writing any additional code. Here's how to do it:

Open the Asset Catalog by opening the Assets.xcassets file in your iOS project.
Create a new color set by using the + button.
Configure the color set by opening the Attributes Inspector and select Any, Dark in the Appearances dialog. This will allow us to define colors for both light and dark modes.

Once we've defined the colors, we can use them in our SwiftUI views like this:

Text(book.name)
    .foregroundColor(Color(named: "primary"))

This code uses the color named "primary" from the asset catalog, which automatically adapts to the current user interface style.

Programmatically defining dynamic colors

To achieve the same results programmatically, we can make use of the UIColor type and its dynamic color capabilities. Here’s how we can create a utility function for dynamic colors:

extension UIColor {
    static func dynamicColor(light: UIColor, dark: UIColor) -> UIColor {
        return UIColor { traitCollection in
            return traitCollection.userInterfaceStyle == .dark ? dark : light
        }
    }
}

We can then use it to define dynamic colors programmatically:

struct ColorScheme {

    var primary: Color {
        return color(light: UIColor(red: 0.7, green: 0.1, blue: 0.1, alpha: 1),
                     dark: UIColor(red: 0.9, green: 0.1, blue: 0.1, alpha: 1))
    }

    private func color(light: UIColor, dark: UIColor) -> Color {
        return Color(UIColor.dynamicColor(light: light, dark: dark))
    }
}

SwiftUI's Color class itself does not provide the trait collection initializer, but as we can see above, we can simply convert the UIKit's UIColor to SwiftUI's Color type.

Now, we can use the created color scheme in our SwiftUI views.

.foregroundColor(colorScheme.primary)

Understanding actors in Swift

Sun, 27 Oct 2024 23:00:00 GMT

Concurrency is a complex problem when writing software, especially when dealing with shared mutable state across different threads. With Swift's move toward structured concurrency, actors are a powerful feature introduced to make it easier to write safe and efficient concurrent code.

In this article, we'll dive into what actors are, how they differ from other types in Swift, and how they can help you avoid data races in concurrent environments.

How do Swift actors prevent data races?

A data race occurs when multiple threads access shared mutable data concurrently, and at least one thread modifies the data. This leads to unpredictable results, bugs, and crashes.

Swift's actors prevent data races through actor isolation, which ensures:

Only one task can access or modify an actor’s mutable state at any given time.
Synchronous access to an actor's mutable state from outside is prohibited.
Direct modification of an actor's mutable state from outside is not allowed.

By using actors, Swift guarantees that shared mutable data is safely managed in a concurrent environment, reducing the risk of data races.

Defining an actor

Actors are represented by a reference type called actor:

actor Shop {
    let id = "abc"
    var itemsCount = 10

    func purchase() {
        itemsCount-=1
    }
}

In this example, Shop is an actor that holds a mutable state itemsCount. The actor ensures that only one task can modify itemsCount at a time. This is the core advantage of actors over classes when it comes to handling concurrent operations.

Using async/await to access data from an actor

To interact with an actor's properties or methods from outside, we need to use async/await, marking any potential suspension points with await. Only immutable data, such as constants (id in this case), can be accessed synchronously.

let shop = Shop()

print(shop.id) // Synchronous access to immutable property

Task {
    await shop.purchase() // Asynchronous call to modify mutable state
    let count = await shop.itemsCount // Asynchronous access to mutable state
}

Even though we didn't explicitly mark purchase as an async function, we still need to use await when calling it because it interacts with the actor's mutable state. If some other task has already called purchase, our purchase() call would suspend and wait for the other one to finish.

This is part of actor isolation, which ensures that only asynchronous access to an actor's mutable state is allowed from outside.

Actor isolation

Actor isolation is the principle that protects an actor's internal state. So when accessing the data of an actor, the following rules apply:

Synchronous access to an actor's mutable state from the outside is not allowed.
Asynchronous access via await is required for mutable state.
Reading immutable properties (constants) from the outside can be done synchronously.
Internal access (within the actor’s methods) can happen synchronously.

These guarantees ensure that concurrent access to shared data is controlled and safe and are known as actor isolation.

Actor's non-isolated declarations

There may be cases where we want to allow synchronous access to certain methods or properties of an actor. For this, Swift provides the nonisolated keyword, which allows a method or property to bypass actor isolation.

actor Shop {
    let id = "abc"

    nonisolated func log(message: String) {
        print("\(id): \(message)")
    }
}

In this example, the log method is declared nonisolated, allowing it to be called synchronously from outside the actor without await. Inside the nonisolated method, we are only allowed to use nonisolated properties (constants) and methods.

Handling thread safety with Sendable types

In Swift, actors are designed to protect their internal state from concurrent access, but we still need to be careful when passing data in and out of an actor. This is where the Sendable protocol comes into play. Sendable ensures that any type used in a concurrent environment is thread-safe, meaning it can safely be shared across different tasks without causing data races.

So far, we have only used value types String or Int when working with actors. By default, Swift's value types like Int and String are Sendable, but when working with custom types, it's important to ensure that they conform to Sendable.

To check the thread safety of a type we can use the Sendable protocol:

actor Shop {
    var owner: Owner
}

struct Owner: Sendable {
    var name: String
}

Mutable classes are not thread safe:

class Owner: Sendable { // compiler error: Non-final class 'Owner' cannot conform to Sendable
    var name: String
}

Since mutable classes are not thread safe we get a compiler error. To avoid this, we should either mark immutable classes as final or prefer using structs, which are value types and inherently thread-safe.

Actor reentrancy

One unique feature of Swift actors is reentrancy. When an actor is suspended awaiting an async call, it can process other tasks in its queue. This improves efficiency but can lead to unexpected behavior if we’re not careful, as an actor’s state may change between async calls. Swift automatically manages reentrancy, but it’s important to be aware of this behavior when working with actors.

Extending optionals in Swift

Sun, 20 Oct 2024 22:00:00 GMT

Optionals in Swift are a powerful feature that allows us to express the absence of a value. In this article, we'll look at how to extend optionals.

Let's jump in.

Optionals under the hood

Under the hood, an optional is simply an enumeration with two cases:

enum Optional<Wrapped> {
    /// The absence of a value.
    case none

    /// The presence of a value, stored as `Wrapped`.
    case some(Wrapped)
}

Since an optional is just another type in Swift, it can be extended in the same way we can extend any other type. This allows us to add custom properties or methods to optionals, enhancing their functionality.

Let's look at how to do that.

Example: Extending an Optional String

Let's say we frequently work with optional String values and want to check if they are either nil or empty. We can achieve this by extending the Optional type specifically when Wrapped is a String:

extension Optional where Wrapped == String {
    var isNilOrEmpty: Bool {
        return self?.isEmpty ?? true
    }
}

In the example above, we are extending an optional String by adding where Wrapped == String to our extension.

Now, we can use the new computed property isNilOrEmpty on every optional String as follows:

var name: String?

if name.isNilOrEmpty {
}

How to call async/await functions in SwiftUI

Sun, 13 Oct 2024 22:00:00 GMT

In this article, we’ll explore different approaches to calling async/await functions in SwiftUI using tasks and view modifiers. Let's jump in.

Depending on the situation, we can call asynchronous functions in SwiftUI at various points, such as:

When a SwiftUI view appears on the screen.
In response to a user interaction like a button tap.
When performing gestures, like pulling to refresh content.

Let's look at each scenario.

Calling async functions when a SwiftUI view appears

When we need to trigger an asynchronous operation as soon as a SwiftUI view appears, the task modifier is ideal. This modifier allows us to create a task when the view is presented and automatically cancels it if the view disappears.

var body: some View {
    Text(viewModel.status)
        .task {
            await viewModel.refreshStatus()
        }
}

In this example, the task starts immediately when the Text view appears. SwiftUI ensures that if the view is removed, the task is canceled.

Calling async functions in response to user actions

In situations where an async task is triggered by a user action (like pressing a button), we can leverage the Task type to perform the asynchronous work within the button’s action handler.

Button("refresh status") {
    Task {
        await viewModel.refreshStatus()
    }
}

Here, when the user taps the button, a new task is created, and the refreshStatus() async function is called. This approach keeps the button's action handler non-blocking, allowing the app to remain responsive during the async work.

Using the `refreshable` modifier for pull-to-refresh

SwiftUI also provides the refreshable modifier, which simplifies handling the common pull-to-refresh gesture.

List {
    // List items
}
.refreshable {
    await viewModel.refreshMessages()
}

This modifier takes an async closure and runs it when the user performs the refresh gesture.

Understanding localization with LocalizedStringKey in SwiftUI

Sun, 06 Oct 2024 22:00:00 GMT

Working with localized strings in SwiftUI can sometimes be confusing due to the variety of available approaches using LocalizedStringKey or NSLocalizedString. Here are some examples of valid ways to use localized strings in SwiftUI:

Text("hello.world")
Text(LocalizedStringKey("hello.world"))
Text(NSLocalizedString("hello.world", comment: ""))
Text(String(format: NSLocalizedString("hello", comment: ""), name))

Let's dive deeper into these approaches and understand how they work and what their differences are.

SwiftUI's LocalizedStringKey type

LocalizedStringKey is a type that SwiftUI uses to handle localized strings. It interprets keys from the app's .strings or .xcstrings files and replaces them with their localized equivalents at runtime.

When we pass a string literal into a SwiftUI view like Text or Button, SwiftUI automatically converts it into a LocalizedStringKey:

Text("hello.world") // Interpreted as LocalizedStringKey at compile-time

While SwiftUI infers LocalizedStringKey from string literals, we can also explicitly use the type in code:

Text(LocalizedStringKey("hello.world")) // Explicitly using LocalizedStringKey

This can be helpful when passing strings dynamically, as SwiftUI only treats string literals as LocalizedStringKey. For instance, if we pass a string variable to a Text view, SwiftUI will not interpret it as a key, but as plain text.

One significant limitation of LocalizedStringKey in SwiftUI is its inability to handle formatted strings that include dynamic content. For instance, consider the localized key pair:

"hello" = "Hello %@";

In this case, we must revert to using NSLocalizedString, which allows for proper string formatting and parameterization.

Using NSLocalizedString

If we need more control over localization such as runtime flexibility or string formatting, we can use the Foundation API NSLocalizedString. This function retrieves a localized String from the app's localization files.

Text(NSLocalizedString("hello.world", comment: ""))

For strings that require parameters or formatting, NSLocalizedString works well:

Text(String(format: NSLocalizedString("hello", comment: ""), name))

To streamline localization with NSLocalizedString, we can add an extension to the String type:

extension String {
    var localized: String {
        return NSLocalizedString(self, comment: "")
    }

    func localized(_ args: CVarArg...) -> String {
        let localizedString = NSLocalizedString(self, comment: "")
        return String(format: localizedString, arguments: args)
    }
}

With this extension, we can simplify our localized string handling as follows:

Text("hello.world".localized)
Text("hello".localized(name))

Getting started with async/await in Swift

Sun, 29 Sep 2024 22:00:00 GMT

Swift's async/await syntax provides a clean and efficient way to handle asynchronous tasks. The async/await syntax is designed to make asynchronous code look and behave more like synchronous code. It allows us to write code that is both easy to understand and free of so-called callback hell.

In this guide, we’ll explore the fundamentals of async/await, see how it compares to traditional callback-based methods, and walk through practical examples.

Let's jump in.

The callback solution

Before async/await, handling asynchronous tasks often involved using completion handlers. This method requires nesting callbacks, which can quickly become unwieldy:

func fetchUserData(userId: String, completion: @escaping (Result<User, Error>) -> Void) {
    networkRequest(for: userId) { result in
        switch result {
        case .success(let data):
            parseUserData(data) { parseResult in
                switch parseResult {
                case .success(let user):
                    completion(.success(user))
                case .failure(let error):
                    completion(.failure(error))
                }
            }
        case .failure(let error):
            completion(.failure(error))
        }
    }
}

This approach, while functional, can lead to deeply nested code and make error handling more complex. Async/await provides a cleaner and more readable alternative.

The async/await solution

Using async/await, the same functionality can be implemented with significantly less code:

func fetchUserData(userId: String) async throws -> User {
    let data = try await networkRequest(for: userId)
    let user = try await parseUserData(data)
    return user
}

With async/await, the nested callbacks are replaced by a straightforward sequence of await calls. It also improved safety, as it is now guaranteed to return a result, whereas a completion handler is not guaranteed to be called.

The async/await syntax

Here's a breakdown of the async/await syntax:

Declaring async functions: Use the async keyword to declare a function that performs asynchronous work.

func fetchData() async -> Data {
}

Handling errors: If the function can throw errors, add the throws keyword.

func fetchData() async throws -> Data {
}

Calling async functions: Use await to call asynchronous functions and wait for their results.

let data = await fetchData()

Calling async throwing functions: Use await with do catch blocks.

do {
    let data = try await fetchData()
} catch let error {
    print(error)
}

Leveraging built-in async functions

Many of Swift’s standard library functions support async/await. For example URLSession comes with async functions for network requests:

let (data, response) = try await URLSession.shared.data(from: imageURL)

Creating async functions with continuations

For integrating with APIs that use completion handlers, Swift provides continuations to bridge the gap:

func fibonacciSequence(count: Int) async -> [Int] {

    return await withCheckedContinuation({ continuation in
        fibonacciSequence(count: count) { result in
            continuation.resume(returning: result)
        }
    })
}

In the above example, we use an existing completion handler function to wrap it in an async function. As soon as we call withCheckedContinuation(function:_:), the function suspends.

Continuations must be resumed exactly once on every path. The compiler produces an error if we forget to resume or call resume multiple times.

If the function needs to throw an error, we can use withCheckedThrowingContinuation(function:_:) instead.

Understanding Substring and String indices in Swift

Sun, 22 Sep 2024 22:00:00 GMT

Representing text values, Strings are one of the most common data structures we use when coding. In Swift, working with strings can be more complex than it first appears due to its unique handling of indices and substrings.

In this article, we will learn how to work with Swift's String type and its companions Character, Index and Substring.

Let's jump in.

Swift's String type is essentially a collection of characters represented by the Character type. Like other collections, strings can be iterated over:

for character in "hello 🐌" {
      print(character) // prints "h", "e", "l", "l", "o", "🐌"
}

Every Character represents a human-readable character which can include multiple Unicode characters. Unicode is a standard for encoding text, allowing representation of nearly any character from any language.

let emoji: String = "🐌"
emoji.count // returns 1
emoji.utf8.count // returns 4

The example shows that the number of Swift characters and UTF-8 bytes may differ.

String indices & substrings

Unlike languages that allow integer-based indexing such as string[0], Swift requires us to use String.Index to work with positions in a string. This is due to Swift’s Unicode-compliant string handling, where characters might consist of multiple Unicode code points and bytes.

The String.Index type represents the position of each Character in a String. Each string comes with a startIndex and an endIndex. Using those we can derive any other index as follows:

let hello = "hello world"
let index = hello.index(hello.startIndex, offsetBy: 6) // index with an offset of 6 characters

hello[index] // returns Character w
hello.prefix(upTo: index) // returns Substring "hello "

The above prefix(upTo:) method returns a Substring and not a String. This is because substrings share memory with the original string, making them more efficient.

To simplify index usage, we can create extensions to abstract implementation details. For example, here’s an extension for the prefix method:

extension String {
    func prefix(upTo: Int) -> String {
        let toIndex = self.index(startIndex, offsetBy: upTo)
        return String(self[..<toIndex])
    }
}

The extension allows us to directly use an Int type instead of Index. We can now call hello.prefix(upTo: 5) to get a prefix of the string.

How to set up and use Core Data with SwiftUI

Sun, 15 Sep 2024 22:00:00 GMT

With SwiftData, Apple introduced a new state-of-the-art persistence framework for iOS. However, Core Data remains a powerful and essential framework for managing complex data structures in many iOS projects.

This guide will walk you through the fundamentals of integrating Core Data with SwiftUI.

Let's jump in.

The Core Data Stack

Before we jump into the example, let's recap the most important aspects about Core Data. The Core Data stack consists of:

NSManagedObjectModel: Represents our model objects, referred to as entities.
NSPersistentStoreCoordinator: Manages the underlying database.
NSManagedObjectContext: Allows us to create, read, update, and delete entities.
NSPersistentContainer: Provides a way to set up the entire Core Data stack.

Basic Core Data Setup with SwiftUI

The easiest way to set up Core Data with SwiftUI is by creating a new project and selecting the Core Data option as the storage method in the project creation dialog.

After doing this, Xcode automatically generates a basic Core Data configuration for us. This setup includes using the NSPersistentContainer to initialize the Core Data stack and inject it into the root SwiftUI view, as shown below:

@main
struct ExampleApp: App {
    let persistenceController = PersistenceController.shared

    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(\.managedObjectContext, persistenceController.container.viewContext)
        }
    }
}

This code injects the managedObjectContext into the ContentView, allowing the view to interact with the Core Data stack:

struct ContentView: View {
    @Environment(\.managedObjectContext) private var viewContext
    // ...
}

The example project also includes an AppName.xcdatamodeld file where we define our data model. This file is where we create and manage our data objects, their properties, and relationships.

Fetching data

To request items from the Core Data store, SwiftUI provides a FetchRequest property wrapper.

struct ContentView: View {
    @Environment(\.managedObjectContext) private var viewContext

    @FetchRequest(
        sortDescriptors: [NSSortDescriptor(keyPath: \Item.timestamp, ascending: true)],
        animation: .default)
    private var items: FetchedResults<Item>

    var body: some View {
        List {
            ForEach(items) { item in
                Text("Item at \(item.timestamp, formatter: itemFormatter)")
            }
        }

    }
}

As we can see above, ContentView has an items property that holds the results of the FetchRequest. The List view is automatically updated whenever an item is added, deleted, or modified.

For a deeper dive into fetch requests, check out @FetchRequest property wrapper in SwiftUI.

Adding new items

To add new items to the Core Data store, we can also use the managed object context:

private func addItem() {
    let newItem = Item(context: viewContext)
    newItem.timestamp = Date()

    do {
        try viewContext.save()
    } catch {
        // Error handling
    }
}

It initializes a new Item entity, sets its attributes and calls save() on the managed object context. The addItem can be called by any SwiftUI view, for example:

Button(action: addItem) {
    Label("Add Item", systemImage: "plus")
}

Deleting items

Deleting items works similar to adding items. Here is an example of using the onDelete modifier of a SwiftUI List view:

List {
    ForEach(items) { item in
        Text("Item at \(item.timestamp!, formatter: itemFormatter)")
    }
    .onDelete(perform: deleteItems)
}

private func deleteItems(offsets: IndexSet) {
    let itemsToDelete = offsets.map { items[$0] }
    itemsToDelete.forEach { viewContext.delete($0) }

    do {
        try viewContext.save()
    } catch {
        // handle error
    }
}

It is called whenever an item is swipe-deleted from the List view. SwiftUI provides a set of indices to the closure, which are used to delete the corresponding items.

Introduction to supporting VoiceOver in SwiftUI

Sun, 08 Sep 2024 22:00:00 GMT

Making an app accessible is crucial for ensuring that all users, including those with disabilities, can enjoy a seamless experience. For instance, users who rely on assistive technologies like VoiceOver should be able to interact with our apps without needing to see the screen.

SwiftUI simplifies the process of adding accessibility to our apps by automatically setting accessibility labels and values for standard views like navigation views, lists, text fields, sliders, and buttons. However, there are scenarios where additional work is needed to enhance the user experience, particularly when using custom views, images, or image-only buttons.

Let's dive into a practical example.

Finding VoiceOver issues

The first step in improving accessibility is to identify potential VoiceOver issues. We can do this by either activating VoiceOver on our device or by using Xcode’s Accessibility Inspector.

To open the Accessibility Inspector, select Xcode > Open Developer Tool > Accessibility Inspector in Xcode's menu.

The Accessibility Inspector allows us to navigate through different view elements and listen to how VoiceOver reads them. This helps us assess whether the accessibility values are providing a good user experience.

While the Accessibility Inspector is a useful development tool, it doesn’t replace the need to test accessibility features with VoiceOver on an actual device. To learn how to use VoiceOver, check out this guide on VoiceOver gestures for iOS.

Example: Improving accessibility of an image-only button

When using buttons with titles, SwiftUI automatically assigns appropriate accessibility values.

Button("Cancel", action: {
    // Cancel button action
})

In this example, VoiceOver will correctly read Cancel Button to the user, requiring no further action on our part.

However, the situation changes when using image-only buttons. SwiftUI will still recognize the element as a button, but without an appropriate label, VoiceOver will only announce Button which is unhelpful for users who cannot see the image.

To address this, we can use the accessibilityLabel(_:) modifier to provide a descriptive label for the button:

Button("", action: {
    // Favorites button action
})
.buttonStyle(ImageButtonStyle(systemImage: "heart"))
.accessibilityLabel("Favorites")

With this label in place, VoiceOver will now read Favorites Button offering much clearer guidance to the user.

Besides accessibilityLabel(_:), SwiftUI provides other accessibility modifiers to improve accessibility.

Example: Improving accessibility when using `onTapGesture`

When using onTapGesture in SwiftUI, the view doesn't automatically gain accessibility traits, which can make it invisible to VoiceOver users. To ensure accessibility, we need to add appropriate labels and traits.

Consider an example where an image triggers an action when tapped:

Image(systemName: "heart")
    .onTapGesture {
        favoriteItem()
    }

In its current form, VoiceOver users won't know this image is interactive. We can improve accessibility by adding a label and traits:

Image(systemName: "star")
    .onTapGesture {
        favoriteItem()
    }
    .accessibilityLabel("Favorite")
    .accessibilityAddTraits(.isButton)

Example: Improving accessibility by combining views to one accessibility element

Sometimes, multiple views on the screen represent a single piece of information or an action. For example, a label and an icon together might indicate the same function. By default, VoiceOver will read each view separately, which can be confusing. To improve accessibility, we can combine these views into one accessibility element.

Consider this example with a text label and an image:

HStack {
    Image(systemName: "heart")
    Text("Favorite")
}

By default, VoiceOver will read "Star" and "Favorite" separately. We can improve this by combining them into a single accessible element:

HStack {
    Image(systemName: "star")
    Text("Favorite")
}
.accessibilityElement(children: .combine)
.accessibilityLabel("Favorite")

Commonly used accessibility modifiers

To summarize, here is a list of the commonly used accessibility modifiers:

accessibilityLabel(_:) to describe the contents of a view.
accessibilityValue(_:) to describe the value that the view contains, if it is different from the view's accessibility label.
accessibilityHint(_:) to describe what happens after performing the view’s action.
accessibilityAction(_:_:) to add a custom accessibility action to the view.
accessibilityAddTraits(_:) to add a trait like .isButton or .isSearchField to the view.
accessibilityRemoveTraits(_:) to remove a trait from the view.
accessibilityHidden(_:) to specify whether to hide the view from accessibility features.
accessibilityElement(children:) to create a new accessibility element and influence its child views behaviour, for example to combine multiple views into one accessibility element.

Cheat sheet on VoiceOver gestures for iOS

Sat, 07 Sep 2024 22:00:00 GMT

As we established in this VoiceOver guide for SwiftUI, the Accessibility Inspector is really helpful during development, but doesn't replace testing accessibility with VoiceOver on a real device.

When VoiceOver is enabled, standard gestures behave differently, and additional gestures allow us to navigate the app and interact with elements.

Activating the VoiceOver shortcut

We can activate VoiceOver through Settings > Accessibility > VoiceOver. To be able to quickly toggle VoiceOver on and off, we can set up a shortcut on our iOS device by navigating to Settings > Accessibility > Accessibility Shortcut > VoiceOver.

To be able to quickly switch VoiceOver on and off, we can activate a shortcut on the iOS device by selecting Settings > Accessibility > Accessibility Shortcut > VoiceOver.

Now, we can triple-click the side button to switch VoiceOver on and off. This is especially handy when we need to test specific parts of the app without keeping VoiceOver on constantly.

Frequently used VoiceOver gestures

Once VoiceOver is activated, the following gestures are helpfull to navigate and interact with the app:

Drag the finger over the screen to explore items. VoiceOver will announce each touched item.
Tap or touch an item to select it and let VoiceOver name it.
Double tap to activate a selected item.
Swipe right or left to select the next or previous item.
Two-finger tap to pause or resume speech.
Two-finger swipe up or down to let VoiceOver read the entire screen from the top or from the selected item.
Three-finger swipe down, up, right or left to scroll.

These gestures are sufficient for testing most app features. For more advanced interactions, refer to Apple's official VoiceOver gestures guide.

Swift optionals cheat sheet

Sun, 01 Sep 2024 22:00:00 GMT

Swift's optionals are a powerful and fundamental feature that allows developers to write expressive, safe code by handling the absence of values gracefully. Understanding how to work with optionals — especially concepts like forced unwrapping, optional binding, and implicit optionals — is essential when developing with Swift.

This cheat sheet covers different scenarios about Swift optionals, including optional binding, forced unwrapping, nil coalescing and more.

Let's dive in.

1. Declaring Optionals

An Optional can hold either a value or nil. Optionals are declared using a question mark ?:

var name: String? = "Lea"
var age: Int? = nil

2. Forced Unwrapping

When using an exclamation mark !, we can forcibly unwrap an optional. Forced unwrapping leads to runtime crashes if the value is nil.

let name = user.name! // Crashes if user.name is nil

3. Optional Binding

Optional binding safely unwraps an optional. If the optional contains a value, it is assigned to a new constant or variable.

if let name = user.name {
    print(name)
} else {
    print("optionalString is nil")
}

When unwrapping an optional we can also use a concise version without declaring a new variable:

var greeting: String?

if let greeting {
    print(greeting)
}

For multiple optionals:

if let name = user.name, let age = user.age {
    print("Both have values")
} else {
    print("One or both are nil")
}

4. Guard Statement

guard is used to unwrap optionals, ensuring that a value is present before continuing. It's particularly useful in functions.

func greet(user: User) {
    guard let name = user.name else { return }
    // Use name
}

5. Nil Coalescing Operator

The nil coalescing operator ?? provides a default value if the optional is nil.

let note = input ?? ""

6. Implicitly Unwrapped Optionals

Implicitly unwrapped optionals automatically unwrap when accessed but will crash if nil. They are declared using an exclamation mark ! after the type.

var greeting: String! = "Hello"
print(greeting) // No need to unwrap, but will crash if nil

7. Optional Chaining

Optional chaining allows us to call properties, methods, and subscripts on an optional that might be nil. The whole chain fails gracefully if any link is nil.

let street = user?.address?.street // Returns an optional String, nil if user or address is nil

9. Comparing Optionals

Optionals can be compared using == and !=. Two optionals are equal if both are nil or both contain the same value.

if optionalString == "Hello" {
    print("It's a match!")
}

10. Optional Collections

You can have collections of optionals, allowing elements to be nil.

let ages: [Int?] = [25, nil, 47]

11. Optional Types with switch

We can also handle optionals with a switch statement:

switch name {
    case .some(let value):
        print("name is \(value)")
    case .none:
        print("name is nil")
}

12. Optionals under the hood

To understand the above switch statement better, the implementation of an optional.

enum Optional<Wrapped>: ExpressibleByNilLiteral {
    /// The absence of a value.
    case none

    /// The presence of a value, stored as `Wrapped`.
    case some(Wrapped)

}

When we look at the implementation of an optional, it is just an enum of two cases.

But wait. Why are we writing Int? and not Optional<Int>? Or why are we using nil and not .none?

In fact, we can do both. Both ways do the same. The second one is just syntactic sugar for ease of reading and writing code.

var age: Optional<Int> = .none
// is the same as
var age: Int? = nil

age = .some(5)
// is the same as
age = 5

Understanding container values in SwiftUI

Sun, 25 Aug 2024 22:00:00 GMT

In the last article on building custom containers in SwiftUI, we explored the fundamentals of creating reusable containers in SwiftUI.

Now, we'll take it a step further by adding dynamic customization to container content using container values.

Let's dive in.

Recap: Basic custom container

To start, let’s quickly recap a basic custom container that adds a background to each subview:

import SwiftUI

struct CustomContainer<Content: View>: View {
    @ViewBuilder var content: Content

    var body: some View {
        VStack {
            ForEach(subviewOf: content) { subview in
                subview
                    .background(.gray)
            }
        }
    }
}

Introducing dynamic content customization

Suppose we want to be able to dynamically customize individual subviews within the container, such as highlighting specific views:

CustomContainer {
    Text(...)
        .highlight(true)
    Image(...)
    ...
}

To enable this behavior, the custom container needs to be aware of which content views have called the highlight modifier. This is where container values come into play.

Defining a new container value

Container values use keyed storage similar to environment values or preferences but with a key distinction: container values can only be accessed by their direct parent container.

To define a new container value, we can use the @Entry property wrapper:

extension ContainerValues {
    @Entry var isHighlighted: Bool = false
}

Here, we define isHighlighted as a new container value with a default value of false.

Additionally, we can create a convenient extension to set this property:

extension View {
    func highlight(_ value: Bool) →> some View {
        containerValue(\.isHighlighted, value)
    }
}

Accessing container values

Within our custom container, we can access this value to apply conditional styling:

ForEach(subviewOf: content) { subview in
    subview
        .background(subview.containerValues.isHighlighted ? .green : .gray)
}

In this example, any subview that has the highlight(true) modifier applied will have a green background, while others will retain the default gray background.

How to call async/await functions concurrently in Swift

Sun, 18 Aug 2024 22:00:00 GMT

In Swift, when we call an asynchronous function using await, the function runs sequentially — meaning that each line of code waits for the previous one to complete before proceeding.

However, there are situations where we might want to run multiple asynchronous functions in parallel, especially when these functions don't depend on each other. This is where tasks come into play.

Lets dive in and see how to do that.

Executing asynchronous functions concurrently with tasks

Tasks work hand in hand with Swift's async/await functionality. Each task runs concurrently, allowing us to execute asynchronous functions in parallel.

To create a task, we can use the async-let binding. Here is how it looks in practice:

Sequential binding:

let profileImage = await someAsyncFunc()
let headerImage = await someAsyncFunc()

In this sequential example, profileImage is fetched first, and only after it completes, the headerImage fetch begins.

Concurrent binding:

async let profileImageTask = await someAsyncFunc()
async let headerImageTask = await someAsyncFunc()

let profileImage = await profileImageTask
let headerImage = await headerImageTask

With the concurrent binding approach, we created two child tasks that start independently without waiting for the previous one to complete.

Group tasks

Additionally to async-let tasks, Swift provides group tasks which are ideal for handling a dynamic number of concurrent tasks.

Group tasks are particularly useful when we don’t know the exact number of tasks beforehand, such as when downloading images from a list of URLs.

Here’s how we can use group tasks to download images concurrently:

func downloadImages(imageURLs: [URL]) async throws -> [UIImage] {
    var results: [UIImage] = []
    try await withThrowingTaskGroup(of: (Data, URLResponse).self, body: { taskGroup in
        for imageURL in imageURLs {
            taskGroup.async { try await URLSession.shared.data(from: imageURL) }
        }
        while let data = try await taskGroup.next(), let image = UIImage(data: data.0) {
            results.append(image)
        }
    })
    return results
}

Downloading multiple images concurrently can drastically reduce the total time taken compared to downloading them sequentially. Using group tasks, we can achieve this concurrency in a clean and structured manner.

Understanding the @FetchRequest property wrapper in SwiftUI

Sun, 18 Aug 2024 22:00:00 GMT

The @FetchRequest property wrapper in SwiftUI simplifies the process of fetching data from a Core Data store for use in a SwiftUI view.

Let's dive in and see how it works.

Basic fetch request

A basic fetch request to fetch a list of Item entities looks as follows:

@FetchRequest(
    sortDescriptors: [])
private var items: FetchedResults<Item>

The @FetchRequest above is applied to the items property of type FetchedResults<Item>. Since FetchedResults conforms to the Collection protocol, we can use it just like an array in a List:

List {
    ForEach(items) { item in
        Text("Item \(item.name)")
    }
}

Filtering and sorting with FetchRequest

The FetchRequest initializer also supports filtering and sorting through its sortDescriptors and predicate parameters. Here’s how we can use them:

@FetchRequest(
    sortDescriptors: [NSSortDescriptor(keyPath: \Item.date, ascending: true)],
    predicate: NSPredicate(format: "name BEGINSWITH %@", "t")
)
private var items: FetchedResults<Item>

This fetch request filters the results to include only items whose names begin with the letter "t" and sorts them by the date attribute in ascending order.

Important Considerations

It’s important to note that both the fetch request and its results rely on the managed object context provided in the environment. Therefore, we must inject a Core Data managed object context into the environment before using @FetchRequest. To learn more about setting up Core Data in SwiftUI, check out our comprehensive guide on integrating Core Data with SwiftUI.

How to create custom reusable container views in SwiftUI

Sun, 11 Aug 2024 22:00:00 GMT

When building iOS apps with SwiftUI, we sometimes need to create a custom reusable container view which can be used as any other SwiftUI container view with any kind of content.

In this article, we'll explore how to create such containers.

Let's dive in.

Understanding the basics of container views in SwiftUI

In SwiftUI, container views are components that encapsulate and manage the layout of their child views, arranging them in a certain way. Common examples include HStack, VStack or List.

When creating custom container views, SwiftUI provides methods to access contained child views, sections or container values which allow a high level of customization.

Creating a simple custom container

Let's start by creating a simple custom container view which adds some styling to the content view.

import SwiftUI

struct CustomContainer<Content: View>: View {
    @ViewBuilder var content: Content

    var body: some View {
        VStack {
            content
        }
        .padding()
        .background(...)
        .cornerRadius(10)
    }
}

In this example, our container takes a closure returning a Content view. The @ViewBuilder attribute allows the closure to return multiple child views:

CustomContainer {
    Text(...)
    Image(...)
    ...
}

Adding custom styling to each subview

SwiftUI allows access to each subview passed into the container, enabling us to apply specific styling to each one. For example:

ForEach(subviewOf: content) { subview in
     subview
        .background(...)

Adding sections

Additionally, SwiftUI gives us access to each Section view and its content that was defined within the container:

ForEach(sectionOf: content) { section in
    VStack {
        Text(section.header)
        section.content
            .background(...)
    }
}

Container values

To add more customization, we can use container values. Container values give us the possibility to configure specific child views. For example:

CustomContainer {
    Text(...)
        .highlight(true)
    Image(...)
    ...
}

Within the container, we can access container values as follows:

ForEach(subviewOf: content) { subview in
    subview
        .background(subview.containerValues.isHighlighted ? .green : .grey)
}

To dive deeper into container values, check out this article on understanding container values in SwiftUI (coming soon).

How to add local Swift Packages to an iOS project

Sun, 04 Aug 2024 22:00:00 GMT

The Swift Package Manager not only supports adding public libraries as Swift Packages, but also local Swift Packages.

This feature is particularly useful, when splitting a project into multiple libraries without having to worry about versioning and being able to directly edit the code.

Let's look at how to do that.

To add a local Swift package to an iOS project, we can follow these steps:

Create a local Swift Package. This step is described in the following article on getting started with Swift Package Manager.
Build the Swift package, for example by hitting Xcode's build action.
Open Xcode's Package Dependencies section in your iOS project and tap the + button.

Use the Add local button to select and add the local library.

When successfully added, the local package will appear alongside any other libraries you have added previously.

Now, you can use the local package in your iOS project just like any public library:

import ExampleSwiftPackage

Note: if you need to edit and rebuild the library, ensure you close the iOS project first.

How to add public libraries as Swift Packages to an iOS project

Sun, 04 Aug 2024 22:00:00 GMT

As we learned in this guide on getting started with the Swift Package Manager for iOS, we can add public libraries to our iOS projects by using the Swift Package Manager.

In this article, we'll look how to add, update and delete remote dependencies in our iOS projects.

Let's get started.

Adding a remote Swift Package

To add a public library which is available on GitHub as a Swift Package requires the following steps:

Copy the documented Swift Package url of the library. (documented in the README of the library if it supports SPM)
In Xcode, tap on the project and open Package Dependencies section. Here, we can use the + button to add a new package.

Decide how the package should be updated, for example up to the next major version, up to the next minor version, in a specified range or restricting it to the current version.

After confirming, Xcode fetches the library automatically. The fetched dependencies are stored in the project’s derived data directory. Xcode also adds it to the Package.resolved file to ensure every developer has the same dependency versions.

Now, we can use the package functionality by importing it as a Swift module in our code files.

import Fakery

Updating or deleting a Swift Package

To update single packages to specific versions or delete them, we can use the same dialog shown above. To update all packages to the latest versions, Xcode provides the menu action File > Swift Packages > Update to Latest Package Versions.

Get started with Swift Package Manager for iOS

Sun, 04 Aug 2024 22:00:00 GMT

Provided by Apple, Swift Package Manager is a dependency manager for Swift projects which is directly integrated into Xcode.

In this article, we'll learn the main concepts of the Swift Package Manager, how to create Swift packages, how to share and use packages across different projects.

Let's jump in.

Main concepts

Swift Packages are reusable components containing resources and code files that can also depend on other packages.

Compiling a package produces a module which can be shared as a public library using services like GitHub or be used as a locale dependency.

The manifest - a file called Package.swift - defines the name of the package, its contents and dependencies. It is placed in the root directory of each package.

Let's see how this manifest file looks like by creating a Swift Package.

Creating a Swift Package

One way to create a new Swift Package is by selecting File > New > Swift Package in Xcode. After entering the name, Xcode generates all necessary files and folders together with the manifest file Package.swift.

// swift-tools-version:6.0

import PackageDescription

let package = Package(
    name: "SnowKit",
    // 1.
    products: [
        .library(
            name: "SnowKit",
            targets: ["SnowKit"]),
    ],
    // 2.
    dependencies: [
    ],
    // 3.
    targets: [
        .target(
            name: "SnowKit",
            dependencies: []),
        .testTarget(
            name: "SnowKitTests",
            dependencies: ["SnowKit"]),
    ]
)

In the products part, we define executables and libraries a package produces.
In the dependencies part, we declare other packages that our package depends on.
In the targets part, we declare targets the package consists of, for example one for our library and one for our tests.

Adding dependencies to the Swift Package

If a package depends on other packages, we can add them in the dependencies section of the manifest file.

dependencies: [
    .package(url: "https://github.com/RainbowKit.git", .upToNextMajor(from: "5.2.0"))
]

We can use the library by importing it into the source code files just as we would in an iOS project.

import RainbowKit

We can also add local packages as dependencies.

dependencies: [
    .package(path: "../SunshineKit")
]

This approach is useful when splitting a project into multiple libraries, allowing us to edit the package's files directly within the project without worrying about versioning.

Using Swift Packages in iOS Projects

Depending on the project requirements, there are different ways to use Swift Packages in an iOS project.

To add a public library as a Swift Package, Xcode provides the Package Dependencies section to add, update and delete Swift packages. Check out this article on how to add public libraries as Swift Packages to an iOS project for more details.

Swift Package Manager also supports local packages, which is useful for organizing our code in a modular way. This involves dragging and dropping the local package into the Xcode project and adding it in the Frameworks, Libraries, and Embedded Content section. For more details, check out this article on how to add a local Swift Package to an iOS project.

Understanding the @Environment property wrapper in SwiftUI

Sun, 28 Jul 2024 22:00:00 GMT

The @Environment property wrapper in SwiftUI allows data sharing between views without explicitly passing the data down the view hierarchy. Setting an environment property on a view makes it accessible to that view and all its subviews.

There are different scenarios for using the @Environment property wrapper:

Using predefined @Environment values in SwiftUI
Using custom @Environment values
Using @Environment objects

Let's explore each scenario in more detail.

1. Using one of SwiftUI's predefined `@Environment` values

SwiftUI provides predefined values that we can use just out of the box like colorScheme, managedObjectContext, timeZone, openURL and more.

For example, we can access the current color scheme by using the colorScheme property:

struct ContentView: View {

    @Environment(\.colorScheme) private var colorScheme

    var body: some View {
        VStack {
            Text(colorScheme == .dark ? "dark" : "light")
        }
    }
}

2. Using custom `@Environment` values

While SwiftUI provides many built-in environment values, there are times when we need to create custom ones to suit our specific needs.

This involves creating an environment key, injecting the custom value into views, and using it similarly to predefined values:

@Environment(\.theme) private var theme

To learn more, check out this article on how to create custom @Environment values in SwiftUI.

3. Using `@Environment` objects

We can also pass reference objects between views using @Environment. For example:

@State private var viewModel = ViewModel()

SomeView()
    .environment(viewModel)

We can access it without using keys:

@Environment(ViewModel.self) private var viewModel

This method is useful for sharing complex objects that manage state or handle logic across multiple views. It ensures that all views are referencing the same instance, keeping the data consistent.

How to delay server requests for user's search query with SwiftUI and Combine

Sun, 14 Jul 2024 22:00:00 GMT

Search is a common feature in many applications. When a user types in a search query, we often want to avoid sending a new server request every time the query changes. Instead, we might want to delay it the request and only send it after the user has stopped typing for a certain amount of time.

This is where Combine's debounce operator comes in. It helps us achieve precisely this behavior. Let's see how we can implement it in combination with SwiftUI.

SwiftUI search implementation

When working with SwiftUI, our UI code for searching might look as follows:

struct SearchView: View {

    @State private var userSearchInput: String = ""

    var body: some View {
        VStack {
            // Show loading indicator, error, or results
        }
        .searchable(text: $userSearchInput)
        .onChange(of: userSearchInput) { _, newValue in
            viewModel.updateSearch(userSearchInput: newValue)
        }
    }
}

We use SwiftUI's searchable modifier to configure the display of a search field.
We use a @State variable to pass in as a binding to the searchable modifier. It will get updated automatically as the user changes the search query.
We subscribe to changes of userSearchInput to notify our view model that it might need to refresh the results.

ViewModel debounce implementation

Next, let's look at how the view model might be implemented:

class SearchViewModel {
    private var userSearchInputSubject = PassthroughSubject<String?, Never>()
    private var cancellables = Set<AnyCancellable>()

    init() {
        userSearchInputSubject
            .debounce(for: 0.5, scheduler: RunLoop.main)
            .sink { [weak self] searchInput in
                self?.reload(with: searchInput)
            }
            .store(in: &cancellables)
    }

    func updateSearch(userSearchInput: String?) {
        userSearchInputSubject.send(userSearchInput)
    }
}

By using the debounce operator, we ensure that the server requests are sent only when the user has stopped typing for half a second, reducing the number of unnecessary requests and improving the overall performance of our application.

Backpressure in Combine

Sun, 07 Jul 2024 22:00:00 GMT

When working with subscribers in Combine, we mostly use sink(receiveValue:) and assign(to:on:) to receive an unlimited amount of values from a publisher. However, there are scenarios where processing these values takes longer, and new values continue to arrive.

To prevent blocking or overflow, we may need to control the rate at which values are received. This concept of limiting the elements the subscriber receives is called backpressure.

Let's look at some examples and strategies on how to solve them.

Examples of backpressure

Backpressure issues may arise in various scenarios, such as:

Reading and writing data: When accessing slow storage media.
Server communication: When handling real-time data from a server.
Rendering: When updating the UI frequently.

For instance, in real-time server-to-client communication using WebSockets, emitting numerous values per second can lead to performance issues if the UI is updated with each incoming value. A better approach would be to buffer these values and update the UI at a controlled rate.

Another practical example is handling user search input. Instead of sending a server request with every keystroke, we can wait until the user stops typing for a specific amount of time before making a request.

Backpressure strategies

There are several strategies for applying backpressure in Combine, including:

Buffer i.e. accumulate incoming values temporarily
Drop i.e. skipping some of the incoming values

Both strategies can be implemented in different ways, either by creating a custom subscriber or by using Combine’s buffering or timing operators.

Using Combine's buffering and timing operators

Combine provides operators that can be attached to a standard subscriber to apply backpressure.

The `debounce(for:scheduler:options:)` operator

This operator publishes elements only after a specified time interval elapses. For example:

cancellable = subject
    .debounce(for: .seconds(0.5), scheduler: RunLoop.main)
    .sink { value in
        print("received \(value)")
    }
subject.send(1)
subject.send(2)

DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
    self.subject.send(3)
    self.subject.send(4)
}

Output:

received 2
received 4

Values 1 and 3 are dropped due to the 0.5-second debounce interval.

The `throttle(for:scheduler:latest:)` operator

This operator produces one element per specified interval, sending either the newest or oldest element received during that interval.

cancellable = Timer.publish(every: 1.0, on: .main, in: .default)
        .autoconnect()
        .throttle(for: 3.0, scheduler: RunLoop.main, latest: true)
        .sink{ date in
            print("received \(date)")
        }

Output:

received 2021-11-10 18:36:16
received 2021-11-10 18:36:19
received 2021-11-10 18:36:22
received 2021-11-10 18:36:25

We receive a date value every 3 seconds.

The `collect(_:)` operator

This operator bundles elements into an array and emits them based on a specified count or time interval.

cancellable = subject
    .collect(2)
    .sink { value in
        print("received \(value)")
    }

subject.send(1)
subject.send(2)
subject.send(3)
subject.send(4)

Output:

received [1, 2]
received [3, 4]

This approach is useful if the subscriber can process multiple elements at the same time.

Creating a custom subscriber to apply back pressure

If none of the above operators meets our needs, we can implement a custom subscriber that applies backpressure. Here is an example of a subscriber which receives one value initially and then two additional values after a second:

class CountSubscriber: Subscriber {
    typealias Input = Int
    typealias Failure = Never
    var subscription: Subscription?

    // 1.
    func receive(subscription: Subscription) {
        print("subscribed")
        self.subscription = subscription
        subscription.request(.max(1))
    }

    // 2.
    func receive(_ input: Int) -> Subscribers.Demand {
        print("received \(input)")
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            self.subscription?.request(.max(2))
        }
        return Subscribers.Demand.none
    }

    // 3.
    func receive(completion: Subscribers.Completion<Never>) {
    }
}

Let's go though it step by step:

receive(subscription:): Called as soon as a new subscription arrives. We request one element from the publisher.
receive(_ input:): Called when an element is received. We request two additional values after one second.
receive(completion:): Called when the publisher completes.

Using the subscriber might look as follows:

let subject = PassthroughSubject<Int, Never>()
let subscriber = CountSubscriber()
subject.subscribe(subscriber)
subject.send(1)
subject.send(2)

DispatchQueue.main.asyncAfter(deadline: .now() + 3) {
    self.subject.send(3)
    self.subject.send(4)
    self.subject.send(5)
}

Output:

subscribed
received 1
received 3
received 4

Developer guide on Swift Testing for iOS

Sun, 30 Jun 2024 22:00:00 GMT

At WWDC 2024, Apple released Swift Testing - a new framework which allows us to write automated tests for iOS applications.

Starting with Xcode 16, Swift Testing is now the default Testing framework when we add a testing target to our iOS project.

Let's directly jump in and look at how test functions look in Swift Testing.

Test functions

An example of a test with Swift Testing looks as follows:

import Testing
@testable import ExampleApp

struct ExampleAppTests {

    @Test func testExample() async throws {
        ...
        expect(resultName == expectedName)
    }

}

A test function follows these rules:

the @Test annotation indicates that a function is a test.
a test function can be a global function or a method in a type
a test function can be async
a test function can throw

Expectations

To validate expected conditions, we can use the #expect macro. It accepts ordinary expressions and operators, for example:

#expect(!array.isEmpty)
#expect(greeting == "Hello")

Alternatively, we can use the #require macro to throw an error and to stop the test if the condition is false. For example:

try #require(!result.isEmpty)

We can also use the #require macro to unwrap an optional:

let element = try #require(array.first)

Traits

We can add traits to the test, for example to describe a test or to customize how it behaves. For example:

@Test("An example test") to customize the display name of a test
@Test(.tags(.critical)) to add a custom tag to the test
@Test.enabled(if: someCondition)) to conditionally enable or disable a test
@Test.disabled("Describe why disabled")) to skip a test
@Test(.timeLimit(.minutes(1))) to add a time limit

Suits

To group related test functions we can use suites. A suite is implicitly created when we wrap test functions for example into a struct:

struct ExampleTests {

    @Test func test1() async throws {
        ...
    }

    @Test func test2() {
        ...
    }
}

With suites, we can use init and deinit functions for setup and teardown logic.

Parameterized testing

Swift Testing supports parameterized tests allowing us to run the same test logic multiple times with different input values:

@Test(arguments: ["a", "b", "c"])
func example(input: String) {
    ...
}

Migrating from XCTest

Swift Testing tests can coexist with XCTest in a single unit test target. This helps us migrate tests incrementally.

Swift Testing does currently not support Ul automation APls such as XCUIApplication or performance testing APls such as XCMetric.

WWDC 2024 summary of Apple's platforms state of the union talk for iOS developers

Sun, 23 Jun 2024 22:00:00 GMT

This article summerizes the announcements for iOS at Apple's platforms state of the union talk at WWDC 2024.

Let's jump in.

Apple Intelligence

Apple Intelligence is Apple's suite of AI technologies that improve user experience by powering features like Siri, image recognition, and personalized recommendations across their devices.

As iOS developers, we can use Apple Intelligence in our apps, for example by using the Image Playground API which allows us to add Image Playgrounds to our apps to let users generate their own new images from text input directly on device:

Button(...)
    .imagePlaygroundSheet (isPresented: $isImagePlaygroundPresented)｛ createdImageURL in
        // Use generated image. The created url is a local url which we can access with FileManager.
    }

Further examples to use Apple Intelligence in an iOS app are:

Genmoji which lets users create new emojis from their text input
Siri with App Intents

Predictive Code Completion & Swift Assist

Xcode 16 introduces Predictive Code Completion which uses machine learning to provide more accurate and context-aware suggestions.

Additionally, Xcode 16 comes with Swift Assist which uses machine learning provide code suggestions from our text input. Since Swift Assist runs in the cloud, it knows all the latest SDK updates and Swift Language features.

Swift Testing

Swift Testing is Apple's new testing framework which is an open-source package. An example of a test with Swift Testing looks as follows:

@Test("test long outputs of MinutesFormatter",
    arguments: [
        (1, "eine Minute"),
        (2, "zwei Minuten")
])
func testMinutesFormatter(minutes: Int, expected: String) {
    let formatter = MinutesFormatter(lang: "de")
    #expect(formatter.longOutput(from: minutes) == expected)
}

Swift Testing also works side-by-side with XCTest which helps us migrate tests incrementally.

Swift 6

Swift has its 10th birthday this year. Swift 6 introduces data-race safety by diagnosing potencial data races at compile time, further concurrency improvements, typed throws, increased interoperability with other languages and more.

SwiftUI updates

SwiftUI comes with improvements on many different topics such as navigation transitions, animation interoperability, programmatic text selection, timer formats, scrolling refinements and more.

SwiftData updates

SwiftData introduces new marcos such as #Index and #Unique. Additionally, we now get access to the history of local changes.

RealityKit updates

RealityKit 4 allows building for iOS, iPadOS, macOS, and visionOS simultaneously.

Reality Composer Pro, introduced with Apple Vision Pro, supports spatial app development across these platforms. Features like MaterialX shaders, portals, and particles work with RealityView on all four platforms. This includes existing APIs, as well as new features like blend shapes, inverse kinematics, skeletal poses and animation timelines.

Additionally, Xcode view debugging now includes 3D scene content inspection, simplifying the debugging process.

Controls API

The new Controls API allows us to add controls to device system spaces such as Control Center and Lock Screen. Controls can for example toggle a setting, execute an action or trigger a deep link. We can use the new ControlWidget type to configure controls.

Tinted App Icons

iOS now supports tinted app icons which can be configured in Xcode additionally to Light and Dark Mode app icons.

How to use NavigationPath for routing in SwiftUI

Sat, 08 Jun 2024 22:00:00 GMT

With NavigationPath, SwiftUI provides a robust and flexible way to handle navigation and routing. It allows us to programmatically control the navigation stack without the need to use a NavigationLink.

In this article, we'll explore how to use NavigationPath in a practical example.

Let's jump in.

When creating a NavigationStack, we have the possibility to pass in a path parameter:

struct SomeView: View {

    @State private var navigationPath = NavigationPath()

    var body: some View {
        NavigationStack(path: $navigationPath) {
            ...
        }
    }
}

The passed in path is a Binding to the navigation state for this stack - enabling us to control the navigation stack by appending data to it:

navigationPath.append(route)

Let's say, we are building an app which can navigate to a recipes search - which in turn can navigate to a recipe detail when a user selects one of the results.

The approach to control this flow could look as follows:

1. Defining an enum which represents all possible navigation routes

enum Route: Hashable {
    case recipesSearch
    case recipeDetail(recipe: Recipe)
}

We don't explicitly need it to use NavigationPath, but I personally find it really helpful to have explicitly defined navigation routes.

2. Creating an `Observable` router which holds the navigation path

To be able to access the same navigation path from different views, we create a router as an Observable which holds the reference to the navigation path and provides a utility function for navigation:

@Observable
class Router {
    var navigationPath = NavigationPath()

    func navigateTo(route: Route) {
        navigationPath.append(route)
    }
}

3. Passing in the router as an environment object to all subviews

For a subview to be able to access and use our created router, we pass it in as an environment object:

struct MainView: View {
    @State private var router = RecipesRouter()

    var body: some View {
        NavigationStack(path: $router.navigationPath) {
            RecipesFeedView()
                .environment(router)
        }
    }
}

4. Defining a navigation destination for possible routes

As a next step, we define a navigationDestination for each of our routes by providing views a specific route should navigate to:

RecipesFeedView()
    .environment(router)
    .navigationDestination(for: RecipesRouter.Route.self) { route in
        switch route {
        case .recipesSearch:
            RecipesSearchView()
                .environment(router)
        case .recipeDetail(let recipe):
            RecipeDetailView(recipe: recipe)
                .environment(router)
        }
    }

5. Using router where needed

Finally, we can use the router for navigation anywhere we need by accessing it tough the @Environment property wrapper:

struct RecipesFeedView: View {
    @Environment(RecipesRouter.self) var router

    var body: some View {
        ...
        Button(action: {
            router.navigateTo(route: .recipesSearch)
        }, label: {
            Image(systemName: "magnifyingglass")
        })
    }
}

Objective-C basics for Swift developers

Sun, 02 Jun 2024 22:00:00 GMT

Objective-C, the primary language for iOS development before the release of Swift in 2014, remains an integral part of many legacy projects and Apple frameworks.

For Swift developers, understanding the basics of Objective-C can be valuable, especially when working on older codebases or integrating with libraries that haven’t been updated to Swift.

This guide will help Swift developers get acquainted with Objective-C, highlighting key concepts and differences between the two languages.

Let's jump in.

Variables

Swift

When defining variables, Swift offers the let keyword for constants and the var keyword for variables. Swift offers type inference and optional data types.

let name = "Swifty" // declaring and assigning a constant

var age: Int? // declaring an optional Int variable
age = 7 // reassigning the variable
age = nil // nullifying the variable

var year = 2014 // the compiler automatically infers the `Int` type

let fruits = ["apple", "orange"] // desclaring and assigning an array of strings

Objective-C

Objective-C does not support type inference, we always have to explicitly specify the variable's type. It includes basic types like int, float, char and object types like NSString, NSNumber etc.

Unlike Swift, Objective-C does not have a separate optional type; all object types can inherently be nullified.

The same example in Objective-C looks as follows:

NSString const *name = @"Obji"; // declaring and assigning a constant

NSNumber *age; // declaring a variable
age = 7; // reassigning the variable
age = nil; // nullifying the variable

NSArray<NSString*> *fruits = @[@"apple", @"orange"]; // desclaring and assigning an array of strings

Let's go through some key points of the above example:

Explicit Type Declaration: Every variable must have its type explicitly declared.
Pointers: Object types are declared as pointers - which is indicated by *. This is conceptually similar to reference types in Swift but syntactically different.
Optionals: Swift’s optionals provide a clear way to handle nil values, whereas in Objective-C, any object can be set to nil.
Constants: const is used to declare constants.
Array syntax: The @ symbol is used before array literals.
String syntax: String literals are prefixed with @ to differentiate them from C-style strings.

Properties

In both Swift and Objective-C, properties are variables that are declared as part of a type. The primary difference lies in the syntax and additional attributes applied for access control and memory management.

Swift

In Swift, properties are commonly used in classes, structures, and enumerations. By default, properties are strong and have an internal access level unless otherwise specified.

class Child {
    private let firstName: String // declaring a private constant property
    private(set) var lastName: String // declaring a read-only property
    var age: Int // declaring an internal property
    weak public var parent: Parent? // declaring a weak public property
}

Objective-C

In Objective-C, properties are used only in classes and are declared using the @property keyword followed by comma-separated attributes specifying memory management and access control.

@property NSString *firstName; // declaring a strong property
@property (readonly) NSString *lastName; // declaring a read-only property
@property (weak) Parent *parent; // declaring a read-only property

The visibility of Objective-C properties is not achieved with attributes but with where we place them in our class declarations. We will look at that later in the classes section.

Methods

Swift

In Swift, methods can be defined on classes, structures, and enumerations. Swift methods support various features like default parameters, multiple return values and concise syntax.

// method declaration with no return type and no parameters
func emptyCard()

// method declaration with two parameters and a return value
func search(_ searchQuery: String, category: String) -> [Tea]

// default parameters
func walk(withSpeed speed: Int = 20)

// method implementation
func search(_ searchQuery: String, category: String) -> [Tea] {
    return []
}

// calling a method
let results = teaShop.search("camomile", category: "herbs")

Objective-C

In Objective-C, only classes can define methods. Objective-C does not support default parameters, making method overloading a common pattern for similar functionality with different parameters.

// method declaration with no return type and no parameters
// `void` represents the absence of a type.
- (void)emptyCard;

// method declaration with two parameters and a return value
- (NSArray<Tea *> *)search:(NSString *)searchQuery category:(NSString *)category

// implementation of a method with two parameters and a return value
- (NSArray<Tea *> *)search:(NSString *)searchQuery category:(NSString *)category {
    return [];
}

// calling a method
NSArray<NSString *> *results = [teaShop search:@"camomile" category:@"herbs"];

As shown above, methods in Objective-C have the - (returnType)methodName:(paramType)paramName syntax. To call a method, we use square brackets, with parameters specified within.

Classes & structs

Swift

In Swift, we distinguish between classes, which are reference types, and structs, which are value types.

import Foundation

class TeaShop {
    // Public & private properties & methods
}

struct Tea {
    // Public & private properties & methods
}

// Using a class
let shop = TeaShop()

// Using a struct
let tea = Tea()

Objective-C

In Objective-C, classes are defined using two separate files: the header file (.h) and the implementation file (.m). All classes are derived from the base class NSObject, which provides essential methods for memory allocation and initialization.

TeaShop.h

@import Foundation;

@interface TeaShop : NSObject
// Public properties & method definitions
@end

TeaShop.m

#import "TeaShop.h"

@interface TeaShop ()
// private properties & method definitions
@end

@implementation TeaShop {
// Private instance variables
}
// Methods implementation
@end

Creating a new object in Objective-C is a two-step process. First, we allocate memory for the object and then initialize it.

TeaShop *shop = [[TeaShop alloc] init];

// Or the shorter version, that will call `alloc` and `init` for us
TeaShop *shop = [[TeaShop new];

Structs in Objective-C are similar to C structs and are less commonly used compared to classes. Objective-C, being a superset of C, allows the use of C constructs.

// Declaration of a struct
struct Position
{
   int x;
   int y;
};

// Usage of a struct
struct Position position;
position.x = 5;
position.y = 10;

Enums

Swift

Like structs, Swift enums are first-class types which support features like associated types, computed properties, custom initializers and more.

enum TeeCategory {
    case herbal
    case green
    case fruits
}

let category = TeeCategory.green

Objective-C

In Objective-C, enums are less flexible compared to Swift enums. They are essentially C-style enums, defined using the typedef keyword and NS_ENUM macro for better type safety and integration with Objective-C.

typedef NS_ENUM(NSInteger, TeeCategory) {
    TeeCategoryHerbal,
    TeeCategoryGreen,
    TeeCategoryFruits
} TeeCategory;

// Using an enum
TeeCategory category = TeeCategoryFruits;

Extensions

Swift

In Swift, extensions are a powerful way to add new functionality to existing classes, structures, enums, or protocols without modifying their original implementation. Extensions can add computed properties, methods, initializers, and conform to protocols.

extension String {
    var asURL: URL? {
        URL(string: self)
    }
}

Objective-C

In Objective-C, categories are used to add new functionality to existing classes. Categories, like classes, consist of a header file and an implementation file.

NSString+URL.h

@interface NSString (URL)

-(NSURL*)toURL;

@end

NSString+URL.m

#import "NSString+URL.h"

@implementation NSString (URL)

-(NSURL*)toURL {
    return [[NSURL alloc] initWithString:self];
}

@end

How to create custom @Environment values in SwiftUI

Sun, 26 May 2024 22:00:00 GMT

The @Environment property wrapper in SwiftUI allows us to share data between views without explicitly passing the data from view to view.

While SwiftUI provides many built-in environment values, there are times when we need to create custom ones to suit our specific needs.

Let's directly jump in and see how to do that.

To create a custom @Environment value, we need to:

Declare a new EnvironmentKey type.
Extend the EnvironmentValues structure to include a property for our new custom key.
Use the @Environment property wrapper to inject the custom value into our views.

Let's look at each step in more detail.

As an example, we'll create a custom environment value to manage the theme of our iOS app. The theme includes properties like colors and font sizes that can be accessed throughout the app.

1. Declaring a new `EnvironmentKey` type

At first, we create a new type that conforms to the EnvironmentKey protocol. For example:

private struct ThemeEnvironmentKey: EnvironmentKey {
    static let defaultValue: Theme = Theme.default
}

2. Extending the `EnvironmentValues` structure

Next, we extend the EnvironmentValues structure to include a property for our custom environment key. This makes it accessible via the environment.

extension EnvironmentValues {
    var theme: Theme {
        get { self[ThemeEnvironmentKey.self] }
        set { self[ThemeEnvironmentKey.self] = newValue }
    }
}

3. Using the `@Environment` property wrapper

Now that we have defined a custom environment value, we can use it in our views with the @Environment property wrapper.

// Setting the environment value.
LoginView()
    .environment(\.theme, Theme.default)

// Accessing the environment value.
struct LoginView: View {
    @Environment(\.theme) var theme: Theme

    var body: some View {
        Text("Hello")
            .foregroundColor(theme.primary)
    }
}

Instead of a String, we can of course use any other type for the environment value.

Combine essentials in Swift - a quick guide

Sun, 19 May 2024 22:00:00 GMT

Apple's Combine framework provides a native way to write functional reactive code in our iOS applications. In this article, we'll go through basic Combine concepts and terms.

Let's directly jump in.

Overview

The core components of Combine are publishers and subscribers. Publishers emit values or errors over time, while subscribers receive and handle these emissions.

In addition, Combine provides a rich set of operators that allow for transforming, filtering, and combining the emitted values.

Let's look at these main components in more detail with an example.

Publishers

Let's say, we are building an app that presents articles which can receive hearts. We want to be able to change the count of hearts for an article and also to notify subscribers about this change.

As a first step, we'll define a publisher which can send new values, in our case the new heart count.

For that, we'll use a subject which is a mutable publisher with the ability to send new values after its initialization:

struct Article {

    // 3.
    var heartsCountPublisher: AnyPublisher<Int, Never> {
        heartsCountSubject.eraseToAnyPublisher()
    }

    // 1.
    private let heartsCountSubject: CurrentValueSubject<Int, Never>

    // 2.
    init(heartsCount: Int) {
        heartsCountSubject = CurrentValueSubject(heartsCount)
    }

    // 4.
    func addHeart() {
        heartsCountSubject.send(heartsCountSubject.value + 1)
    }
}

Let's break down the code step by step:

We define a subject named heartsCountSubject as a private variable of type CurrentValueSubject<Int, Never>. We will use it to send new values to subscribers. Since a subject is a generic type we specify its Output and Failure type. The output type defines what kind of values the subject will send, in our case Int values. Since our example doesn't involve errors, we use Never as error type.

Note: there are two subject types available:

CurrentValueSubject: This subject type maintains access to the current value.
PassthroughSubject: This subject type simply passes values through and does not maintain access to the current value.

We define an initializer that takes a heartsCount parameter to set the initial value for heartsCountSubject.
We define a publisher named heartsCountPublisher of type AnyPublisher<Int, Never>. It has the same Output and Failure type as our subject. Although we could make our subject public, using a publisher allows us to expose only the subscription functionality to the outside world, preventing external entities from sending new values.
We define an addHeart method for increasing the count of hearts. Here, we use our subject to send a new value. To be able to add a heart we access the subject's value property to get the current value. That's the reason why we used a CurrentValueSubject and not a PassthroughSubject - only a CurrentValueSubject has access to its current value.

Subscribers

A publisher can have one or more subscribers. These subscribers request values and receive them when they are published.

In our example, we can use the Article struct and subscribe to its hearts count as follows:

// 1.
let article = Article(heartsCount: 5)

// 2.
let heartsCountSubscriber = article.heartsCountPublisher
    .sink { value in
        print(value)
    }

// 3.
article.addHeart()
article.addHeart()

Let's go through this code step by step.

We create an Article instance with an initial hearts count of 5.
We create a subscriber named heartsCountSubscriber that listens for updates on the hearts count. The subscriber uses the publisher's sink(receiveValue:) method to subscribe for updates. Now, every time the hearts count changes, the closure is called, printing the new value.
We increase the count of hearts by calling addHeart() twice.

Therefore, the code produces the following output:

5
6
7

When we create a new subscriber, the publisher returns an object that conforms to the Cancellable protocol. This allows us to cancel receiving new values by calling the cancel() method on the subscriber.

For example:

article.addHeart()
heartsCountSubscriber.cancel()
article.addHeart()

In the code above, the last increment is not printed because the subscriber has been canceled.

Operators

Operators modify values sent from publishers, allowing us to transform, filter, and combine data streams.

In our example, we can use operators to modify received values before executing the print closure. For instance, to print a more descriptive message, we can use the map operator to convert Int values to String values:

let heartsCountSubscriber = article.heartsCountPublisher
    .map { "\($0) hearts" }
    .sink { print($0) }

Now, our output looks as follows:

5 hearts
6 hearts
7 hearts

We can chain multiple operators to build complex data processing pipelines. Let's explore a more detailed example:

let publisher1 = PassthroughSubject<[Int], Never>()
let publisher2 = PassthroughSubject<[Int], Never>()

publisher1
    .merge(with: publisher2) // 1.
    .flatMap { Publishers.Sequence(sequence: $0) } // 2.
    .filter { $0 % 2 == 0 } // 3.
    .dropFirst() // 4.
    .collect() // 5.
    .sink { print($0) }

publisher1.send([1, 3])
publisher2.send([6, 10])
publisher2.send([4, 19, 8])
publisher1.send(completion: .finished)
publisher2.send(completion: .finished)

While this example may not perform a useful task, it demonstrates how operators work and how they can be combined. Try to predict the output of each operator before checking the explanation below.

merge: Combines elements from publisher1 and publisher2. Output: [1, 3] [6, 10] [4, 19, 8].
flatMap: Flattens the array into a sequence of Int values. Output: 1, 3, 6, 10, 4, 19, 8.
filter: Keeps only even values in our example. Output: 6, 10, 4, 8.
dropFirst: Drops the first element. Output: 10, 4, 8.
collect: Collects all received items into an array. Output: [10, 4, 8]

To explore more operators, visit the official Publisher documentation.

Memory management in Combine

In Combine, memory management is crucial to prevent memory leaks and retain cycles. The lifecycle of a subscriber is linked to the lifecycle of the retaining object. When this object is deallocated, the cancel method is automatically called on the subscriber, releasing it as well.

To avoid creating retain cycles, especially when using self within a sink closure, we need to manage memory carefully. One common approach is to use the AnyCancellable type. When we subscribe to a publisher, it returns an AnyCancellable instance which we can store and manage appropriately. For example:

var cancellables = Set<AnyCancellable>()

publisher.sink {
   // ...
}
.store(in: &cancellables)

In this example, we:

Use [weak self] to avoid a retain cycle, ensuring that self is not strongly captured by the closure.
Store the AnyCancellable instance returned by sink in a Set called cancellables.

When the object holding the cancellables set is deallocated, the AnyCancellable instances in the set are automatically cancelled. These steps prevent memory leaks and ensure that subscriptions are properly terminated.

How to combine SwiftUI and UIKit views in iOS

Sun, 12 May 2024 22:00:00 GMT

With SwiftUI pushing UIKit into the background since 2019, UIKit may still be part of existing iOS applications.

To combine those two worlds, Apple provides tools to place UIKit views and view controllers inside SwiftUI views, and vice versa.

Let's look at how to do that.

Using UIKit views inside SwiftUI views

To use a UIKit view in a SwiftUI view, we wrap the UIKit view in a SwiftUI view that conforms to the UIViewRepresentable protocol.

struct Label: UIViewRepresentable {
    @Binding var title: String

    func makeUIView(context: Context) -> UILabel {
        let label = UILabel()
        return label
    }

    func updateUIView(_ label: UILabel, context: Context) {
        label.text = title
    }
}

When implementing the UIViewRepresentable protocol, we need to implement two methods:

makeUIView where we create and return our UIKit view.
updateUIView which gets called from SwiftUI every time state changes happen, so we can update our UIKit view accordingly.

Using UIKit view controllers in SwiftUI views

In SwiftUI, there is no concept of a UIKit view controller - everything is a view.

To embed a view controller in a SwiftUI view, we can use the same approach as described above. With the only difference, that this time, the SwiftUI view conforms to the UIViewControllerRepresentable protocol:

struct SomeView: UIViewControllerRepresentable {
    @Binding var title: String

    func makeUIViewController(context: Context) -> SomeViewController {
        let vc = SomeViewController()
        return vc
    }

    func updateUIViewController(_ uiViewController: SomeViewController, context: Context) {
        uiViewController.title = title
    }
}

As we can see above, it has equivalent methods as the UIViewRepresentable protocol.

Using SwiftUI views inside UIKit views

For using SwiftUI views inside UIKit, Apple provides a class named UIHostingViewController. We simply initialize a UIHostingController with the SwiftUI view and then use it as usual.

let vc = UIHostingController(rootView: Text("Hi"))

How to localize plurals with Localizable.stringsdict files in iOS

Sun, 05 May 2024 22:00:00 GMT

In this article, we'll look at how to localize plurals with Localizable.stringsdict files. If you are using String Catalogs, check out this article instead.

If you are already familiar with localizing plurals in iOS and you are just looking to remember the specifics, you can directly scroll down to the cheat sheet at the end of the article.

Let's jump in.

Every time we need to localize texts like My dog ate 2 carrots where the carrot count is dynamic, one localization string will not be enough. For example, localizing with My dog ate %i carrots would produce My dog ate 1 carrots when passing in 1.

The first solution that may come up could be to create another localization string for one carrot and adding some logic such as:

if carrotCount == 1 {
    return NSLocalizedString("dog_eating_carrots_one")
} else {
    return String(format: NSLocalizedString("dog_eating_carrots_multiple"), carrotCount)
}

The problem with the solution above is that different languages vary in how they handle plurals. For example, in Russian, we would need to handle more cases. Plural rules for the word dog look like this:

собака for 1, 21, 31, 41, 51, 61 etc. Examples: 1 собака, 21 собака
собаки for 2-4, 22-24, 32-34 etc. Examples: 2 собаки, 22 собаки
собак for 5-20, 25-30, 35-40 etc. Examples: 5 собак, 20 собак

It would be complicated to handle this logic in code. Instead, we can use a Localizable.strigsdict file to solve it.

Unlike a Localizable.strings file, a Localizable.strigsdict file provides additional features to work with different languages, for example to define plural rules. The Localizable.strigsdict is able to interpret the arguments you pass in and select the right localized string based on it.

Creating and localizing a `Localizable.stringdict` file

To create a Localizable.stringdict file, we can select a .stringdict template from Xcode's dialog when creating a new file. The localization process is exactly the same as for Localizable.strings files.

Adding plural configuration

Now, we can add the plural configuration for a specific language. We can use the template as a starting point:

The .stringdict template

The configuration for our example could look as follows:

A .stringdict configuration example

Let's go through it step by step.

Localized String Key — is replaced with the key that we will use when calling NSLocalizedString. In our example the key is dog_eating_carrots.
NSStringLocalizedFormatKey - the localized text with parameters. In our case it's My dog ate %#@carrotsCount@.. It has the following structure:
- every variable is be preceded by %#@ and followed by @
- we only need to define variables for parameters where plural rules should be applied
- in case we need to pass in additional arguments, we can simply use the string format specifiers we already know such as %@, %d etc. For example, to pass in the dog's name, our format string would look as follows: My dog %@ ate %#@carrotsCount@.
Variable — the rules dictionary that applies to a specific variable. We create one for every variable we defined in NSStringLocalizedFormatKey. In our example, it's one variable with the name carrotsCount.
NSStringFormatSpecTypeKey — parameter processing rule. It's already set to NSStringPluralRuleType so we can leave it as is.
NSStringFormatValueTypeKey — specifies the format of the parameter, for example d for integer or f for double.
CLDR Language Plural Rules — we can choose different plural rules like zero, one, two, few, many and other. For some languages like English we only need to configure two rules, one and other. Other languages have only a single plural rule and some languages have more than two.

Switching between property list and source code

Xcode provides a user interface to work with property list files. Depending on your preference, you can directly work with source code instead. To switch, right-click on the Localizable.stringdict file and choose Open as -> Source Code. Switching back works the same way with Open as -> Property List.

The source code version of our example above looks as follows:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>dog_eating_carrots</key>
    <dict>
        <key>NSStringLocalizedFormatKey</key>
        <string>My dog ate %#@carrotsCount@.</string>
        <key>carrotsCount</key>
        <dict>
            <key>NSStringFormatSpecTypeKey</key>
            <string>NSStringPluralRuleType</string>
            <key>NSStringFormatValueTypeKey</key>
            <string>d</string>
            <key>zero</key>
            <string>no carrots</string>
            <key>one</key>
            <string>1 carrot</string>
            <key>other</key>
            <string>%d carrots</string>
        </dict>
    </dict>
</dict>
</plist>

Cheat sheet

And that's basically it. Below is the promised cheat sheet which shows another example with two variables.

Cheatsheet for localizing plurals in iOS

How to solve problems with bitwise operators in Swift

Sun, 28 Apr 2024 22:00:00 GMT

Knowing how to work with bitwise operators can become really useful when solving specific types of problems.

Let's directly jump in and look at an example.

Recently, I had to solve the following task at work.

The server sends an integer value between 0 and 127 that represents the state of a weekdays selection. When the server sends a 0, no checkbox should be selected. For a 127, all check boxes should be selected. The numbers in between represent all the other states. The task was to evaluate this value to be able to preselect the appropriate checkboxes.

Check boxes for weekday selection

The logic behind the integer value is simple when we imagine that each weekday is represented by it's bit value:

mon tue wed thu fri sat sun

0000000 - equals 0 - no weekday is selected
0000011 - equals 3 - sat sun are selected
1010101 - equals 85 - mon wed fri sun are selected
1111100 - equals 124 - mon tue wed thu fri are selected
1111111 - equals 127 - all days are selected

With this pattern, we are able to represent every state of the seven check boxes with numbers ranging from 0 to 127.

Checkboxes selection for value 85 (1010101)

Now, the question is:

What is the best approach to convert the number send by the server into the correct checkboxes state?

The trivial solution

The most trivial approach which might come to our mind could look as follows:

switch weekdaysSelectionValue {
    case 0:
        monCheckbox.isChecked = false
        tueCheckbox.isChecked = false
        wedCheckbox.isChecked = false
        thuCheckbox.isChecked = false
        friCheckbox.isChecked = false
        satCheckbox.isChecked = false
        sunCheckbox.isChecked = false
    case 1:
        monCheckbox.isChecked = false
        tueCheckbox.isChecked = false
        wedCheckbox.isChecked = false
        thuCheckbox.isChecked = false
        friCheckbox.isChecked = false
        satCheckbox.isChecked = false
        sunCheckbox.isChecked = true
    ...
    case 127:
        monCheckbox.isChecked = true
        tueCheckbox.isChecked = true
        wedCheckbox.isChecked = true
        ...
}

Having 127 switch cases is a lot of fun, but let's look into a more generic approach to solve this with bitwise operators.

monCheckbox.isChecked = // get the bit on the 6th position & check if it is 0 or 1
tueCheckbox.isChecked = // get the bit on the 5th position & check if it is 0 or 1
wedCheckbox.isChecked = // get the bit on the 4th position & check if it is 0 or 1
thuCheckbox.isChecked = // get the bit on the 3th position & check if it is 0 or 1
friCheckbox.isChecked = // get the bit on the 2th position & check if it is 0 or 1
satCheckbox.isChecked = // get the bit on the 1th position & check if it is 0 or 1
sunCheckbox.isChecked = // get the bit on the 0th position & check if it is 0 or 1

To implement the solution above, let's look into how to work with bits in Swift.

Basics about bits in Swift

A bit is the smallest piece of information that can be 1 or 0. Eight bits together are called a byte.

The unsigned UInt8 type in Swift is represented by 8 bits - which means we can represent 2⁸ = 256 different numbers with UInt8. That's enough for our use case since we only need 127 numbers.

UInt8

0 = 00000000 = 0 * 2^0
1 = 00000001 = 1 * 2^0
2 = 00000010 = 0 * 2^0 + 1 * 2^1
3 = 00000011 = 1 * 2^0 + 1 * 2^1
...
6 = 00000110 = 1 * 2^0 + 1 * 2^1 + 1 * 2^2
...
255 = 11111111 = 1 * 2^0 + 1 * 2^1 + 1 * 2^2 + 1 * 2^3 + 1 * 2^4 + 1 * 2^5 + 1 * 2^6

A signed Int8 type also represents 256 different numbers, but ranging from -128 to 127. The most left bit is used to signify whether the integer is positive or negative. So theoretically, we could also use an Int8 for our task.

In Swift, when defining a number, we can choose to use its bit representation:

let value1: UInt8 = 3
let value2: UInt8 = 0b00000011

In the example above, value1 and value2 are the same values, they are just written down differently.

Bitwise shifting and bitwise operators in Swift

Additionally to basic operators, Swift offers advanced operators for bit manipulations, for example:

0b00000011 | 0b00000101 // The bitwise OR operator produces 0b00000111
0b00000011 & 0b00000101 // The bitwise AND operator produces 0b00000001
0b00000010 << 1 // The bitwise LEFT SHIFT operator << produces 0b0000100
0b00000010 >> 1 // The bitwise RIGHT SHIFT operator >> produces 0b0000001

the OR operator | produces a 0 only if both bits are a 0. Otherwise it produces a 1.
the AND operator & produces a 1 only if both bits are a 1. Otherwise it produces a 0.
the LEFT SHIFT operator << shifts every bit to the left by a certain number of places. Any bits that are moved beyond the bounds are discarded.
the RIGHT SHIFT operator >> does the same as the LEFT SHIFT operator in the other direction.

Solution with bitwise operators

With the help of those operators, we now can do the following.

monCheckbox.isChecked = ((serverValue & 0b01000000) >> 6) == 1
tueCheckbox.isChecked = ((serverValue & 0b00100000) >> 5) == 1
wedCheckbox.isChecked = ((serverValue & 0b00010000) >> 4) == 1
thuCheckbox.isChecked = ((serverValue & 0b00001000) >> 3) == 1
friCheckbox.isChecked = ((serverValue & 0b00000100) >> 2) == 1
satCheckbox.isChecked = ((serverValue & 0b00000010) >> 1) == 1
sunCheckbox.isChecked = ((serverValue & 0b00000001) >> 0) == 1

What exactly is happening here? Let's pick one value to illustrate this.

1. Imagine, we get a 85 from the server. That is a 0b01010101.

2. Now, we want to know if the Friday's checkbox is checked. For that, we nullify all bits instead of the one on position 2 by using the AND operator.

0b01010101 & 0b00000100 // produces 0b000000100

3. Next, we want to know if the value on the second position is a 1 or a 0. For that, we shift 2 positions to the right, so the value is now at position 0.

0b000000100 >> 2 // produces 0b000000001

4. Finally, we can check if our produced value is a 0 or a 1 with the basic == operator.

0b000000001 == 1 // is true

Actually, we can even solve this without shifting. Instead of shifting to the right and checking if the value is 1, we can simply check if our value is not 0:

friCheckbox.isChecked = serverValue & 0b00000100 != 0

Solution with an OptionSet

Now, since we understand how to solve this task with bitwise operators, there is an even simpler solution. Swift's standard library offers an OptionSet type which represents bit set types.

struct WeekdayOptions: OptionSet {
    let rawValue: Int

    static let sun = WeekdayOptions(rawValue: 1 << 0)
    static let sat = WeekdayOptions(rawValue: 1 << 1)
    static let fri = WeekdayOptions(rawValue: 1 << 2)
    static let thu = WeekdayOptions(rawValue: 1 << 3)
    static let wed = WeekdayOptions(rawValue: 1 << 4)
    static let tue = WeekdayOptions(rawValue: 1 << 5)
    static let mon = WeekdayOptions(rawValue: 1 << 6)
}

After defining weekday options as an OptionSet as shown above, we get all the logic behind it for free. To check if Monday is selected, we can simply use the OptionSet's contains method.

let weekdayOptions = WeekdayOptions(rawValue: serverValue)
monCheckbox.isSelected = weekdayOptions.contains(.mon)

Even though an OptionSet makes it easy, knowing the bit operators and how it works behind the scenes makes its usage more clear.

GraphQL essentials for iOS development

Sun, 21 Apr 2024 22:00:00 GMT

GraphQL is an API design paradigm which has emerged as an alternative to RESTful APIs. Compared to REST, which exposes fixed endpoints for different resources, GraphQL enables clients to query and retrieve only the data they need, in a single request.

In this article, we'll dive into the essentials of GraphQL for iOS development. Let's jump in.

Understanding the difference between GraphQL and REST

To get a first impression of how GraphQL works, let's look at an example and how it is solved with GraphQL compared to REST.

Let's say we're implementing the frontend of a dog treats shop displaying an overview of the orders a user made.

When working with a REST API, we would use multiple endpoints where each endpoint returns specific information, for example:

/orders to get all orders with basic information
/order/[id] to get the details of a specific order

It may happen that the information we get from the /orders endpoint will not be enough for our frontend needs because we want to display some of the details directly in the orders overview. To achieve this with REST, we could:

Send an additional request for every order to load more details to the /order/[id] endpoint.
Or ask the backend team to add more data to the /orders endpoint.

Both ways are not ideal. With the first approach, we end up sending a lot of requests to the server. With the second approach, every time frontend requirements change, we may need to change the backend.

In comparison to REST, GraphQL APIs only expose a single endpoint. We can specify precisely what data we need. By using GraphQL, we define all needed detail fields in a GraphQL query:

{
  orders {
    id
    name
    price
    status
    supplier {
        id
        name
    }
  }
}

When we send a request with this query to the server, we get exactly the data we defined, nothing more and nothing less.

GraphQL as server-side runtime

As an iOS developer, in most cases we won't need to know all the details on how GraphQL is implemented server-side wise.

An interesting thing to know is that GraphQL isn't tied to any specific framework, programming language or database. GraphQL acts more as a layer lying between an existing backend implementation and the client.

Many different programming languages support GraphQL, including Swift. For example, Graphiti is a Swift library for building GraphQL schemas.

Basic concepts of GraphQL

Queries

In the example above we already saw an example of a GraphQL query. Let's look at its the basic parts:

Basic parts of a GraphQL query.

As shown above, we can name a query to be able to reference it.

Additionally, we can pass in arguments into the query. In our example, the id of an order is an argument. The exclamation point ! indicates, that the argument is required.

A field is a unit of data, which ends up as a field in the JSON response data. For the query above, we could get the following JSON response:

{
 order {
    name: "Dog soft frisbee",
    status: "PAID"
 }
}

Mutations

When working with APIs, we also need to be able to mutate, delete or create new data. As an equivalent to POST, PUT and DELETE requests in REST, so called mutations are used in GraphQL.

Mutations consist of the same parts as a query. A mutation for creating a new order could look as follows:

mutation CreateOrder($order: OrderInput!) {
    createOrder($order: OrderInput!) {
        id
    }
}

In the mutation above, we create a new order by passing it in as an argument of type OrderInput. The mutation will return the id of the freshly created order in the response.

GraphQL schema and explorer

As a frontend developer, we need to know what kind of data we can ask for and what fields we can select. That's where the schema comes in.

Each GraphQL service defines a set of types which completely describe all possible data we can query or mutate as a client. When we send a query to that service, it will be executed against that schema to check if it's valid.

To explore that schema, GraphQL services often offer an in-browser exlorer like GraphiQL. With GraphiQL, we can write and test queries against the service. It offers a documentation and supports debugging as we type, giving hints and pointing out errors.

GitHub's GraphQL explorer.

Fragments

The last GraphQL concept I like to introduce are fragments. Fragments are reusable units that can be used when building more complicated queries. For example, we could extract the supplier behind an ordered product into a separate fragment to reuse it in different queries.

fragment Supplier on Order {
    supplier {
        id
        name
    }
}

When fetching an order, we can now use the defined fragment as follows:

{
  order($id: Id!) {
    name
    ...Supplier
  }
}

GraphQL in iOS

To be able to send requests to a GraphQL service from an iOS application, we could build the request on our own with the same tools we would use for sending REST requests.

For example, for sending a GraphQL query, you would send the query and its variables in the query parameter of a HTTP GET request.

http://myapi/graphql?query={me{name...}}&variables={...}

Or send it in the body of a POST request:

{
  "query": "...",
  "operationName": "...",
  "variables": { "myVariable": "someValue", ... }
}

I prefer to use another way to communicate with a GraphQL service by using the library Apollo iOS Client. This networking library was specifically designed for working with GraphQL.

After we provide a schema file of the GraphQL service, the library will generate strongly typed Swift files out of our defined queries, which we can then use to send requests.

Here is an example of how sending a request looks like with Apollo:

apollo.fetch(query: GetOrderQuery(id: id)) { result in
  switch result {
  case .success(let graphQLResult):
    // handle success.
  case .failure(let error):
    // handle error.
  }
}

To dive deeper, check out this article on getting started with Apollo iOS for GraphQL in Swift.

Conclusion

I hope, I could give you a good introduction into the world of GraphQL. If you are new to GraphQL, I recommend playing around with Githubs GraphQL explorer, by reading through their docs and try out different types of queries. This will give you a good first impression on how GraphQL works in practice.

And of course, you can also dive deeper into the concepts of GraphQL by reading the official documentation.

Quick tip on adding child view controllers programmatically in UIKit

Sun, 21 Apr 2024 22:00:00 GMT

To better separate and organize our code, we have the possibility to nest view controllers inside each other.

The following code snippet provides an extension method for adding a child view controller programmatically. This extension method takes care of all the necessary steps, including setting constraints for the child view controller’s view.

extension UIViewController {

    /// Utility method to add a `UIViewController` instance to a `UIView`.
    ///
    /// Calls all necessary methods for adding a child view controller and set the constraints
    /// between the views.
    ///
    /// - Parameters:
    ///   - viewController: `UIViewController` instance that will be added to `contentView`.
    ///   - contentView: `UIView` that will add the `childViewController` as its subview.
    func add(childViewController viewController: UIViewController, to contentView: UIView) {
        let matchParentConstraints = [
            viewController.view.leadingAnchor.constraint(equalTo: contentView.leadingAnchor),
            viewController.view.trailingAnchor.constraint(equalTo: contentView.trailingAnchor),
            viewController.view.topAnchor.constraint(equalTo: contentView.topAnchor),
            viewController.view.bottomAnchor.constraint(equalTo: contentView.bottomAnchor)
        ]

        addChild(viewController)
        viewController.view.translatesAutoresizingMaskIntoConstraints = false
        contentView.addSubview(viewController.view)
        NSLayoutConstraint.activate(matchParentConstraints)
        viewController.didMove(toParent: self)
    }
}

My favorite Xcode keyboard shortcuts to be more productive

Sun, 14 Apr 2024 22:00:00 GMT

Using keyboard shortcuts is key of being productive and efficient when working with a development environment like Xcode. In this article, I'll show you my favorite Xcode shortcuts.

Before we start, here is a quick key reference:

⌘ - Command
⇧ - Shift
⌥ - Option/Alt
⌃ - Control

Let's jump in.

1. Product

Let's start with some basic shortcuts which we can find in Xcode's Product menu:

Run ⌘ R
Test ⌘ U
Clean Build Folder ⇧ ⌘ K
Stop ⌘ .

If you are working with Xcode for some time now, you most certainly use them already.

2. Navigate

Quickly navigating back and forth when working on different files is a real time saver:

Go forward ⌃ ⌘ →
Go back ⌃ ⌘ ←

3. Open quickly and jump to definition

Another essential shortcut is one for opening a file quickly with ⇧ ⌘ O.

After doing so, the jump to definition ⌃ ⌘ J shortcut comes in handy to jump to that file in the project navigator.

4. Find

Whether it's within the currently opened file or throughout the project/workspace, searching is another essential action:

Find ⌘ F
Find and replace ⌥ ⌘ F
Find in project / workspace ⇧ ⌘ F

5. View

Being able to show and hide different Xcode areas quickly is really useful especially when working on smaller screens:

⌘ 0 to show and hide the project navigator
⌘ ⇧ Y to show and hide the debug console
⌘ ⌥ 0 to show and hide the inspectors

6. Quickly open two files side by side

I already mentioned the Open quickly ⌘ ⇧ O command - which becomes even more powerful when using it with ⌥.

Use ⌘ ⇧ O to open the dialog
Enter the file name you are searching for
Use ⌥ in combination with enter to select the file. The new file will open in a separate editor allowing us to continue working on our current file while having access to the new opened file.

The ⌥ tip also works when selecting a file in the project navigator.

7. Quickly jump to a specific method in a file

This shortcut comes in particularly handy for larger files with numerous methods, where scrolling quickly becomes tedious.

Use ⌃ 6 to open the documents structure
Start typing the methods name
Use enter to jump to the method.

You can skip letters when typing, Xcode will do the work for you.

8. Repeat the last test

The ⌃ ⌘ ⌥ G shortcut is especially useful when writing tests to repeat the last test we were running.

9. Reindent code

We can re-indent selected code in Xcode by pressing ⌃ I - which is useful when code is out of place, for example after refactoring.

10. Disable / enable breakpoints

This ⌘ Y shortcut comes in handy when debugging code to toggle between enabling and disabling breakpoint.

Introduction to Combine for iOS developers with RxSwift experience

Sun, 07 Apr 2024 22:00:00 GMT

If you are already exprerienced with RxSwift, switching to Combine will mostly be a matter of learning new namings for similar concepts.

Let's directly jump in.

Publisher & Subscriber

A Publisher is what in RxSwift is an Observable. A publisher defines how values are produced and allows registration of a subscriber.

A Subscriber is what in RxSwift is an Observer. A subscriber receives values from the publisher after subscribing.

Let's remind how to create and subscribe to an Observable in RxSwift first:

let observable = Observable.from([1, 2, 3, 4])
observable.subscribe(onNext: { value in
    print(value)
}, onCompleted: {
    print("completed")
})

And here how it looks to create and register to a Publisher in Combine:

let publisher = Publishers.Sequence<[Int], Error>(sequence: [1, 2, 3, 4])
publisher.sink(receiveCompletion: { _ in
    print("completed")
}) { value in
    print(value)
}

Both examples produce the same output:

1
2
3
4
completed

SubjectType

A SubjectType is what in RxSwift is a Subject, so the name is not that different in this case. Only the subtypes of a subject were named differently.

There are two kinds of a subject type in Combine: PassthroughSubject and CurrentValueSubject.

A PassthroughSubject is what in RxSwift is a PublishSubject. If you subscribe to it you will get all events that happen after you subscribed.

A CurrentValueSubject is what in RxSwift is a BehaviourSubject. It behaves like a PassthroughSubject but it also will send it's most recent element to new subscribers.

In RxSwift, creating a subject and sending values to the observer might look as follows:

let subject = PublishSubject<String>()
subject.asObservable().subscribe(onNext: { value in
    print(value)
})

subject.onNext("Yes")
subject.onNext("Ve")
subject.onNext("gan")

The equivalent in Combine:

let subject = PassthroughSubject<String, Never>()
subject.eraseToAnyPublisher().sink { value in
    print(value)
}

subject.send("Yes")
subject.send("Ve")
subject.send("gan")

Both examples produce the same output:

Yes
Ve
gan

If you like going deeper, you can find a good comparison of available RxSwift und Combine components here.

Operators

Many operators like map, flatMap, reduce etc. that are available in RxSwift are also available in Combine. Using Combine operators is just like using RxSwift operators.

So it should feel really familiar to see Combine operators in action:

Publishers.Sequence(sequence: [1, 2, 2, 3, 3, 4, 7])
    .map { $0 * 2 }
    .filter { $0.isMultiple(of: 2) }
    .dropFirst(3)
    .removeDuplicates()
    .sink { value in
        print(value)
}

This code produces the following output:

6
8
14

A full comparison list of RxSwift und Combine operators is available here.

Error Handling

A notable difference between RxSwift’s Observable and Combine’s Publisher is the error handling. In RxSwift, we work with the general Error type whereas in Combine we can use any kind of custom error:

let publisher = Publishers.Sequence<[Int], SomeCustomError>(sequence: [1, 2])

If a subject can never fail, Combine provides the Never type:

let subject = PassthroughSubject<String, Never>()

Memory Management

To deal with ARC and memory management, RxSwift provides a DisposeBag. In Combine, we can use a collection of AnyCancellables.

Here is an example of how a DisposeBag is typically used in RxSwift:

let disposeBag = DisposeBag()

let subject = PublishSubject<String>()
subject.asObservable().subscribe(onNext: { value in
    print(value)
}).disposed(by: disposeBag)

And here is the equivalent example in Combine:

var cancellables = Set<AnyCancellable>()

let subject = PassthroughSubject<String, Never>()
subject.eraseToAnyPublisher().sink { value in
    print(value)
}.store(in: &cancellables)

Performance

I didn't compare the performance of RxSwift and Combine myself but there are some great articles about it. They all agree that Combine is clearly faster than RxSwift.

If you are interested in more specifics, you can find some performance tests and its results here. The tests compare the performance of the most commonly used components and operators in RxSwift and Combine.

Quick tip on how to learn Xcode keyboard shortcuts efficiently

Sun, 07 Apr 2024 22:00:00 GMT

Knowing Xcode keyboard shortcuts is key to be more productive while developing iOS applications. But memorizing a lot of shortcuts can prove tedious, especially when starting out.

The following quick tip allowed me to integrate an efficient learning process into my development workflow.

The key is to be able to lookup a shortcut real quick, so we can learn them on the fly while developing.

An efficient way to lookup a shortcut quickly is by opening Xcodes help menu and typing in the action. Xcode will make suggestions so we can directly see the shortcut, use the escape key to close the help menu and then use the looked up shortcut to perform the action.

For me, this technique payed out real soon, I memorized the shortcuts automatically when using them on a daily basis.

Since there is no keyboard shortcut for opening Xcodes help menu, we can create our own custom shortcut by going to System Settings > Keyboard > Shortcuts > App Shortcuts > Show Help menu.

How to avoid using AnyView in SwiftUI

Sun, 31 Mar 2024 22:00:00 GMT

SwiftUI provides the type-erased view AnyView that can be used as a wrapper for any other SwiftUI view, for example to be able to return multiple view types from a function.

While using AnyView might be a valid choice in some cases, we should use alternatives where possible. The reason is that SwiftUI works with a so called structural identity mechanism, which uses the view's type to identify it and to determine when they should be updated. Since AnyView erases the type of the view, it reduces SwiftUI’s ability to efficiently update the view.

There are different possibilities which can help us avoiding AnyView:

Using @ViewBuilder attribute instead of AnyView
Using Group instead of AnyView
Using Generics instead of AnyView

Let's jump in and look at each possibility in more detail.

Using `@ViewBuilder` attribute instead of `AnyView`

Let's look at an example where we might be tempted to use AnyView:

private var nameView: some View {
    if isEditable {
        return TextField("Your name", text: $name)
    } else {
        return Text(name)
    }
}

When defining view properties or functions that return a view, we often use the some View opaque return type so we don't need to explicitly define an exact return type.

But the above code won't compile with the error message Function declares an opaque return type, but the return statements in its body do not have matching underlying types.

To resolve the error and return the same type for both views, we might be tempted to wrap them in AnyView.

private var nameView: some View {
    if isEditable {
        return AnyView(TextField("Your name", text: $name))
    } else {
        return AnyView(Text(name))
    }
}

But there is a more elegant and more performant solution to solve the compiler error - the @ViewBuilder attribute.

The @ViewBuilder attribute allows us to compose multiple views into a single return type:

@ViewBuilder
private var nameView: some View {
    if isEditable {
        TextField("Your name", text: $name)
    } else {
        Text(name)
    }
}

All we have to do is to add the attribute to our property or function and remove the return statements.

That's the same mechanism the body of a SwiftUI view uses. The only difference is that we explicitly have to add the ViewBuilder attribute on our own properties and functions.

Using Group instead of AnyView

By using the Group type, we can collect multiple views into a single one without affecting the layout of those views.

private var nameView: some View {
    Group {
        if isEditable {
            TextField("Your name", text: $name)
        } else {
            Text(name)
        }
    }
}

Since Group uses ViewBuilder, we can group different kinds of views with conditional statements.

Using Generics instead of AnyView

Another common situation where we might be tempted to use AnyView is when we need to store a view without knowing its type:

struct FlyoutView: View {

    let headerView: AnyView

    var body: some View {
        VStack {
            headerView
            Spacer()
            // other views
        }
    }
}

In the example above, we want the headerView to be of a flexible type. Since we can't use some View for stored properties, AnyView seems like a good choice.

A more elegant and performant solution would be using generics.

struct FlyoutView<HeaderView> : View where HeaderView : View {

    let headerView: HeaderView

    var body: some View {
        VStack {
            headerView
            Spacer()
        }
    }
}

When creating a FlyoutView, we don't need to wrap the header view in AnyView.

FlyoutView(headerView: Text("Header view"))

The same generics approach is used by many views provided by SwiftUI.

struct VStack<Content> : View where Content : View {
}

As we can see above, the content view of a VStack is of a generic type that conforms to View.

Conclusion

Using AnyView can be avoided in most situations. The shown alternatives not only add more performance to our SwiftUI views, they also result in a more elegant and readable code.

How to use Swift's logging API

Sun, 24 Mar 2024 23:00:00 GMT

Logging is an essential aspect in software development, enabling developers to track and understand the behavior of their applications.

Swift's logging API is part of the os framework providing different logging levels, categories, persistence, formatting and privacy features.

Let's look at how to use it.

Let's directly jump in and look at the following example:

import os

let logger = Logger()
logger.log("Starting video with title \(title, privacy: .public)")

We can log any type confirming to CustomStringConvertable. The log outputs appear in Xcode's console while running the app. With a connected device, we can use the Console.app from the Utilities folder.

Alternatively, we could initialize the logger as follows:

let logger = Logger(subsystem: "someSubsytem", category: "someCategory")

the subsystem parameter can for example be the bundle identifier of your app.
the category parameter can be used to structure logs from different parts of the app.

Logging Levels

The API provides five log levels:

Debug
Info
Notice (default)
Error
Fault

The Logger instance provides corresponding methods such as debug, info etc. For example, to log an API error:

logger.error("Missing field \(field) in response from \(endpoint).")

Persistence

Logs are archived to retrieve them later from the device. To browse through persisted messages from your device, connect the device and open Console.app that is preinstalled in the Utilities folder.

Only logs that are persisted can be retrieved after execution. Whether or not a log message is persisted depends on the log level. The Notice, Error and Fault messages are persisted.

Performance

According to Apple, the logging system is very performant, so you can use it widely in your app without slowing it down. Unlike with print, log messages are not fully converted into a string representation. Instead, the compiler and the logging library work together to produce an optimized representation of the log message.

Privacy

Nonnumeric values in your logs are configured as private by default, so they are hidden in the message. This makes sure, that after shipping the app, the logs don't show any personal information. For example:

logger.log("Logging in user with email \(emailAddress)")

The statement above will produce the following log message:

Logging in user with email <private>

If the information you are logging should not be hidden, you have to explicitly mark it as public:

logger.log("Opening video \(videoId, privacy: .public)")

Conclusion

One thing I'm personally missing when comparing the API with third party libraries, is the ability to retrieve all messages from the Logger instance, for example to be able to show the logs directly within the application.

How to support dark mode in SwiftUI programmatically

Sun, 17 Mar 2024 23:00:00 GMT

To add support for dark mode in an iOS application, Apple provides so called semantic colors which means they can have multiple values.

In this article, we'll look at how to define and use those semantic colors in code without using the asset catalog.

Let's directly jump in.

At first, let's take a short look at how to define semantic colors via an asset catalog. Xcode provides a convenient way to do so:

Defining semantic colors via asset catalog.

To use that color in code, we call:

Color("primary")

When working with raw strings as shown in the example above, we loose type safety. To improve that, we could either

combine asset catalog with encapsulation

define these colors programmatically

The first option could look as follows:

extension Color {
    static let primary = Color("primary")
    static let secondary = Color("secondary")
}

Text("Some text")
     .foregroundColor(.primary)

Another way is to not to use asset catalogs entirely but to define colors programmatically instead.

Defining colors programmatically

For the programmatic approach, we can use the userInterfaceStyle property of UITraitCollection to find out which color to use:

extension UIColor {
    static func dynamicColor(light: UIColor, dark: UIColor) -> UIColor {
        return UIColor { $0.userInterfaceStyle == .dark ? dark : light }
    }
}

With the extension in place, we can use it as follows:

struct Colors {
    var primary: Color {
        return color(light: UIColor(red: 0.7, green: 1, blue: 0.7, alpha: 1),
                     dark: UIColor(red: 0.5, green: 1, blue: 0.5, alpha: 1))

    private func color(light: UIColor, dark: UIColor) -> Color {
        return Color(UIColor.dynamicColor(light: light, dark: dark))
    }
}

Alternatively, we can use the same approach in a color extension.

Only supporting light mode

A quick tip at the end: as long as you are not supporting dark mode, set Info.plist key UIUserInterfaceStyle to Light.

This way, we can avoid unwanted appearance effects when users use your app with dark mode turned on.

Safe array subscription in Swift

Sun, 17 Mar 2024 23:00:00 GMT

The possibility to use optionals in Swift allows us to write safe and expressive code. However, accessing elements from an array is not safe by default.

Let's look at an example:

let shoppingList = ["apples", "raspberries"]
let item = shoppingList[2]

Accessing an element this way will crash the app if the element isn't there.

By adding the following extension to our code base, we have the possibility to access it in a safe way.

extension Collection {

    /// Returns the element at the specified index if it exists, otherwise nil.
    subscript (safe index: Index) -> Element? {
        return indices.contains(index) ? self[index] : nil
    }
}

We know can access the item with conditional binding:

if let item = shoppingList[safe: 2] {
    // use item
}

How to use TipKit to create tool tips in SwiftUI

Sun, 03 Mar 2024 23:00:00 GMT

At WWDC23, Apple introduced TipKit which allows us to show feature hints to the user with a few lines of code.

Let's directly jump in and see how it works.

The following image shows an example of a TipKit popover hint that is shown over a toolbar button when the user opens the view for the first time.

Example of a TipKit popover

The tip shown above can be implemented by following these steps:

Defining a tip which conforms to the Tip protocol
Initializing and configuring tips on app start
Displaying the tip on top of the desired view using popover tips

Let's look at each step in more detail.

1. Defining a tip which conforms to the `Tip` protocol

The first step is to define our custom tip which conforms to Tip which is a protocol defined by TipKit:

import TipKit

struct EditShoppingListRecipesTip: Tip {
    // 1.
    var title: Text {
        Text(LocalizedStringKey("common.shoppingList.edit.tip.title"))
    }

    var message: Text? {
        Text(LocalizedStringKey("common.shoppingList.edit.tip.message"))
    }

    var image: Image? {
        Image(systemName: "square.and.pencil")
    }

    // 2.
    var options: [Option] {
        [MaxDisplayCount(1), IgnoresDisplayFrequency(true)]
    }
}

The Tip protocol provides different properties which we can use to configure the tip's UI components like title, message and image.
Additionally, we can specify the options property, for example to configure the maximum number of times a tip displays or to control whether a tip obeys the preconfigured display frequency interval.

Furthermore, we could specify rules for our tip to add even more control when to show it to the user. To learn more about rules, check out this article (coming soon).

2. Initializing and configuring tips on app start

The next step is to initialize tips on app start. All we need to do here is to call Tips.configure() once per app session, for example in the init() method of the app.

struct RecipesApp: App {

    ...

    var body: some Scene {
        WindowGroup {
            AppRootView()
                ...
        }
    }

    init() {
        try? Tips.configure()
    }
}

If needed, we could pass in a configuration, for example to set the display frequency:

Tips.configure([.displayFrequency(.daily)])

When set, the system will not show more than one tip per day.

3. Displaying the tip on top of the desired view using popover tips

The last step is to call the tip by using SwiftUI's popoverTip modifier.

private var editingModeTip = EditShoppingListRecipesTip()

var body: some View {
    ...
    Image(systemName: "square.and.pencil")
        .popoverTip(editingModeTip)
}

With that in place, the system will show the tip to the user once the editing button becomes visible.

Instead of a popover, TipKit also provides the possibility to show the tip inside any SwiftUI view by using TipView, for example:

VStack {
    TipView(tip)
    ContentView()
}

How to delay an animation in SwiftUI

Sun, 25 Feb 2024 23:00:00 GMT

When working with animations in SwiftUI, we sometimes need to delay an animation, for example when showing a UI element to users and then hiding it after a certain amount of time.

Let's jump right in and see how to do that.

Let's look at the following example:

@State private var offset = -60.0 // 1.

var body: some View {
    ErrorView()
        .offset(y: offset)
        .onAppear {
            // 2.
            withAnimation(.bouncy) {
                offset = 60.0
            } completion: {
                // 3.
                withAnimation(.bouncy) {
                    offset = -60.0
                }
            }
        }
}

What we do in the code above is:

Setting the initial offset of the view out of screen bounds so it's not visible at first.
As soon as the view appears, we animate it to a different offset so it becomes visible on the screen.
As soon as the animation is completed, we animate the view back to a non-visible offset.

What is missing in the example is a delay, so the view stays on the screen for a few seconds before bouncing back.

Since delays are built-in into SwiftUI animations, we can achieve this with one simple call. All we need to do is to add a delay to our second animation:

withAnimation(.bouncy.delay(3))

How to define one-to-many relationships in SwiftData

Sun, 18 Feb 2024 23:00:00 GMT

In this article, we will look at how to define one-to-many relationships in SwiftData. If you are new to SwiftData, check out this developer guide on SwiftData first.

Let's directly jump in.

Relationships in SwiftData can only be defined between reference types, i.e. classes. Let's look at an example of a one-to-many relationship:

@Model
class User {
    @Relationship(inverse: \Note.user) var notes: [Note]?

    init(notes: [Note]? = nil) {
        self.notes = notes
    }
}

@Model
class Note {
    var user: User
    var title: String
    var text: String

    init(user: User, title: String, text: String) {
        self.user = user
        self.title = title
        self.text = text
    }
}

In the example above, we use the @Relationship macro to define a one-to-many relationship between a user and their notes. With that in place, if we now create a new Note for example, this note will automatically be added to the user's list of notes.

An interesting fact to know here is that when both relationship ends are declared as optional, SwiftData will automatically infer an inverse relationship even without the @Relationship macro.

Furthermore, we can use the @Relationship macro to specify delete rules. By default, SwiftData uses the .nullify delete rule which only nullifies the related model's reference to the deleted model. That means that if in our example above a User gets deleted, then their notes will stay intact in our data store. In some cases that's the behaviour we want, but in our example, we'd like to delete the user's notes when the user gets deleted. For that, we can use the .cascade delete rule:

@Model
class User {
    @Relationship(deleteRule: .cascade) var notes: [Note]?
}

With a .cascade rule, all user related notes will be deleted whenever the user is deleted.

Getting started with Apollo iOS for GraphQL in Swift

Sun, 11 Feb 2024 23:00:00 GMT

In this article on GraphQL essentials, we looked at what GraphQL is and how it differs from a REST approach.

Now, we are going to look at how we can implement a networking GraphQL layer by using Apollo in our iOS applications.

Let's get started.

Apollo iOS is an open-source GraphQL framework for iOS written in Swift. We can use it to automatically generate Swift queries from a GraphQL scheme and GraphQl query files.

To begin using Apollo iOS, the following steps are recommended:

Adding Apollo as dependency using the Swift Package Manager
Installing Codegen CLI provided by Apollo which helps with schema introspection and code generation.
Configuring code generation options by creating the configuration file apollo-codegen-config.json.
Downloading a schema from the GraphQL endpoint which Apollo needs to generate Swift types.
Creating queries which will be converted to Swift types by Apollo.
Execute queries and handle responses by using pregenerated functions.

Let's look at each step in more detail.

1. Adding Apollo dependency

Apollo offers the common options to install the library into an iOS project. For example by using the Swift Package Manager, we can add the following package: https://github.com/apollographql/apollo-ios.git.

Adding Apollo package with SPM

Within the dialog which offers different packages to install, only choose Apollo for now:

Choosing Apollo package.

2. Installing Codegen CLI

The Apollo iOS SPM package includes the Codegen CLI as an executable target. To install it, we can right-click on the project in Xcode's file explorer using the Install CLI command:

Installing Codegen CLI.

After installing the plugin, a symbolic link to the Codegen CLI is created in the project's root folder. We can now run the CLI from the command line with ./apollo-ios-cli which we'll use in later steps.

Note that apollo-ios-cli only works if the compiled CLI executable exists which is located in Xcode's Derived Data or .build folder. If these are cleared, we need to rerun the Install CLI plugin to rebuild the executable.

3. Configuring code generation options

As a next step, we create a configuration file named apollo-codegen-config.json. The Codegen CLI uses this file to configure the code generation engine.

We can use the Codegen Cli to create and prefill this file for us with default values by running:

./apollo-ios-cli init --schema-namespace ExampleAppAPI --module-type swiftPackageManager

The command above generates the apollo-codegen-config.json file in our project's root folder with the following content:

{
  "schemaNamespace" : "ExampleAppAPI",
  "input" : {
    "operationSearchPaths" : [
      "**/*.graphql"
    ],
    "schemaSearchPaths" : [
      "**/*.graphqls"
    ]
  },
  "output" : {
    "testMocks" : {
      "none" : {
      }
    },
    "schemaTypes" : {
      "path" : "./exampleAppAPI",
      "moduleType" : {
        "swiftPackageManager" : {
        }
      }
    },
    "operations" : {
      "inSchemaModule" : {
      }
    }
  }
}

This default configuration will:

find all GraphQL schema files ending with .graphqls within our project directory.
find all GraphQL query files ending with .graphql within our project directory.
generate Swift code for schema types and queries in a directory named ExampleAppAPI when we use the CLI to generate code.

Before we can generate code, we need a GraphQL schema. Let's look at how to download it.

4. Downloading a GraphQL schema

A GraphQL schema serves as a contract between the client and the server, defining how clients can query or mutate data.

We can download the schema with the Codegen CLI by using the following command:

./apollo-ios-cli fetch-schema

The above command won't work yet. First, we need to add info to the configuration file about where to fetch the schema:

"schemaDownloadConfiguration": {
    "downloadMethod": {
        "introspection": {
            "endpointURL": "http://localhost:4000/graphql",
            "httpMethod": {
                "POST": {}
            },
            "includeDeprecatedInputValues": false,
            "outputFormat": "SDL"
        }
    },
    "downloadTimeout": 60,
    "headers": [],
    "outputPath": "./graphql/schema.graphqls"
}

Now, after running fetch-schema we should see a graphql folder in the project directory containing a schema.graphqls file.

5. Creating queries

Now, we can start creating queries, for example by copying them from the Apollo Sandbox. To add a query to an iOS project, we at first create a new file with a .graphql extension and then paste the query into it, for example:

RecipeFeedQuery.graphql

query RecipeFeed {
  recipeFeed {
    id
    imageUrl
    name
    creator {
      id
      profile {
        caption
        imageUrl
        name
      }
    }
  }
}

6. Executing queries and handle responses

Finally, after building the project, we can now execute the query by using functions Apollo generated for us:

import Apollo
import ExampleAppAPI


let apolloClient = ApolloClient(url: endpointUrl)
apolloClient.fetch(query: RecipeFeedQuery()) { result in
    switch result {
    case .success(let response):
        print(response.data?.recipeFeed)
    case .failure(let error):
        print(error)
    }
}

Get started with auto‑renewable subscriptions for iOS

Sun, 10 Dec 2023 23:00:00 GMT

Apple provides 4 different types of in-app purchases that allow us to offer revenue generating content and features to users:

Consumable for recurring purchases that users can consume.
Non-consumable for one-time purchases that don’t expire.
Auto‑renewable subscriptions for subscriptions that renew automatically at the end of each subscription period until the user cancels.
Non-renewing subscriptions for subscriptions that expire after a fixed duration and require the user to manually renew them.

In this article, we'll take a closer look at auto‑renewable subscriptions, on how they work and how we can implement them using StoreKit and SwiftUI.

Let's get started.

Overview

Auto‑renewable subscriptions allow users to pay for access to premium features or content on a recurring basis, typically on a monthly or yearly basis. They are perfect for apps that offer ongoing access to premium content, services or features.

To implement auto‑renewable subscriptions, the following basic steps are required:

Configure subscriptions in App Store Connect or through a local StoreKit configuration file for testing.
Load and show subscriptions options in the iOS application.
Unlock content when a user subscribes.
Add support for restoring in-app purchases.

Let's look at each step in more detail.

1. Configure auto‑renewable subscriptions

To configure suscriptions through App Store Connect, we need an Apple Developer Account and a configured app in App Store Connect. For testing purposes, we can alternatively setup a StoreKit configuration file locally in Xcode which we'll do in this article. To learn more about StoreKit configuration files, check out this article on StoreKit Testing in Xcode.

Every subscription is part of a group. Users can only subscribe to one subscription of the same group at a time, but can change to another subscription in the same group. When adding our first auto-renewable subscription, we'll be asked to enter a group name.

The setup above shows a subscription group named subscriptionOptions which contains two different subscription options: a premium.yearly and a premium.monthly subscription.

For every subscription option, we can setup a price, duration, free trial periods and more. To learn more on how to setup and display a free trial period, check out this article on introductory offers in StoreKit 2.

2. Load and show subscriptions options in the iOS application

After setting up subscrition options, we can load and show subscriptions options in our iOS application. In StoreKit 2, a subscription is represented by the Product struct. We can load products by calling its products(for:) method:

let subscriptions = try await Product.products(for: ["premium.yearly", "premium.monthly"])

Each product has properties which we can use to display subscription infos to the user. For example:

displayPrice which is a localized string representation of the subscription price
displayName which is a localized display name of the subscription
subscription.subscriptionPeriod.unit which we can use to display the period info for the subscription
subscription.introductoryOffer which we can use to display introductory offers such as free trials

3. Unlock content when users subscribe

When a user decides to subscribe to one of the offered subscriptions, we can use the purchase method on the selected product:

let result = try await product.purchase()

This call will trigger Apple's native purchasing dialog providing us with the result after the user completes:

switch result {
case .success(let result):
    switch verificationResult {
    case .verified(let transaction):
        // Give the user access to purchased content.
        // Complete the transaction with transaction.finish()
    case .unverified(let transaction, let verificationError):
        // The purchase failed verification for the provided reason.
    }
case .pending:
    // The purchase is waiting for some user action.
    // Purchase may succeed in the future,
    // the resulting Transaction will be delivered via Transaction.updates
case .userCancelled:
    // The user cancelled the purchase.
default:
    break
}

4. Add support for restoring in-app purchases

When users reinstall our iOS app or download it on a new device, we want to make sure all in-app purchases the user previously made are restored. Restoring subscriptions works the same way as for any other StoreKit 2 products. Check out this article on how to restore in-app purchases with StoreKit 2 to learn more.

Introduction to Kotlin for Swift developers - protocols, extensions & generics

Fri, 01 Dec 2023 23:00:00 GMT

In the first part of Kotlin for Swift developers, we looked at the basics of Kotlin like variables, functions & control flow.

In the second part, we looked at classes, structs and enums and how those are similar or differentiate from Swift.

In this part, we'll do the same for protocols, extensions and generics.

Let's get started.

Protocols

As an equivalent to Swift protocols, Kotlin provides interfaces. Like Swift's protocols, interfaces in Kotlin can contain declarations of abstract methods and properties as well as method implementations, but cannot store state.

Here is an example of an interface in Kotlin:

interface Purchasable {

    var price: BigDecimal

    fun purchase()
    fun newUserDiscount(): BigDecimal {
        return price - ...
    }
}

class Chocolate : Purchasable {

    var price: BigDecimal = BigDecimal("3.99")

    override fun purchase() {
        // ...
    }
}

As we can see above, we can provide a default method implementation when working with Kotlin interfaces. In Swift, we can achieve the same with protocol extensions.

Extensions

Similar to Swift, Kotlin provides extensions that allow us to extend a class or an interface with new functionality. An example of an extension function in Kotlin might look as follows:

fun Animal.run() {
    println("Running")
}

The equivalent in Swift looks as follows:

extension Animal {
    func run() {
        print("Running")
    }
}

Similar to Swift, extensions in Kotlin cannot have stored properties, but computer properties are allowed:

val Animal.description: String
    get() = "name: $name, age: $age"

Generics

Generics are a powerful feature in programming languages that enable us developers to write flexible and reusable code.

Similar to Swift, Kotlin provides the possibility to create generic functions and generic types, for example:

class Stack<Element>(initialItems: Array<Element>) {
    private var items: Array<Element> = initialItems
}

val stack = Stack<Int>(intArrayOf(1, 2, 3))

In Swift, the same example looks as follows:

class Stack<Element> {
    private var items: [Element] = []

    init(items: [Element]) {
        self.items = items
    }
}

let stack = Stack<Int>(items: [1, 2, 3])

As we can see above, there are almost no differences when defining generic types.

The same applies to generic functions - which look as follows in Kotlin:

fun <Element> add(item: Element) {
}

fun <Element: SomeInterface> add(item: Element) {
}

In Swift:

func add<Element>(item: Element) {
}

func add<Element: SomeProtocol>(item: Element) {
}

As we can see, the only difference is the position of the placeholder type name.

How to store images in SwiftData

Sun, 26 Nov 2023 23:00:00 GMT

SwiftData allows us to store images by using the Data type, for example:

@Model
class Recipe {
    var imageData: Data
}

When working with larger or many images, it might be a good idea to separate them from the model storage and store them in an external file. For that, SwiftData provides the .externalStorage attribute:

@Attribute(.externalStorage)
var imageData: Data?

With that in place, we tell SwiftData to store the image data in external storage managed by SwiftData, which may lead to improved performance when working with larger amounts of data.

How to migrate to a new schema with SwiftData in iOS

Sun, 19 Nov 2023 23:00:00 GMT

Whenever we release a new version of our app where we made changes to our SwiftData models, we need to make sure that SwiftData is able to migrate between the old and the new schema to prevent data loss.

Let's directly jump in and look at how to create a migration plan in SwiftData.

The basic steps of a migration with SwiftData are:

Use VersionedSchema to create versions of SwiftData models
Use SchemaMigrationPlan to order the created versions
Define a migration stage for each migration - which can be lightweight or custom

Let's look at each step in more detail.

1. Use `VersionedSchema` to create versions of SwiftData models

If we want to make a change to a SwiftData model, the first thing to do is to create a schema version for the old model. For example:

enum UserSchemaV1: VersionedSchema {
    static var versionIdentifier = Schema.Version(1, 0, 0)

    static var models: [any PersistentModel.Type] {
        return [User.self]
    }

    @Model
    class User {
        @Attribute(.unique) var id: String
        var validated: Bool
        ...
    }
}

enum UserSchemaV2: VersionedSchema {
    static var versionIdentifier = Schema.Version(2, 0, 0)

    ...

    @Model
    class User {
        @Attribute(.unique) var id: String
        @Attribute(originalName: "validated") var isValidated: Bool
    }
}

The above example shows two schema versions each containing the model classes they define. In the second version, we renamed the validated property to isValidated and marked it with an appropriate attribute. With that in place, SwiftData can migrate those two versions with a lightweight migration.

2. Use `SchemaMigrationPlan` to order the created versions

After defining a new version, we need to create a migration plan which describes how to handle the migrations from version to version:

enum UsersMigrationPlan: SchemaMigrationPlan {
    static var schemas: [any VersionedSchema.Type] {
        [UserSchemaV1.self, UserSchemaV2.self]
    }
}

With schemas, we tell the migration plan in which order the migration should be performed.

3. Define the migration stage for each migration

With that in place, we now can define the migration stage for each migration. A migration stage can be a lightweight or custom.

For a specific set of changes, SwiftData can perform a lightweight migration. Examples of those changes are adding, renaming or deleting entities, attributes or relationships, changing the relationship type and more.

Since we only renamed an attribute in our example and already annotated it, we can use the lightweight migration:

enum UsersMigrationPlan: SchemaMigrationPlan {
    static var schemas: [any VersionedSchema.Type] {
        [UserSchemaV1.self, UserSchemaV2.self]
    }

    static var stages: [MigrationStage] {
        [migrateV1toV2]
    }

    static let migrateV1toV2 = MigrationStage.lightweight(
        fromVersion: UserSchemaV1.self,
        toVersion: UserSchemaV2.self
    )
}

When changes exceed the capabilities of a lightweight migration, we need to do a custom migration which can look as follows:

static let migrateV1toV2 = MigrationStage.custom(
    fromVersion: UserSchemaV1.self,
    toVersion: UserSchemaV2.self,
    willMigrate: { context in
        // Custom steps before the migration begins
    },
    didMigrate: { context in
        // Custom steps after the migration
    }
)

As we can see above, the custom stage provides us with two closures, which we can use to perform an operation before or after the data is migrated.

How to implemet a free trial period for StoreKit 2 subscriptions in iOS

Sun, 12 Nov 2023 23:00:00 GMT

When setting up auto-renewable subscriptions for an iOS application with StoreKit 2, we might want to offer users a free trial period.

Let's look at how to do that.

Setting up a subscription with a free trial

When setting up a StoreKit subscription in App Store Connect or via a StoreKit test file, we have the possibility to setup an introductory offer.

Introductary offers.

As shown above, we can choose between 3 options:

Pay as you go - new subscribers pay an introductory price each billing period for a specific duration, for example 0.99 € per month for 3 months. After 3 months, subscribers pay the regular monthly price.
Pay up front - new subscribers pay a one-time introductory price for a specific duration, for example 0.99 € for 1 month. After 1 month, subscribers pay the regular monthly price.
Free trial - new subscribers access content for free for a specified duration. After the free trial period is over, they pay the regular price.

In our case, we choose the free trial option and select the duration of the free trial period.

Showing the free trial options in the iOS app

After setting up the free trial, the next step is to show it to eligible users. A user is not eligible if they already used an introductary offer of that subscription or a subscription of the same group before.

We can use the subscription's introductoryOffer property that will automatically be applied if the user is eligible. Alternatively, we can use the isEligibleForIntroOffer property on the subscription to check if the user is eligible:

func isEligibleForFreeTrial() async -> Bool {
    guard let subscription = product?.subscription else { return false }
    return await subscription.isEligibleForIntroOffer
}

The subscription's introductoryOffer offers different properties which represent the information we configured, for example:

introductoryOffer.paymentMode represents the configured payment option which may be payAsYouGo, payUpFront or freeTrial
introductoryOffer.period represents the period of the introductary offer

If we decide to offer another option such as payAsYouGo or payUpFront, we can also use properties like displayPrice or periodCount to show relevant information to the user.

How to get a SwiftData model container and context in SwiftUI

Sun, 29 Oct 2023 23:00:00 GMT

At WWDC23, Apple introduced SwiftData - a framework which focuses on persisting data by using declarative code. In this overview on SwiftData for iOS, we already looked at the basics of SwiftData.

In this article, we'll look at view modifiers which we can use to setup a SwiftData container and context directly in SwiftUI.

Let's get started.

In the previous article, we already learned on how to setup a SwiftData model container:

let modelContainer = try ModelContainer(for: User.self)

When working with SwiftUI, we can alternatively use the modelContainer view modifier as follows:

struct ExampleApp: App {

    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .modelContainer(for: [User.self])
    }
}

The example above creates a container for the whole window group scene. The window and its views will inherit the container.

If a view needs its own container, we can setup one in the same way by applying the modelContainer modifier to a specific view. Changes to one container won't affect another container.

When we setup the model container through the view modifier as shown above, it makes the model context available through the application's environment:

@Environment(\.modelContext) private var context

We can use the environment to get the model context in any SwiftUI view we need.

Introduction to bash scripting for iOS developers

Sun, 22 Oct 2023 22:00:00 GMT

Bash (or shell) scripting provides a powerful way to automate repetitive tasks and can save us developers a lot of time.

Using Bash scripting as an iOS developer can help perform a wide range of tasks such as automating build processes, managing file systems, running tests or and deploying applications. Any command we can run in the terminal can be run in a Bash script.

In this article, we'll look at the basics of Bash scripting and a practical example for iOS development.

Let's get started.

What is Bash?

Bash, short for Bourne Again Shell, is a command-line shell and scripting language widely used in Unix and Linux environments. It provides a way to interact with the operating system by executing commands and scripts.

Writing and running your first Bash script

Every Bash script file starts with #!/bin/bash on its own line. This way, the computer knows which type of interpreter to use for the script.

#!/bin/bash
echo "Hello world!"

We can save the code above in a file with a .sh extension, for example test.sh and then try and run it in the terminal by simply entering the path to the script:

/path/test.sh

A script file needs to have permission to be executed. In case of a permission error, run the following command:

chmod +x /path/test.sh

After running the script again, the Hello world! greeting should now be printed out in the terminal.

Basic scripting concepts

While Bash is primarily a scripting language, it incorporates many programming language elements. Here are some of the key ones:

1. Variables

In Bash scripting, variables are declared and used as follows:

#!/bin/bash
hello="Hello to you!"
echo $hello

As shown above, when accessing a value of a variable, we always prefix it with a $ sign.

2. Conditionals

Bash scripting supports if-else conditions:

if [ "$input" == "$name" ]
then
  echo "yes"
else
  echo "no"
fi

When working strings, it's best practice to put the variable into quotes to prevent errors when the variable contains spaces.

3. Loops

Bash scripts support for, while and until loops. Let's look at a for-loop example:

for name in 1 2 3 4 5
do
  echo $name
done

Alternatively to the sequence, we could setup a range {1..5} to achieve the same results.

4. Functions

Bash also supports functions:

function greet() {
    echo "Hello, $1!"
}

greet "Alice"

Function arguments are not defined as part of a function but accessed using $1, $2 etc.

There is more to discover like working with arrays and dictionaries, numeric calculations, error handling, file handling and more which is not covered by this article. Checkout this cheatsheet on Bash scripting to see more examples.

Handling user input

When writing a bash script, we often need some kind of outside input. A common way is to use input arguments that are entered when calling a script separated by spaces:

/path/test.sh argument1 argument2

Within the script, the arguments are accessed using $1, $2 etc.

Another possibility is to request user input with read:

echo "What's your name?"
read userInput
echo $userInput

Setup an alias

When working with a script, we can setup an alias so we don't need to use the full path every time we call it:

alias test='/path/test.sh'

Now we can call the script by using the alias:

testscript argument1 argument2

For a permanent alias, we can set it up in the .bash_profile file which is a hidden configuration file in the home directory.

Bash scripting for iOS example

Finally, let's look at a practical example on how we could use bash scripting for iOS development.

The following script automates taking screenshots of an iOS application for different devices and languages:

#!/bin/bash

// 1.
projectName="./exampleApp.xcodeproj"
schemeName="exampleApp"
simulators=("iPhone 14" "iPhone 13")
languages=("en" "de")
appearances=("light" "dark")

// 2.
targetFolder=$1

// 3.
for simulator in "${simulators[@]}"
do
    for language in "${languages[@]}"
    do
        for appearance in "${appearances[@]}"
        do
            // 4.
            xcrun simctl boot "$simulator"
            xcrun simctl ui "$simulator" appearance $appearance

            xcodebuild -testLanguage $language -scheme $schemeName -project $projectName -destination "platform=iOS Simulator,name=$simulator" build test

            xcparse screenshots /path/to/xcresult "$targetFolder/$simulator/$language/$appearance" \;
        done
    done
done

Let's go through it step-by-step:

Defining variables that list devices, languages and appearance modes we'll use to take screenshots.
Defining the targetFolder variable and assigning it the first user input argument.
Looping through previously defined variables.
Using xcrun, xcodebuild and xcparse command line tools to start a simulator, run tests and to extract screenshots that were taken while running the tests.

Quick developer guide on SwiftData for iOS

Sun, 15 Oct 2023 22:00:00 GMT

At WWDC23, Apple introduced SwiftData - a framework which focuses on persisting data by using declarative code. SwiftData uses Swift's new macro system and is designed to work with SwiftUI.

Let's directly jump in and look at the basics on how SwiftData works.

Defining a schema with the `@Model` macro

The first step when trying to persist data in a data base is to define a model schema - which is a blueprint that outlines the structure and relationships within a database.

SwiftData introduces the @Model macro which lets us define our models directly with Swift. Let's look at a simple example:

@Model
class User {
    var name: String
    var notes: [Note]

    init(name: String, notes: [Note] = []) {
        self.name = name
        self.notes = notes
    }
}

When defining models with SwiftData, we can use all basic types as properties out of the box. We can also use custom types like structs and enums that conform to the Codable protocol.

SwiftData provides different ways to add meta data to properties which gives us control on how they are persisted. For example, we can use the @Attribute macro to add a uniqueness constraint to a property:

class User {
    ...
    @Attribute(.unique) var id: String
}

By default, SwiftData persists all non-computed attributes. In case we want to exclude properties from persisting, we can use the @Transient macro:

class User {
    @Transient var isValidated: Bool
}

To specify a relationship between two model classes, SwiftData provides the @Relationship macro. Check out this article to learn more about relationships in SwiftData.

Model container

SwiftData's model container represents the persistence backend which we can use to customize persistence behaviour or to control migration. To use SwiftData, an app needs to setup at least one model container.

We can setup a model container as follows:

let modelContainer = try ModelContainer(for: User.self)

When initializing a model container, we pass in all models we'd like to store.

If needed, we can additionally pass in a configuration, for example to use a certain storage location or to save the data in memory by using ModelConfiguration:

let configuration = ModelConfiguration(isStoredInMemoryOnly: true)
let container = try ModelContainer(for: schema, configurations: [configuration])

Model context

SwiftData's model context allows us to track updates, fetch models, save or undo changes.

We can create a model context as follows:

let context = ModelContext(container)

Now, we can use it to execute an action, for example to save a user:

context.insert(user)
try context.save()

Alternatively to creating a model container as shown above, SwiftUI provides a view modifier to setup a model container on a SwiftUI view and use the environment to get the model context. Check out this article on how to use SwiftData view modifiers with SwiftUI to learn more.

Fetching data

To get stored data, we can create a fetch descriptor and use it to fetch the data we need. For example a simple request to fetch all users might look as follows:

let fetchDescriptor = FetchDescriptor<User>()
let users = try modelContext.fetch(fetchDescriptor)

Additionally, we can pass in a predicate and a sort descriptor to filter and sort the results:

let descriptor = FetchDescriptor<User>(
                predicate: predicate,
                sortBy: sortDescriptor)

Swift provides a new fully type checked Predicate type for fetching data which is a replacement for NSPredicate. For example:

let predicate = #Predicate<User> {
    $0.id == someId
}

For SwiftUI, SwiftData additionally provides the @Query property wrapper which provides the view with the data.

Migration

When working with persistence, migration is often needed as soon as the schema changes. For example, if we need to rename some properties, change relationships and more.

SwiftData provides a VersionedSchema and SchemaMigrationPlan to define migration steps. Check out this article on how to migrate to a new schema with SwiftData to learn more.

How to restore in-app purchases with StoreKit 2 for iOS

Sun, 08 Oct 2023 22:00:00 GMT

When it comes to handling in-app-purchases in an app, we as developers need to make sure that as soon as users reinstall our iOS app or download it on a new device, all in-app purchases the user previously made are restored.

The best practice is to implement the following two options:

Restoring in-app purchases proactively, without the user needing to take any actions.
Providing a restore purchases button which users can use when they suspect that the app does not show all the transactions.

Let's look at how to do that.

If you need to refresh your knowledge on StoreKit 2, check out this article on getting started with StoreKit 2 for iOS.

Restoring in-app purchases proactively

StoreKit automatically keeps up to date transaction information and subscription status available in our app, even when users reinstall it or download it on a new device.

This means that when our app launches, all transactions are automatically available so we can use current entitlements to restore all in-app purchases as follows:

func refreshPurchasedProducts() async {
    for await result in Transaction.currentEntitlements {
        guard case .verified(let transaction) = result else { continue }
        if transaction.revocationDate == nil {
            self.purchasedProductIDs.insert(transaction.productID)
        } else {
            self.purchasedProductIDs.remove(transaction.productID)
        }
    }
}

Providing a restore purchases button

In case that the in-app purchases cannot be automatically restored, for example because the user is not logged in with the App Store, we should provide a restore purchases button which calls AppStore.sync():

Button {
    Task {
        do {
            try await AppStore.sync()
        } catch {
            print(error)
        }
    }
} label: {
    Text("Restore purchases")
}

Calling AppStore.sync() forces the app to obtain transaction information and subscription status from the App Store. It may display a system prompt that asks users to authenticate with their App Store credentials. Apple advices to only call this function in response to an explicit user action, like tapping a button.

Get started with StoreKit 2 for iOS

Sun, 01 Oct 2023 22:00:00 GMT

At WWDC21, Apple introduced a new version of StoreKit - StoreKit 2. The new in-app purchases API offers new features and improvements over the previous version, including async/await adaptation, more flexible payment options, improved testing and debugging tools.

In this article, we'll go though the StoreKit 2 API and learn how to use it to request in-app purchase products, how to purchase and validate them, how to restore in-app purchases, how to check user's entitlements and more.

Configuring products

The first step of offering in-app purchases in an iOS app is to create products we'd like to offer.

We can do that through App Store Connect or through a local StoreKit configuration file for testing. To get up and running quickly, we can just use a local StoreKit configuration file for now.

StoreKit configuration file.

Checkout this article on StoreKit testing in Xcode to get more details on how to setup a StoreKit configuration file.

Requesting products

After setting up the file, we can load the configured products to show them to the user.

To load available products, StoreKit 2 provides the following method:

let productIdentifiers = ["com.example.budget", "com.example.standard", " com.example.solidary"]
let products = try await Product.products(for: productIdentifiers)

Each Product has properties like displayName, description or displayPrice and more that we can directly use to show to the user.

If the product is an auto-renewable subscription, we can use the status and renewalInfo on the subscription property to provide users with appropriate informations about their subscription status.

Purchasing a product

If a user decides to purchase one of our products, we can call the purchase method on the selected product:

let result = try await product.purchase()

This method brings up a system confirmation sheet. The user can then confirm the purchase or cancel it.

The value of the purchase result represents the state of the purchase:

switch result {
case .success(let result):
    switch verificationResult {
    case .verified(let transaction):
        // Give the user access to purchased content.
        // Complete the transaction with transaction.finish()
    case .unverified(let transaction, let verificationError):
        // The purchase failed verification for the provided reason.
    }
case .pending:
    // The purchase is waiting for some user action.
    // Purchase may succeed in the future,
    // the resulting Transaction will be delivered via Transaction.updates
case .userCancelled:
    // The user cancelled the purchase.
default:
    break
}

Transactions & current entitlements

When offering paid content or features, we need to know which ones were already bought by a user to unlock them.

For that, StoreKit 2 provides access to current entitlements which lists all products the user is entitled to:

func refreshPurchasedProducts() async {
    for await result in Transaction.currentEntitlements {
        guard case .verified(let transaction) = result else { continue }
        if transaction.revocationDate == nil {
            self.purchasedProductIDs.insert(transaction.productID)
        } else {
            self.purchasedProductIDs.remove(transaction.productID)
        }
    }
}

Restoring in-app purchases

When users reinstall an iOS app or download it on a new device, we as developers need to make sure that all in-app purchases the user previously made are restored.

When it comes to restoring in-app purchases, Apple recommends doing it proactively, without the user taking any actions. This can be done by using the current entitlements described above.

Additionally, we can offer a restore in-app purchases button which calls AppStore.sync() to enforce the synchronisation of transaction information.

Check out this article to learn more on how to restore in-app purchases with StoreKit 2 .

Introduction to Kotlin for Swift developers - classes, structs & enums

Sun, 24 Sep 2023 22:00:00 GMT

If you are a iOS developer learning Kotlin - which is the main programming language for Android development - or you just want to explore another modern programming language, this article series may be for you.

In the first part of Kotlin for Swift developers, we looked at Kotlin variables, functions & control flow and how those are similar or different from Swift.

In this part, we'll do the same for classes, structs and enums.

Let's get started.

Classes

Classes in Kotlin and Swift share several similarities. Both represent reference types, support inheritance, interfaces and protocols, allow setting up initial values and behavior using constructors or initializers and more.

Let's look at an example of a Kotlin class:

Kotlin

class User(
    val name: String,
    val age: Int,
) {

    val allowAccess: Int
        get() = !this.isVerified

    private var isVerified: Bool = false

    init {
        // Constructor parameters name and age are available here
    }
}

val user = User("tanaschita", 34)

To a Swift developer, the constructor in Kotlin may seem a bit unusual. While in Swift, init parameters are defined as part of the init function, a Kotlin class constructor is defined as a part of the class header.

If some additional initialization code is needed, it can be defined in the init block where all constructor parameters are available.

The same code in Swift looks as follows:

Swift

class User {
    private let name: String
    private let age: Int
    private var isVerified: Bool = false

    var allowAccess: Int {
        return !isVerified
    }

    init(name: String, age: Int) {
        self.name = name
        self.age = age
    }
}

let user = User(name: "tanaschita", age: 34)

Structs

Additionally to classes, Swift offers structs for value types. For example:

struct Circle {
    let radius: Int
}

let circle = Circle(radius: 5)
let anotherCircle = circle

Since structs are value types, anotherCircle is a copy of circle and not a reference to circle.

Kotlin's value types are not as integral to the language as Swift's value types. To get similar behaviour, Kotlin provides data classes, for example:

data class Circle(val radius: Int)

When defining a data class, Kotlin automatically generates a copy() function, which can be used to get similar behaviour as Swift's struct:

val circle = Circle(5)
val anotherCircle = circle.copy()

Enums

Kotlin and Swift both support enumerations, which are used to represent a set of related values. A simple enumaration in Kotlin is very similar to Swift:

Kotlin

enum class Weekday {
    MONDAY, TUESDAY, WEDNESDAY ...
}

Swift

enum Weekday {
    case monday, tuesday, wednesday ...
}

We can provide a constructor for Kotlin enums, which is similar to rawValues in Swift enums:

Kotlin

enum class Weekday(val short: String) {
    MONDAY("mo"),
    TUESDAY("tue"),
    ...
}

Swift

enum Weekday: String {
    case monday = "mo"
    case tuesday = "tue"
    ...
}

A powerful feature of enums in Swift is that we can associate each state with a value, even with different types. For example:

enum Result {
    case success(String)
    case error(Int)
}

We can't do that with Kotlin enums. To achieve similar behaviour, we can use Kotlin's sealed classes.

sealed class Result {
    data class Success(val data: String) : Result()
    data class Error(val errorCode: Int) : Result()
}

fun handleResult(result: Result) {
    when (result) {
        is Result.Success -> {
            println("Success: ${result.data}")
        }
        is Result.Error -> {
            println("Error: ${result.errorCode}")
        }
    }
}

How to intercept and edit a server response with Proxyman for iOS

Sun, 17 Sep 2023 22:00:00 GMT

When developing iOS applications, sending and receiving network requests is an essential part of almost every application. During the development or testing process, we often need to test different scenarios on how our app behaves with different server responses.

To be able to do that, we can use Proxyman - which is a proxy server app that enables us to view, inspect and change networking traffic coming in and out from our iOS application.

In this article, we are going to look at how to intercept and change a server response before receiving it on an iOS device or simulator with Proxyman's breakpoint tool. If you are new to Proxyman, check out this guide to get started with Proxyman for iOS.

Let's get started.

Let's say, we are developing an iOS application which shows quotes depending on a tag which a user selected. For that, the application sends the following request:

https://api.quotable.io/quotes?tags=technology

With an answer looking as follows:

{
  "count": 20,
  "totalCount": 50,
  "page": 1,
  "totalPages": 3,
  "lastItemIndex": 20,
  "results": [
    {
      "id": "KMTJ0Ya3e9",
      "author": "Thomas Edison",
      "content": "To invent, you need a good imagination and a pile of junk.",
      "tags": ["Creativity", "Science", "Technology"]
    },
    {
      "id": "sXhSm0WMZqL",
      "author": "Alan Watts",
      "content": "Technology is destructive only in the hands of people who do not realize that they are one and the same process as the universe.",
      "tags": ["Technology"]
    },
    ...

After receiving the response, we show the results in a list.

We also implemented an no results view to show to the user when no quotes are available for a certain tag, so we'd like to test that by changing the response to an empty list.

To change the response to be able to test that scenario, we can follow these steps:

1. Creating a breakpoint

One way to create a breakpoint is to right-click on the request and select tools > breakpoint:

Creating a breakpoint with Proxyman.

After doing that, Proxyman opens a settings dialog where we can configure whether we'd like to intercept the request, the response or both and define matching rules for the url to match.

Breakpoint settings.

In our example, we use the wildcard * for the tags query value to intercept the response for any tag. Since we only want to edit the response, we leave the request option unchecked.

2. Intercepting and modifying the response

After configuring the breakpoint, we can now send a request we'd like to intercept. After doing that, Proxyman will open the following window when receiving a response:

Intercept and change a response.

In this window, we can edit the response the way we want, for example to an empty results array - as shown above. To continue, we can use the execute button in the bottom right corner.

With this simple setup, we can test many different scenario concerning the server communication. The Breakpoint tool is not only suitable to modify the response's body. We can also use it to modify headers or status code, for example to test different server errors.

How to manually subscribe to changes of SwiftUI's @Observable objects

Mon, 21 Aug 2023 22:00:00 GMT

At WWDC23, Apple released a new Observation framework for SwiftUI. We already covered the basics in this article on how to migrate from ObservableObject to the Observation macro in SwiftUI.

In this article, we'll dive a bit deeper and look at how we can subscribe to changes of @Observable objects manually. Let's get started.

When working with @Observable marked objects within SwiftUI views, SwiftUI automatically takes care of tracking changes und updating views when needed. But there are still use cases, where we need to manually subscribe to those changes, for example to trigger actions such as dismissing a view or to trigger view unrelated actions such as persisting data o.s.

When working with @Published properties, we have the opportunity to access the Combine publisher for a property by prefixing it with an $ to suscribe to property changes, for example:

class UserViewModel: ObservableObject {
    @Published var name = ""

    func subscribeToChanges() {
        cancellable = viewModel.$name.sink { [weak self] newValue in
            print(newValue)
        }
    }
}

With the Observation framework, we can't do that anymore. For tracking changes outside of SwiftUI, it provides the withObservationTracking(_:onChange:) method.

Let's look at an example:

@Observable
class UserViewModel {

    var name: String = ""

    func subscribeToChanges() {
        withObservationTracking {
            _ = name
        } onChange: { [weak self] in
            guard let self else { return }
            print(self.name)
        }
    }
}

As we can see above, the functions takes two closures as its parameters: apply and onChange. The apply closure contains which properties to track and the onChange closure is invoked when the value of a property changes.

There are two important differences to the mentioned Combine publisher approach though:

The onChange closure is called right before the new values are set, so we don't have access to the new values in the onChange closure
The onChange method is only called once - when one of the tracked values changes - and is never called again.

Unfortunately, the Observation framework does currently not provide an API to be able to continuously subscribe to changes and getting their new values. Since the Observation framework is currently in beta, the framework will hopefully provide this functionality in the future.

Introduction to Kotlin for Swift developers - variables, functions & control flow

Mon, 14 Aug 2023 22:00:00 GMT

If you are a iOS developer learning Kotlin - which is the main programming language for Android development - or you just want to take a glimpse into another modern programming language, this article series may be for you.

This is a 4-part article series which will cover the following Kotlin topics from a Swift developer's point of view:

In part 1 (this article), we'll look into basic concepts like variables, functions and control flow.
In part 2, we'll take a closer look into classes, structs and enums.
In part 3, we'll look into protocols, extensions and generics.

Let's get started.

Variables & Optionals

The syntax between Swift and Kotlin is quite similar. As a Swift developer, you most likely will be able to read Kotlin code and understand most of it right from the beginning, and also recognize a lot of features you know from Swift.

Let's look at the following code:

Kotlin

fun sumOf(x: Int, y: Int? = null): Int {
    println("x is $x, y is $y")

    if (y != null) {
        val result = x + y
        return result
    }
    return x
}

Swift

func sumOf(x: Int, y: Int? = nil) -> Int {
    print("x is \(x), y is \(y)")

    if let y {
        let result = x + y
        return result
    }
    return x
}

As we can see above, the Kotlin code is almost self-explanatory since the syntax in both languages is only slightly different. A few things to point out:

To define constants, Kotlin provides the val keyword (equivalent to let in Swift).
For mutable variables, it even has the same keyword as Swift: var result = ....
Just like Swift, Kotlin supports type inference. The type of the result variable is inferred, we don't need to explicitly specify it with val result: Int = x + y.
Just like Swift, Kotlin supports optionals. While we use a if let binding in Swift to unwrap optionals, in Kotlin, an optional variable is automatically casted to non-nullable after a null check.

Similar to Swift, Kotlin also supports optional chaining and forced unwrapping:

result?.user?.isValidated // optional chaining in Kotlin
result!!.user!!.isValidated // forced unwrapping in Kotlin

Functions

In the example above, we already saw a function in action:

fun sumOf(x: Int, y: Int? = null): Int {
    ...
}

Similar to Swift, functions in Kotlin support default arguments. Kotlin provides a lot of flexibility for calling functions. We can call the function without the argument names or by using named arguments. When using named arguments, we can freely change the order that they are listed in.

Here are valid possibilities we can call the above function in Kotlin:

sumOf(1)
sumOf(x = 1)
sumOf(1, 4)
sumOf(y = 4, x = 1)

Similar to Swift, Kotlin functions are first-class which means they can be stored in variables and can be passed as arguments to and returned from other functions. A function type in Kotlin is defined as follows:

(Int) -> String

Which is the same syntax as in Swift. Kotlin also provides similar higher-order functions like map, filter, reduce and more:

Kotlin

val numbers = intArrayOf(1, 2, 3)
val numbersTimesTwo = numbers.map { it * 2 }
val sum: Int = numbers.reduce { acc, next -> acc + next }

The equivalent in Swift looks as follows:

Swift

let numbers = [1, 2, 3]
let numbersTimesTwo = numbers.map { $0 * 2 }
let sum = numbers.reduce(0) { $0 + $1 }

In Kotlin, the implicit parameter name it can only be used for single parameters.

Control flow

Kotlin provides similar control flow statements we already know from Swift. An if-else-statement was already shown in previous examples. Let's look at two other often used statements - the when statement and the for-loop.

when defines a conditional expression with multiple branches.

Kotlin

enum class Color {
  RED, GREEN, BLUE, BROWN
}

when (color) {
    Color.RED -> println("red")
    Color.GREEN, Color.BLUE -> println("green or blue")
    else -> println("otherwise")
}

As we can see above, it is very similar to the switch statement in Swift. Just like in Swift, the else statement is not required when all possible cases are covered. The Swift equivalent looks as follows:

Swift

enum Color {
    case red, green, blue, brown
}

switch self {
case .red:
    print("red")
case .green, .blue:
    print("green or blue")
default:
    print("otherwise")
}

For loops in Kotlin are also very similar to those in Swift:

Kotlin

for (item in items) {
    // ...
}

The only difference are the parentheses which we can leave out in Swift:

Swift

for item in items {
    // ...
}

The difference between @StateObject and @ObservedObject in SwiftUI

Sun, 30 Jul 2023 22:00:00 GMT

When it comes to state management in SwiftUI combined with reference types, SwiftUI provides two property wrappers: @StateObject and @ObservedObject. Understanding the difference between them is crucial for building robust SwiftUI applications, as it determines how data is managed and flows through the view hierarchy.

Note: Apple introduced the Observation framework at WWDC23 which will make these two property wrappers obsolete in the future. The knowledge around them is still useful since they are used in many existing applications. The knowledge might also help migrate to new Observation framework.

So let's directly dive in and look at an example.

Let's look at the following example of a view and a view model working together:

struct RandomNameGeneratorView: View {
    @ObservedObject private var viewModel = RandomNameGeneratorViewModel()

    var body: some View {
        VStack {
            Text(viewModel.generatedName ?? "Tap the button to generate a new name")
            Button("Generate") {
                viewModel.generateNewName()
            }
        }
    }
}

class RandomNameGeneratorViewModel: ObservableObject {
    @Published var generatedName: String?

    func generateNewName() {
        generatedName = ...
    }
}

The example above shows a view which the user can use to generate a new name every time they tap the generate button. The view references the view model with the @ObservedObject property wrapper so the view is automatically updated when the view model's published properties change.

When using the view, for example as follows:

struct ContentView: View {
    var body: some View {
        RandomNameGeneratorView()
    }
}

everything seems to work fine.

But there is actually a potential error we introduced. As soon as our view hierarchy becomes more complex, we might run into the problem, that a generated name suddenly becomes empty without us resetting it explicitly. The reason behind this behaviour is that we used @ObservedObject to subscribe to model changes.

An @ObservedObject is reinitialized every time their containing view redraws. Since SwiftUI might recreate a view at any time, using @ObservedObject in our example might lead to unwanted behaviour and some headache trying to find the cause.

The correct approach in this case is to use the @StateObject property wrapper instead. @StateObject makes sure the view model retains state between view redraws so we don't lose any state.

An @ObservedObject should only be used to pass a @StateObject into a subview. For example:

struct ContentView: View {
    @StateObject private var viewModel = RandomNameGeneratorViewModel()

    var body: some View {
        RandomNameGeneratorView(viewModel: viewModel)
    }
}

struct RandomNameGeneratorView: View {
    @ObservedObject var viewModel: RandomNameGeneratorViewModel

    ...
}

In the example above, we create a two-way binding by passing in a @StateObject and referencing it as an @ObservedObject. This way, every change to published properties of the view model made by any of the view will also be reflected in the other view.

How to automate taking screenshots with fastlane for iOS

Sun, 23 Jul 2023 22:00:00 GMT

As mentioned in this fastlane guide for iOS, fastlane provides a snapshot action to automatically generate screenshots for an iOS application.

Automatically taking screenshots of a mobile application can serve us developers in different ways, for example as part of publishing the app to the App Store, as part of a QA process or as part of UI testing to identify changes to previous versions.

Let's look at how we can use fastlane's snapshot action to do that.

The snapshot action uses the capabilities of UI tests to create the desired application state. If you never worked with UI tests before, check out this article on getting started with UI tests to learn more.

To setup snapshot, the following steps are required:

Creating a new UI test target
Running fastlane snapshot init in the project folder which will create a Snapfile and ./SnapshotHelper.swift
Open the created Snapfile file to configure languages, devices and more, for example:

devices([
 "iPhone 14"
 ])

output_directory("./screenshots")
clear_previous_screenshots(true)
override_status_bar(true)

Add the created ./SnapshotHelper.swift file to the UI Test target
Add a new Xcode scheme for the created UI Test target, open its Build section and enable the Run and Shared checkbox.
Add the following code in the setUp() method:

let app = XCUIApplication()
setupSnapshot(app)
app.launch()

Add interactions to the UI test class that lead to desired screens and call snapshot("NameOfTheScreen") to take a screenshot where needed.
Run fastlane snapshot in the terminal. It will create the screenshots inside the fastlane/screenshots directory.

To add device frames around created screenshots, we can use the fastlane frameit action. We also have the possibility to add a background and titles by setting up a Framefile.json.

Beginner's guide on Flutter for iOS developers

Sun, 16 Jul 2023 22:00:00 GMT

Recently, I was experimenting with Flutter for a small project of mine. Flutter is an open source framework by Google for building cross-platform applications from a single codebase.

Knowledge in Swift and SwiftUI are valuable when building apps with Flutter. With this article, I would like to give you a overview of the main concepts of Flutter from a native iOS developer's point of view.

Let's get started.

Dart as programming language

Dart is the programming language used by Flutter developers.

For a Swift developer, learning Dart feels familiar. Both languages share concepts like type safety, type inference, optionals, generics, concurrency with async/await, error handling, extensions and more.

Let's look at the following Dart example:

API api = API(); // 1.

try {
  User user = await api.login(username, password);
} catch (error) {
  // Handle error.
}


class User {
  String _username; // 2.

  User(this._username); // 3.
}

class API {

  User? _currentUser;

  Future<User> login(String username, String password) async {

      // 4.
      if (_currentUser != null) {
        throw UserAlreadyLoggedIn(_currentUser);
      }
      // Network request
      return user;
  }
}

To a Swift developer, the code above should be almost self-explanatory. Some things to point out here are:

Variables defined without any keyword are similar to a var in Swift. To define a constant variable in Dart, we can use the final keyword which is similar to the let keyword in Swift.
Underscores in Dart are used to make variables or classes private.
Since writing constructors to assign all class fields is often redundant, Dart offers syntactic sugar that looks like shown in the example above.
Optionals in Dart are defined and handled just like in Swift with ? and !. To unwrap an optional safely, Dart offers the if statement as shown in the example above. Inside the if-statement, _currentUser is treated as a non-optional.

Widgets as UI elements

Just like SwiftUI, Flutter provides a declarative API to build user interfaces. While SwiftUI represents UI elements as views, Flutter does the same with so called widgets. To compose layouts, both SwiftUI and Flutter nest UI components within one another.

For example, the following SwiftUI code:

Text("Hello world!")
  .padding(5)

looks as follows in Flutter:

Padding(
  padding: EdgeInsets.all(5.0),
  child: Text("Hello world!"),
)));

As we can see above, while SwiftUI uses view modifiers to configure views, Flutter uses widget properties.

In SwiftUI, views may expand to the available space or limit their size to their content. Flutter widgets behave similar.

When layouting views in SwiftUI, the parent view proposes a size to its child view and then renders it at the returned size. Flutter differs at that point because the parent component can override the child's returned desired size. The parent widget passes constraints to its child widget which includes minimum and maximum values for height and width. If the requested size doesn't fit in the constraints, the parent limits the child view to fit the constraints.

Just like SwiftUI, Flutter provides a widget catalog which offers widgets for aligning and positioning their children. For example, equivalents to SwiftUI's HStack and VStack are Row and Column in Flutter.

Aligning in SwiftUI:

VStack {
  Text("Hello"),
  Text("world!")
}

Aligning in Flutter:

Column(
  mainAxisAlignment: MainAxisAlignment.center,
  children: const [
    Text('Hello'),
    Text('world!'),
  ],
),

Other examples of Flutter widgets are ListView to create lists, GridView for displaying a grid or SingleChildScrollView for creating a scroll view. These are also resembling their equivalents in SwiftUI.

Managing state

Just like SwiftUI, Flutter follows the declarative approach when it comes to state management. Which means that every state change leads to a redraw of the user interface.

While SwiftUI provides property wrappers like @State & @Binding and StateObject & ObservedObject, Flutter works with so called stateful widgets which consist of a subclass of StatefulWidget and State, for example:

class MyStatefulWidget extends StatefulWidget {
  const MyStatefulWidget({super.key});

  @override
  State<MyStatefulWidget> createState() => _MyStatefulWidgetState();
}

class _MyStatefulWidgetState extends State<MyStatefulWidget> {
  int _selectedIndex = 0;

  void _onItemTapped(int index) {
    setState(() {
      _selectedIndex = index;
    });
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: ...,
      body: ...,
      bottomNavigationBar: BottomNavigationBar(
        items: const <BottomNavigationBarItem>[
          BottomNavigationBarItem(
            icon: Icon(Icons.home),
            label: 'Home',
          ),
          ...
        ],
        currentIndex: _selectedIndex,
        selectedItemColor: Colors.amber[800],
        onTap: _onItemTapped,
      ),
    );
  }
}

As we can see above, the State object stores the widget's state. When we call setState() like in the _onItemTapped function, the framework redraws the widget.

If a widget does not depend on anything other than the initial configuration we can use a StatelessWidget instead.

Quick tip on how to split text into words with the Natural Language framework in Swift.

Sun, 18 Jun 2023 22:00:00 GMT

When it comes to splitting a text into words, the first solution that might come to mind is to simply split the string components by whitespace. But this solution doesn't work for all languages. For example, Chinese and Japanese don't use spaces to delimit words.

The Natural Language framework tokenizer provides the possibility to tokenize a string ensuring correct behaviour for all languages. For that, the framework provides the NLTokenizer type:

func words(for text: String) -> [String] {
    let tokenizer = NLTokenizer(unit: .word)
    tokenizer.string = text
    return tokenizer.tokens(for: text.startIndex..<text.endIndex).map { String(text[$0]) }
}

As shown above, we initialize the tokenizer with .word as unit and then simply call the tokens method which returns the ranges corresponding to the tokens.

And that's basically it. The tokenizer also accepts other units than words, for example .sentence to split a text into sentences or .paragraph to split it into paragraphs.

How to find synonyms with the Natural Language framework for iOS

Sun, 11 Jun 2023 22:00:00 GMT

The possibility to find synonyms for a given word can help us improve the user experience in an iOS application, for example to provide more intelligent search results or being able to offer similar content.

The Natural Language framework provides the synonyms functionality out of the box with its NLEmbedding type which represents a vector map of strings.

We can use its neighbors function to find synonyms as follows:

func synonyms(for word: String, maximumCount: Int = 5) -> [String] {
    guard let embedding = NLEmbedding.wordEmbedding(for: .english) else { return [] }
    let synonyms = embedding.neighbors(for: word, maximumCount: maximumCount).map { $0.0 }
    return synonyms
}

To support different languages, we could improve the method above by detecting the language automatically. The Natural Language framework supports this functionality out of the box. Check out this article on how to detect the language of a text with the Natural Language framework to learn how to do that.

The neighbors function not only provides synonyms but also their distance to the given word. Strings that are semantically similar have a smaller distance value. We can find out the distance between two words directly as follows:

let distance = embedding.distance(between: word, and: anotherWord)

The distance functionality can also be used to find out similarity between sentences, which can be really usefull for example when building an FAQ service, it could suggest related questions based on the user's entered question.

To get the distance between two sentences, we create an embedder by using its sentenceEmbedding function and then use it just like we used it with words:

guard let embedding = NLEmbedding.sentenceEmbedding(for: .english) else { return }
let distance = embedding.distance(between: sentence, and: anotherSentence)

How to map a SwiftUI state to a binding of a different type

Sun, 04 Jun 2023 22:00:00 GMT

When working with states and bindings in SwiftUI, we sometimes might have a use case where we need to map a state type to a different binding type. Let's look at an example and see how to do that.

Imagine, we have a SwiftUI view with a selection from a list and a button to save that selection. The button should be disabled as long as the user hasn't made a selection yet:

struct SaveView: View {

    @State private var selectedOption: SelectionOption?

    var body: some View {
        VStack {
            SelectionView(selectedOption: $selectedOption)
            Spacer()
            SaveButton(action: {}, isDisabled: ???)
        }
    }
}

The isDisabled parameter is of type Bindable<Bool> so we need some kind of mapping from the selectedOption state property. For that case, we can initialize a Binding as follows:

SaveButton(action: {}, isDisabled: Binding(
    get: { selectedOption == nil },
    set: { _ in }))

As shown above, we can create a custom binding using the Binding type which takes a get and a set closure. This is really useful when we need to add custom logic to a binding.

Continuous integration and delivery for iOS

Sun, 28 May 2023 22:00:00 GMT

Continuous integration, delivery and deployment practices help us continuously and automatically build, test and deploy iterative code changes. Using CI/CD can help developer teams to improve the quality of the code base, reduce the time and effort required to release new features, and make it easier for team members to collaborate on code. It can also help to improve the reliability and stability of deployments by automating the deployment process and providing early feedback on code changes.

In this article, we'll look at CI/CD concepts and how a CI/CD workflow can be realized when developing iOS applications.

CI/CD concepts

Continuous integration (CI) is a practice in which developers regularly merge their code changes into a central repository, where they are automatically built and tested. This allows teams to detect and fix errors quickly and ensure that their code is always in a deployable state.

CI typically involves setting up an automated build and test pipeline that is triggered whenever a developer pushes a code change. This pipeline can include tasks such as compiling code, running static analysis tools and running tests. If any of these tasks fail, the pipeline can be configured to alert the team so that they can investigate and fix the issue.

Continuous delivery (CD) takes continuous integration a step further by also deploying the code changes to a staging or production environment.

CD can also refer to continuous deployment. The key difference between continuous delivery and continuous deployment is that continuous delivery allows for manual intervention and review before code is deployed to production, while continuous deployment automatically deploys all code changes to production as soon as they are ready.

Main components of a CI/CD workflow

The main components of a CI/CD workflow are:

A central repository where the team's code is stored and managed. In most cases, it's the version control system Git, where each code change is committed and tracked.
A build server that is responsible for building the code and running tests whenever a code change is pushed to the central repository.
A deployment environment where the code will be deployed, such as a staging or production environment. This can be a local server, a cloud-based platform, or in case of iOS applications a third-party service like Testflight and App Store.
A pipeline which is a set of automated steps that are executed when triggered by a code change. The pipeline can include tasks such as building the code, running tests and deploying the code.

CI/CD workflow for an iOS application

A CI/CD workflow for an iOS application might look something like this:

A developer creates a new Git branch, develops and tests a new feature, pushes it to a shared Git repository and creates a Merge Request.
The Merge Request triggers a CI/CD pipeline, which builds the code and runs unit and UI tests.
If the build and tests are successful, another developer reviews the code. Every pushed code change resulting from the review triggers the pipeline to again build and test the code.
When the Merge Request is accepted and merged, a pipeline can automatically deploy the code to a staging environment, where it can be tested further by QA team members or beta testers.

The pipeline can also be configured to perform other tasks, such as automatically releasing a new version of the app to the App Store or generating release notes.

Tools to realize CI/CD workflows

To realize CI/CD workflows, there are many tools available, for example Jenkins, CircleCI, TeamCity, Bamboo, GitLab CI, Travis CI, Codemagic and more.

These are just a few examples of CI/CD tools. There are many other tools available and the right choice depends on specific needs and requirements for a team.

How to identify parts of speech and names in a text with Swift

Sun, 14 May 2023 22:00:00 GMT

As we learned in the developer guide on the Natural Language framework, it supports linguistic tagging. Linguistic tagging, also known as part-of-speech tagging, is the process of assigning grammatical tags to words in a text based on their role and function within a sentence.

We could use linguistic tagging for example to identify parts of speech in a text like verbs and nouns, or names like people names, place names or organization names in texts.

Let's look at how it works.

The linguistic tagging functionality is provided by the Natural Language framework's NLTagger type. The tagger is initialized with a scheme of type NLTagScheme which specifies what kind of tags should be used for classification.

For example, we could use .tokenType as a scheme, which would classify parts of a text with the following tags: .word, .punctuation, .whitespace and .other.

Another example for a scheme is .lexicalClass, which classifies parts of a text with the tags .noun, .verb, .adjective, .adverb etc.

Let's look at the following function which extracts all verbs from a text:

func getVerbs(from text: String) -> [String] {
    let tags = tags(for: text, tagScheme: .lexicalClass)
    return tags.filter { $0.tag == .verb }.map { $0.word }
}

The function uses the following helper function which creates pairs of words and their tags based on the provided text and scheme.

func tags(for text: String, tagScheme: NLTagScheme) -> [(word: String, tag: NLTag)] {
    var taggedWords: [(String, NLTag)] = []

    let tagger = NLTagger(tagSchemes: [tagScheme])
    tagger.string = text
    tagger.enumerateTags(in: text.startIndex..<text.endIndex,
                            unit: .word,
                            scheme: tagScheme,
                            options: [.omitPunctuation, .omitWhitespace]) { tag, tokenRange in
        if let tag = tag {
            taggedWords.append((String(text[tokenRange]), tag))
        }
        return true
    }
    return taggedWords
}

We can use the same helper function to extract other words, for example names. The following code extracts place names from a given text:

func getPlaceNames(from text: String) -> [String] {
    let tags = tags(for: text, tagScheme: .nameType)
    return tags.filter { $0.tag == .placeName }.map { $0.word }
}

And that's basically it. The NLTagger makes it really easy for us to identify parts of speech in a text.

Check out the official NLTagScheme documentation to learn more about supported classification possibilities.

How to detect the language of a text with the Natural Language framework in Swift

Sun, 30 Apr 2023 22:00:00 GMT

If we need to detect a language of some text in an iOS application, for example some user input, the Natural Language framework comes in handy. It provides the NLLanguageRecognizer type which we can use for that purpose.

When using the language recognizer, we get the most likely language for a piece of text or a set of possible languages with their probabilities.

func language(for text: String) -> NLLanguage? {
    let recognizer = NLLanguageRecognizer()
    recognizer.processString(text)
    return recognizer.dominantLanguage
}

We can then use the optained language to switch over the languages:

guard let language = language(for: text) else { return }
switch language {
case .english:
    ...
}

To get a set of languages with their probabilities, we can use the languageHypotheses(withMaximum:) method:

func languages(for text: String) -> [NLLanguage: Double] {
    let recognizer = NLLanguageRecognizer()
    recognizer.processString(text)
    return recognizer.languageHypotheses(withMaximum: 5)
}

To process another text with the same recognizer, we need to call its reset() method to return it to its initial state:

recognizer.reset()

Developer guide on App Clips for iOS

Sun, 23 Apr 2023 22:00:00 GMT

Announced at WWDC 2020, an App Clip is a lightweight version of an app that enables users to perform a specific task without installing the full app, i.e. App Clips allow users who do not have downloaded the app to still use its functionality.

In this article, we'll look at how App Clips work and how we can implement them in our iOS applications.

How do App Clips work?

App Clips can be launched with so called invocation URLs, for example, by scanning an NFC tag, QR code, App Clip code or tapping on a link.

As soon as a user opens an App Clip URL, the system at first presents a so called App Clip experience, which is a card showing an App Clip summary and an action button to open the App Clip. If the user chooses to open it, the App Clip binary is downloaded and launched. The invocation URL is passed in, so it can be handled as a deep link if needed.

In case the according iOS application is already installed on the user's device, it gets opened instead of the App Clip.

If an App Clip is not launched for several days, it gets deleted by the system.

Supporting App Clips in an iOS application

To support App Clips in an iOS application, the following general steps are required:

Adding an App Clip target
Developing the App Clip which includes sharing assets and code between the iOS app and the App Clip and handling of the invocations
Associating the App Clip with the corresponding website
Configuring the App Clip experience in App Store Connect

Let's go through those steps in more detail.

1. Adding an App Clip target

To add an App Clip target to an iOS project, we can use Xcode's App Clip template.

Xcode's App Clip template.

The template creates a structure for the App Clip which is similar to our app's structure.

App Clip's structure.

Additionally, it creates the correct entitlements and a scheme to build and run the App Clip and its tests. It also adds a new build phase for the app target that embeds the App Clip in the app.

2. Developing the App Clip

After adding the App Clip target, we can directly try out to build and run it by choosing the created scheme.

When it succeeds, we can start sharing code and assets between the App Clip and the actual iOS app. Sharing code with an App Clip works just like with any other target by selecting target memberships of a file in Xcode's File Inspector.

For iOS 16 devices, the uncompressed App Clip binary can be up to 15 MB in size, for iOS 15 and earlier up to 10 MB.

In cases we have to differentiate between the iOS app and its App Clip in code, we can use the Active Compilation Conditions build setting which can be configured in the App Clip's target build settings.

Active Compilation Conditions.

With that setup, we can use it as follows:

#if !APPCLIP
// App code
#else
// App Clip code
#endif

The invocation URL is passed in as a user activity. To handle the URL in a SwiftUI application after the App Clip is launched, we can use the onContinueUserActivity(_:perform:) method:

import SwiftUI

@main
struct ExampleAppClipApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
                .onContinueUserActivity(NSUserActivityTypeBrowsingWeb) { activity in
                    guard let incomingURL = activity.webpageURL else { return }
                    guard let components = NSURLComponents(url: incomingURL, resolvingAgainstBaseURL: true) else { return }
                    // Navigate to a certain part of the App Clip based in the URL
                }
        }
    }
}

As we can see above, the passed in user activity has a webpageURL property which we can use to show customized content to the user if needed.

Since the main application is launched instead of the App Clip if installed, similar code should be added there too.

3. Associating the App Clip with the corresponding website

The App Clip will be launched if a user opens an invocation URL. Before the system launches the App Clip, it verifies the app's entitlement and the server's Apple App Site Association file to make sure that the App Clip and the website are associated.

To associate an App Clip with a website, the following steps are required:

Add an Associated Domains entitlement. For that, we need to enable the Associated Domains capability in Xcode's project settings and to specify the invocation URL's domain within the Associated Domains Entitlement: appclips:<fully qualified domain>.
Add an Apple App Site Association file on the domain's server. For that, an Apple App Site Association file needs to be configured and uploaded to the server's .well-known directory with the following content:

{
  "appclips": {
      "apps": ["PREFIX.com.tanaschita.ExampleApp.Clip"]
  }
  ...
}

Check out this guide on associated domain files for iOS development to learn more.

4. Configure the App Clip experience in App Store Connect

After uploading a build that contains an App Clip to App Store Connect, we can configure App Clip experiences in App Store Connect. This includes configuring the URL which will launch the App Clip experience card, adding meta data like title, subtitle and image and choosing a call to action.

Additionally, we can choose between default and advanced experiences. With a default App Clip experience, we can add a Smart App Banner to the corresponding website that launches the App Clip. This will also enable invocations from links that are shared in Messages.

To support additional invocations such as scanning an App Clip Code or an NFC tag, we need to configure an advanced App Clip experience.

We can configure multiple App Clip experiences for one App Clip, for example one experience for each deep link the App Clip supports.

Cheatsheet for the JSON payload of an iOS push notification

Sun, 16 Apr 2023 22:00:00 GMT

When configuring the JSON payload of an iOS push notification, there are a lot of configurations options we can choose from. This guide serves as a reference and cheatsheet for those configuration options.

Basic JSON payload structure

The payload for a remote notification is a JSON dictionary with the following basic structure:

{
  "aps": {
    "alert": "Title of the push notification",
    "sound": "default",
    // More configuration keys and values
  },
  "customKey1": "Some content",
  "customKey2": "Some other content",
  // More custom keys and values.
}

As we can see above, the JSON is a dictionary which can contain custom keys for example to provide a deep link or additional information our app may need.

To customize the push notification, we can use the aps dictionary as also shown above. Let's explore those keys and their effects on the push notification.

The alert key

The value for the alert key can either be a String or a Dictionary.

{
  "aps": {
    "alert": "Title of the push notification"
  }
}

The configuration above produces the following push notification:

Push notification with title only.

Alternatively, we can specify the notification's title, subtitle and body:

{
  "aps": {
    "alert": {
        "title": "Title of the notification",
        "subtitle": "Subtitle of the notification",
        "body": "The content of the notification."
    }
  }
}

Which results in the following output:

Push notification with title, subtitle and body.

There is also the possibility to use localized keys instead:

{
   "aps" : {
      "alert" : {
         "title-loc-key" : "notification.newMessage.title",
         "title-loc-args" : [ "argument1", "argument2"],
         "subtitle-loc-key" : "notification.newMessage.subtitle",
         "body-loc-key" : "notification.newMessage.body",
      }
   }
}

The keys stored in Localizable.strings will automatically be used.

The badge key

The badge key is used to specify the number that will appear on the app's icon as a badge.

{
  "aps" : {
    ...
    "badge" : 0
  }
}

The value 0 removes the current badge.

The sound key

The sound key is used to specify the sound that will play when the notification is received which can either be a default, a custom or a critical sound.

Default sound

{
   "aps" : {
      ...
      "sound" : "default"
   }
}

The example above plays the system sound.

Custom sound

{
   "aps" : {
      ...
      "sound" : "applause.wav"
   }
}

As shown above, we can specify a sound file in the app's main bundle in .aiff, .wav or .caf file format to be played when the notification is shown.

Critical sound

A critical sound plays even if Do Not Disturb is turned on or the device is muted. Only apps approved for the critical alerts entitlement are allowed to send critical alerts. For example:

{
   "aps" : {
      ...
      "sound": {
        "critical" : 1,
        "name": "default", // or name of a sound file in the app's main bundle
        "volume": 1 // value between 0 (silent) and 1 (full volume)
      }
   }
}

The thread-id key

An identifier for grouping related notifications, for example:

{
   "aps" : {
      ...
      "thread-id": "com.tanaschita.newArticle"
   }
}

The iOS system will automatically sum up notifications with the same thread-id into a group when showing them in the notification center.

The category key

The category key can be used to add custom actions to the notification.

{
   "aps" : {
      ...
      "category" : "drinkingReminderCategory"
   }
}

Checkout this article on how to add custom actions for iOS notifications to learn more.

The content-available key

The content-available key declares the notification as a background notification.

A background notification doesn't display an alert, play a sound or show a badge. It wakes the app in the background and gives it time to initiate downloads and update its content.

{
   "aps" : {
      "content-available" : 1
   }
}

Check out the official documentation on pushing background updates to your app to learn more about background notifications.

The mutable-content key

The mutable-content key can be used if we need to modify the payload of a remote notification before it's shown to the user, for example to decrypt data or to incorporate additional content based on data within the application.

{
   "aps" : {
      "mutable-content" : 1,
      ...
   },
}

Modifying a remote notification requires a notification service app extension, which receives the contents of the notification before is is displayed to the user to be able update the notification payload.

Check out the official documentation on modifying content in newly delivered notifications to learn more.

The interruption-level key

The interruption-level key represents the importance and delivery timing of a notification:

{
   "aps" : {
      "interruption-level" : "active",
      ...
   },
}

The following values are available:

active - presents the notification immediately, lights up the screen, can play a sound.
critical - presents the notification immediately, lights up the screen, bypasses the mute switch to play a sound.
passive - adds the notification to the notification list without lighting up the screen or playing a sound.
timeSensitive - similar to active notifications, but can break through system controls such as Notification Summary and Focus. The user can turn off the ability for time sensitive notification interruptions.

The relevance-score key

The relevance score value is a number between 0 and 1, that the system uses to sort the notifications from the same iOS application.

{
   "aps" : {
      "relevance-score" : 1,
      ...
   },
}

The highest score gets featured in the notification summary.

How to scan QR codes with VisionKit for iOS

Sun, 09 Apr 2023 22:00:00 GMT

Starting with iOS 16, Apple introduced a data scanner in VisionKit, which allows us to to scan data in the live video stream from the iOS camera. Besides different text types, it supports recognition for various barcode types including automatic item highlighting.

Let's look at how we can implement the data scanner functionality for QR codes.

Overview

To implement a data scanner for QR codes, the following steps are required:

Adding camera usage description for user permission.
Creating a data scanner view controller.
Using delegate methods to react to recognized QR codes.

Let's see how to implement those steps in more detail.

1. Adding camera usage description for user permission

To be able to use the data scanner, the user needs to grant permission for camera usage. We can configure the reason for using the camera by adding the NSCameraUsageDescription key to the target's information property list.

2. Creating a data scanner view controller

When initializing the data scannner, we can specify the item types to scan, quality level, highlighting and more:

let viewController = DataScannerViewController(
    recognizedDataTypes: [.barcode(symbologies: [.qr])],
    qualityLevel: .balanced,
    recognizesMultipleItems: false,
    isHighFrameRateTrackingEnabled: false,
    isHighlightingEnabled: true)
viewController.delegate = self

try? viewController.startScanning()

As shown in the code above, we pass in [.barcode(symbologies: [.qr])] to scan QR codes. Besides QR codes, the scanner view controller supports various other barcode symbologies. Checkout the official documentation on supported barcode symbologies to learn more.

Besides various barcode types, the data scanner view controller supports text recognition for different text content types like email address, phone number, street address, flight numbers and more.

For example, we could pass in [.text([], .emailAddress)] as recognizedDataTypes to recognize email addresses.

3. Using delegate methods to react to recognized QR codes

The scanner delegate provides methods to react to recognized items or to user's interactions such as tapping on an item. The following delegate method is called when the scanner recognizes new items:

func dataScanner(_ dataScanner: DataScannerViewController, didAdd addedItems: [RecognizedItem], allItems: [RecognizedItem]) {
    guard let item = allItems.first else { return }
    switch item {
    case .barcode(let recognizedCode):
        print(recognizedCode.payloadStringValue)
    default:
        break
    }
}

And that's basically it. The DataScannerViewController makes is really easy to implement QR code scanning functionality in iOS applications.

Get started with Create ML to train a machine learning model in iOS

Sun, 02 Apr 2023 22:00:00 GMT

As mentioned in this developer guide on machine learning for iOS with Core ML, Apple's Create ML app allows us to train a model.

Create ML is part of Xcode's tool chain and allows us to train machinge learning models without requiring extensive knowledge of machine learning, for example allowing us to drag and drop datasets, choose an algorithm, and configure the model parameters through a graphical interface.

Let's look at how to do that.

After opening Create ML, the application presents different templates to choose from. They can be used to train models for tasks such as image classification, object detection, text and sound classification, classification and regression of tabular data and more.

Create ML templates

As an example, we'll work with the image classification template.

Let's say, we want to train a model which recognizes different weather conditions like rain, sunshine, sunset and clouds in photos.

To be able to train the model to do that, we need a labeled dataset of photos. The data set might look as follows:

Image classification data set

As we can see above, the images are categorized in folders. The folder names represent the image labels.

After adding the data set, Create ML creates a class for each folder:

Create ML training

This is all we need to do to be able to start the training process by clicking the train button.

After the model training is completed, we can test the model with new data in the preview tab.

Create ML preview

When satisfied with the model, we can save it as a .mlmodel file from the output tab and integrate it into our iOS application. To learn how to do that, check out this article on machine learning for iOS with Core ML.

How to change JSON keys by using Swift's CodingKey protocol

Sun, 26 Mar 2023 22:00:00 GMT

Swift's Codable protocol makes it easy to convert JSON data to native Swift types and the other way around. In the article on how to use the CodingKey protocol, we explored how to use custom names for Swift properties when decoding JSON data.

In some cases though, we might need an even more customized solution, for example to map the JSON data to a different structure.

Let's look at how to do that.

Let's say we get the following JSON data:

{
  "username" : "tanaschita",
  "validated": true,
  "address": {
    "postalCode": "04275",
    "city": "Leipzig",
    ...
  }
}

Our application is only interested in the user's city property, that's why we'd like to add it directly to our User struct without defining an extra Address type as follows:

struct User: Codable {

    let username: String
    let isValidated: Bool
    let city: String
}

To be able to map the data the way we want, we can provide a custom implementation of Encodable and Decodable to define our own encoding and decoding logic:

struct User: Codable {

    let username: String
    let isValidated: Bool
    let city: String

    enum CodingKeys: String, CodingKey {
        case username
        case isValidated = "validated"
        case address
    }

    enum AddressCodingKeys: String, CodingKey {
        case city
    }

    init(from decoder: Decoder) throws {
        let values = try decoder.container(keyedBy: CodingKeys.self)

        username = try values.decode(String.self, forKey: .username)
        isValidated = try values.decode(Bool.self, forKey: .isValidated)

        let address = try values.nestedContainer(keyedBy: AddressCodingKeys.self, forKey: .address)
        city = try address.decode(String.self, forKey: .city)
    }
}

In the same way, we can add our own encoding logic:

func encode(to encoder: Encoder) throws {
    var container = encoder.container(keyedBy: CodingKeys.self)
    try container.encode(username, forKey: .username)
    try container.encode(isValidated, forKey: .isValidated)

    var address = container.nestedContainer(keyedBy: AddressCodingKeys.self, forKey: .address)
    try address.encode(city, forKey: .city)
}

This possibility gives us a way to be fully independent of the JSON structure so we can create an entirely customized representation of that data in our iOS apps.

Get started with NSPredicate to filter NSFetchRequest in Core Data

Sun, 19 Mar 2023 23:00:00 GMT

As mentioned in this guide on the main aspects of Core Data, predicates can be used to filter fetch request results.

Let's jump in and look at some examples to understand how predicates work.

Creating predicates

Predicates are represented by the NSPredicate type.

They represent logical conditions, which we can use to filter a collection of objects. When working with Core Data, we can filter fetch request results by setting a predicate as follows:

let usersFetchRequest = NSFetchRequest<User>(entityName: "User")
usersFetchRequest.predicate = NSPredicate(format: "isVerified == YES")

Or when using SwiftUI:

@FetchRequest(predicate: NSPredicate(format: "isVerified == YES"))
private var users: FetchedResults<User>

As we can see above, we initialize a predicate with a string format. The example will fetch all users that are verified.

The predicate used in the example can also be written by using variable substitution as follows:

NSPredicate(format: "isVerified == %@", NSNumber(value: true))

%@ is a format specifier and will be substituted with NSNumber(value: true).

Instead of referencing properties with raw strings, we could use key paths to add more safety to our code by using the %K format specifier:

NSPredicate(format: "%K == %@", #keyPath(User.isVerified), NSNumber(value: true))

Format specifiers

As we already saw above, format specifiers allow us to use variable substitution. Examples of format specifiers are:

%@ for objects
@K for key paths
@d for integers
@f for floating numbers

Checkout Apple's official documentation to discover more format specifiers.

Comparison predicate operators

In the example above, we used == as comparison operator for an exact match.

We could also use compare operators like !=, >=, >, <= < etc. which are self-explanatory. An example to filter all users who reached the age of 18 could look this way:

NSPredicate(format: "age >= 18")

Two more interesing compare operators are IN and BETWEEN:

IN can be used to provide an array of values to match. For example, to filter all users of certain ages:

NSPredicate(format:"age IN %@", agesArray)

BETWEEN can be used to provide a range to match:

NSPredicate(format:"age BETWEEN {12, 17}")

When working with strings, we can also use comparison operators BEGINSWITH, CONTAINS or ENDSWITH. For example, to match all users which last names begin with a t:

NSPredicate(format:"lastName BEGINSWITH 't'")

Compound predicate operators

To combine multipe predicates, we can use standard logical operators:

AND or &&
OR or ||
NOT or !

For example:

NSPredicate(format:"age >= 18 AND isVerified == YES")

Conclusion

While NSPredicate is a powerful filter mechanism, it does come with downsides when used in Swift. Since queries are written as raw strings, we don't get any compile-time safety, mistakes are only noticed at runtime.

In this article, we only discovered the basics of predicates. To dive deeper, check out Apple's official programming guide.

Developer guide on machine learning for iOS with Core ML

Sun, 12 Mar 2023 23:00:00 GMT

Starting with iOS 11, Apple introduced Core ML which abstracts the complexity of machine learning allowing us to utilize it in our iOS applications.

In this article, we'll look at basic machine learning concepts and how we can use Core ML to implement it in an iOS application.

What is machine learning?

Machine learning is an artificial intelligence study field which deals with computer learning, especially with questions and answers on how computers can learn without being explicitly programmed.

Nowadays, many apps utilize machine learning to implement certain features, for example for image recognition, natural language processing and more.

To integrate machine learning into an application, basically two steps are required:

Training: Training a machine learning model involves choosing a learning algorithm and providing the model with labeled training data to learn from.
Inference: Once the model was trained, we can ask it to make predictions about new data. This process is called inference.

Let's look at how to do that for iOS applications.

Machine learning models in iOS

In iOS, a machine learning model is represented by a .mlmodel file.

Apple provides several pretrained open source models which are ready to use, for example:

MNIST to classify a single handwritten digit
MobileNetV2, Resnet50 or SqueezeNet for image classification
PoseNet for estimatations about joint positions for each person in an image

A full list of pretrained models can be found at the official Apple developer documentation. For each model, we can download a .mlmodel file.

We can also use a custom trained model, for example we can build and train a model with the Create ML app bundled with Xcode. Check out this article on how to train a model with Create ML to learn more.

Integrating ML models into iOS projects

We can add the model to an iOS project by simply dragging the .mlmodel file into the project. When we open the file, we can see details like the input and output of the model.

Example of an .mlmodel file

In the example above, we see the MobileNetV2 model which was trained to classify the dominant object in an image.

The input of the model is an image and as output, we get a classLabelProbs dictionary with probabilities of each category and a classLabel which represents the most likely category.

Utilizing the ML model to get predictions

After dragging the model into the project, Xcode automatically generates a programmatic interface which we can use to interact with the model in our code. The code to get a prediction about an image could look as follows:

func classifyImage(_ image: UIImage) throws -> String? {
    let model = try MobileNetV2Int8LUT(configuration: MLModelConfiguration())
    guard let pixelBuffer = image.pixelBuffer() else { return nil }
    let prediction = try model.prediction(image: pixelBuffer)
    return prediction.classLabel
}

As we can see above, all we need to do is to initialize the model with a configuration and after that, we can use its prediction(image:) function for inference.

Quick tip on how to unit test Swift optionals with XCTUnwrap

Sun, 05 Mar 2023 23:00:00 GMT

When unit testing optionals in Swift, the first idea on how to do that might be to use if let or guard statements combined with the XCTFail assertion method. For example:

func testMixingSmoothies() throws {
  let smoothieMaker = SmoothieMaker()
  guard let bananaSmoothie = smoothieMaker.makeBananaSmoothie() else {
    XCTFail("bananaSmoothie should not be nil")
    return
  }
}

The XCTest framework actually provides a more elegant solution.

It provides the XCTUnwrap method which attempts to unwrap the optional and throws an error i.e. the test fails if the optional is nil.

func testMixingSmoothies() throws {
  let smoothieMaker = SmoothieMaker()
  let bananaSmoothie = try XCTUnwrap(smoothieMaker.makeBananaSmoothie())
}

This approach eliminates the need to write repeating XCTFail descriptions. All we need to do is to mark our test function with throws.

Quick guide on fastlane for iOS development

Sun, 12 Feb 2023 23:00:00 GMT

When it comes to publishing an iOS app to the App Store, we need to perform multiple steps like running tests, code signing, archiving and uploading the build, creating screenshots, setting metadata and more. These steps can be very time consuming, especially when publishing on a regular basis.

fastlane is an open source tool that allows you to automate all of these steps and more. At its core, fastlane is a set of Ruby scripts that wrap xcodebuild, the App Store Connect API and more and allow us iOS developers to use commands to automate iOS builds.

Let's see how to do that.

Installing fastlane

The recommended way to install fastlane for iOS projects is by using Bundler and running bundle init in the root directory of the project. This creates a Gemfile where we can add the following:

source "https://rubygems.org"

gem "fastlane"

After running bundle install, Bundler creates a Gemfile.lock file which clearly defines the fastlane version to be used and its dependencies for the specific iOS project.

To create an initial fastlane setup, we can now run bundle exec fastlane init which creates a fastlane folder including the files Appfile and Fastfile.

Defining and running lanes

From the created files, the most interesting one is fastlane/Fastfile which is a Ruby configuration file we can use to add so called lanes for signing, testing, building, deploying etc.

Each lane is a group of actions. A lane definition looks as follows:

lane :my_lane do
  # fastlane actions
end

Which we can run with the following command:

bundle exec fastlane [lane]

Using fastlane actions

fastlane provides predefined actions for different purposes like running tests, taking screenshots, deploying the app etc. We can combine multiple actions to build a lane, for example:

lane :beta do
  sync_code_signing(type: "appstore")
  build_app(scheme: "ExampleApp")
  upload_to_testflight
  slack(message: "New beta build available.")
end

We'll look at some available actions in more detail later in this article.

Authenticating with Apple services

Several fastlane actions communicate with Apple services that need authentication.

fastlane has historically used Apple IDs with username and password for authentication. Since the announcement of the App Store Connect API at WWDC18, the official and recommended way for authentication is by using the App Store Connect API key. Checkout this guide to learn more on how to generate an API key.

fastlane provides the app_store_connect_api_key action which we can use to generate the key we need for JWT authorization:

api_key = app_store_connect_api_key(
    key_id: "79NWH6F376",
    issuer_id: "69a6de73-ea56-47e3-e053-5b8c7c11a4d1",
    key_filepath: "./AuthKey_79NWH6F376.p8"
)

We can then use the api_key to pass in as a parameter into fastlane actions, for example pilot(api_key: api_key).

Sync certificates and provisioning profiles across the team

For many fastlane actions like deploying to the App Store, a beta testing service or installing the app on a device, a valid certificate and provisioning profile is required.

fastlane provides an action called match which creates all required certificates & provisioning profiles and stores them in a separate Git repository.

Running fastlane match init will create a Matchfile which we can fill out with required properties like Git URL, app identifier etc.:

git_url("https://github.com/tanaschita/exampleAppCertificates")
app_identifier("com.tanaschita.exampleapp")

After doing that, we can run fastlane match appstore or fastlane match development to generate provisioning profiles and certificates and store them in the configured storage.

After successfully setting that up, we can use the match action on our Fastfile to automatically fetch the latest provisioning profiles and certificates:

match(api_key: api_key, type: "appstore")

Running tests

Now, let's look at some actions fastlane provides.

For example, to run tests, we can use fastlane's run_tests action as follows:

lane :tests do
  run_tests(workspace: "ExampleApp.xcworkspace",
            devices: ["iPhone 13 Pro"],
            scheme: "ExampleAppTests")
end

There are various other parameters we can provide such as reset_simulator to automatically erase the simulator before running the iOS application or slack_url to posts results in Slack. To see a full list of parameters, run fastlane action run_tests.

Taking screenshots and uploading screenshots to App Store Connect

To automate the process of taking screenshots with fastlane, we can use its snapshot action which uses the capabilities of UI tests to create the desired application state.

Check out this step-by-step guide on how to setup fastlane's snapshot action.

After creating screenshots, we can use fastlane deliver to upload them to App Store Connect.

Building the application

To build the iOS application, we can use fastlane's build_app action:

build_app(scheme: "ExampleApp")

It creates a ExampleApp.ipa in the current directory.

Uploading to Testflight

Since Testflight is part of App Store Connect, uploading a beta build is just another fastlane action:

upload_to_testflight

fastlane also supports beta deployments to Firebase, HockeyApp and TestFairy.

Uploading to the App Store

Uploading the build to the App Store is also just another fastlane action:

upload_to_app_store

Conclusion

I hope, this guide helped you to get an overview on fastlane which is a powerful tool for automating the development and deployment process for iOS apps. To dive deeper into fastlane, check out their official documentation.

How to import Objective-C types as optionals or non-optionals into Swift

Sun, 29 Jan 2023 23:00:00 GMT

When working on a project that consists of a mixed code base, we might need to import and use Objective-C code in Swift files. Since every object in Objective-C can become nil, Swift imports every type as an implicitly unwrapped optional without any nullability annotations.

To be more expressive in Swift by using either optional or non-optional types, we have the possibility to extend the Objective-C code with nullability declarations and macros.

Let's look at how to do that.

Nullability declarations

We can annotate Objective-C code to indicate whether an instance can have a nil value. Swift uses those annotations to import declarations either as optional or non-optional:

types with a nonnullable annotation are imported as non-optionals
types with a nullable annotation are imported as optionals

- (nullable Tea *)search:(nonnull NSString *)name;

The example above is imported to Swift as follows:

search(name: String) -> Tea?

Without a nullability annotation, Swift would import a type as an implicitly unwrapped optional, which would look as follows:

search(name: String!) -> Tea!

Nullability macros

Additionally, we can use the macros NS_ASSUME_NONNULL_BEGIN and NS_ASSUME_NONNULL_END to annotate regions in Objective-C as nonnullable.

This can simplify the process of annotating Objective-C code if we'd like to import most of the types as non-optionals into Swift.

NS_ASSUME_NONNULL_BEGIN

@interface SomeClass : NSObject

- (nullable String *)subtitleForItem:(SomeItem *)item;
@property NSString *title;
@property NSArray<SomeItem *> *items;
@end

NS_ASSUME_NONNULL_END

In the example above, all types will be imported as non-optionals into Swift, except those we annotated with a nullable declaration.

Authorizing App Store Connect API requests

Sun, 25 Dec 2022 23:00:00 GMT

As mentioned in this developer guide on the App Store Connect API, a JSON Web Token (JWT) is needed to authorize each request we make.

The JWT is an open standard that defines a way to securely transmit information. To create a JWT, the following steps are required:

Generate and download an API key from the Users and Access section in App Store Connect.
Create a JWT header and payload.
Sign the JWT with the private key of the API key.
Include the JWT as a bearer token in the request's authorization header.

Let's look at each step in more detail.

1. Generating an API key

An API key can be created in the Users and Access section in App Store Connect. When generating a key, we select a user role which determines what type of information this key can access. The roles are the same we already know from roles we can assign to team members.

An API key is a pair consisting of a public and a private key. After generating a key, we can download the private key as a .p8 file, while Apple keeps the public key.

For security reasons, Apple doesn't store the private key, so we can only download it once. From here, we can also revoke the API key immediately if it becomes inactive, lost or compromised.

2. Creating a JWT header and payload

A JWT header and payload might look as follows:

header

{
    "alg": "ES256",
    "kid": "79NWH6F376",
    "typ": "JWT"
}

payload

{
    "iss": "69a6de73-ea56-47e3-e053-5b8c7c11a4d1",
    "iat": 1528407600,
    "exp": 1528408800,
    "aud": "appstoreconnect-v1",
    "scope" : ["PATCH /v1/apps"]
}

Whereas

kid is the KEY ID of the API key we can copy from App Store Connect.
iss is the issuer id we can also copy from the API key entry in App Store Connect.
iat is the token's creation time in UNIX epoch time
exp is the token's expiration time in UNIX epoch time
scope specifies which API requests should be accepted for the token

3. Signing the JWT token

There are a variety of open source libraries available online for creating and signing JWT tokens. See JWT.io for more information.

4. Include JWT in the request's authorization header

We now can use the signed token to send requests to the App Store Connect API. For example:

curl -v -H 'Authorization: Bearer [signed token]'
"https://api.appstoreconnect.apple.com/v1/apps"

How to perform a lightweight migration in Core Data

Sun, 18 Dec 2022 23:00:00 GMT

A database migration is required whenever we need to make changes to our Core Data model. For a specific set of changes, Core Data can perform an almost automatic migration, called lightweight migration.

This allows us to evolve our schema without losing existing data or manually defining mapping rules.

Examples of supported changes include adding, renaming, or deleting entities, attributes, or relationships, and changing relationship types.

When our model changes exceed what Core Data can infer, we need to perform a heavyweight (manual) migration.

In this article, we’ll look at how to perform a lightweight migration in Core Data.

Steps to perform a lightweight migration in Core Data

To perform a lightweight migration in Core Data, the following steps are required:

Enabling lightweight migration
Creating a new model version
Modifying the new model

Let's look at these steps in more detail.

1. Enabling lightweight migration

When we use the NSPersistentContainer class to create and manage the Core Data stack, we don't need to do any additional setup work, the lightweight migration is automatically activated for us.

If we build our own Core Data stack manually, we can enable these options explicitly when adding our store:

let coordinator = NSPersistentStoreCoordinator(managedObjectModel: managedObjectModel)
let options = [
    NSMigratePersistentStoresAutomaticallyOption: true,
    NSInferMappingModelAutomaticallyOption: true
]
do {
    try coordinator.addPersistentStore(
        ofType: NSSQLiteStoreType,
        configurationName: nil,
        at: url,
        options: options
    )
} catch {
    // handle migration failure
}

These two options tell Core Data to automatically infer a mapping model and migrate data when it detects a compatible schema change.

2. Creating a new model version

To perform an automatic migration, Core Data needs both the source and destination versions of our data model.

If we modify an existing .xcdatamodeld directly after shipping our app, Core Data won’t know how to migrate and will throw an incompatible model error.

To avoid that, we create a new model version by selecting Editor > Add Model Version in Xcode's menu. This will add a new .xcdatamodel file to our project.

After adding a new version, we can set it to the current version in Xcode's File Inspector. Now we can safely make changes without breaking existing stores.

3. Modifying the new data model version

We can now make changes to our model. For Core Data to be able to create an inferred mapping model, the changes must fit a specific pattern, for example:

Adding or deleting entities, attributes or relationships.
Renaming entities, attributes or relationships by setting the renaming identifier to the name of the corresponding property or entity in the previous model in Xcode's Data Model inspector.
Changing required attributes to optional attributes or vice versa with a default value.
Changing a relationship from to-one to to-many, or a nonordered to an ordered relationship.

To verify whether Core Data can infer a mapping between two model versions, we can use:

let inferred = try? NSMappingModel.inferredMappingModel(
    forSourceModel: oldModel,
    destinationModel: newModel
)

if inferred != nil {
    // Lightweight migration is possible
}

If this call returns nil, Core Data cannot infer the mapping, meaning we'll need a heavier, manual migration.

Developer guide on the App Store Connect API

Sun, 27 Nov 2022 23:00:00 GMT

The App Store Connect API allows us to automate tasks that usually can be performed through the Apple Developer website and App Store Connect.

It's a REST API that enables us to automate tasks like managing provisioning, beta builds, in-app purchases, app metadata and more. Let's look at how to do that.

App Store Connect API overview

The App Store Connect API provides a single unified REST resource model, which means that the same patterns are applied throughout the whole API.

To construct an App Store Connect API URL, we can always apply the following pattern:

{base url}/{version number}/{resource type name}

whereas:

base URL is https://api.appstoreconnect.apple.com
current version number is v1
some example resources are:
- apps to manage and maintain the existing apps
- builds to manage existing builds
- bundleIds to manage the app's unique identifier
- devices to manage devices used for development and testing
- users to manage users

The API provides standard REST methods:

GET to get a resource or a list of resources
POST to create a resource
PATCH to change a resource
DELETE to delete a resource

Let's look at some examples.

GET requests

Let's start with a GET request. Understanding the example below will allow us to apply the knowledge to all other requests of the API.

For example, to list all apps available in App Store Connect, we could send the following request:

GET https://api.appstoreconnect.apple.com/v1/apps

The returned JSON follows a pattern. A successful response always contains a data property. In our case, it contains an array of app objects:

{
    "data": [
        {
            "attributes":
            {
                "bundleId": "tanaschita.com.exampleApp",
                "name": "ExampleApp",
                "primaryLocale": "en",
                ...
            },
            "id": "16fksv98-3j6d-39ok-12dh",
            "relationships": []
            ...
        }
    ]
    ...
}

Each resource has an attributes, an id and a relationships property.

In case of an app object, the attributes property contains values like the app's bundle ID, name, primary locale etc.

The relationships property contains references to different parts of the API which we'll discuss closely later on.

The id value is a unique id, which identifies the resource and which we can use to form other requests, for example to fetch a specific resource.

GET https://api.appstoreconnect.apple.com/v1/{resourceName}/{resourceId}

In case of our example:

GET https://api.appstoreconnect.apple.com/v1/apps/16fksv98-3j6d-39ok-12dh

POST, PATCH and DELETE requests

Just like GET requests, POST, PATCH and DELETE requests also follow a pattern. As an example, we'll use the users resource which allows us to change or delete users.

Just like in App Store Connect itself, we have to invite the user to our team and they can accept that invitation. To do that, the API provides the userInvitations resource.

A request might look like this:

POST /v1/userInvitations

{
    "data": {
        "type": "userInvitations",
        "attributes": {
            "firstName": "Natascha",
            "lastName": "Fadeeva",
            "email": "tanaschita@gmail.com",
            "roles": ["DEVELOPER"],
            "allAppsVisible": true

        }
    }
}

As we can see above, the user object follows the same principles we already saw in the app object.

As a JSON response to our POST request, we get the same object enriched with some values like the user's id, which we can then use to modify or delete a user.

To modify a user, we can send a PATCH request including the attributes we'd like to change. For example, to change the roles of a user, we could send the following request:

PATCH /v1/users/userId

{
    "data": {
        "type": "users",
        "attributes": {
            "roles": ["ADMIN"],
        }
    }
}

To delete a user, we can just do the following:

DELETE /v1/users/userId

Relationships

To understand the relationships property we already saw earlier, let's look at the betaTesters and the betaGroups resource and how they relate to each other.

The betaTesters resource represents users who can install and test prerelease builds. The betaGroups resource represents a group of testers who can access builds for testing.

The relationships object of a group looks as follows:

{
    "apps": ...,
    "betaTesters": {
        "links": {
            "related": "/v1/betaGroups/16fksv98-3j6d-39ok-12dj/betaTesters",
            "self": "/v1/betaGroups/16fksv98-3j6d-39ok-12dj/relationships/betaTesters"
        },
        ...
    },
    builds: ...
}

As we can see above, a beta tester has 3 relationships: apps, betaGroups and builds.

Each relationship again follows the same pattern, for example providing a links property. Each links object consists of the following two links:

related: a url which we can use to get all testers from this group
self: a url which represents the relationship between a beta tester and and a beta group

To connect testers and groups, we modify the relationship. For example, to add a user to a group, we would use the self link with the following request:

POST /v1/betaGroups/16fksv98-3j6d-39ok-12dj/relationships/betaTesters

{
    "data": [
        {
            "type": "betaTesters",
            "id": "19fksv98-3j6d-39ok-12dj"
        },
        ...
    ]
}

To delete the tester, we just use the same request as above with a DELETE method instead of a POST method.

Query parameters

Each API endpoint provides query parameters we can use for example to filter, limit, sort or specify the results we need. Let's look at the following request:

GET /v1/betaGroups?include=betaTesters&fields[betaTesters]=email

The request sends two query parameters:

include=betaTesters which will include testers for every group in the response
fields[betaTesters]=email which defines the fields that should be returned for the testers

Authorizing API requests

All App Store Connect API requests require authorization. The API expects a JSON Web Token (JWT) to authorize each request we make. The JWT is an open standard that defines a way to securely transmit information. Checkout this guide on how to authorize App Store Connect API requests to learn more.

All available API endpoints are documented at Apple's official App Store Connect API documentation.

How to handle non-optional Core Data properties in Swift

Sun, 06 Nov 2022 23:00:00 GMT

As described in this article on how to create an NSManagedObject subsclass for a Core Data entity in Xcode, we can either let Xcode automatically generate entity subclasses and their properties for us or create and manage them manually.

While the auto code generation has the advantage that the entity classes are always up-to-date, the manual option gives us more control and flexibility for example to improve the handling of non-optional properties.

Let's look at how to do that.

Declaring a property as optional or non-optional in Core Data

When adding properties in Core Data's .xcdatamodeld file, we can decide whether the property should be optional or non-optional:

Optional checkbox for a Core Data entity property.

But after declaring a property as non-optional, Core Data still generates the username property as a Swift optional property:

@NSManaged public var username: String?

That's because the concept of optional and non-optional values in Core Data is different from that in Swift.

The concept behind optional and non-optional values in Core Data

In Swift, the compiler enforces the presence or absence of a value, which gives us guarantees about whether or not it is safe to expect a value at compile time.

Just like in Swift, declaring a property as non-optional in Core Data means that we need to handle the abscence accordingly, but we don't get any compiler guarantees or enforcements when initializing the object. That's because when working with Core Data, the framework checks the values at run time with validation rules and throws an error when the validation fails.

Using non-optional Swift values in Core Data

Not having compiler guarantees for non-optionals when working with Core Data is a drawback. Let's look at how we can solve this.

1. Declaring the properties as non-optional in Swift

To define Core Data properties as Swift non-optionals, we need to manually generate the entity subclasses. After doing that, the first thing we can do is to simply declare the properties as non-optional by removing question marks where needed:

public class User: NSManagedObject {

    @NSManaged public var username: String
    @NSManaged public var lastLogin: Date
    @NSManaged public var verified: Bool
}

With that in place, the compiler will prevent us from setting any of these properties to nil. That's a good start.

But since the properties are marked with the @NSManaged attribute - which indicates that Core Data dynamically provides its implementation at runtime - Swift’s initialization rules do not apply. This means that we can still call init() and init(context:) without initializing any of the properties.

2. Preventing initializers from being called

To prevent initializers from being called, we can use Swift's @available attribute to mark the init methods as unavailable.

@available(*, unavailable)
public init() {
    fatalError()
}

@available(*, unavailable)
public init(context: NSManagedObjectContext) {
    fatalError()
}

With that in place, the compiler will now produce an error when calling init() or init(context:).

3. Providing a designated initializer

Now we can provide our own initializer:

public init(context: NSManagedObjectContext,
            username: String,
            lastLogin: Date? = nil,
            verified: Bool = false) {
    let entity = NSEntityDescription.entity(forEntityName: "User", in: context)!
    super.init(entity: entity, insertInto: context)
    self.username = username
    self.lastLogin = lastLogin
    self.verified = verified
}

The initializer enforces non-optional values to be passed in with a value and allows us to define default values where needed.

Conclusion

The approach described above provides a lot more clarity and safety when working with entities in code.

A drawback is that there is a lot of manual work to do to enforce the rules Swift usually enforces for us. Every time we edit an entity, we need to manually keep the initializer and properties up-to-date.

Understanding different cache policies when working with URLRequest in Swift

Sun, 30 Oct 2022 23:00:00 GMT

When in comes to server communication in iOS, the system provides different caching strategies to improve performance and reduce network traffic.

By choosing a cache policy, we can decide whether the caching should depend on expiration dates or disabled entirely or whether the server should be contacted to determine if the content has changed since the last request.

Let's jump in and explore available URLRequest cache policies and their consequences.

Setting a cache policy for URL requests

When creating a URLRequest, we can use its cachePolicy property to specify which caching should be performed, for example:

let urlRequest = URLRequest(url: url, cachePolicy: .reloadIgnoringLocalCacheData)

Alternatively, we can set the desired caching policy when configuring a URLSession. All requests created from this session inherit its cache policy.

let configuration = URLSessionConfiguration.default
configuration.requestCachePolicy = .returnCacheDataElseLoad

let urlSession = URLSession(configuration: configuration)

The following caching policies are available:

.useProtocolCachePolicy
.reloadIgnoringLocalCacheData
.reloadIgnoringLocalAndRemoteCacheData
.returnCacheDataElseLoad
.returnCacheDataDontLoad
.reloadRevalidatingCacheData

Let's go through each policy and see how the cache is being managed.

.useProtocolCachePolicy

The .useProtocolCachePolicy value is the default cache policy. It uses the caching logic defined in the protocol implementation.

When working with HTTP or HTTPS, the caching capabilities are built into the protocol so the server is able to communicate with the client on how the content should be cached.

For example, the server might send the following cache control headers:

Last-Modified: Mon, 08 Dec 2014 19:23:51 GMT
ETag: "adg2jl4kfmm5"
Cache-Control: max-age=533280
Expires: Sun, 03 May 2024 11:02:37 GMT

We don't need to dive deeper into what each header means, since the caching policy will do all the work for us. So depending on the values the server sends, the caching policy will basically perform the following behaviour:

In case no cached response is available, the system fetches the data from the URL.
In case a cached response is available, not expired and doesn't always require revalidation, the system returns the cached response.
In case a cached response is available, but expired or requires revalidation, a HEAD request is send to the server to check if the resource changed. If it's changed, the system fetches the data from the URL. Otherwise, it returns the cached response.

.reloadIgnoringLocalCacheData

The .reloadIgnoringLocalCacheData policy is self-explanatory, it simply fully ignores local cache data always sending the request to the server.

.reloadIgnoringLocalAndRemoteCacheData

The .reloadIgnoringLocalAndRemoteCacheData also fully ignores local cache data. Additionally, it instructs proxies and other intermediates to ignore their caches so far as the protocol allows.

.returnCacheDataElseLoad

The .returnCacheDataElseLoad policy always uses cached data if available ignoring its age or expiration date. It sends the request to the server only if there is no cached data.

.returnCacheDataDontLoad

The .returnCacheDataDontLoad policy always uses cached data. If no cached data is available, it returns an error. So a request is never send to the server.

.reloadRevalidatingCacheData

The .reloadRevalidatingCacheData policy uses cached data if it can be validated by the server. Otherwise, the request is send to the server.

How to create NSManagedObject subsclasses for Core Data entities in Xcode

Sun, 23 Oct 2022 22:00:00 GMT

As described in this developer guide on the main aspects of Core Data, each entity we setup in the .xcdatamodeld file describes an object and has a corresponding class that inherits from NSManagedObject.

Xcode provides three different code generation options to control how those subclasses are created.

Xcode's entity codegen options.

As we can see above, the options are Manual/None, Class Definition and Category/Extension. We can choose which option to use for a specific entity in the Data Model inspector by selecting the entity in the .xcdatamodeld file.

Let's take a closer look at what each of that options means.

Codegen option `Class Definition`

This is the default codegen option when we add a new entity. With the Class Definition option selected, Core Data generates an NSManagedObject subclass with all entity properties and relationships automatically.

For example, a generated subclass for a User entity looks as follows:

User+CoreDataClass.swift

@objc(User)
public class User: NSManagedObject {
}

User+CoreDataProperties.swift

extension User {
    @nonobjc public class func fetchRequest() -> NSFetchRequest<User> {
        return NSFetchRequest<User>(entityName: "User")
    }

    @NSManaged public var username: String?
    @NSManaged public var lastLogin: Date?
    @NSManaged public var verified: Bool
    @NSManaged public var posts: NSSet?
}

extension User {
    @objc(addPostsObject:)
    @NSManaged public func addToPosts(_ value: Post)

    @objc(removePostsObject:)
    @NSManaged public func removeFromPosts(_ value: Post)

    @objc(addPosts:)
    @NSManaged public func addToPosts(_ values: NSSet)

    @objc(removePosts:)
    @NSManaged public func removeFromPosts(_ values: NSSet)
}

As we can see above, Core Data creates a class file and an extension file. These files don't appear in our source code. Xcode produces them as part of the build process and places them in the projects build directory. After building the project, we are able to reference the User entity in our source code. The files are regenerated every time we change the corresponding entity.

Note: If Xcode throws a compiler error saying Cannot find type 'User' in scope, try to clean build the project.

Codegen option `Category/Extension`

With the Category/Extension option selected, Xcode only generates the properties file User+CoreDataProperties.swift.

We are responsible to generate the class file ourselves which gives us more control for example to add additional methods or business logic inside the managed object subclass.

To generate the class file initially, we can use Xcode's help by selecting Editor > Create NSManagedObject Subclass in the menu.

Codegen option `Manual/None`

When using the Manual/None option, Core Data doesn't generate any files. We create and maintain the subclass and all its properties and relationsships ourselves.

Core Data locates these files using the values we supply in the class name and module fields in Xcode's Data Model inspector when selecting an entity in the .xcdatamodeld file.

To generate a class and properties file initially, we can use Xcode's help by selecting Editor > Create NSManagedObject Subclass in the menu.

Conclusion

The decision whether to let Xcode automatically generate entity subclasses and their properties for us or to create and manage them manually depends on individual project needs and developer preferences.

The automatic generation option has the advantage that we don't have to worry about keeping the entity classes up-to-date, Xcode will do that for us.

The manual option on the other hand provides us with more control and flexibility, for example to improve the handling of non-optional properties. If you are interested to learn more, checkoout this article on how to handle non-optional Core Data properties in Swift.

iOS developer guide on the main aspects of Core Data

Sun, 18 Sep 2022 22:00:00 GMT

To persist complex data structures in an iOS application, Apple provides us with the Core Data framework. Core Data allows us to store permanent data for offline use, to cache data, to add undo functionality and more.

In this developer guide, we'll look at the main concepts of Core Data.

Core Data model

In Core Data, we define object structures by using entities that can have attributes as properties and relationships between each other.

A Core Data model is represented by a .xcdatamodeld file. Within the file, we can use Xcode's built-in editor to add entities, their attributes, define relationships and more.

Xcode's .xcdatamodeld file editor

Internally, the .xcdatamodeld file is an XML file. We can open it in any text editor to inspect it.

.xcdatamodeld file's XML content

Managed objects

Each entity we setup in the .xcdatamodeld file describes an object and has a corresponding class that inherits from NSManagedObject.

The NSManagedObject subclass and properties extension for the User entity might look as follows:

@objc(User)
public class User: NSManagedObject {
}

extension User {
    @NSManaged public var username: String?
    @NSManaged public var lastLogin: Date?
    @NSManaged public var verified: Bool
    @NSManaged public var posts: NSSet?
}

Each attribute has an @NSManaged annotation which indicates that Core Data dynamically provides its implementation at runtime, based on the associated entity description.

The NSManagedObject subclasses can be generated automatically or manually. Checkout this article on how to create an NSManagedObject subsclasses for Core Data entities in Xcode to learn more.

Managed object context

Represented by the NSManagedObjectContext type, a context has a central role in the life cycle of managed objects.

It allows us to retrieve objects from a persistent store, create new objects, delete and edit objects. These changes remain in memory until we either discard the changes or save them back to the persistent store.

let newUser = User(context: managedObjectContext)
newUser.username = ...
// setting more attributes

do {
    try managedObjectContext.save()
} catch {
    // handle error
}

In the example above, we create a new user and then use the save() method on the context to save the user.

Fetch requests

Represented by NSFetchRequest, we can use a fetch request to define which managed objects we want to request from the managed context.

An example to fetch all users might look like this:

let usersFetchRequest = NSFetchRequest<User>(entityName: "User")
usersFetchRequest.sortDescriptors = [NSSortDescriptor(keyPath: \User.username, ascending: true)]

do {
    let users = try viewContext.execute(usersFetchRequest)
} catch {
    // handle error
}

As we can see in the example above, a fetch request specifies which entity to search. Optionally, we can add a predicate to filter the results, a sort descriptor, a fetch limit and more.

When working with SwiftUI, we can use the @FetchRequest property wrapper to retrieve data from Core Data.

@FetchRequest(
  sortDescriptors: [NSSortDescriptor(keyPath: \User.username, ascending: true)])
private var users: FetchedResults<User>

Checkout this article on @FetchRequest property wrapper in SwiftUI to learn more.

NSPersistentContainer

The NSPersistentContainer class simplifies creating and managing the Core Data stack.

container = NSPersistentContainer(name: "CoreDataExampleApp")
container.loadPersistentStores(completionHandler: { (storeDescription, error) in
    // Handle error if needed.
})

In the example above, we create an instance of NSPersistentContainer and call loadPersistentStores() on it. When successfully setup, it provides the viewContext property that gives us access to a managed object context to start working with Core Data.

How to manage view lifecycle events in SwiftUI

Wed, 14 Sep 2022 22:00:00 GMT

When working with SwiftUI views, we often need to trigger side effects when a view appears or disappears. We can do that by using declarative modifiers that attach to views.

The onAppear(perform:) method

onAppear runs right before a view appears. It is useful for lightweight setup or triggering updates.

struct SomeView: View {

    var body: some View {
        VStack {
            ...
        }
        .onAppear {
            viewModel.update()
        }
    }
}

The onDisappear(perform:) method

onDisappear runs right after the view disappears. It's the place to clean up or cancel ongoing work.

struct SomeView: View {

    var body: some View {
        VStack {
            ...
        }
        .onDisappear {
            viewModel.cancelLoading()
        }
    }
}

The task(priority:_:) method

The task modifier allows us to start asynchronous work when a view appears. SwiftUI automatically cancels the task when the view disappears, so it integrates neatly with the view lifecycle.

struct SomeView: View {

    var body: some View {
        VStack {
            ...
        }
        .task {
            await viewModel.load()
        }
    }
}

The task(id:) variant

task(id:) is a more advanced form of task. It still behaves like the regular task in that it runs once when the view appears and is canceled when the view disappears. The difference is that it also observes a value we provide as an identifier. Whenever that value changes, SwiftUI cancels the old task and starts a new one automatically.

.task(id: viewModel.query) {
    await viewModel.search(query: viewModel.query)
}

In this example, the search runs once when the view appears, and then again every time the query changes. This makes task(id:) especially useful for scenarios like search bars or dynamic filters, where you want to restart asynchronous work when a parameter updates, without having to manage cancellation manually.

With these tools, SwiftUI provides a clear way to run both synchronous and asynchronous work in response to view lifecycle changes.

Building configurable widgets with WidgetKit and SwiftUI

Sun, 04 Sep 2022 22:00:00 GMT

In the previous article on building widgets with WidgetKit and SwiftUI, we looked at the basic structure of a WidgetKit widget.

In this article, we'll look at configurable widgets. A configurable widget lets users choose values that affect what the widget displays. For example, a finance app could let users choose an account, a task app could let users choose a project, and a quote app could let users choose a category.

We'll use a simple quote widget as an example. The user will be able to choose a quote category when adding or editing the widget, and the widget will show a quote for that selected category.

The flow is: the user chooses a value, WidgetKit stores it in the intent, the provider receives the intent, and the widget renders an entry built from that value.

Defining the configurable value

The first step is to define the value the user can choose. In our example, this value is the quote category.

For a fixed list of options, we can use an enum that conforms to AppEnum. Dynamic options are also possible when the available values come from app data, and we'll look at that later in the article.

import AppIntents

enum QuoteCategory: String, AppEnum {
    case motivation
    case focus
    case mindfulness

    static var typeDisplayRepresentation = TypeDisplayRepresentation(name: "Category")

    static var caseDisplayRepresentations: [QuoteCategory: DisplayRepresentation] = [
        .motivation: "Motivation",
        .focus: "Focus",
        .mindfulness: "Mindfulness"
    ]
}

The display representations define how the enum cases appear in the widget configuration UI.

Exposing the value to WidgetKit

Next, we define a type that conforms to WidgetConfigurationIntent. The intent describes the values WidgetKit should show when the user configures the widget.

We can use the QuoteCategory enum as a parameter:

struct QuoteWidgetIntent: WidgetConfigurationIntent {
    static var title: LocalizedStringResource = "Quote Widget"
    static var description = IntentDescription("Shows a quote from the selected category.")

    @Parameter(title: "Category")
    var category: QuoteCategory = .motivation
}

The @Parameter property is the value users can change. Here, the user can choose a quote category, and the widget can later use that selected category to decide which quote to display.

Connecting the intent to the widget

For a configurable widget, we use AppIntentConfiguration:

import AppIntents
import SwiftUI
import WidgetKit

struct QuoteWidget: Widget {
    var body: some WidgetConfiguration {
        AppIntentConfiguration(
            kind: "com.example.QuoteWidget",
            intent: QuoteWidgetIntent.self,
            provider: QuoteTimelineProvider()
        ) { entry in
            QuoteWidgetView(entry: entry)
        }
        .configurationDisplayName("Quote")
        .description("Shows a quote for the selected category.")
        .supportedFamilies([.systemSmall, .systemMedium])
    }
}

WidgetKit uses the intent type to show the widget configuration UI and to pass the selected values to the timeline provider.

Using the selected value

A timeline entry contains the data that the widget view needs to render a specific state:

struct QuoteEntry: TimelineEntry {
    let date: Date
    let category: QuoteCategory
    let quote: String
}

Because the widget is configurable, the provider conforms to AppIntentTimelineProvider. Its snapshot and timeline methods receive the selected configuration, which is where the user choice becomes useful:

struct QuoteTimelineProvider: AppIntentTimelineProvider {
    func placeholder(in context: Context) -> QuoteEntry {
        QuoteEntry(
            date: Date(),
            category: .motivation,
            quote: "Small steps count."
        )
    }

    func snapshot(for configuration: QuoteWidgetIntent, in context: Context) async -> QuoteEntry {
        entry(for: configuration.category)
    }

    func timeline(for configuration: QuoteWidgetIntent, in context: Context) async -> Timeline<QuoteEntry> {
        let entry = entry(for: configuration.category)
        let nextUpdate = Date().addingTimeInterval(60 * 60)

        return Timeline(entries: [entry], policy: .after(nextUpdate))
    }

    private func entry(for category: QuoteCategory) -> QuoteEntry {
        QuoteEntry(
            date: Date(),
            category: category,
            quote: quote(for: category)
        )
    }

    private func quote(for category: QuoteCategory) -> String {
        switch category {
        case .motivation:
            return "Small steps count."
        case .focus:
            return "One thing at a time."
        case .mindfulness:
            return "Take a breath before moving on."
        }
    }
}

The important part is configuration.category. It contains the category selected by the user, so the provider can create a timeline entry for that category.

Building the widget view

The widget view receives the timeline entry and renders the selected content:

struct QuoteWidgetView: View {
    let entry: QuoteEntry

    var body: some View {
        Text(entry.quote)
            .font(.headline)
            .containerBackground(.background, for: .widget)
    }
}

In a real app, the provider could load the quote from shared app data, a local database, or another persistence layer that the app and widget extension can both access.

When options come from app data

An enum works well when the available choices are known ahead of time. If the options come from user data, such as projects, accounts, or lists, the configuration can use App Intents entities and queries instead.

For example, a task app might let users choose one of their own projects. In that case, the widget configuration needs to load the available projects dynamically instead of defining them as enum cases.

Summary

To build a configurable widget, we define a WidgetConfigurationIntent, use it with AppIntentConfiguration, and read the selected values in an AppIntentTimelineProvider.

For simple fixed choices, an AppEnum is often enough. For user-generated choices, App Intents entities are a better fit because the available options can be loaded dynamically.

How to bridge async/await functions to Combine's Future type in Swift

Sun, 21 Aug 2022 22:00:00 GMT

When working with asynchronious code in Swift, we might have to find ways to mix and connect different asynchronious patterns like using the Combine framework together with Swift's async/await API.

In this article, we'll look at how to call async-marked functions within Combine based APIs.

Let's look at the following async function which loads a user from server with the async/await pattern.

func loadUser() async throws -> User {
    // Load user from server
    return user // or throw error
}

To implement the same behaviour with Combine, its Future publisher comes in handy. A future is initialized with a closure that takes a Future.Promise. After doing some asynchronous work, we call that closure with a Result that is either a success or a failure. Combine then automatically maps the result into proper publisher events.

Let's look at how the async function above could be implemented with a Future publisher:

func loadUser() -> Future<User, Error> {
    return Future() { promise in
        // Load user from server.
        promise(.success(user))  // or promise(.failure(error))
    }
}

But since we already have an implementation that loads a user, we'd like to avoid duplication writing the same logic twice.

So let's try to find a more generic solution, that allows us to convert an async func to a Future publisher.

extension Future where Failure == Error {
    convenience init(asyncFunc: @escaping () async throws -> Output) {
        self.init { promise in
            Task {
                do {
                    let result = try await asyncFunc()
                    promise(.success(result))
                } catch {
                    promise(.failure(error))
                }
            }
        }
    }
}

In the code above, we extend the Future type with a convenience initializer that allows us to initialize an instance with an async closure. Applied to our example:

func loadUser() -> Future<Int, Error> {
    return Future(asyncFunc: {
        try await loadUser()
    })
}

For non-throwing async functions, we could add another extension:

extension Future where Failure == Never {

    convenience init(asyncFunc: @escaping () async -> Output) {
        self.init { promise in
            Task {
                let result = await asyncFunc()
                promise(.success(result))
            }
        }
    }
}

With a generic solution like this, we now have the possibility to use it on any async function to bridge it to Combine's Future type.

Implementing Password AutoFill for an iOS application

Sun, 14 Aug 2022 22:00:00 GMT

Apple's Password AutoFill feature allows users to login into the same account on different devices without having to remember their credentials.

For example, when signing up in a web app, users are able to generate a password and to save credentials in their iCloud keychain. When they run a native app to access the same account at some point, the app suggests the credentials stored for the website in the password QuickType bar. After the user authenticates, let's say by using Face ID, the system prefills the credentials - so there is no need to reenter them.

To activate Password Autofill in an iOS application, the following steps are required:

Setting up the app's associated domains.
Setting the correct AutoFill type on relevant text fields.

Let's look at those steps in more detail.

Setting up the app's associated domains for shared web credentials

Associated domains establish a secure association between a website and an iOS application. To support shared web credentials, the following steps are required:

Creating and configuring an associated domain file for shared web credentials.
Adding the associated domain file to the related website.
Adding an associated domain entitlement to the iOS app.

Each of those steps is described in more detail in this quide on associated domain files.

Enable Password Autofill with `textContentType`

After setting up shared web credentials, all we need to do is to set the textContentType property on any relevant input views to activate the correct AutoFill suggestions.

The following UITextContentType values are available:

.username for account names
.password for passwords
.newPassword for new passwords
.oneTimeCode for one-time passwords, for example to autocomplete security codes from single-factor sms login flows

Let's see how to do that for SwiftUI and UIKit applications.

Enable Password Autofill for SwiftUI

In SwiftUI, we can set a UITextContentType value by using the textContentType(_:) method:

TextField("Enter your email", text: $emailAddress)
    .textContentType(.username)
    .keyboardType(.emailAddress)

TextField("Enter your password", text: $password)
    .textContentType(.password)

Based on textContentType we provided, iOS automatically chooses a matching keyboard to show to the user.

To present a different keyboard, for example if the app uses emails as user names, we can additionally set the .keyboardType to a desired value.

Enable Password Autofill for UIKit

UIKit supports Password AutoFill on UITextField, UITextView and any custom view that adopts the UITextInput protocol. We can set a UITextContentType value by using the textContentType instance property:

userTextField.textContentType = .username
userTextField.keyboardType = .emailAddress
passwordTextField.textContentType = .password

Quick guide on Proxyman for iOS development

Sun, 03 Jul 2022 22:00:00 GMT

Proxyman is a proxy server app available for macOS that enables us to view networking traffic, including traffic from iOS applications. It provides the possibility to configure the iOS simulator or device to pass its HTTP and HTTPS requests and responses through Proxyman, so we are able to inspect and even change the data in our testing and debugging process.

This guide provides an overview on Proxyman and its features with a focus on iOS development.

Recap on proxies

A proxy is an application that acts as an intermediary between a client requesting a resource and the server providing that resource. So instead of connecting directly to a server, the client directs the request to the proxy, which performs the request, receives the response and then directs the response to the client.

Proxy as interactor between client and server.

Getting started with Proxyman

Proxyman provides a free version with all essential features that can be downloaded on the official download page.

After installing and launching the app, it asks for permission to install a proxy helper tool to configure system proxy settings. When finished, Proxyman directly starts recording network traffic.

When calling a URL, for example in a browser, the requests pop up in the flow list panel.

Proxyman start screen.

Selecting a request in the flow list panel shows request and response details in the flow content panel.

Enabling SSL Proxying

As shown above, we cannot inspect the HTTPS response yet because it is encrypted. When communicating over HTTPS, encryption prevents proxy servers and other middleware from eavesdropping on sensitive data. SSL/TLS encrypts the networking traffic using certificates generated by trusted certificate issuers.

To change that we need to install the Proxyman Root Certificate. Proxyman will then act as a man-in-the-middle, which enables us to see the HTTPS traffic in plain text.

To install the Proxyman Root Certificate:

Open Certificate ▸ Install Certificate on this Mac in Proxyman's menu.
Select Install & Trust in the opened window and enter your password when prompted.
Open Tools ▸ SSL Proxying List > add a specific domain, a wildcard or and app to enable SSL proxying.

SSL Proxying List window.

After finishing the steps, we are now able to read encrypted responses from the domains and apps we listed.

Inspecting network traffic from an iOS simulator or device

To be able to see traffic coming in and out from an iOS application, Proxyman provides the possibility to install the Proxyman Root Certificate on an iOS simulator or device.

To install the certificate on a iOS simulator:

Launch an iOS simulator, for example by running the app from Xcode.
Open Proxyman's menu Certificate > Install Certificate on iOS > Simulators.
In the opened iOS Simulators Setup window, just click install and trust and then reboot the simulators.

iOS Simulators Setup

Now, networking traffic from the iOS Simulator should show up in the flow list panel.

Since Proxyman installs the certificate only on booted iOS simulators, repeat the process when running the app on a different simulator.

To setup Proxyman with an iOS device, open Certificates > Install Certificate on iOS > Physical Devices. Proxyman will guide you step by step through the process.

Limiting results to specific apps or domains

To limit network traffic showing up in the flow list, for example to only one specific domain, we can use the pin tool.

Pinning a domain

After selecting the domain or app to pin, drag it into the pin section in the source list panel. Or alternatively right-click and select pin.

Repeating, editing and composing requests

To repeat a request without resending it manually, we can use the repeat tool by selecting a request in the flow list, right-clicking it and choosing Repeat.

Repeat a request

Alternatively to the Repeat option, there is an Edit and Repeat option to edit a request before resending it. It allows to change query, header values and body of the selected request.

We can also compose a fully new request using the compose button in the menu or by selecting Tools > Compose Request.

Using breakpoints to intercept and edit requests and responses

The breakpoint tool allows us to edit the content of a request or response on the fly.

Right-clicking the request and selecting Tools > Breakpoint opens the following breakpoints dialog.

Adding a breakpoint

It provides different options to configure which requests and responses should be intercepted.

After creating the breakpoint, Proxyman will open a new editing window as soon as it receives a request or response we want to intercept. It allows us to modify the data as we wish before continuing the execution with new changes.

Using map local tool to change responses

Being able to change responses is a really useful feature when developing apps, for example to simulate different scenarios or errors and see how our app responds.

The map local tool enables us to setup a custom response by right-clicking the request and selecting Tools > Map Local.

Changing the response with the map local tool

In the opened window, we can edit the response directly or choose a local file that will serve as response.

Exporting request and response data

To export or share networking data with others, we can copy a cURL by right-clicking the request and selecting Copy cURL or use one of the export options by selecting Export.

Request and response exporting options

After choosing a destination, Proxyman will create two .txt files with all relevant network data for the selected request and response.

Customizing buttons in SwiftUI with the ButtonStyle protocol

Sun, 22 May 2022 22:00:00 GMT

SwiftUI provides a ButtonStyle protocol which allows us to create reusable button styles without having to create new views.

Let's directly jump into an example.

When working with buttons, SwiftUI provides modifiers to customize them. Instead of writing:

Button("Primary", action: someAction)
    .padding(.horizontal, 20)
    .padding(.vertical, 10)
    .foregroundColor(.white)
    .background(Color.red)
    .clipShape(RoundedRectangle(cornerRadius: 10))

we can encapsulate that style:

struct PrimaryButtonStyle: ButtonStyle {
    func makeBody(configuration: Configuration) -> some View {
        configuration.label
            .padding(.horizontal, 20)
            .padding(.vertical, 10)
            .foregroundColor(.white)
            .background(Color.red)
            .clipShape(RoundedRectangle(cornerRadius: 10))
    }
}

Then reuse it cleanly:

Button("Primary", action: someAction)
    .buttonStyle(PrimaryButtonStyle())

The makeBody function provides a configuration that we can use to adjust the appearance. It also provides the property isPressed which indicates whether the user is currently pressing the button.

.foregroundColor(configuration.isPressed ? .brown : .red)

Another benefit we get is that we can set the button style in the environment of a view.

VStack(spacing: 10) {
    Button("Primary button 1") {}
    Button("Primary button 2") {}
    Button("Primary button 3") {}
}
.buttonStyle(PrimaryButtonStyle())

Setting the button style on the VStack will automatically apply it to all the buttons inside the view.

Customizing the appearance of the NavigationView title in SwiftUI

Sun, 15 May 2022 22:00:00 GMT

Note: Starting with iOS 16, NavigationStack provides more robust navigation handling, such as support for deep linking, programmatic navigation, and improved management of state. While NavigationView remains available for backward compatibility, it's recommended to use NavigationStack for modern SwiftUI projects.

In this article, we'll look at how to customize the navigation title for NavigationView. Let's jump in.

The default NavigationView in iOS shows a large title when it's expanded and switches to an inline title when scrolled. The following code example results in such default behaviour.

NavigationView {
    VStack {
        /// List...
    }
    .navigationTitle("Title")
}

SwiftUI provides 2 options to customize the appearance of the title:

the navigationBarTitleDisplayMode(_:) modifier
the toolbar(content:) modifier.

The `navigationBarTitleDisplayMode(_:)` modifier

By using the navigationBarTitleDisplayMode(_:) modifier and setting it to .inline disables the large title style. The title always stays within the standard bounds of the navigation bar.

var body: some View {
    NavigationView {
        VStack {
            // List...
        }
        .navigationTitle("Title")
        .navigationBarTitleDisplayMode(.inline)
    }
}

The `toolbar(content:)` modifier

In case we need a custom appearance of the title, we can use the toolbar(content:) modifier.

var body: some View {
    NavigationView {
        VStack {
            // List...
        }
        .navigationTitle("Title")
        .navigationBarTitleDisplayMode(.inline)
        .toolbar {
            ToolbarItem(placement: .principal) {
                Image(systemName: "photo.fill")
                    .foregroundColor(.green)
            }
        }
    }
}

We set a ToolbarItem of placement type .principal with the content we want to show as a title view. If a navigation bar title is also configured, it gets overridden by the toolbar item.

We can replace the Imageview from the example above with any type of SwiftUI view hierarchy.

Quick guide on local notifications for iOS

Sun, 01 May 2022 22:00:00 GMT

iOS local and push notifications allow us to keep users informed about important updates, reminders, or time-sensitive events, even when the app is running in the background or is inactive.

While remote push notifications are sent from a server via the Apple Push Notification Service (APNs), local notifications are generated and controlled by the app itself. Both are configured using the UserNotifications framework.

In this guide, we are going to look at how local notifications work, how to ask for user's permission, how to schedule them in different ways, and how to handle them effectively.

Let's jump in.

Requesting user permission

Before sending notifications, we need to request the user's permission, typically when the app starts or when a user first accesses a feature that triggers notifications.

import UserNotifications

UNUserNotificationCenter.current().requestAuthorization(options: [.alert, .badge, .sound]) { granted, error in
    if granted {
        print("Notification permission granted.")
    } else if let error = error {
        print("Error requesting notification permissions: \(error.localizedDescription)")
    }
}

With [.alert, .badge, .sound], we ask for the ability to display alerts, to update the app's badge and to play sounds.

There are more options available. For example, we could ask for:

criticalAlert - which requires a special entitlement issued by Apple because they bypass silent modes.
.carPlay - to display notifications in a CarPlay environment.

Creating notification content

Once we have permission, the next step is to create the notification's content using UNMutableNotificationContent. For example:

let content = UNMutableNotificationContent()
content.title = "Stay hydrated"
content.body = "It's time for a glass of water"
content.sound = UNNotificationSound(named: UNNotificationSoundName("water.wav"))

In the above example, we set the title, body and sound properties. For a native sound, we could just set it to .default.

There are more options available. For example, the badge property that specifies the number to apply to the app's icon when the notification arrives. Or the threadIdentifier property to group notifications visually. We could also set the userInfo dictionary to add some custom data we can use later when handling the notification.

Scheduling the local notification

The next step is to define a trigger for the notification. There are three main types:

Time Interval trigger which fires after a set number of seconds
Calendar trigger which fires at a specific date and time
Location trigger which fires when the user enters or exits a geographic region

To learn how to configure any of those triggers, checkout this article on scheduling notifications with time, calendar, and location triggers.

Registering the notification request

Once the content and trigger are ready, we can register a notification:

let id = UUID().uuidString
let request = UNNotificationRequest(
    identifier: id, content: content, trigger: trigger)

UNUserNotificationCenter.current().add(request) { error in
    if let error = error {
        print("Error adding notification request: \(error.localizedDescription)")
    }
}

The identifier allows us to modify or cancel this specific notification later if needed.

The method above is also available as an asynchronous method func add(_ request: UNNotificationRequest) async throws that we can use when working with async/await instead.

Cancelling a notification request

To cancel a specific request, we pass the id we used when creating it.

UNUserNotificationCenter.current().removePendingNotificationRequests(withIdentifiers: [id])

To remove all pending requests, the notification center provides the method removeAllPendingNotificationRequests().

Handling notifications in the foreground

When the app is running in the foreground, the notification will not be shown to the user by default. To change this behavior, we can implement the UNUserNotificationCenterDelegate methods which notify us when the notification is about to be presented.

func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {

    UNUserNotificationCenter.current().delegate = self
    return true
}

func userNotificationCenter(_ center: UNUserNotificationCenter, willPresent notification: UNNotification, withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void) {
    completionHandler([.alert, .badge, .sound])
}

Calling the completionHandler will show the notification based on the UNNotificationPresentationOptions parameter we pass in indicating how to present a notification in a foreground app.

Instead of showing the notification, we could also implement a custom solution for example to show an app dialog that makes more sense for this specific use case.

Handling notification actions

When the user interacts with a delivered notification, we can handle the response:

func userNotificationCenter(_ center: UNUserNotificationCenter, didReceive response: UNNotificationResponse, withCompletionHandler completionHandler: @escaping () -> Void) {

    let userInfo = response.notification.request.content.userInfo
    // Handle notification

    completionHandler()
}

Here, we could for example use the userInfo to trigger certain flows or to show information or screens related to the notification.

Manipulating networking requests and responses with Charles

Sun, 06 Mar 2022 23:00:00 GMT

Charles is a proxy server that enables us to view the networking traffic between the app and the internet.

In Quick guide on Charles Proxy for iOS development, we already looked at the features Charles has to offer and how to use them.

In this article, we are going to dive more deeper and look at the Charles breakpoints tool. It lets us intercept and manipulate requests and responses before they are passed through Charles.

Being able to manipulate response data is a great way to test how the app handles unexpected values. Let's get started.

Setting up a breakpoint

Each breakpoint in Charles matches a URL using location matching patterns and is also assigned to either the request, the response or both.

The simplest way to enable a breakpoint is by selecting the URL and then clicking the breakpoint button in the top toolbar.

Enable breakpoints.

For more control, open Proxy -> Breakpoint Settings in the menu. Here, we see an overview of all the breakpoints that are set, can edit, remove them or add new ones.

Breakpoint settings.

When editing or adding a breakpoint, we are able to configure details like protocol, host, port, path patterns or wildcards. Here, we can also select whether the breakpoint should be assigned to the request, the response or both.

Editing request and response data

When a request hits a breakpoint, the breakpoints window automatically opens in Charles we can view and edit the data.

Edit request.

The same happens when a response hits a breakpoint.

Edit response.

After editing, we can use different action buttons on how Charles should proceed with the request or response. The following actions are available:

Execute: Applies any changes we made and lets the request or response proceed.
Abort: Blocks the request or response and sends an error message to the client.
Cancel: Discards any changes we made and lets the request or response proceed as originally received.

Conclusion

Charles breakpoint tool is an easy to use and powerful way to debug our applications.

Charles offers even more advanced tools like repeating, automatic rewrites, map local, map remote, cache, cookies control and more. Check out their official tools documentation to check those out.

Quick guide on Charles Proxy for iOS development

Sun, 27 Feb 2022 23:00:00 GMT

Charles is a proxy server that enables us to view the networking traffic between our iOS app and the internet.

We can configure the iOS simulator or device to pass its networking requests and responses through Charles Proxy, so we’ll be able to inspect and even change the data in our testing and debugging process.

Recap on proxies

Proxy as interactor between client and server.

When communicating over HTTPS, encryption prevents proxy servers and other middleware from eavesdropping on sensitive data. SSL/TLS encrypts the networking traffic using certificates generated by trusted certificate issuers.

For Charles to be able to decrypt and show us encrypted traffic, it offers to generate its own certificate that we install on our iOS simulator or device and explicitly trust it. We'll look at that in more detail later.

Getting started with Charles

Charles Proxy isn’t free, but offers a free 30-day trial that can be downloaded on the official Charles download page.

After installing and launching the app, Charles should ask for permission to automatically configure our network settings. When granted, Charles will change our computer's network configuration to route all traffic through it. This allows Charles to inspect all network events to and from our computer.

After granting privileges, Charles directly starts recording network traffic that we see on the left pane.

Charles start screen.

When calling some URL for example in a browser, we should see the requests pop up in the left pane of Charles.

To be able to see the traffic coming in and out from an iOS simulator, follow these steps:

Quit the iOS Simulator
Launch Charles
Open menu Help > SSL Proxying > Install Charles Root Certificate in iOS Simulators

This will install the Charles Root Certificate into all iOS Simulators. Now, we should also be able to see the networking traffic from the iOS Simulator in Charles.

To setup Charles with an iOS device, check out the official documentation. Charles also offers a Charles for iOS app that can be used instead to monitor networking traffic for iOS devices.

Charles sessions

When we start Charles, a new session is automatically created by default and contains all recorded information. In most cases, we'll only need one session. Sessions can be saved and re-opened for example for sharing with others.

Charles default session.

Recording

Charles records requests and responses to the current session for us to inspect. We can start and stop recording by using the record button in the top toolbar.

Charles record button.

By default, Charles tracks all network calls. We can control the recorded traffic by opening Proxy -> Recording Settings in Charles menu and adding the API endpoints we want to observe. Port 443 is the standard port for HTTPS traffic.

Charles recording settings.

To be able to see the encrypted traffic, we also need to add the same endpoints to Proxy -> SSL Proxying Settings.

Structure and sequence view

In the left pane of the Charles app, we can switch between the structure and the sequence view.

The structure view lets us view the requests in a tree organised by the host name and the directories within the host.

Structure view in Charles.

The sequence view lets us view the requests in the sequence that they occur.

Sequence view in Charles.

Note: If you don't see any requests in the sequence view, uncheck the Focused checkmark or mark the endpoints you want to see as focused by right-clicking them in the structure view.

Request and response views

When choosing one request in the left pain, we get a detail view on the right side.

Request and response view in Charles.

As we can see above, the top area shows the request with query parameters, form parameters, cookies, authentication and JSON headers. The bottom area shows the response. For both, we can switch between different views of the same data like text, raw, json etc.

Chart view

The chart view in Charles shows us request and response times of each request.

Chart view in Charles.

Simulating slow networking

Charles can be used to adjust the bandwidth and latency of the network connection. This allows us to test our application under poor networking conditions. Go to Proxy -> Throttle Settings to see the available options.

Network throttling with Charles.

We can apply throttling to all requests or only to specific hosts, so the rest of our networking requests aren't slowed down.

Manipulating requests and responses

Being able to manipulate response data is a great way to test how the app handles unexpected values.

Charles breakpoints tool lets us intercept and manipulate requests and responses before they are passed through Charles.

Check out the guide on Manipulating requests and responses with Charles for more details on this topic.

Symmetric-key cryptography with CryptoKit for iOS

Sun, 16 Jan 2022 23:00:00 GMT

Unlike public-key encryption, which uses separate keys for encryption and decryption, symmetric encryption relies on a single shared key. While this requires securely exchanging the key beforehand, it is significantly less complex and more performant than asymmetric encryption.

In real-world applications, both encryption methods are often used together:

Asymmetric encryption is used to securely exchange a symmetric key.
Symmetric encryption is used to encrypt and decrypt actual data efficiently.

Let's see how we can implement symmetric-key cryptography in iOS using CryptoKit.

Generating and exchanging a shared secret

Before we can encrypt data with symmetric encryption, both parties (client and server) must share the same secret key. This is commonly achieved through public-key cryptography:

The server generates a symmetric key, encrypts it using the client's public key, and sends it over.
The client decrypts the symmetric key using its private key.
Now, both the client and server have the same shared symmetric key, which they can use for fast encryption and decryption.

Once the symmetric key is obtained, we can create a SymmetricKey instance in CryptoKit as follows:

let keyData = Data(base64Encoded: base64EncodedKeyString)
let symmetricKey = SymmetricKey(data: keyData)

Encrypting and decrypting data

Modern symmetric encryption algorithms use an approach called AEAD (Authenticated Encryption with Associated Data). The two most commonly used ciphers in this category are AES-GCM and ChaCha20-Poly1305.

Using CryptoKit, encrypting data with these algorithms is straightforward:

let encryptedData = try ChaChaPoly.seal(data, using: symmetricKey).combined

The same can be achieved using AES-GCM:

let encryptedData = try AES.GCM.seal(data, using: symmetricKey).combined

To decrypt the data, we reconstruct the sealed box and use the symmetric key:

let sealedBox = try ChaChaPoly.SealedBox(combined: encryptedData)
let decryptedData = try ChaChaPoly.open(sealedBox, using: symmetricKey)

Signing with symmetric key

In addition to encryption, symmetric cryptography can also be used for verifying data integrity and authenticity through HMAC (Hash-based Message Authentication Code).

HMAC allows us to sign a message using a symmetric key, generating an authentication code that can be verified by the recipient. This is useful when ensuring that data has not been tampered with during transmission.

For that, we use the previously shared secret key to sign the digest of the data and then send both, the data and the signed digest to the server. The server uses the same key to validate the data.

let authenticationCode = HMAC<SHA512>.authenticationCode(for: data, using: symmetricKey)

This authentication code is sent along with the data. The recipient can then validate its authenticity:

let isValid = HMAC<SHA512>.isValidAuthenticationCode(Data(authenticationCode),
                                                          authenticating: data,
                                                          using: symmetricKey)

Conclusion

CryptoKit provides a simple and powerful API for applying symmetric cryptography in iOS applications, whether for encrypting data, verifying integrity with HMAC, or securely exchanging keys.

By combining symmetric and asymmetric cryptography, we can create secure communication channels, protect sensitive data, and ensure data authenticity - all with just a few lines of Swift code.

How to preview SwiftUI views in dark mode

Sun, 07 Nov 2021 23:00:00 GMT

With dark mode becoming a common user preference on iOS devices, it's essential to test how your app's views look in both light and dark modes.

Thankfully, SwiftUI makes this process effortless. We can use the preferredColorScheme(_:) modifier in our previews and pass .dark or .light as the argument. Here's how to implement it:

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
          .preferredColorScheme(.dark)

        ContentView()
          .preferredColorScheme(.light)
    }
}

In this example, we’re previewing the ContentView in both dark and light mode.

Quick tip: Toggle dark and light modes in the simulator

When running your app in the iOS simulator, you can quickly switch between dark and light modes using the keyboard shortcut CMD + SHIFT + A. This is a fast and convenient way to test UI elements dynamically while developing.