(This article assumes you have basic knowledge of shell scripts)

The challenge of version management

Shared library version management can be a daunting task. Whether you’re working on an in-house project or maintaining a public package, keeping track of changes and their impact becomes increasingly complex as the project grows. Even for solo developers, there’s a significant risk of introducing breaking changes without properly marking them with a major version bump.

The solution: automated versioning

This article presents a practical solution through automation. We’ll explore how to either fully automate the versioning process or verify manually proposed versions, ensuring consistent and correct semantic versioning across your Swift packages.

Understanding Swift Package Manager versioning

Swift Package Manager (SPM) uses Semantic Versioning (semver). While Semantic Versioning supports suffixes (like 1.0.1-alpha), SPM works best with the "version core" only (e.g., 1.0.1). Tagging changes with just the version core enables library consumers to reliably use SPM's .upToNextMinor(from:) and .upToNextMajor(from:) to specify supported versions.

How it can be achieved?

Let’s break down our automation approach into clear, manageable steps:

1. Compare API states: We’ll extract the public interface from both the latest tagged version and the current codebase
2. Analyze differences: We’ll identify what has been added, modified, or removed in the public API
3. Apply versioning rules: Based on the changes detected, we’ll determine the appropriate version bump:
   - Patch (x.x.Z) — bug fixes and internal changes that don’t affect the public API
   - Minor (x.Y.x) — new features that are backward compatible
   - Major (X.x.x) — breaking changes that require consumer code updates
4. Propose version: We’ll generate the next appropriate version number following semantic versioning principles

Script foundation and argument parsing

First, setup the script basics:

#!/usr/bin/env bash

set -Eeuo pipefail
trap 'error_handler ${FUNCNAME-main context} ${LINENO} $?' ERR

# CONSTANTS

readonly CALL_DIR="$PWD"
readonly SCRIPT_NAME=$(basename -s ".sh" "$0")
readonly TEMP_DIRECTORY="tmp$RANDOM"

# FUNCTIONS

function error_handler() {
    echo "$SCRIPT_NAME.sh: in '$1()', line $2: error: $3"
    reset
    exit 1
}

function main() {
    # We will fill it later.
}

# ENTRY POINT

while [[ $# -gt 0 ]]; do
    case $1 in
        # Device for which public interface is created. Use value supported by `-destination` argument from `xcodebuild archive`,
        # e.g. `platform=iOS Simulator,name=iPhone 14,OS=17.0`.
        -d|--device)
            DESTINATION=${2}
            shift 2
        ;;
        # Derived data path (might be optional).
        -r|--derived-data-path)
            DERIVED_DATA_PATH=${2}
            ARCHIVE_PATH="$DERIVED_DATA_PATH/archive"
            shift 2
        ;;
        # Package scheme name. For packages with multiple targets, it may be required to add `-Package` suffix.
        # Example: your package is named `ClientService` and has two targets inside: `ClientServiceDTOs` and `ClientServiceAPI`.
        # Then, your target would be `ClientService-Package`.
        -s|--scheme)
            SCHEME=${2}
            shift 2
        ;;
        *)
            echo "Unknown parameter: '${1}'."
            exit 1
        ;;
    esac
done

main

The argument parsing allows parametrized inputs, like:

propose_next_version.sh \
    --device "platform=iOS Simulator,name=iPhone 16,OS=18.0" \
    --derived-data-path ".build" \
    --scheme "FooBar"

Although $DERIVED_DATA_PATH is optional, I highly recommend using it. Due to different directory (I suggest local, e.g. ./.build) it prevents data collision issues when the script runs in parallel CI jobs on one runner.

Next, add some helpers which will be used later on:

function reset() {
    cd "$CALL_DIR"
    rm -rf "$TEMP_DIRECTORY" > /dev/null
}

# Extract package name from Package.swift
function swift_package_name() {
    swift package describe --type json | jq -r .name
}

These helper functions serve two purposes: reset() cleans up temporary files and returns to the original directory, while swift_package_name() extracts the package name from Package.swift using Swift's built-in package description and jq for JSON parsing. Make sure you have jq installed.

Finding the current version tag

We need to identify the latest version to compare against. The script scans git history starting from the active branch HEAD to find the latest version tag:

function get_current_version_tag_name() {
    local current_branch_name
    local last_reference_tag_name

    current_branch_name=$(git rev-parse --abbrev-ref HEAD)
    last_reference_tag_name=$(git tag --merged="$current_branch_name" --list --sort=-version:refname "[0-9]*.[0-9]*.[0-9]*" | head -n 1)
    cat <<< "$last_reference_tag_name"
}

This function:

1. Gets the current branch name. Usually it is default branch (main/master)
2. Lists all tags merged into the current branch that match semver pattern
3. Sorts them by version in reverse order (-version:refname), from latest to oldest
4. Takes the first (latest) one

Generating public API interfaces

Swift provides built-in capabilities to generate public API files. We could have two different approaches depending on the package type:

For packages using Apple frameworks (like UIKit):

function build_public_interface() {
    xcodebuild \
        -archivePath "$ARCHIVE_PATH" \
        -derivedDataPath "$DERIVED_DATA_PATH" \
        -destination "$DESTINATION" \
        -scheme "$SCHEME" \
        BUILD_LIBRARY_FOR_DISTRIBUTION=YES \
        SKIP_INSTALL=NO \
        OTHER_SWIFT_FLAGS="-no-verify-emitted-module-interface" \
        archive | xcbeautify
}

Be aware that the above solution works only on macOS.

For clean Swift packages (universal):

function build_public_interface() {
    swift build \
        --build-path "$DERIVED_DATA_PATH" \
        -Xswiftc -enable-library-evolution \
        -Xswiftc -emit-module-interface \
        -Xswiftc -no-verify-emitted-module-interface | xcbeautify
}

By default, after generating public interface, compiler verifies it. The -no-verify-emitted-module-interface parameter disables that verification. In our case we only need generated file and its verification is not required. xcbeautify is not a mandatory here, but it is nice to have. It prints nicely the building output which we may use in case of encountered build error.

Extracting the public interface

After building the package, we need to extract its public interface for comparison. The function below automates this process:

function get_public_interface() {
    local package_name
    local public_interface_directory
    local build_output

    if ! build_output=$(build_public_interface 2>&1); then
        echo "❌ Build failed. Error details:" >&2
        echo "$build_output" >&2
        echo "Cannot complete the build due to the compile error. Check logs above." >&2
        exit 1
    fi

    package_name=$(swift_package_name)
    public_interface_directory=$(find "./$DERIVED_DATA_PATH/" -name "${package_name}.swiftinterface")
    cat <<<"$(cat "$public_interface_directory")"
}

This function:

• Builds the package and captures any compilation errors, exiting early if the build fails.
• Determines the package name and locates the generated .swiftinterface file.
• Outputs the contents of the public interface, which will be used for API comparison.

Creating temporary workspaces and comparing versions

Let’s build now the main function. First, define local variabales, get branch name and latest version tag. Setup reporary directories and cleanup derived-data folder to avoid any possible data issues:

local current_branch_name
local current_public_interface
local current_public_interface_path
local has_breaking_changes
local has_additive_changes
local normalized_derived_data_path
local normalized_temp_dir
local temp_diff_directory
local temp_version_directory
local version_public_interface
local version_public_interface_path
local version_tag

local -r semantic_version_regex='([0-9]+).([0-9]+).([0-9]+)'

current_branch_name=$(git rev-parse --abbrev-ref HEAD)
version_tag=$(get_current_version_tag_name)

normalized_temp_dir=$(echo "$TEMP_DIRECTORY" | sed 's/^\.\///')
normalized_derived_data_path=$(echo "$DERIVED_DATA_PATH" | sed 's/^\.\///')

temp_diff_directory="$TEMP_DIRECTORY/diff"
temp_version_directory="$TEMP_DIRECTORY/version"

# Clean up derived data directory to prevent usage of any cached files
rm -rf "$DERIVED_DATA_PATH"

Next, create temporary copies of both the tagged version and current changes. They are going to be used for diffing later:

# Copy change tagged with given version tag to temporary directory
git clone "$CALL_DIR" --branch "$version_tag" --single-branch "$temp_version_directory" --quiet --recurse-submodules -c advice.detachedHead=false

# Get public interface from the previous version
cd "$temp_version_directory"
version_public_interface=$(get_public_interface)

# Go back to the project root.
cd "$CALL_DIR"

# Get public interface from the current changes
current_public_interface=$(get_public_interface)

# Save public interfaces for comparison
mkdir -p "$temp_diff_directory"
version_public_interface_path="$temp_diff_directory/version.swiftinterface"
current_public_interface_path="$temp_diff_directory/current.swiftinterface"

# Save public API outputs without comments (comments can change without affecting API)
echo "$version_public_interface" | grep --invert-match '^//' > "$version_public_interface_path"
echo "$current_public_interface" | grep --invert-match '^//' > "$current_public_interface_path"

Analyzing differences and proposing versions

The final step compares the two interface files using diff:

# Make public interfaces diffs
has_breaking_changes=$(diff "$version_public_interface_path" "$current_public_interface_path" | grep -c -i "^<" || true)
has_additive_changes=$(diff "$version_public_interface_path" "$current_public_interface_path" | grep -c -i "^>" || true)

# Create version based on diff output
if [[ ! $version_tag =~ $semantic_version_regex ]]; then
    cat <<< "$version_tag"
else
    local major="${BASH_REMATCH[1]}"
    local minor="${BASH_REMATCH[2]}"
    local patch="${BASH_REMATCH[3]}"

    if [[ $has_breaking_changes -gt 0 ]]; then
        major=$((major+1))
        minor=0
        patch=0
    elif [[ $has_additive_changes -gt 0 ]]; then
        minor=$((minor+1))
        patch=0
    else
        patch=$((patch+1))
    fi

    cat <<< "${major}.${minor}.${patch}"
fi

The semantic version is parsed using regex. Based on the diff analysis:

• Breaking changes (lines removed from the API, indicated by ^< in diff output): increment major version, reset minor and patch to 0
• Additive changes (new lines added to the API, indicated by ^> in diff output): increment minor version, reset patch to 0
• No API changes: increment only the patch version

Cleanup

Finally, clean up the temporary directory to avoid leaving behind artifacts:

reset

Practical usage examples

The script above can be used to create a tag with every successful merge into the default branch (main/master). Here's a complete usage example:

# Basic usage
chmod +x "propose_next_version.sh" && ./propose_next_version.sh \
    --device "platform=iOS Simulator,name=iPhone 16,OS=18.0" \
    --derived-data-path ".build" \
    --scheme "MyPackage"

# In CI/CD pipeline
NEXT_VERSION=$(chmod +x "propose_next_version.sh" && ./propose_next_version.sh --device "platform=iOS Simulator,name=iPhone 16,OS=18.0" --derived-data-path ".build" --scheme "MyPackage")
git tag "$NEXT_VERSION"
git push origin "$NEXT_VERSION"

Conclusion

By combining Swift’s built-in tools with shell scripting, we’ve created a solution for automating version proposals. This approach ensures consistent versioning practices and reduces human error in version management.

The complete code for this article is available in my GitHub repository.

Future improvements

While described current solution provides a solid foundation, there are several areas where it could be enhanced:

1. Dependency analysis: Implement scanning of Package.swift for dependency version changes that might affect compatibility
2. Package mutliple target support: This solution works well for one-target Swift packages. It can be improved to scan all targets within provided scheme and do diffing for all public interface files
3. Custom API Analysis: Develop more sophisticated parsing for complex API changes, like treating new parameter with default value inside a method or enum as non-breaking change
4. Beta releases support: The discussed script handles versioning for mature packages, where breaking changes bump the MAJOR version. For beta releases, breaking changes would bump the MINOR version instead
5. Multiple device support: Some packages have platform-specific APIs for Linux or macOS. The current example requires developers to run the script individually for each supported platform and compare the resulting versions

For GitHub users, instead of implementing the script from scratch, consider using a ready-made action from my repository: Filozoff/action-swift-propose-next-version. You can see a live example of its usage in my library.

Originally published at https://github.com.

What Are Accessibility Identifiers, and What Are They For?

Accessibility identifiers can be used to reliably distinguish an element (XCUIElement) in UI automated tests (XCUITests). The alternatives either have low performance (XPath) or require specific selectors that may randomly fail. Still, it may be useful to know them. To learn about other options, check BrowserStack’s guide on finding elements.

For more information about accessibility identifiers, please visit Apple’s documentation.

How To Verify Them

The best way is to preview XCUIElements by using inspector tools. XCUIElements are tree-structured, the same as views. There are two well-known ways to preview them.

Accessibility Inspector

The Accessibility Inspector is a tool provided with Xcode. It can be opened from Xcode’s menu: Xcode -> Open Developer Tool -> Accessibility Inspector or cmd+space and typing “accessibility inspector.”

While the app is running in the simulator, go to “All processes” in “Accessibility Inspector,” choose “Simulator,” and then click on the “Target an element” button (1). The “selection mode” will be enabled.

Click on the element you want to inspect (green overlay will assist with choosing the right one). The accessibility identifier is under “Identifier” in the “Advanced” section (2).

Here’s an example of Health.app:

Accessibility Inspector comes with amazing tools that help you improve the accessibility of your app (e.g., contrast ratio scans). To learn more about Accessibility Inspector and its features, please watch a WWDC session from 2019.

Appium Inspector

Appium Inspector requires more work to set up, but in the end, it is more convenient for accessibility identifier preview and provides data in a readable form.

Installation

Several tutorials will help you install Appium Inspector, but if you want to save some time, feel free to use the one below:

Appium Inspector requires npm and Appium Server. The simplest way is to type these commands in the terminal and install it through homebrew:

brew install node # installs npm

npm install -g appium@next # installs appium server through npm

You can check the Appium installation by printing its version. You can do it by typing the following in the terminal:

appium -v

To run XCUITests or scan the tree structure, Appium needs to install an additional driver. To install the XCUITest driver, type the following in the terminal:

appium driver install xcuitest # installs Appium driver which allows to run XCUITest

To check if the driver was successfully installed, you can create a list of the installed drivers using the terminal:

appium driver list --installed

Next, download Appium Inspector’s installation package from Appium’s GitHub. In case of errors, please follow Appium’s installation guide.

Usage

First, run the Appium server by typing this command in the terminal:

appium server

Then, open the Appium Inspector app and define properties (1). At a minimum, you have to define platformName and appium:automationName as follows:

• platformName: use iOS
• appium:automationName: use XCUITest

You can save that configuration (it is not saved by default). To start a screen scanning process, click the “Start Session” button (2).

To learn more about available options (like running on a physical device), please visit Appium’s guide.

Click on the element you want to inspect (an overlay will assist with choosing the right one). Here’s an example of Health.app (with the same screen and identifier used in the previous example above):

Use the “Refresh” button from the top list to refresh the screen and see the updated view data.

Composing IDs

Now, as you know how to verify the identifiers, it’s time to compose them. We are going to use a tree structure.

A tree is constructed with branches (1, 2) and leaves (3, 4, 5). Like regular trees, a leaf cannot exist without at least one branch.

Take a look at the identifier from Health.app: UIA.Health.ReviewHealthChecklistTile.Header.Title. A dot separates each of its parts and defines the next level of nesting, building a tree structure. In that case, the following parts: UIA, Health, ReviewHealthChecklistTile, and Header are branches and Title is a leaf.

As you may notice, a tree structure has the following key advantages:

• it allows better identifier organization
• each nesting level provides more detail about the view placement, so it is easier to find it in a view hierarchy

The example of Apple’s Health app is constructed by using the following format: Purpose.App.ViewGroup.Component.Element, but feel free to define your own (e.g., it is absolutely fine to use ScreenName.ViewGroup.Component.Element instead).

Composing identifiers can be done by simply passing the identifier through a constructor like this:

struct UserDetails: View {

    let name: String
    private let parentIdentifier: String

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

    var body: some View {
        Text(name)
            .accessibilityIdentifier("\(parentIdentifier).Label")
    }
}

However, it is not flexible enough. First, it introduces an additional dependency passed through the constructor, polluting its API with UI-related dependency. Second, you lose an option to set an “identifier branch” to regular SwiftUI view containers, like VStack. The best option would be to allow an identifier to be created in the same way that sets up a background color or adds padding to a View or a group of them.

To achieve that, we are going to use custom EnvironmentKey and ViewModifier. Let’s start by creating a dedicated EnvironmentKey:

import SwiftUI

struct ParentAccessibilityBranchKey: EnvironmentKey {

    static let defaultValue: String? = nil
}

extension EnvironmentValues {

    var parentAccessibilityBranch: String? {
        get { self[ParentAccessibilityBranchKey.self] }
        set { self[ParentAccessibilityBranchKey.self] = newValue }
    }
}

That environment value will be used to pass a branch name from the parent View, to its children. Once set to a parent, it is visible to all child views.

Next, let’s create a dedicated ViewModifier to construct a branch and leaf.

Branch modifier

import SwiftUI

public struct AccessibilityIdentifierBranchModifier: ViewModifier {

    @Environment(\.parentAccessibilityBranch) private var parentBranch

    private let branch: String

    public init(branch: String) {
        self.branch = branch
    }

    public func body(content: Content) -> some View {
        content
            .environment(\.parentAccessibilityBranch, makeGroupPath())
    }

    private func makeGroupPath() -> String {
        guard let parentBranch = parentBranch else { return branch }
        return "\(parentBranch).\(branch)"
    }
}

public extension View {

    func accessibilityIdentifierBranch(_ branch: String) -> ModifiedContent<Self, AccessibilityIdentifierBranchModifier> {
        modifier(AccessibilityIdentifierBranchModifier(branch: branch))
    }
}

The branch modifier takes a branch from a parent View and appends to it the branch provided in the constructor. The modifier only constructs the identifier but does not apply it to a View.

Leaf modifier

public struct AccessibilityIdentifierLeafModifier: ViewModifier {

    @Environment(\.parentAccessibilityBranch) private var branch

    private let leaf: String

    public init(leaf: String) {
        self.leaf = leaf
    }

    public func body(content: Content) -> some View {
        if let branch = branch {
            content
                .accessibilityIdentifier("\(branch).\(leaf)")
                .environment(\.parentAccessibilityBranch, nil)
        } else {
            content
        }
    }
}

public extension View {

    func accessibilityIdentifierLeaf(_ leaf: String) -> ModifiedContent<Self, AccessibilityIdentifierLeafModifier> {
        modifier(AccessibilityIdentifierLeafModifier(leaf: leaf))
    }
}

The leaf modifier applies the identifier to a View. You may have noticed, that the parentAccessibilityBranch environment value is nullified for the leaf modifier. It prevents further branching creation because growing a branch from a leaf is not feasible. The leaf modifier closes the identifier creation.

Once the implementation is done, let’s create an example of a reusable View:

struct UserDetails: View {

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

    var body: some View {
        HStack {
            Image(systemName: "person.circle")
                .resizable()
                .aspectRatio(contentMode: .fit)
                .frame(width: 40.0)
            VStack(alignment: .leading) {
                Text("Name")
                    .foregroundColor(.secondary)
                    .font(.caption)
                    .accessibilityIdentifierLeaf("Label")
                Text(name)
                    .accessibilityIdentifierLeaf("Value")
            }
        }
        .padding()
        .frame(maxWidth: .infinity, alignment: .leading)
        .background(.thinMaterial)
        .cornerRadius(10.0)
    }
}

and use it by another View with identifier modifiers:

struct ContentView: View {

    var body: some View {
        VStack {
            UserDetails(name: "Bugs Bunny")
                .accessibilityIdentifierBranch("UserDetails")
        }
        .padding()
        .accessibilityIdentifierBranch("Users")
    }
}

As a result of the above, let’s take a look at the preview to verify the identifier:

Conclusion

Setting up accessibility identifiers with custom SwiftUI components can be flexible without introducing an additional element to the Views constructor. SwiftUI provides an API that allows composing identifiers with the same ergonomics as modifying a View with padding, background, and foreground color.

Although the solution above is flexible, consider building the identifier tree with caution to prevent introducing frequent changes that may break the UI tests.

You may find the complete code in my GitHub repository.

Composing Accessibility Identifiers for SwiftUI Components was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

When taking the first steps with SwiftUI, this runtime warning is very often encountered:

“Accessing StateObject’s object without being installed on a View. This will create a new instance each time.”

… which can be frustrating at the beginning, especially for devs who come from “ UIKit world". Paying attention to this message is strongly recommended, because that highlighted code may not only impact the performance but the logic as well. Besides, the way how the dependencies are passed defines API design and construction of Unit Tests.

So then, how to pass dependency to a ViewModel safely and reliably?

See the proposals below.

Through onAppear

One of the solutions is passing dependencies when we are 100% sure that it happens after a view’s creation: through onAppear modifier. Let's take a look at the code:

ViewModel:

@MainActor
class ViewOneViewModel: ObservableObject {

    @Published var id = "nil"
    @Published var name = ""

    var userRepository: UserRepository?

    @Published private(set) var isFetchingData = false

    private var currentTask: Task<Void, Error>?

    init() { }

    deinit {
        currentTask?.cancel()
    }

    private func fetchUserData() {
        guard !isFetchingData else { return }
        isFetchingData = true
        currentTask = Task { [weak self] in
            do {
                guard let id = self?.id,
                      let repository = self?.userRepository
                else { return }

                let name = try await repository.fetchName(id: id)
                self?.name = name
            } catch {
                print(error.localizedDescription)
            }

            self?.isFetchingData = false
        }
    }
}

// MARK: - Actions

extension ViewOneViewModel {

    func onAppear() {
        fetchUserData()
    }
}

View :

struct ViewOne: View {

    let id: String
    let userRepository: UserRepository

    @StateObject private var viewModel = ViewOneViewModel()

    init(id: String, userRepository: UserRepository) {
        self.id = id
        self.userRepository = userRepository
    }

    var body: some View {
        VStack(alignment: .leading) {
            Text("Your ID: \(viewModel.id)")
            HStack {
                Text("Name: ")
                TextField("type name", text: $viewModel.name)
                if viewModel.isFetchingData {
                    ProgressView()
                        .progressViewStyle(.circular)
                }
            }
            .padding()
            .background(.quaternary)
            .cornerRadius(10)
            .disabled(viewModel.isFetchingData)

            NavigationLink("Next View", value: RootView.Page.nextView)
        }
        .padding()
        .onAppear {
            viewModel.id = id
            viewModel.userRepository = userRepository
            viewModel.onAppear()
        }
    }
}

At the current stage, the View resets its state with every "appear" action, e.g. when navigating back or switching tabs. Ideally would be, to assign properties only "on View loaded" event. Due to the lack of such a modifier in SwiftUI, it is required to create a custom one to tackle this issue:

struct OnLoadViewModifier: ViewModifier {

    typealias Action = () -> ()

    @State private var isLoaded = false

    private let action: Action

    init(action: @escaping Action) {
        self.action = action
    }

    func body(content: Content) -> some View {
        content
            .onAppear {
                guard !isLoaded else { return }
                isLoaded = true
                action()
            }
    }
}

extension View {

    func onLoad(perform action: @escaping OnLoadViewModifier.Action) -> some View {
        modifier(OnLoadViewModifier(action: action))
    }
}

Updated ViewOne with a new modifier:

struct ViewOne: View {

    (...)

    var body: some View {
        VStack(alignment: .leading) { (...) }
        .padding()
        .onLoad {
            viewModel.id = id
            viewModel.userRepository = userRepository
        }
        .onAppear {
            viewModel.onAppear()
        }
    }
}

As you may see, with this solution ViewOneViewModel requires to have either pre-defined, optional, or late init values. ViewOne's properties are used to be passed further to ViewModel only. That duplication creates API pollution which may lead to the wrong adaptation by other developers e.g. by using properties from a View instead of a ViewModel. Besides, the code requires more attention during its maintenance.

Through constructor

This solution is based on passing dependencies when @StateObject property wrapper calls its closure (i.e. when a View is created).

ViewModel :

@MainActor
class ViewTwoViewModel: ObservableObject {

    @Published var name = ""

    let id: String

    @Published private(set) var isFetchingData = false

    private var currentTask: Task<Void, Error>?
    private let userRepository: UserRepository

    init(id: String, userRepository: UserRepository) {
        self.id = id
        self.userRepository = userRepository
    }

    deinit {
        currentTask?.cancel()
    }

    private func fetchUserData() {
        guard !isFetchingData else { return }
        isFetchingData = true
        currentTask = Task { [weak self] in
            do {
                guard let id = self?.id,
                      let repository = self?.userRepository
                else { return }

                let name = try await repository.fetchName(id: id)
                self?.name = name
            } catch {
                print(error.localizedDescription)
            }

            self?.isFetchingData = false
        }
    }
}

// MARK: - Actions

extension ViewTwoViewModel {

    func onAppear() {
        fetchUserData()
    }
}

View :

typealias ReturnClosure<T> = () -> T

struct ViewTwo: View {

    @StateObject private var viewModel: ViewTwoViewModel

    init(viewModel: @escaping @autoclosure ReturnClosure<ViewTwoViewModel>) {
        _viewModel = .init(wrappedValue: viewModel())
    }

    var body: some View {
        VStack(alignment: .leading) {
            Text("Your ID: \(viewModel.id)")
            HStack {
                Text("Name: ")
                TextField("type name", text: $viewModel.name)
                if viewModel.isFetchingData {
                    ProgressView()
                        .progressViewStyle(.circular)
                }
            }
            .padding()
            .background(.quaternary)
            .cornerRadius(10)
            .disabled(viewModel.isFetchingData)

            NavigationLink("Next View", value: RootView.Page.nextView)
        }
        .padding()
        .onAppear {
            viewModel.onAppear()
        }
    }
}

The View's call looks quite neat too and matches the declarative style:

ViewTwo(
    viewModel: .init(
        id: "123",
        userRepository: userRepository
    )
)

This option is based on Q&A session notes from SwiftUI Lab at WWDC (I strongly encourage checking the whole article) and the discussion from Swift Forum.

Edit 2:

During the WWDC 2023 that topic was raised on WWDC’s Slack channel by @Tudor-Mihai and answered by Apple employee:

For @Observable macro and @State introduced at WWDC 2023 it looks the same:

It looks more clear than the previous one, however, also comes with limitations. In the case of passing a value type, bear in mind that its mutation does not update the View as it is taken only once. Make sure the passed value type is up to date.

That does not affect a reference type or the Binding.

@StateObject vs @ObservedObject

To choose the right property wrapper it is important to know who owns a ViewModel.

The examples above are using @StateObject because ViewOne and ViewTwo are the only owners. @StateObject calls it's closure after View's load and keep closure's result until View deallocation. That makes ViewModel created only once.

Using @ObservedObject with a View as an owner makes ViewModel recreating with every View's redraw. @ObservedObject is a good choice as a child ViewModel, e.g. for a table cell, where the child is held by a parent ViewModel.

Conclusion

Passing dependencies to aViewModel in SwiftUI may look very difficult at the first sight, however, it could be easily manageable. It is important to take into consideration all limitations and a data type while passing to a ViewModel. You may find working examples in my GitHub repository.

Edit 1: Changed code example to more complex and added section about property wrappers.

Edit 2: Update with information received from WWDC 2023 swiftui channel.

Originally published at https://github.com.