DEV Community: Fatbobman( 东坡肘子 )

Swifter and Swifty: Mastering the Swift Testing Framework

Fatbobman( 东坡肘子 ) — Tue, 16 Jul 2024 12:00:00 +0000

Since the inception of the Swift language, XCTest has been the preferred testing framework for the majority of Swift developers. However, deeply rooted in Objective-C, its API design heavily borrows from the traditions of that language, failing to fully reflect the modern best practices of Swift programming. In some respects, this has even become a barrier to further development. To overcome these limitations, Apple officially introduced Swift Testing at WWDC 2024—a new testing framework specifically designed for the Swift language. This framework has been integrated into Xcode 16 and positioned as the official testing tool of choice. In this article, we will delve into the features, usage, and unique aspects of the Swift Testing framework, analyzing how it helps developers write test codes faster (Swifter) and more in line with Swift programming habits (Swifty).

Don’t miss out on the latest updates and excellent articles about Swift, SwiftUI, Core Data, and SwiftData. Subscribe to Fatbobman’s Swift Weekly and receive weekly insights and valuable content directly to your inbox.

Configuring and Using Swift Testing

This chapter will guide you through setting up and running Swift Testing in different environments, as well as how to write your first test case.

Integrating Swift Testing in Xcode Projects

Swift Testing has been seamlessly integrated into Xcode 16, becoming the officially recommended testing framework. When creating a new project, you can easily select Swift Testing as the default framework, as shown in the following image:

As a component of the Swift 6 toolchain, Swift Testing can be used directly without the need for additional dependency declarations, greatly simplifying the configuration process.

Swift Testing also offers direct support for Swift Packages. When creating a new package, you can directly choose the Swift Testing framework:

Configuring Swift Testing in VSCode

To accommodate developers using different development environments, the Swift Server Work Group provides comprehensive support for VSCode users. With their developed VSCode plugin, Swift Testing can be truly plug-and-play in a Swift 6 environment.

Swift Testing on the Command Line

It is important to note that as of the Xcode 16 beta2 version, the swift test command in the command line still defaults to using the XCTest framework. To enable Swift Testing, a specific parameter must be added:

swift test --enable-swift-testing

Adding this parameter ensures that test codes based on the Swift Testing framework are executed:

Writing Your First Swift Testing Test Case

The syntax of Swift Testing is much more concise and clear compared to XCTest. Here is a basic username check test case:

@testable import Demo1
import Testing

@Test func checkName() async throws {
  let fat = People.fat
  #expect(fat.name == "fat")
}

This code demonstrates several features of Swift Testing:

Uses import Testing to introduce the framework
The @Test macro marks the test function
Supports the format of global function for test codes
Test function naming is flexible, with no special restrictions

In the test navigator of Xcode, you can find and run this test case:

For enhanced readability, Swift Testing allows you to add descriptive names to your test cases:

@Test("Check Name") func checkName() async throws {

This makes the test names in the test navigator easier to understand:

By following these simple steps, you have successfully configured and written your first Swift Testing test case. Subsequent sections will explore more advanced features of Swift Testing, helping you to fully leverage this powerful testing framework.

Expectations

When writing tests, libraries typically provide APIs for comparing values—such as verifying that a function returns the expected result. If the comparison fails, the test is reported as failed. These APIs might be called "assertions," "expectations," "checks," "requirements," "matchers," etc., in different libraries. In Swift Testing, they are referred to as Expectations.

#expect Macro

Unlike XCTest, which has over 40 assertion functions, Swift Testing aims to minimize the learning curve for developers and offers greater flexibility. Leveraging the powerful expression capabilities of Swift, in Swift Testing, developers mostly need to express their expectations as a boolean expression and validate it through the #expect macro.

let x = 2
#expect(x < 1)  // failed: (x → 2) < 1

let a = [1, 2, 3]
let b = 4
#expect(a.contains(b)) // failed: (a → [1, 2, 3]) does not contain (b → 4)

let str = "fatbobman"
#expect(str.count > 5) // success 

let array1 = [1, 2, 3, 4, 5]
let array2 = [1, 2, 3, 3, 4, 5]
#expect(array1 == array2) // failed: (array1 → [1, 2, 3, 4, 5]) != (array2 → [1, 2, 3, 3, 4, 5])

#expect also supports various forms for capturing exceptional scenarios:

Should not throw an error

let age = 10
#expect(throws: Never.self) { // Expectation failed: an error was thrown when none was expected: "err1" of type MyError
  if age > 0 {
    throw MyError.err1
  }
}

Must throw an error (any error type)

let age = 10
#expect(throws: any Error.self) { // Expectation failed: an error was expected but none was thrown
  if age < 10 {
    throw MyError.err1
  }
}

Must throw a specified error (error type must conform to Equatable protocol)

enum MyError: Error, Equatable {
  case err1
  case err2(Int)
}

let age = 10
#expect(throws: MyError.err1) { // Expectation failed: expected error "err1" of type MyError, but "err2(10)" of type MyError was thrown
  if age > 5 {
    throw MyError.err2(age)
  }
}

Must throw an error and make a decision based on the boolean return value of the error-catching logic

let age = 10
#expect(performing: {
  if age > 5 {
    throw MyError.err2(age)
  }
}, throws: { err in
  guard let error = err as? MyError, case let .err2(age) = error else {
    return false
  }
  return age > 10 // Evaluate the boolean return value of the error-catching logic
})

These examples clearly demonstrate that for Swift developers, using #expect combined with Swift's syntax to construct test expressions offers clarity, simplicity, and flexibility.

#require Macro

The #require macro is primarily used to unwrap optional values in tests, similar to XCTest's XCTUnwrap:

let x: Int? = 10
let y: String? = nil
let z = try #require(x) // succeeds, z == 10
let w = try #require(y) // fails, test ends prematurely due to thrown error

Besides unwrapping, #require also offers all the constructors available with the #expect macro, with the main difference being its semantic—#require is used for "tests that must pass," whereas #expect focuses more on "what results are anticipated."

Any code that uses #expect can be replaced with #require:

try #require(a == b)

try #require(throws: any Error.self, performing: {
  if age < 10 {
    throw MyError.err1
  }
})

When using #require, the test function must be marked as able to throw errors, and try must be used before #require.

Confirmation

When it is necessary to verify the occurrence of certain events, especially when #expect and #require are insufficient, the confirmation function becomes crucial. It not only verifies that events occur within a specific context, such as event handlers or delegate callbacks, but can also confirm the number of times an event occurs.

The following code example demonstrates how to use the confirmation function: we set an expectation that the pressDown event must be triggered three times. The test will only pass if indeed three pressDown events are received:

await confirmation(expectedCount: 3) { keyPressed in 
  keyHandler.eventHandler = { event in
    if event == .pressDown {
      keyPressed() // mark the event as occurred
    }
  }
  await keyHandler.getEvent() // activate the event handler to await the event
}

In some testing scenarios, verifying that certain events did not occur is equally important. For example, the following code snippet demonstrates how to ensure that no pressDown events are triggered during the test execution. The test only passes if no pressDown events are received:

await confirmation(expectedCount: 0) { keyPressed in 
  keyHandler.eventHandler = { event in
    if event == .pressDown {
      keyPressed()
    }
  }
  await keyHandler.getEvent()
}

withKnownIssue

For functions that are known to potentially produce problems or errors, but you do not want these issues to cause test failure, you can use withKnownIssue to tag them.

@Test func example() async throws {
  withKnownIssue(isIntermittent: true) { // Expected failure
    try flakyCall()
  }
}

This method offers several advantages:

Enhances test reliability, especially for tests containing unstable elements.
Allows the continuation of tests containing known issues without affecting the overall test results.
Provides a mechanism for recording and tracking known issues, rather than simply disabling tests.

withKnownIssue is a powerful tool, suitable for dealing with complex testing scenarios and known system limitations. It allows developers to continue testing while acknowledging existing problems, which is invaluable for maintaining large and complex test suites.

In Swift Testing, using the aforementioned tools can replace the numerous assertion methods in XCTest, significantly simplifying the process of writing test code.

Organizing Test Cases

Swift Testing offers various ways and dimensions to organize and manage test cases, enabling developers to effectively control and maintain their test code. Through flexible structured approaches, including suites, nested suites, and a tagging system, developers can build clear and logically strong test architectures tailored to project needs.

Test Suites

Swift Testing supports constructing tests through global functions and also allows defining test cases within structures (struct), classes (class), and actors (actor), thereby forming structured test suites.

A type that contains @Test functions is implicitly considered a suite without any additional configuration. The following example demonstrates a basic test suite that includes validations for names and ages:

struct PeopleTests {
  @Test func checkName() async throws {
    let fat = People.fat
    #expect(fat.name == "fat")
  }

  @Test func checkAge() async throws {
    let fat = People.fat
    #expect(fat.name.count > 0)
  }
}

If there is a need to rename a suite or set specific conditions, the @Suite macro can be used to clearly specify:

@Suite("Personnel Tests")
struct PeopleTests {
  // Definitions of test functions
}

In Swift Testing, test methods not only support async and throws but can also use the mutating keyword to modify the data of struct type suites.

struct Group {
  var count = 0
  @Test mutating func test1() {
    count += 1
    #expect(count > 0)
  }
}

Nested Suites

For more complex testing needs, Swift Testing supports nested suites, allowing other suites to be embedded within one, thus building a more detailed testing structure.

struct PeopleTests {
  struct NameTests {
    @Test func checkName() async throws {
      let fat = People.fat
      #expect(fat.name == "fat")
    }
  }

  struct AgeTests {
    @Test func checkAge() async throws {
      let fat = People.fat
      #expect(fat.name.count > 0)
    }
  }
}

In Swift Testing, test suites need to contain a parameterless init(), thus, it is not possible to directly define test cases within enums. However, enums can be used to organize suites:

enum PeopleTests {
  struct Name Tests {
    @Test func checkName() async throws {
      let fat = People.fat
      #expect(fat.name == "fat")
    }
  }

  struct Age Tests {
    @Test func checkAge() async throws {
      let fat = People.fat
      #expect(!fat.name.isEmpty)
    }
  }
}

Using Tags for Test Management

Swift Testing also provides a tagging-based classification system, adding flexibility and dimensions to test case management.

@Suite(.tags(.people))
struct PeopleTests {
  struct NameTests {
    @Test func checkName() async throws {
      let fat = People.fat
      #expect(fat.name == "fat")
    }
  }

  struct AgeTests {
    @Test(.tags(.numberCheck)) func checkAge() async throws {
      let fat = People.fat
      #expect(!fat.name.isEmpty)
    }
  }
}

After tagging suites (@Suite) or test cases (@Test), not only can you directly run tests containing specific tags, but you can also conveniently build and manage test plans (Test Plan). This makes it simpler and more efficient to focus testing on different features or requirements.

Traits

Swift Testing offers a variety of trait definitions, allowing developers to control and configure both test suites (@Suite) and test cases (@Test). These traits enable meticulous management of the behavior of test executions, such as the .tag trait previously mentioned, which is used specifically for adding tags.

tag

Add tags to a suite or test case. Developers can declare tags as follows:

@Suite(.tags(.people))

extension Tag {
  @Tag static var people: Self
  @Tag static var numberCheck: Self
}

enabled

Execute the test only if specific conditions are met:

let enableTest = true
@Test(.enabled(if: enableTest)) func example() {}

disabled

Disable the current test. Compared to disabling tests through comments, the disabled trait allows for a clearer explanation of the reason for disabling in the test log:

@Test(.enabled(if: enableTest), .disabled("ignore for this loop"))
func example() {} // Test 'example()' skipped: ignore for this loop

bug

Add information related to bugs (such as URLs, identifiers, or comments) to a test case or suite. This information is integrated into the test report:

@Test(.bug("https://example.org/bugs/1234"))
func example() {
  withKnownIssue {
    #expect(3 > 4)
  }
}

timeLimit

Set the maximum runtime for the test; exceeding this time is considered a test failure:

@Test(.timeLimit(.minutes(1)))
func example() async throws{  // Time limit was exceeded: 60.000 seconds

  try await Task.sleep(for: .seconds(70))
  #expect(4 > 3)
}

serialized

Although Swift Testing defaults to parallelized testing modes, the serialized trait allows designated test suites to run in a serial manner:

@Suite(.serialized)
struct PeopleTests {
  struct NameTests {
    @Test func checkName() async throws {
      let fat = People.fat
      #expect(fat.name == "fat")
    }
  }

  struct AgeTests {
    @Test(.tags(.numberCheck)) func checkAge() async throws {
      let fat = People.fat
      #expect(!fat.name.isEmpty)
    }
  }
}

Trait Inheritance

Traits defined on a test suite are inherited by all its nested types and test cases. For example, the .tags(.people) trait added to PeopleTests automatically applies to NameTests and AgeTests, as well as their included test cases:

@Suite(.tags(.people)) // Add the people tag to the suite
struct PeopleTests {
  struct Name Tests { // Inherits people tag by default
    @Test func checkName() async throws { // Inherits people tag by default
      let fat = People.fat
      #expect(fat.name == "fat")
    }
  }

  struct Age Tests { // Inherits people tag by default
    @Test func checkAge() async throws { // Inherits people tag by default
      let fat = People.fat
      #expect(!fat.name.isEmpty)
    }
  }
}

Understanding the rules of trait inheritance and their interrelationships across multiple levels is crucial. In the following example, test1() is executed only if both the Suite and the individual test case's conditions are met. If the conditions are not satisfied, such as if count is not greater than 20, the relevant test case will be skipped:

let count = 10
@Suite(.enabled(if: count > 3))
struct Group1 {
  @Test(.enabled(if: count > 20)) // skip
  func test1() async throws {
    #expect(true)
  }

  @Test
  func test2() async throws { // success
    #expect(true)
  }
}

Making Test Content and Results More Clear

Swift Testing has significantly improved the quality of failure messages, surpassing XCTest. However, we can further enhance the clarity and informativeness of error reports with the following approaches:

Custom Error Messages

Swift Testing offers robust capabilities for customizing error messages, applicable to assertions like #expect, #require, confirmation, and withKnownIssue:

@Test func checkAge() async throws {
  let age = 0
  #expect(age > 10, "age should be greater than 10") // Expectation failed: (age → 5) > 10 age should be greater than 10
}

These custom messages make the reasons for errors immediately apparent, aiding in quick problem resolution.

Custom Representation in Error Reports

For complex data types, we can implement the CustomTestStringConvertible protocol and customize the testDescription property to improve their representation in error reports. This approach not only makes the error information more intuitive but also enhances the readability of the reports.

struct Student: Equatable {
  let name: String
  let age: Int
  let address: String
  let id: Int
}

@Test func checkStudent() async throws {
  let fat = Student(name: "fat", age: 5, address: "", id: 0)
  let bob = Student(name: "bob", age: 5, address: "", id: 0)
  // Expectation failed: (fat → Student(name: "fat", age: 5, address: "", id: 0)) == (bob → Student(name: "bob", age: 5, address: "", id: 0))
  #expect(fat == bob) 
}

// Custom testDescription
extension Student: CustomTestStringConvertible {
  var testDescription: String {
    "student: \(name)"
  }
}

@Test func checkStudent() async throws {
  let fat = Student(name: "fat", age: 5, address: "", id: 0)
  let bob = Student(name: "bob", age: 5, address: "", id: 0)
  // Expectation failed: (fat → student: fat) == (bob → student: bob)
  #expect(fat == bob)
}

By employing these techniques, the descriptions of test outcomes are not only more specific but also easier to understand, greatly simplifying the debugging process of test code.

Parameterized Testing

Parameterized testing is a distinctive feature of Swift Testing that significantly reduces the need to repetitively test the same logic with different parameters. This allows developers to expand the test coverage and encompass a broader range of scenarios with minimal code duplication.

Consider the following examples of multiple test cases:

struct VideoContinentsTests {

    @Test func mentionsFor_A_Beach() async throws {
        let videoLibrary = try await VideoLibrary()
        let video = try #require(await videoLibrary.video(named: "A Beach"))
        #expect(!video.mentionedContinents.isEmpty)
        #expect(video.mentionedContinents.count <= 3)
    }

    @Test func mentionsFor_By_the_Lake() async throws {
        let videoLibrary = try await VideoLibrary()
        let video = try #require(await videoLibrary.video(named: "By the Lake"))
        #expect(!video.mentionedContinents.isEmpty)
        #expect(video.mentionedContinents.count <= 3)
    }

    @Test func mentionsFor_Camping_in_the_Woods() async throws {
        let videoLibrary = try await VideoLibrary()
        let video = try #require(await videoLibrary.video(named: "Camping in the Woods"))
        #expect(!video.mentionedContinents.isEmpty)
        #expect(video.mentionedContinents.count <= 3)
    }

    // ...and more, similar test functions
}

By utilizing parameterized testing, the above code can be simplified as follows:

struct VideoContinentsTests {
    @Test("Number of mentioned continents", arguments: [
        "A Beach",
        "By the Lake",
        "Camping in the Woods",
        "The Rolling Hills",
        "Ocean Breeze",
        "Patagonia Lake",
        "Scotland Coast",
        "China Paddy Field",
    ])
    func mentionedContinentCounts(videoName: String) async throws {
        let videoLibrary = try await VideoLibrary()
        let video = try #require(await videoLibrary.video(named: videoName))
        #expect(!video.mentionedContinents.isEmpty)
        #expect(video.mentionedContinents.count <= 3)
    }
}

Swift Testing automatically tracks the parameters used in each test call and records them in the results. Developers can selectively rerun specific parameter combinations that failed, enabling fine-grained debugging:

let data = [
  ("fat",3),
  ("bob",2)
]

@Test(arguments=data)
func matchStrLength(str:String, count:Int) {
  #expect(str.count == count)
}

In the tests above, an error with the data for "bob" being "2" was identified, and after adjusting it to "3", you can click on the corresponding "bob" parameter in the navigation bar to run the test for that specific data set alone.

Swift Testing supports using any data structure that conforms to the Collection protocol as a source of parameters, with the requirement that the data types are consistent and each item complies with the Sendable protocol. The following data declarations can all be used as sources for the matchStrLength test:

let data: [String: Int] = [
  "fat": 3,
  "bob": 3,
]
@Test(arguments: data)

let strs = ["fat","bob"]
let counts = [3,3]
@Test(arguments: strs,counts)

let strs = ["fat","bob"]
let counts = [3,3]
@Test(arguments: zip(strs,counts))

The parallel execution of parameterized tests not only simplifies the testing code but also significantly enhances the flexibility and accuracy of the testing process through automatic tracking of test parameters and the provision of selective rerun capabilities.

Parallelization

Swift Testing adopts a default parallelized testing approach. Parallelization not only speeds up the output of test results and shortens iteration cycles but also helps reveal hidden dependencies between tests, prompting developers to implement stricter state isolation measures in their code.

For tests unsuitable for parallel execution, the serialized trait can be added to @Suite to disable parallelization. Due to the inheritable nature of traits, once a suite is marked as serialized, all tests within it will execute sequentially.

Parameterized testing is also parallelized by default, significantly enhancing test efficiency compared to traditional for in loop iterations. However, this method does not guarantee the order of data processing.

In XCTest, adding the @MainActor or other GlobalActor annotations to a subclass of XCTestCase might trigger warnings, forcing developers to add @MainActor to each test case individually.

@MainActor // Main actor-isolated class 'LoggerTests' has different actor isolation from nonisolated superclass 'XCTestCase'; this is an error in the Swift 6 language mode
class LoggerTests: XCTestCase {
}

In Swift Testing, such restrictions do not exist. You can directly use the @MainActor annotation on a Suite or declare an actor type of Suite. It is important to note that even in this setup, the included test cases will still execute in parallel, thus the order of execution cannot be guaranteed.

Developers can define init and deinit methods for each suite to prepare and clean up data for each test case:

actor IntermediateTests {
  private var count: Int

  init() async throws {
    // Runs before each @Test instance method in this type
    this.count = try await fetchInitialCount()
  }

  deinit {
    // Runs after each @Test instance method in this type
    print("count: \(count), delta: \(delta)")
  }

  @Test func example3() async throws {
    delta = try await computeDelta()
    count += delta
    // ...
  }
}

The testing framework creates an independent suite instance for each test case, ensuring that variables within each instance are isolated, thus supporting a higher degree of test isolation and parallelism.

Mixing with XCTest

Swift Testing is an emerging testing framework that does not yet support certain functionalities, such as performance and UI testing, necessitating its use alongside other testing frameworks like XCTest. Moreover, it is unrealistic to expect developers to convert all existing XCTest cases to Swift Testing at once. Therefore, Swift Testing is designed to coexist with XCTest within the same target, supporting a gradual migration.

It is important to note that using XCTest assertions within Swift Testing, or vice versa, is not allowed.

By executing the swift test --enable-swift-testing command in the command line, it is possible to run test cases from both Swift Testing and XCTest in a single run, achieving seamless integration of the two frameworks.

Does Swift Testing Only Run in Swift 6 Language Mode?

While Swift Testing requires the Swift 6 toolchain to run, it does not mandate the use of Swift 6 language mode. Even under Swift 5 language mode, or with minimal concurrency checks, Swift Testing operates normally. However, to fully leverage the concurrent testing capabilities offered by Swift Testing, developers are encouraged to use more modern concurrency models and enforce strict data race restrictions, thereby benefiting from these default features.

Open Source and Cross-Platform

Swift Testing is an open-source framework developed under community leadership, covering all major platforms supported by the Swift language, including the Apple ecosystem, Linux, and Windows. As an open-source project, Swift Testing is more than just a testing tool; it is a vibrant technical community. The development team actively encourages developers worldwide to participate in the project's discussions and development. Whether it's proposing new ideas, reporting issues, or directly contributing code, every effort helps Swift Testing grow and mature more quickly.

This open and collaborative model not only ensures that the framework continues to improve and adapt to evolving development needs but also provides Swift developers with a valuable opportunity to learn and influence the direction of testing tools. By actively participating, developers can collectively shape the future of this critical component within the Swift ecosystem.

Conclusion

The Swift Testing framework offers a new testing experience for Swift developers. Its concise syntax, flexible expression of expectations, and robust feature support make writing and maintaining test code not only faster (Swifter) but also more in tune with the habits of Swift developers (Swifty). This article has detailed the core functionalities of Swift Testing with code examples, showing how to apply it in projects and utilize its unique advantages to enhance test quality.

In practice, gradually transitioning to the Swift Testing framework is a prudent choice. Developers can start by adopting Swift Testing for new test cases and gradually migrate existing XCTest cases. Meanwhile, for performance and UI tests, Swift Testing still needs to be used in conjunction with other testing frameworks to achieve comprehensive test coverage. As Swift Testing continues to evolve and improve, we look forward to it bringing more functionalities and optimizations. The introduction of Swift Testing not only enriches the Swift language ecosystem but also marks a significant step in enhancing developer productivity. Let's anticipate the additional surprises Swift Testing will bring to Swift development!

The original article was published on my blog Fatbobman's Blog.

List or LazyVStack: Choosing the Right Lazy Container in SwiftUI

Fatbobman( 东坡肘子 ) — Mon, 15 Jul 2024 02:55:48 +0000

In the world of SwiftUI, List and LazyVStack, as two core lazy containers, offer robust support for developers to display large amounts of data. However, their similar performance in certain scenarios often causes confusion among developers when making a choice. This article aims to analyze the characteristics and advantages of these two components to help you make a better decision.

Note: The LazyVStack mentioned in this article primarily refers to the combined use of ScrollView and LazyVStack, typically used in conjunction with ForEach to dynamically provide data. It's worth mentioning that the features of LazyVStack discussed here are largely applicable to LazyHStack and partially to other Lazy series containers. We will focus on a macro-level comparison and discussion, rather than the specific details of API usage.

Underlying Implementation: Different Origins, Divergent Architectures

Throughout the evolution of SwiftUI, List and LazyVStack have played different roles and hold distinct positions. List, as a veteran lazy container from the first version of SwiftUI, was not only the sole official lazy component at the time but also set the tone for the data loading processes of many subsequent lazy containers. In contrast, LazyVStack debuted in the second year alongside other lazy containers such as LazyHStack, LazyVGrid, and LazyHGrid. Although both components perform similarly in certain scenarios, their underlying architectures are vastly different.

Essentially, List is a clever encapsulation of UIKit/AppKit components by Apple. From iOS 13 to iOS 15, it relied on the UITableView; starting with iOS 16, its implementation shifted to the more flexible UICollectionView. In stark contrast, LazyVStack and other Lazy+ series containers are native SwiftUI implementations, and their underlying mechanics do not depend on any specific UIKit/AppKit components.

This fundamental difference in implementation is not just a technical detail but is also the root cause of their differing performance in several key aspects. Whether it's performance, feature richness, customization flexibility, or layout logic, List and LazyVStack each exhibit unique characteristics due to their distinct underlying architectures. Understanding this is crucial for developers when choosing and using these two components.

Styling and Presets: Feature-Rich vs. Minimalist Flexibility

LazyVStack, like its cousin VStack, focuses on the fundamental function of layout. As a pure layout container in SwiftUI, it strictly adheres to preset layout rules, orderly arranging subviews without arbitrarily adding extra effects. This minimalist design offers developers the greatest degree of freedom.

In contrast, the design philosophy behind List is markedly different. It is not just a container but a feature-rich UI component. List comes with multiple preset visual templates, allowing developers to easily switch between different styles using listStyle. However, the advantages of List go beyond visual effects; it also offers a series of unique interactive capabilities:

Swipe actions (swipeActions) are exclusive to List subviews.
The onDelete and onMove functionalities of ForEach are only effective within List.
Built-in edit mode support makes gesture-based item reordering possible, a unique feature in SwiftUI.

For scenarios requiring swipe menus, or system-like delete and move editing features, List is undoubtedly the best choice. Not only is its code concise, but it is also deeply optimized for the entire Apple ecosystem. Additionally, the rich construction methods of List (including integration with ForEach and data binding) significantly enhance development efficiency, especially for beginners or prototype development.

However, the preset features of List also introduce certain limitations. Although List has received more preset templates with updates to SwiftUI, as of iOS 18, Apple has yet to open up complete customization capabilities for List styles. In contrast, LazyVStack is like a blank canvas; although it lacks preset modes, it offers unlimited possibilities for developers' creativity.

In summary, Apple's positioning of these two components is distinctly different: List is a multifunctional container with default styles and behaviors, while LazyVStack is a purely flexible layout tool.

Layout and Customization: Balancing Flexibility and Constraints

LazyVStack, as a lazy container in SwiftUI, has unique characteristics in terms of layout, particularly when it comes to handling the height of subviews. Unlike VStack, LazyVStack uses the ideal size of the subviews when their height is not explicitly specified. This feature is very evident in practice:

struct ContentView: View {
  var body: some View {
    LazyVStack {
      Rectangle()
    }
  }
}

In the code above, the Rectangle will only display as a rectangle with a height of 10 (the default ideal size for shapes), rather than filling the available space as it would in a VStack.

This size determination logic aligns with ScrollView in terms of layout in the scrollable direction. Even when nested in a VStack, the Rectangle still maintains a height of 10:

ScrollView {
  VStack {
    Rectangle()
  }
}

For a deeper understanding of SwiftUI's layout size determination mechanism, I recommend reading SwiftUI Layout: The Mystery of Size.

As a pure layout container, LazyVStack offers developers tremendous freedom, allowing for a more precise recreation of design styles. In contrast, the presentation of List is influenced by multiple factors, including the selected style, the container environment, and the operating system platform. Developers have limited ability to intervene in the styling of List, and its layout tends to be more formulaic.

Adjusting the appearance and behavior of List primarily relies on specialized view decorators provided by Apple. Although these decorators are enriched with updates to SwiftUI versions, some complex layouts may be difficult to achieve or require workaround methods in earlier versions of SwiftUI.

Due to differences in underlying implementation, List has limitations in handling dynamic changes in row height. For example:

struct ContentView: View {
  @State var high = false
  var body: some View {
    List{
      Toggle(isOn: $high.animation()){}
      Rectangle()
        .frame(height:high ? 200 : 100)
    }
  }
}

For scenarios involving dynamic height changes, it is recommended to avoid using List.

Moreover, List has restrictions on the types of transition animations for subviews (rows). For scenarios that require special animations and transition effects, LazyVStack often provides greater flexibility and better performance.

Collaboration with Other Containers: The Advantage of Context Awareness

Despite some developers' reservations about the implementation of List, believing it does not fully meet specific needs, leading them to consider wrapping UIKit/AppKit components themselves to create better-suited alternatives. While this approach can indeed better meet personalized needs in some cases, we should not overlook the considerable efforts Apple has made to adapt List for multi-platform compatibility and specific requirements.

SwiftUI includes an important yet undisclosed mechanism—context awareness. Official containers and components can intelligently sense their environment and automatically adjust their presentation styles based on different contexts. This unique capability is one of the significant advantages of List over LazyVStack.

List works seamlessly with navigation containers:

Supports special display modes such as Sidebars.
Navigation containers provide excellent support for the data sources and row tags bound to List.
Some components, such as NavigationLink, have a unique style when displayed within List.

These features not only significantly reduce development workload but also achieve an interactive experience that LazyVStack cannot match.

For a deeper understanding of the collaboration between List and navigation containers, I recommend reading The New Navigation System in SwiftUI and Adaptive Programmatic Navigation in SwiftUI.

However, this context awareness and default behavior can sometimes pose challenges:

By default, List responds only to the action of one Button element in a row view (this can be resolved by adjusting the buttonStyle).
In early versions of SwiftUI, due to a lack of comprehensive programmatic navigation capabilities, controlling the style of NavigationLink was quite challenging.

In summary, when developers want to fully utilize the automatic sensing capabilities of system components to create interfaces consistent with the system style, List is undoubtedly the better choice. It not only provides a familiar interactive experience for users but also allows developers to achieve higher code reuse across different platforms.

Scroll Control: Native and Workaround Solutions

In recent updates to SwiftUI, Apple has significantly enhanced scroll control capabilities by introducing a series of new APIs. However, these new features are mainly targeted at ScrollView, with the development of List lagging somewhat in this area. Currently, the official scroll control methods provided for List are still limited to ScrollViewReader.

Despite this, the underlying implementation of List is based on mature UIKit components, offering developers an alternative route. By using third-party libraries such as SwiftUI-Introspect, developers can directly access the APIs of underlying UIKit components, thus enabling more control options. This method is not only applicable to scroll control but can also be used for customizing display styles.

Even so, starting with iOS 17, the combination of ScrollView and LazyVStack has far surpassed List in terms of scroll control capabilities and convenience. Considering LazyVStack's inherent advantages in layout flexibility and animation support, when precise subview scrolling or varying visual effects based on subview positions are needed, LazyVStack is undoubtedly the superior choice.

For a deeper understanding of the latest developments in scroll control APIs, I recommend reading Deep Dive into the New Features of ScrollView in SwiftUI 5 and The Evolution of SwiftUI Scroll Control APIs and Highlights from WWDC 2024.

Performance: Challenges and Trade-offs

Although SwiftUI has been around for six years, the performance of List and LazyVStack when handling large datasets still leaves room for improvement. Even with medium-sized datasets, due to differences in underlying implementations, both exhibit distinct performance characteristics.

LazyVStack is essentially a VStack with lazy loading capabilities, maintaining a complete container height (the total height of subviews plus spacing). To achieve lazy loading, it employs a dynamic height estimation method, calculating the overall height based on the number and height of subviews near the visible area. This mechanism leads to two significant issues:

Rapidly scrolling to a specific position requires instantiating and calculating the height of all subviews prior to that position (i.e., evaluating their body), which can lead to noticeable performance degradation.
When there is a large height difference between subviews, rapid scrolling or large jumps may cause a white screen phenomenon (failure to calculate all necessary subviews in time).

In contrast, List does not maintain a concept of complete content height at the SwiftUI level. During fast scrolling or extensive jumps, it intelligently selects the necessary subviews for instantiation and height calculation, significantly improving scrolling and jumping efficiency.

It is worth noting that using the id modifier in List may cause subviews to lose their lazy loading capabilities, which is not an issue with LazyVStack. Therefore, when providing a data source for List, it is recommended that the data type adhere to both the Identifiable and Hashable protocols, to avoid using the id modifier as a scroll control tag.

Overall, with the same amount of data, List typically demonstrates higher efficiency than LazyVStack.

For a deeper understanding of performance optimization strategies, I recommend reading Tips and Considerations for Using Lazy Containers in SwiftUI and Demystifying SwiftUI List Responsiveness: Best Practices for Large Datasets.

Conclusion

The notion that "everything exists for a reason" is fully embodied in the design philosophies of List and LazyVStack. These two components each have their unique features, providing different solutions for SwiftUI developers. When choosing which one to use, developers need to consider several key factors comprehensively:

Performance: Special attention should be paid to scenarios requiring extensive jumps and significant differences in subview heights.
Scroll Control: The precision and the ability to detect subview positions.
Layout Flexibility: The capability to adapt to complex UI designs and compatibility with animations and transitions.
Preset Functionality: Whether there is a need to utilize built-in features provided by the system.
Cross-platform Compatibility: Performance across different Apple ecosystems.
Collaboration with Other SwiftUI Components: Especially in navigation and data binding.

There is no one-size-fits-all solution; the best choice often depends on the specific project requirements and development scenarios. A deep understanding of the strengths and weaknesses of these components will help developers make wise decisions when facing specific challenges.

In practice, there may be situations where both are used together, or they are used separately on different pages to maximize their respective strengths. The key is to flexibly choose and apply these tools based on specific application needs, target user groups, and performance requirements.

As SwiftUI continues to evolve, the capabilities and applicable scenarios of these components may change. Staying informed about new features and best practices will help maintain efficiency and innovation in SwiftUI development.

The original article was published on my blog Fatbobman's Blog.

Before WWDC 2024: The Future Potential and Real Challenges of SwiftData

Fatbobman( 东坡肘子 ) — Fri, 31 May 2024 11:40:00 +0000

At the 2023 Worldwide Developers Conference (WWDC), Apple launched the highly anticipated new generation data management framework — SwiftData. As the successor to Core Data, can SwiftData play a key role in the Apple ecosystem? With WWDC 2024 approaching, this article will evaluate the overall performance of SwiftData since its initial release during the Xcode 15 period (i.e., its first major version), and provide a forecast of its future development.

Toward the Future: SwiftData, A Modern Data Management Framework

SwiftData was not built entirely from scratch; its core technology is still based on Core Data. In the first WWDC 2023 session about SwiftData, Apple did not elaborate on this aspect.

Initially, I was confused and even suspicious about why Apple did not clarify the connection with Core Data right from the start. However, as I delved deeper into SwiftData, I gradually understood Apple's strategy. While SwiftData is built on the proven technological foundation of Core Data, its overall design and presentation signify the birth of a completely new data management framework. Apple's choice to downplay the connection with Core Data aims to free developers from the preconceived notions associated with Core Data, enabling a better understanding of SwiftData's team's fresh interpretation of a modern data management framework. This strategy not only emphasizes SwiftData’s status as an independent framework but also clearly defines its future role within the Apple ecosystem.

For developers with extensive Core Data experience, they might find it challenging to grasp and apply the new programming philosophy introduced by SwiftData, similar to the challenges faced by UIKit developers transitioning to SwiftUI.

SwiftData not only simplifies some of the complex and seldom-used features of Core Data but also introduces many practices that align with modern programming paradigms. The framework fully leverages new features of the Swift language, demonstrating how to build secure, stable, and elegant code, and laying the foundation for its central role in the Apple ecosystem.

Therefore, SwiftData can be regarded as a new and modernized data management framework, with the potential to play a pivotal role in the Apple ecosystem for over a decade.

Hastily Launched: The Real Issues Facing SwiftData

Although SwiftData's design is highly visionary, its launch was clearly rushed, and its first version not only lacks some important features, but several key issues have also severely impacted its performance and usability:

Immature Predicate Conversion Capability:

SwiftData introduced a new Predicate system provided by Foundation, which is safer and more ergonomically sound. Although it is not as comprehensive as the traditional NSPredicate yet, it meets the retrieval declaration needs of most developers. However, as more applications activate data cloud synchronization, increasingly, model properties are declared as optional to meet synchronization requirements. Yet, SwiftData's current performance in converting predicates that include optional values (transforming predicates into SQL commands) is poor, especially when handling "to-many" relationships with optional predicates. This deficiency not only severely impacts SwiftData's usability but also significantly restricts the functionalities that applications using SwiftData can offer.

UI Response to Data Updates is Problematic:

SwiftData utilizes Swift's modern concurrency model to provide an elegant mechanism for handling concurrent data operations, allowing developers to encapsulate concurrent data operations through @ModelActor, thus effectively preventing the common concurrency crashes seen in Core Data. However, despite updates over the past year, data update operations performed through @ModelActor often fail to prompt timely responses in SwiftUI views. To circumvent this issue, developers are forced to abandon @ModelActor or resort to various tricks to force view updates, not only wasting this feature's potential but also severely impacting the application's efficiency.

Model Validation and Conversion Issues:

In Core Data, when data network synchronization is enabled, Xcode's model editor automatically verifies whether models comply with synchronization standards. By contrast, SwiftData uses a purely code-based modeling approach, requiring developers to manually code for model validation. This not only increases development complexity but might also lead to developers, who are inadequately informed about synchronization standards, discovering mismatches in their models near project completion, necessitating extensive modifications. Additionally, occasional conversion errors may occur when translating code-declared models into the underlying Core Data-recognizable NSManagedObjectModel, especially in the absence of explicit inverse relationship annotations (which could otherwise be omitted). These errors are often hard to detect, and troubleshooting them requires a significant investment of time and effort.

Codable Support and Unclear Data Storage:

SwiftData allows developers to use types that conform to the Codable protocol directly as model properties, significantly clarifying models and simplifying operations. However, the lack of a clear guideline and defined storage correspondence from the official side presents numerous challenges in practical use. Not all types conforming to the Codable protocol can be reliably converted, occasionally leading to application crashes. Furthermore, the absence of clear official guidance might cause issues for developers adjusting Codable types, especially in data cloud synchronization scenarios, where new model versions may not be eligible for seamless migration (failing to utilize lightweight migration).

Despite the fact that SwiftData's first version is not as comprehensive as Core Data, if the framework operates stably and meets project requirements, these shortcomings do not pose significant issues. However, as mentioned earlier, existing problems may lead to application anomalies and unexpected challenges during development.

Overall, given the rushed launch of SwiftData, its first version has not fully met expectations and has not adequately demonstrated the capabilities and stability expected of a data management framework. Therefore, it is crucial to conduct necessary updates and enhancements to SwiftData at the upcoming WWDC 2024.

Applicability: Who is the First Version of SwiftData Suitable For?

As a developer who has invested considerable effort in researching SwiftData, I fully recognize its ingenious design and bright prospects. However, I must admit that the first version of SwiftData is not suitable for all developers and projects.

For Beginners (with no experience in data management frameworks): Not Recommended

Developers unfamiliar with data management frameworks might find that due to a lack of understanding of SwiftData's capabilities and limitations, they easily encounter insurmountable obstacles during project development.

For Projects with Complex Requirements: Not Recommended

If a project has high demands for a data management framework, the maturity and comprehensive functionality of Core Data make it a better choice than the first version of SwiftData. Although it is possible to integrate SwiftData and Core Data within a project, the cost and effort involved may not be justified.

For Projects with Undefined Requirements: Not Recommended

As project functionalities continue to expand, it is likely that developers will find the first version of SwiftData unable to meet the evolving development needs.

For Projects with Clear Requirements and Unaffected by Current Issues in SwiftData: Recommended

Despite its limitations in the first version, SwiftData is suitable for projects with simple functional requirements that do not involve complex relationships or performance issues, provided you can avoid the major issues present in the first version of SwiftData. Additionally, if the project does not utilize data network synchronization features, some of SwiftData's shortcomings can be further mitigated.

For a Specific Audience: Worth Trying

For those developers who fully understand the project requirements and are well aware of the limitations and shortcomings of the first version of SwiftData, particularly those with extensive Core Data development experience, using the first version of SwiftData for commercial project development, despite the challenges, can be rewarding as it provides a sense of achievement in overcoming difficulties.

Although the performance of the first version of SwiftData did not fully meet expectations, its advanced design concepts and elegant implementation are still worth learning from. Even if you currently do not need a data management framework, or are not considering using SwiftData, studying and understanding it can still have a positive impact on your future development work.

Over the past year, I have written more than a dozen articles on SwiftData. These articles thoroughly explore the principles and design strategies of SwiftData, and should be very helpful for developers who wish to gain a deeper understanding of this framework.

Looking Ahead: The Upcoming Changes in SwiftData

As WWDC 2024 approaches, I am hopeful that the forthcoming updates will address some of the major issues revealed in the first version of SwiftData.

As previously mentioned, Apple is in the process of creating SwiftData as a brand new data management framework, specifically designed for the current and future Apple ecosystem, particularly for environments that include mobile applications and high-performance hardware like high-speed CPUs and solid-state drives. Therefore, many of the distinctive features found in Core Data might not be included in SwiftData due to changes in the market and hardware environment. Additionally, SwiftData may introduce more refined encapsulations to simplify some of the complex operations of the past.

Thus, I am curious about how Apple will add new features to SwiftData, not just which features will be added.

Based on the development experience with SwiftUI, it may take another two to three years for SwiftData to become a key official data management framework within the Apple ecosystem. This process will be lengthy and challenging, but it will ultimately provide developers with powerful tools to build future applications.

Advice for Current SwiftData Developers

If you have already implemented SwiftData in your project and it is performing well, congratulations 🎉 ! Furthermore, I recommend that you delve deeper into the major issues currently faced by the first version of SwiftData and do your best to mitigate these in upcoming updates. Finally, if possible, consider raising the minimum system requirements of your project after the release of iOS 18 (or subsequent systems on other platforms) to take advantage of potential optimizations and improvements.

Appendix: Some Key Features Missing, Major Issues, and Partial Temporary Solutions in the First Version of SwiftData

Lazy Loading (Faulting): SwiftData does not support the faulting feature typical in Core Data for lazy loading of data.
Batch Data Operations: Currently, there is no support for batch data operations, but this can be achieved by integrating with Core Data.
Multiple Persistence Storage Support: Prior to iOS 17.4, SwiftData did not support multiple persistence storages.
Advanced Query Features: Does not support advanced query features such as group, having, distinct. If needed, these can be addressed through SwiftDataKit.
Predicate Functionality Limitations: After enabling synchronization features, the capability to express predicates in many-to-many relationships is restricted.
Public Database and Data Sharing: Does not support synchronizing public databases and sharing data.
Performance Issues: Operations on to-many relationships can trigger severe performance issues.
View Update Response: Views are unable to respond to data updated within @ModelActor. Refer to Solution One and Solution Two.
Predicate Merging: Does not support predicate merging. Refer to this solution.
Codable Support: When using types that comply with the Codable protocol, ensure that all properties of the type are consistent with the fundamental properties of SQLite (such as integers, floats, dates, etc.).
Codable as Query Criteria: Properties of Codable types cannot be used as query criteria (though Core Data supports Composite Attributes).
Model Validation: When developing data models that support synchronization, validate the model first.
Enum Storage: It is not recommended to use enums directly as storage types because they cannot be used as query criteria; it is best to save their corresponding rawValue.
Insufficient Event Handling: SwiftData does not support adding custom logic during lifecycle events such as didSave or willSave. This limitation affects the ability to perform specific actions during data saving processes. A workaround is available in the solution guide.
Cascade Deletion Issue: SwiftData does not automatically delete related association data when performing delete operations with the cascade deletion rule. This functionality can be achieved using SwiftDataKit.
System Version Requirements: It is advisable to raise the minimum system requirements of your project, recommended to be at least iOS 17.2.

The original article was published on my blog Fatbobman's Blog.

Before WWDC 2024: Reviewing Key SwiftUI Upgrades from 2019 to 2023 and Their Impact

Fatbobman( 东坡肘子 ) — Wed, 29 May 2024 23:16:45 +0000

When people reunite after a long absence, they are often surprised by the changes in each other; however, the transformations in those who are with us day after day are often overlooked. In this article, I will sift through the key updates to SwiftUI that have made a significant impression on me since its first version. This is not only a reflection on the evolution of SwiftUI from its inception to its maturity but also a fresh appreciation of the vitality it embodies.

Each update to SwiftUI has brought numerous new features and capabilities. In this text, I will focus primarily on those changes that have had a profound impact on me personally and discuss other frameworks and features closely related to SwiftUI and the Apple ecosystem, demonstrating how they collectively shape the platform we use today.

2019

Despite its initially limited functionality, the first version of SwiftUI showcased some core features—such as its declarative syntax, reactive mechanisms, and layout logic—that have persisted through today with almost no changes across multiple versions. This not only proves the thoughtful consideration Apple gave when designing SwiftUI but also highlights the forward-thinking nature of its philosophy and architectural design.

The framework's name itself illustrates the inseparable connection between SwiftUI and the Swift programming language, a relationship that has been continually strengthened and validated with each subsequent update. SwiftUI leverages the features and advantages of Swift, and conversely, the development of Swift has also been influenced to some extent by the evolution of the SwiftUI framework.

Released alongside SwiftUI was the Combine framework, which provides powerful control over asynchronous data streams. SwiftUI uses it to implement an observation mechanism for reference types. Combine has enabled Apple and third-party developers to conveniently transform existing APIs into reactive APIs that support SwiftUI. However, due to Combine's inability to offer high-precision observation capabilities, SwiftUI faced significant performance issues in certain scenarios, which were not addressed until the introduction of the Observation framework last year.

Also launched at WWDC 2019 was Core Data with CloudKit, giving new life to Core Data and offering a unique and powerful advantage for applications within the Apple ecosystem. Many developers have embraced Core Data, largely attracted by its convenient and free data synchronization capabilities.

Although the initial version of SwiftUI may seem naive from today's perspective, as a declarative and reactive framework introduced by Apple, it has fully demonstrated its uniqueness and potential.

2020

New Project Templates: Xcode introduced new project templates for SwiftUI, allowing developers to more easily create complete app entries using the App and Scene protocols. Additionally, this update brought SwiftUI support for macOS development and introduced multi-window capabilities on iPad.
Numerous New Lazy Containers: This version introduced a variety of lazy containers such as LazyVStack, LazyHStack, LazyVGrid, and LazyHGrid. These containers offer more flexible layout options and are natively implemented in SwiftUI, independent of any specific UIKit/AppKit components. Unfortunately, these native lazy containers still have some performance issues, and many developers are eager for the development team to resolve these soon.
@StateObject: The introduction of @StateObject addressed the instability issues with the lifecycle of reference type instances that were previously observed with @ObservedObject.
onChange: The onChange modifier enhances developers' ability to execute logic in response to specific state changes within views, further reinforcing SwiftUI's unique take on declarative programming. This includes embedding some lightweight imperative logic directly into the function-based UI declarations. Although this design philosophy has its pros and cons, it also provides unique advantages to SwiftUI.
Scrolling Positioning: ScrollViewReader offers a method for positioning within scroll views using id and anchor, fully reflecting SwiftUI’s philosophy of layout: based on view identity and not reliant on absolute positioning.
Introduction of Widgets: Starting with iOS 14, Apple introduced WidgetKit, a framework specifically designed for building widgets. WidgetKit requires developers to use SwiftUI to construct these widgets, a change that significantly encouraged developers who were initially hesitant about adopting SwiftUI to begin actively learning and using it.

At WWDC 2020, Core Data with CloudKit introduced synchronization features for public databases, further expanding its potential for data management and multi-device synchronization.

Following WWDC 2020, SwiftUI now has the fundamental capabilities needed to build a complete application. In less complex application scenarios, developers can almost avoid using UIViewRepresentable to wrap UIKit components.

2021

Integration of the new concurrency model: With the release of Swift 5.5, a new concurrency model was introduced to Swift. SwiftUI leverages the task, task(id:), and refreshable modifiers to provide a convenient context for this new concurrent code, significantly simplifying the complexity of asynchronous programming.
Focus management based on view hierarchy: With @FocuseState, SwiftUI not only completed the previously missing text input focus management features but also elevated focus management to a new level. Developers can now manage multiple focus transitions and detect focus states across the entire view hierarchy. This unified focus management feature left a profound impression on me as it not only fulfills basic functionalities but also provides an optimal solution in line with the philosophy of SwiftUI.
Integration of FormatStyle: With the introduction of new Formatter APIs by Swift's Foundation, SwiftUI has supported these formatting interfaces in Text and TextField components. This allows developers to control the formatted input and output of text more conveniently through FormatStyle, greatly enhancing the expressiveness and readability of the code. However, there is currently a limitation in using FormatStyle in TextField: it cannot apply formatters in real-time during user input. This is an area where SwiftUI needs to improve in future versions.
Support for AttributedString: The support for AttributedString in SwiftUI significantly enhanced the functionality and flexibility of the Text component for displaying text. This change provides developers with a more diverse range of text processing options, greatly enriching the user interface's expressiveness. However, despite the significant enhancements brought by AttributedString, there have been no similar-scale features introduced since its inclusion. More regrettably, TextField and TextEditor still do not support AttributedString to this day, limiting these controls' ability to handle complex text formats.
Dynamic modification of fetch conditions: This update introduced the ability to dynamically adjust fetch conditions in @FetchRequest, allowing developers to modify conditions without needing to create additional wrapper views. However, the @Query property wrapper introduced for SwiftData in 2023 does not yet have this capability.

At WWDC 2021, Core Data with CloudKit introduced data sharing capabilities, completing the three major features of Core Data with CloudKit.

It can be said that in 2021, the many enhancements SwiftUI received were closely related to the updates of Swift and Swift Foundation that year.

2022

Layout Protocol: The introduction of the Layout protocol not only provided developers with the ability to create custom layout containers but also deeply demonstrated SwiftUI's layout mechanism based on negotiation. This protocol has enhanced developers' understanding of SwiftUI's layout logic. The new Grid component, as well as existing layout components such as VStack and HStack, have been updated to conform to the Layout protocol and support AnyLayout, significantly increasing layout flexibility. Currently, the Layout protocol does not support the creation of lazy containers; we look forward to future versions expanding and refining this capability.
New Programmatic Navigation: NavigationStack and NavigationSplitView introduced a new programmable navigation system, fundamentally improving previous limitations with SwiftUI navigation. This change has led many developers to set the minimum system requirements for SwiftUI projects to iOS 16 to utilize these new navigation features.
Swift Charts: Apple's introduction of the Swift Charts framework for SwiftUI has set new standards in the industry for construction methods, visual effects, and integration with SwiftUI. In its second-year update, the framework added more chart types and support for interaction, further extending its functionality. Swift Charts has now become a top choice for chart applications within the Apple ecosystem, enhancing the significance and practicality of SwiftUI itself.
Enhanced macOS Support: This version significantly improved support for macOS, particularly in handling WindowGroup as well as Settings and MenuBarExtra. From this version onward, SwiftUI's capabilities in building macOS applications have been substantially enhanced.

The updates in 2022 brought many significant improvements to SwiftUI, especially the Layout protocol and the new navigation system, which have profound implications for the future development of SwiftUI applications.

2023

New Observation Framework: With the release of Swift 5.9, the newly introduced Observation framework provides the ability to observe properties of observable objects, fundamentally solving the issue of excessive invalid updates in SwiftUI views caused by insufficient precision in Combine observations. The full adoption of Observation has significantly improved application efficiency. Moreover, this update has simplified the declaration and injection of state in SwiftUI; developers can now manage various states simply using @State and Environment, without relying on Combine.
Revolutionary Upgrades in Animation and Visual Effects: The 2023 update brought a range of innovative features to SwiftUI, including animation completion callbacks, phase animations, keyframe animations, and new Transition and Shape protocols, along with support for Shaders. These features have significantly enhanced developers' freedom in creating animations and visual effects. The newly introduced animation and visualEffect modifiers use closures to provide clearer logic handling, effectively reducing the impact on upstream and downstream components of the view tree, guiding the future development of SwiftUI view decorators.
Comprehensive Enhancement of Scrollable Containers: Scrollable containers have also been enhanced with many new features, such as scroll indicators, margin adjustments, scroll clipping, and advanced scrolling capabilities independent of ScrollViewReader. Although these individual features might not seem prominent, their collective appearance certainly sparks speculation: could this be laying the groundwork for a major update to lazy container functionalities in the future?
SwiftData: The long-awaited SwiftData was finally released, serving as the successor to Core Data. Its code-based modeling approach and tight integration with the Observation framework make it the most suitable data management framework for the SwiftUI era. If the upcoming WWDC 2024 still does not introduce a feature similar to NSFetchedResultsController for external data retrieval (real-time change detection) in SwiftData, it will further confirm Apple's strategic decision to position SwiftUI as the sole UI framework for the future, accelerating this transition.
visionOS: With the launch of Apple Vision Pro, it has become the only hardware platform in the Apple ecosystem where native application development exclusively supports SwiftUI. This change indicates that the Apple Vision Pro team will use SwiftUI to build more native applications, a development eagerly anticipated by developers. The widespread adoption of SwiftUI by Apple's official team will promote rapid iteration in fixing issues, enhancing performance, and introducing new features in the framework. I look forward to seeing more official applications developed using SwiftUI on iOS and macOS platforms at this year's WWDC 2024.

2023 has become a pivotal year in the development of SwiftUI, with the introduction of the Observation framework and SwiftData, among other innovative technologies, helping to cement its status as a mainstream development platform.

Looking Ahead to WWDC 2024

In an era where AI becomes a mainstream trend, how will SwiftUI leverage the powerful momentum of AI to achieve breakthrough improvements? At the upcoming WWDC 2024, which will be held in two weeks, I believe we will witness more exciting transformations.

Let's all look forward to the surprises that WWDC 2024 will bring!

The original article was published on my blog Fatbobman's Blog.

SwiftUI Views and @MainActor

Fatbobman( 东坡肘子 ) — Wed, 17 Apr 2024 06:58:59 +0000

An increasing number of developers are starting to enable strict concurrency checks in preparation for the arrival of Swift 6. Among the warnings and errors received, a portion relates to SwiftUI views, many of which stem from developers not correctly understanding or using @MainActor. This article will discuss the meaning of @MainActor, as well as tips and considerations for applying @MainActor within SwiftUI views.

My PasteButton Stopped Working

Not long ago, in my Discord community, a friend reported that after enabling strict concurrency checks, the compiler threw the following error for PasteButton:

Call to main actor-isolated initializer 'init(payloadType:onPast:)' in a synchronous nonisolated context

After examining the declaration of PasteButton, I asked him whether he placed the view code outside of body. Upon receiving a positive response, I advised him to add @MainActor to the variable declaration of PasteButton, and that solved the problem.

@MainActor public struct PasteButton : View {
    @MainActor public init(supportedContentTypes: [UTType], payloadAction: @escaping ([NSItemProvider]) -> Void)

    @MainActor public init<T>(payloadType: T.Type, onPaste: @escaping ([T]) -> Void) where T : Transferable
    public typealias Body = some View
}

So, where was the issue initially? Why did adding @MainActor resolve it?

What is @MainActor

In Swift's concurrency model, actor offers a safe and understandable way to write concurrent code. An actor is similar to a class but is specifically designed to address data races and synchronization issues in a concurrent environment.

actor Counter {
    private var value = 0

    func increment() {
        value += 1
    }

    func getValue() async -> Int {
        return value
    }
}

let counter = Counter()
Task {
  await counter.increment()
}

The magic of actor lies in its ability to serialize access to prevent data races, providing a clear and safe path for concurrent operations. However, this isolation is localized to specific actor instances. Swift introduces the concept of GlobalActor to extend isolation more broadly.

GlobalActor allows us to annotate code across different modules to ensure that these operations are executed in the same serial queue, thereby maintaining the atomicity and consistency of operations.

@globalActor actor MyActor: GlobalActor {
    static let shared = MyActor()
}

@MyActor
struct A {
  var name: String = "fat"
}

class B {
  var age: Int = 10
}

@MyActor
func printInfo() {
  let a = A()
  let b = B()
  print(a.name, b.age)
}

@MainActor is a special GlobalActor defined by Swift. Its role is to ensure that all code annotated with @MainActor executes in the same serial queue, and all this happens on the main thread.

@globalActor actor MainActor : GlobalActor {
    static let shared: MainActor
}

This succinct and powerful feature of @MainActor provides a type-safe and integrated way to handle operations that previously relied on DispatchQueue.main.async within Swift's concurrency model. It not only simplifies the code and reduces the error rate but also ensures, through compiler protection, that all operations marked with @MainActor are safely executed on the main thread.

The View Protocol and @MainActor

In the world of SwiftUI, a view plays the role of declaratively presenting the application's state on the screen. This naturally leads to the assumption that all code composing a view would execute on the main thread, given that views directly relate to the user interface's presentation.

However, delving into the View protocol reveals a detail: only the body property is explicitly marked with @MainActor. This discovery means that types conforming to the View protocol are not guaranteed to run entirely on the main thread. Beyond body, the compiler does not automatically ensure that other properties or methods execute on the main thread.

public protocol View {
    associatedtype Body : View
    @ViewBuilder @MainActor var body: Self.Body { get }
}

This insight is particularly crucial for understanding the use of SwiftUI's official components like PasteButton, which, unlike most other components, is explicitly marked with @MainActor. This indicates that PasteButton must be used within a context also marked with @MainActor, or else the compiler will report an error, indicating that a call to a main actor-isolated initializer is not allowed in a synchronous nonisolated context:

struct PasteButtonDemo: View {
  var body: some View {
    VStack {
      Text("Hello")
      button
    }
  }

  var button: some View {
    PasteButton(payloadType: String.self) { str in // Call to main actor-isolated initializer 'init(payloadType:onPaste:)' in a synchronous nonisolated context
      print(str)
    }
  }
}

To resolve this issue, simply marking the button variable with @MainActor can smoothly pass the compilation, as it ensures that button is initialized and used within an appropriate context:

@MainActor
var button: some View {
  PasteButton(payloadType: String.self) { str in
    print(str)
  }
}

Most SwiftUI components are value types and conform to the Sendable protocol, and they are not explicitly marked as @MainActor, thus they do not encounter the specific issues faced by PasteButton.

This modification highlights the importance of using @MainActor in SwiftUI views and also serves as a reminder to developers that not all code related to views is executed on the main thread by default.

Applying @MainActor to Views

Some readers might wonder, could directly annotating the PasteButtonDemo view type with @MainActor fundamentally solve the problem?

Indeed, annotating the entire PasteButtonDemo view with @MainActor can address the issue at hand. Once annotated with @MainActor, the Swift compiler assumes that all properties and methods within the view execute on the main thread, thus obviating the need for a separate annotation for button.

@MainActor
struct PasteButtonDemo: View {
  var body: some View {
    ...
  }

  var button: some View {
    PasteButton(payloadType: String.self) { str in
      ...
    }
  }
}

This approach also brings other benefits. For example, when building observable objects with the Observation framework, to ensure their state updates occur on the main thread, one might annotate the observable objects themselves with @MainActor:

@MainActor
@Observable
class Model {
  var name = "fat"
  var age = 10
}

However, attempting to declare this observable object instance in the view with @State, as recommended by official documentation, would encounter a compiler warning; this is considered an error in Swift 6.

struct DemoView: View {
  @State var model = Model() // Main actor-isolated default value in a nonisolated context; this is an error in Swift 6
  var body: some View {
    NameView(model: model)
  }
}

struct NameView: View {
  let model: Model
  var body: some View {
    Text(model.name)
  }
}

This issue arises because, by default, a view's implementation is not annotated with @MainActor, thus it cannot directly declare types annotated with @MainActor. Once DemoView is annotated with @MainActor, the aforementioned issue is resolved.

To further simplify the process, we could also define a protocol annotated with @MainActor, allowing any view that conforms to this protocol to automatically inherit the main thread execution environment:

@MainActor
protocol MainActorView: View {}

Thus, any view that implements the MainActorView protocol ensures that all its operations execute on the main thread:

struct AsyncDemoView: MainActorView {
  var body: some View {
    Text("abc")
      .task {
        await do something()
      }
  }

  func doSomething() async {
    print(Thread.isMainThread) // true
  }
}

Although annotating view types with @MainActor seems like a good solution, it requires all asynchronous methods declared within the view to execute on the main thread, which may not always be desirable. For example:

@MainActor
struct AsyncDemoView: View {
  var body: some View {
    Text("abc")
      .task {
        await doSomething()
      }
  }

  func doSomething() async {
    print(Thread.isMainThread) // true
  }
}

If not annotated with @MainActor, we could more flexibly annotate properties and methods as needed:

struct AsyncDemoView: View {
  var body: some View {
    Text("abc")
      .task {
        await doSomething()
      }
  }

  func doSomething() async {
    print(Thread.isMainThread) // false
  }
}

Therefore, whether to annotate a view type with @MainActor depends on the specific application scenario.

New Uses for @StateObject

With the Observation framework becoming the new standard, the traditional use of @StateObject seems to become less prominent. However, it still possesses a special functionality that allows it to remain useful in the era of Observation. As we've discussed before, an @Observable object marked with @MainActor cannot be directly declared with @State—unless the entire view is also annotated with @MainActor. But, with @StateObject, we can cleverly circumvent this limitation.

Consider the following example, where we can safely introduce an observable object marked with @MainActor into the view without having to mark the entire view with @MainActor:

@MainActor
@Observable
class Model: ObservableObject {
  var name = "fat"
  var age = 10
}

struct StateObjectDemo: View {
  @StateObject var model = Model()
  var body: some View {
    VStack {
      NameView(model: model)
      AgeView(model: model)
      Button("update age"){
        model.age = Int.random(in: 0..<100)
      }
    }
  }
}

The feasibility of this practice stems from the unique loading mechanism of @StateObject. It calls the constructor's closure on the main thread when the view is actually loaded. Moreover, the wrappedValue of @StateObject is annotated with @MainActor, ensuring it can correctly initialize and use types conforming to the ObservableObject protocol marked with @MainActor.

@frozen @propertyWrapper public struct StateObject<ObjectType>: SwiftUI.DynamicProperty where ObjectType: Combine.ObservableObject {
    @usableFromInline
    @frozen internal enum Storage {
        case initially(() -> ObjectType)
        case object(SwiftUI.ObservedObject<ObjectType>)
    }

    @usableFromInline
    internal var storage: SwiftUI.StateObject<ObjectType>.Storage
    @inlinable public init(wrappedValue thunk: @autoclosure @escaping () -> ObjectType) {
        storage = .initially(thunk)
    }

    @_Concurrency.MainActor(unsafe) public var wrappedValue: ObjectType {
        get
    }

    @_Concurrency.MainActor(unsafe) public var projectedValue: SwiftUI.ObservedObject<ObjectType>.Wrapper {
        get
    }

    public static func _makeProperty<V>(in buffer: inout SwiftUI._DynamicPropertyBuffer, container: SwiftUI._GraphValue<V>, fieldOffset: Swift.Int, inputs: inout SwiftUI._GraphInputs)
}

The main advantage of this method is that it ensures the safety of the observable object's lifecycle while completely preserving its observation logic based on the Observation framework. This allows us to flexibly use observable types marked with @MainActor without having to mark the entire view with @MainActor. This offers a path that maintains the flexibility of the view without compromising data safety and response logic. Until Apple provides a more definitive solution for running @State on the main thread or adjusting view declarations, this approach serves as a practical and effective temporary strategy.

In the current version of SwiftUI (prior to Swift 6), when developers declare state within a view using @StateObject, the Swift compiler implicitly treats the entire view as being annotated with @MainActor. This implicit inference behavior can easily lead to misunderstandings among developers. With the official adoption of the SE-401 proposal, starting from Swift 6, such implicit inference will no longer be permitted.

Conclusion

After enabling strict concurrency checks, many developers might feel confused and overwhelmed by a slew of warnings and errors. Some may resort to modifying code based on these prompts to eliminate errors. However, the fundamental purpose of introducing a new concurrency model into projects goes far beyond "deceiving" the compiler. In reality, developers should deeply understand Swift's concurrency model and reassess their code on a more macro level to discover higher-quality, safer resolution strategies, rather than simply addressing symptoms. This approach not only enhances the quality and maintainability of the code but also helps developers navigate the world of Swift's concurrency programming with greater confidence and ease.

The original article was published on my blog Fatbobman's Blog.

Practical SwiftData: Building SwiftUI Applications with Modern Approaches

Fatbobman( 东坡肘子 ) — Tue, 26 Mar 2024 07:01:10 +0000

In the previous article Concurrent Programming in SwiftData, we delved into the innovative concurrent programming model proposed by SwiftData, including its principles, core operations, and related considerations. This elegant programming solution has earned considerable praise. However, as more developers attempt to use SwiftData in actual SwiftUI applications, they have encountered some challenges, especially after enabling Swift's strict concurrency checks. They found that SwiftData's actor-based concurrency model is difficult to integrate with traditional application construction methods. This article will explain, in a tutorial-like manner, how to integrate SwiftData with modern programming concepts smoothly into SwiftUI applications and provide strategies to address the current challenges faced by developers.

Don’t miss out on the latest updates and excellent articles about Swift, SwiftUI, Core Data, and SwiftData. Subscribe to Fatbobman’s Swift Weekly and receive weekly insights and valuable content directly to your inbox.

What Are Modern Approaches?

When discussing modern programming approaches, different developers might have various perspectives, but there are some core principles that are widely agreed upon. In the context of building SwiftUI applications with SwiftData, I believe modern programming approaches should at least meet the following key standards:

Modularity: By encapsulating data definitions and operational logic within independent modules, we can not only enhance code readability and maintainability but also promote feature reusability. Modularity is the cornerstone of ensuring a project structure is clear and flexible enough to adapt to future changes.
Comprehensive Testability: Ensuring every data operation is thoroughly unit tested is crucial. This practice guarantees the reliability and stability of the code, making the continuous integration and deployment process smoother.
Thread Safety: Maintaining the integrity and consistency of data in concurrent programming is extremely important. Effective thread safety measures not only prevent data conflicts and race conditions but also comply with Swift's strict concurrency standards, ensuring the application's high performance and stable operation.
Architecture Agnostic: A powerful data management module should flexibly adapt to various architectural designs, whether it's SwiftUI's own data injection mechanism or integration with other third-party frameworks, it should seamlessly connect, demonstrating a high degree of adaptability.
Preview Support: The preview feature in SwiftUI is a significant highlight of its development experience, allowing developers to see interface changes instantly. Therefore, ensuring the data layer supports this functionality is vital for speeding up the development process and enhancing efficiency.
Separation of Data Display and Operations: While adhering to SwiftUI's reactive design principles, it's effective to separate the data display and operational logic. Data is intuitively displayed and responds to changes through @Query, while creation, update, deletion, and other operations are handled by SwiftData's new concurrency model, thus enhancing efficiency and fully leveraging the advantages of SwiftUI's reactive framework.

To better understand the concepts discussed in this article and to see the application of these modern programming methods in practice, I have prepared a demo project. You can obtain the complete project code by visiting the following GitHub repository:

Access the demo project code

This project includes examples implemented using SwiftData in a SwiftUI application, demonstrating how to build applications according to the modern programming standards introduced in the article.

Creating a Data Management Module

For a long time, the practice of extracting data management logic from the main project and encapsulating it into an independent module has been highly acclaimed. Many developers have adopted this approach in projects using Core Data. However, compared to SwiftData, Core Data presents additional challenges in terms of modularity. This is mainly because Core Data uses a graphical model editor to build data models, and the data models themselves are stored as separate files, loaded at different stages of the application's lifecycle with various file extensions. This dependency on external model files has significantly diminished developers' inclination to modularize their data management code.

SwiftData, with its pure code declaration approach, greatly simplifies this process, leaving virtually no excuse not to isolate the data management logic. This method not only simplifies code maintenance but also enhances the portability and reusability of the code.

Considering that the data management module is usually highly related to a specific project, I chose to create a new Swift Package in the current directory of the demo project, rather than setting up a separate repository for it.

I started by creating a package named DataProvider. In its Package.swift file, we enabled Swift's strict concurrency checks to ensure the safety of concurrent code:

.target(
  name: "DataProvider",
  swiftSettings: [
    .enableExperimentalFeature("StrictConcurrency"),
  ]
),

In this independent module, we will complete the definition of the data model, the implementation of the data operation logic, and the related testing work. This structure not only clearly delineates the different concerns of the application but also makes maintenance and testing more efficient.

Building the Data Model

In SwiftData, the method of building a data model is very similar to defining Swift's basic types, requiring only pure code to complete. In our demo project, we have defined a succinct model Item:

@Model
public final class Item {
  public var timestamp: Date
  public var createTimestamp: Date

  public init(timestamp: Date) {
    self.timestamp = timestamp
    createTimestamp = .now
  }
}

It's important to note that adopting SwiftData's pure code modeling approach means that once the application is deployed, any modifications to the data model or data migrations require manual management of all versions of the data model. Therefore, even though our model currently has only one version, it's best to plan a strategy for data migration right from the start.

To this end, we first define an enumeration to represent the version of the model, and use the CurrentScheme type alias to mark it as the version currently in use:

public typealias CurrentScheme = SchemaV1

public enum SchemaV1: VersionedSchema {
  public static var versionIdentifier: Schema.Version {
    .init(1, 0, 0)
  }

  public static var models: [any PersistentModel.Type] {
    [Item.self]
  }
}

Next, we embed the declaration of the Item class into SchemaV1, and maintain consistency in the naming through a type alias:

public typealias Item = SchemaV1.Item

extension SchemaV1 {
  @Model
  public final class Item {
    public var timestamp: Date
    public var createTimestamp: Date

    public init(timestamp: Date) {
      self.timestamp = timestamp
      createTimestamp = .now
    }
  }
}

In our demo project, to simplify the learning process, we haven't further extended the data model. However, in real-world applications, developers can enhance the data model by adding predefined predicates, sorting rules, or FetchDescriptors through extensions, as detailed in this example code.

Now, whether inside the module or externally, we can use Item to reference this version of the data model. If the model changes in the future, we can easily introduce a new Schema version, such as SchemaV2, and adjust the type aliases accordingly to accommodate the new model structure.

To delve deeper into the principles of building SwiftData data models, refer to Unveiling the Data Modeling Principles of SwiftData. Additionally, if you are interested in SwiftData's data model migration methods, you can read this article, which discusses migration strategies and implementation steps.

SwiftData Also Requires a Stack

In Core Data projects, developers are accustomed to constructing a structure akin to a stack that centrally manages the declaration of the persistent container and data operation logic. SwiftData significantly simplifies this process, allowing developers to quickly build containers and perform data injections using straightforward calls like .modelContainer(for: Item.self). So, in scenarios using SwiftData, is it still necessary to maintain a structure similar to a stack?

Even though we will be using the @ModelActor macro to encapsulate the data operation logic, building a structure similar to a stack remains crucial. Such a structure not only uniformly provides a container and @ModelActor implementation for different parts of the application but is also particularly key in projects attempting to combine SwiftData with Core Data in a dual-framework mode, as it can handle the container construction for both frameworks in one place.

In our demo project, we defined a DataProvider class. This class functions similarly to the CoreDataStack commonly used in Core Data projects:

public final class DataProvider: Sendable {
  public static let shared = DataProvider()

  public let sharedModelContainer: ModelContainer = {
    let schema = Schema(CurrentScheme.models)
    let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false)

    do {
      return try ModelContainer(for: schema, configurations: [modelConfiguration])
    } catch {
      fatalError("Could not create ModelContainer: \(error)")
    }
  }()

  public init() {}
}

Here, the construction of the schema directly utilizes the type information provided by CurrentScheme.models. Moreover, if the data model requires migration, the corresponding migration logic will also be implemented within the initialization closure of sharedModelContainer.

Please read Mastering the Core Data Stack to learn more about building techniques for the Core Data Stack.

Encapsulating Data Operation Logic with @ModelActor

SwiftData offers the @ModelActor macro, encouraging developers to utilize this feature to create an actor type, thereby encapsulating the data operation logic within it. For our Item type, we have defined the logic for creating, updating, and deleting data items:

@ModelActor
public actor DataHandler {
  @discardableResult
  public func newItem(date: Date) throws -> PersistentIdentifier {
    let item = Item(timestamp: date)
    modelContext.insert(item)
    try modelContext.save()
    return item.persistentModelID
  }

  public func updateItem(id: PersistentIdentifier, timestamp: Date) throws {
    guard let item = self[id, as: Item.self] else { return }
    item.timestamp = timestamp
    try modelContext.save()
  }

  public func deleteItem(id: PersistentIdentifier) throws {
    guard let item = self[id, as: Item.self] else { return }
    modelContext.delete(item)
    try modelContext.save()
  }
}

In implementing these functionalities, several points need special attention:

The update and delete operations only accept PersistentIdentifier as a parameter.
After creating a new Item instance, the method returns the PersistentIdentifier of the newly created object. Although this return value might not be commonly used in many practical application scenarios, it is extremely useful during unit testing, providing an effective way to reference and test the newly created data entities.

For a deeper understanding of the usage of @ModelActor and its role in SwiftData, please refer to the article Concurrent Programming in SwiftData.

Writing Tests

Although the logic of Test-Driven Development (TDD) usually recommends writing tests before implementing functionalities, in our demo project, we will construct the test units after completing the data operation logic.

First, we set up a helper function dedicated to testing, ensuring that each test case can use a clean database environment:

enum ContainerForTest {
  static func temp(_ name: String, delete: Bool = true) throws -> ModelContainer {
    let url = URL.temporaryDirectory.appending(component: name)
    if delete, FileManager.default.fileExists(atPath: url.path) {
      try FileManager.default.removeItem(at: url)
    }
    let schema = Schema(CurrentScheme.models)
    let configuration = ModelConfiguration(url: url)
    let container = try! ModelContainer(for: schema, configurations: configuration)
    return container
  }
}

This helper function creates a separate database for each test case, with the database name based on the name of the test function. By default, it deletes the old data file before each test.

Here is a test case designed to verify the functionality of creating a new Item instance:

final class DataProviderTests: XCTestCase {
  @MainActor
  func testNewItem() async throws {
    // Arrange
    let container = try ContainerForTest.temp(#function)
    let hander = DataHandler(modelContainer: container)

    // ACT
    let date = Date(timeIntervalSince1970: 0)
    try await hander.newItem(date: date)

    // Assert
    let fetchDescriptor = FetchDescriptor<Item>()
    let items = try container.mainContext.fetch(fetchDescriptor)

    XCTAssertNotNil(items.first, "The item should be created and fetched successfully.")
    XCTAssertEqual(items.count, 1, "There should be exactly one item in the store.")

    if let firstItem = items.first {
      XCTAssertEqual(firstItem.timestamp, date, "The item's timestamp should match the initially provided date.")
    } else {
      XCTFail("Expected to find an item but none was found.")
    }
  }
}

Test Process Overview:

Initialize a new, clean database instance.
Use DataHandler to add a new data item.
Retrieve Item data from the database through the container's mainContext.
Assert whether the retrieved data meets the expectations.

Special Considerations:

The test case is marked with @MainActor to allow direct use of the container's mainContext.
Creation and retrieval of data are conducted in different contexts to ensure the accuracy of the logic and to simulate real application scenarios.
When testing deletion functionality, the returned PersistentIdentifier of the newly created data item can be used to simplify the process and avoid repeated data retrieval from the database.
The returned PersistentIdentifier should be used in the same context, especially when it is still in a temporary state. For operations across contexts, it may be necessary to retrieve the data again to obtain a persistent identifier.

Concerns About Testing Efficiency: Based on practical experience, even the method of testing with new database files can complete a large number of tests in a short time, so developers should not worry about its impact on testing performance.

Preparing for Injection

After completing comprehensive testing of data operations in the demo project, the next step is to consider how to make DataHandler easily accessible or injectable into other parts of the project in a safe manner that aligns with modern programming paradigms.

To this end, we have defined the following method in the DataProvider class:

public func dataHandlerCreator() -> @Sendable () async -> DataHandler {
  let container = sharedModelContainer
  return { DataHandler(modelContainer: container) }
}

This helper function provides a safe method to create DataHandler instances, which is particularly crucial when Swift's strict concurrency checks are enabled.

In the demo project, we demonstrated how to inject the DataHandler creation function into the view environment. This approach is not limited to injection through environment values but is also applicable to various architectural designs. For instance, when using The Composable Architecture (TCA), a similar strategy can be employed to define DependencyKey for the purpose of dependency injection. Moreover, given that DataProvider itself conforms to the Sendable protocol, it can also be used directly as a source for dependency injection in certain scenarios. This flexibility allows developers to choose the most appropriate injection and dependency management strategy based on the specific requirements of their application architecture.

By extending SwiftUI's EnvironmentValues, we can seamlessly integrate the DataHandler creation logic into the SwiftUI environment, thereby providing a robust data operation capability to the view layer:

public struct DataHandlerKey: EnvironmentKey {
  public static let defaultValue: @Sendable () async -> DataHandler? = { nil }
}

extension EnvironmentValues {
  public var createDataHandler: @Sendable () async -> DataHandler? {
    get { self[DataHandlerKey.self] }
    set { self[DataHandlerKey.self] = newValue }
  }
}

With this, we have completed all the preparatory work for the data management module, and now it can be integrated into the project and put to use.

Always Use One Instance or Create a New Instance Every Time

When developing with SwiftData, I recommend avoiding the retention of a long-term shared DataHandler instance within DataProvider. Instead, it might be a better choice to create a new instance independently in each business logic scenario. This approach has several advantages:

Firstly, considering the excellent performance of modern devices, the overhead of dynamically creating a new DataHandler instance is generally acceptable and does not negatively impact the application's response speed or efficiency.

Secondly, due to the absence of configurations such as error handling and merge strategies in SwiftData, creating a new independent instance for each data operation can simplify the complexity of exception handling. In this way, each instance is self-contained, and operations do not interfere with each other, thereby reducing the risk of errors and making the code clearer and easier to maintain.

Integrating the Data Module into the Project

After introducing the package into the project, we can start utilizing it within the application, providing the container and methods to generate DataHandler.

import DataProvider
import SwiftData
import SwiftUI

@main
struct SwiftDataConcurrencyDemoApp: App {
  let dataProvider = DataProvider.shared

  var body: some Scene {
    WindowGroup {
      ContentView()
        .environment(\.createDataHandler, dataProvider.dataHandlerCreator())
    }
    .modelContainer(dataProvider.sharedModelContainer)
  }
}

This code segment integrates the instance of DataProvider into the main entry of the SwiftUI application. We inject the createDataHandler method using the .environment modifier, making it available in ContentView and its subviews.

In ContentView, we have implemented the functionality to add new data items, as shown below:

struct ContentView: View {
  @Environment(\.modelContext) private var modelContext
  @Environment(\.createDataHandler) private var createDataHandler
  @Query(sort: \Item.createTimestamp, animation: .smooth) private var items: [Item]

  var body: some View {
    NavigationSplitView {
      List {
        ForEach(items) { item in
          ItemView(item: item)
        }
      }
      .toolbar {
        ToolbarItem {
          Button(action: addItem) {
            Label("Add Item", systemImage: "plus")
          }
        }
      }
    } detail: {
      Text("Select an item")
    }
  }

  @MainActor
  private func addItem() {
    let createDataHandler = createDataHandler
    Task.detached {
      if let dataHandler = await createDataHandler() {
        try await dataHandler.newItem(date: .now)
      }
    }
  }
}

Key Points Summary:

Use @Environment(\.createDataHandler) to introduce the method for creating DataHandler into the view.
To comply with Swift's strict concurrency checks, the addItem function is annotated with @MainActor.
Utilize Task.detached to create a detached task, ensuring that the DataHandler instance is created on a non-main thread, and perform data operations, thereby avoiding blocking the UI.

In this way, the data management logic is separated from the view logic, maintaining the clarity and maintainability of the code while also facilitating asynchronous data processing and interface updates.

Building Independent View to Display Data

Following the list view, we will next construct an independent view for displaying detailed Item data. In ItemView, we use the createDataHandler environment variable to create a DataHandler instance, handling the data's deletion and update operations respectively. All operations of the DataHandler instances are carried out on non-main threads to ensure that the smoothness of the interface is not affected by the data processing.

struct ItemView: View {
  @Environment(\.createDataHandler) private var createDataHandler
  let item: Item
  var body: some View {
    VStack {
      Text("\(item.timestamp.timeIntervalSince1970)")
      HStack {
        Button("Update Timestamp") {
          let id = item.id
          let date = Date.now
          let createDataHandler = createDataHandler
          Task.detached {
            if let dataHandler = await createDataHandler() {
              try? await dataHandler.updateItem(id: id, timestamp: date)
            }
          }
        }
        Button("Delete") {
          let id = item.id
          let createDataHandler = createDataHandler
          Task.detached {
            if let dataHandler = await createDataHandler() {
              try? await dataHandler.deleteItem(id: id)
            }
          }
        }
      }
    }
    .buttonStyle(.bordered)
  }
}

Now, we can fully run the project in the simulator and implement the addition and deletion of data.

Is a Data Transformation Layer Still Needed?

In traditional Core Data projects, it's common to create a value-type data transformation layer, which mainly serves to convert managed objects (reference types) into value types that are more suitable for use in views. This helps enhance the safety of data handling and simplifies the data binding in views.

In SwiftData, the model is built using pure Swift types, and SwiftData's PersistentModel leverages the observation mechanism provided by the Observation framework. This mechanism provides observability for each property, ensuring that views can accurately respond to data changes. Transforming these data in the views would disrupt this observation mechanism, leading to unnecessary view updates. Therefore, it is recommended to use the data models defined in SwiftData directly in the views.

However, this does not mean that a data transformation layer is unnecessary in all scenarios. In fact, using value-based data models for creating or updating data can be safer and more efficient, especially when it comes to data comparison and testing.

Although we did not provide a data transformation layer type in the demo project, developers should consider whether to introduce this layer based on specific needs during the actual application development process. This design decision should be based on the specific requirements of the project, taking into consideration data safety, development efficiency, and whether it can enhance the overall code quality and maintainability.

Preparing for Preview

In SwiftUI development, previewing is an indispensable feature that can greatly improve development efficiency. Therefore, configuring an appropriate environment for previews is crucial. We typically recommend using an in-memory database for preview scenarios, which requires us to make appropriate adjustments to DataProvider.

Firstly, we add the following code in DataProvider to initialize a non-persistent ModelContainer specifically for preview environments:

public let previewContainer: ModelContainer = {
  let schema = Schema(CurrentScheme.models)
  let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: true)
  do {
    return try ModelContainer(for: schema, configurations: [modelConfiguration])
  } catch {
    fatalError("Could not create ModelContainer: \(error)")
  }
}()

Next, we modify the dataHandlerCreator function so that it can choose between using a persistent or non-persistent container based on the requirements:

public func dataHandlerCreator(preview: Bool = false) -> @Sendable () async -> DataHandler {
  let container = preview ? previewContainer : sharedModelContainer
  return { DataHandler(modelContainer: container) }
}

To effectively utilize these configurations in previews, we typically create a dedicated preview wrapper view, which not only prepares the preview environment but also constructs demo data. Below is an example demonstrating how to build a preview container for ItemView:

#if DEBUG
  struct ItemViewPreviewContainer: View {
    @Environment(\.createDataHandler) var createDataHandler
    @Query var items: [Item]
    var body: some View {
      VStack {
        if let item = items.first {
          ItemView(item: item)
        }
      }
      .task {
        if let dataHander = await createDataHandler() {
          let _ = try? await dataHander.newItem(date: .now)
        }
      }
    }
  }
#endif

#Preview {
  let dataProvider = DataProvider()
  return ItemViewPreviewContainer()
    .environment(\.createDataHandler, dataProvider.dataHandlerCreator(preview: true))
    .modelContainer(dataProvider.previewContainer)
}

When configuring the preview environment for ItemViewPreviewContainer, ensure to use the container and DataHandler creation functions specifically prepared for previews. This guarantees that the preview environment is isolated, not affecting the actual application data, and provides a fast and efficient way to demonstrate and test views.

A New Issue: The View Does Not Refresh After Data Update

If you follow this article to build your own code, you might encounter a problem: clicking the update data button in ItemView does not refresh the data on the interface as expected. Considering that our unit tests pass successfully and there is no issue with the data update logic itself, what could be causing this problem?

This is actually caused by a known bug in the current version of SwiftData, which leads to the view not refreshing after a data update under the following two conditions:

The data update logic is encapsulated within a ModelActor.
An independent view is used to display and respond to data changes (for example, when we adjust the display code as follows, using Text directly to show the data, the difference after the update becomes noticeable):

List {
  ForEach(items) { item in
    VStack {
      Text("\(item.timestamp.timeIntervalSince1970)")
      ItemView(item: item) // don't change after update
    }
  }
}

This issue has been raised by several developers using ModelActor, and the solution I provided at the time was not ideal. It mainly involved adding extra parameters to the data display view to achieve update awareness. This method has significant limitations and might result in the loss of changes during the initial update. This article will explore other possible solutions.

struct ItemView: View {
  @Environment(\.createDataHandler) private var createDataHandler
  let item: Item
  let date: Date
  var body: some View {
     ....
  }
}

ItemView(item: item, date: item.timestamp)

I have submitted feedback to Apple (FB13689240) and hope that the issue will be resolved soon.

Solution Approach

To address the issue of the view not refreshing after a data update, we initially consider the following two methods:

Avoid using independent views to display and respond to data.
Extract the data update logic from DataHandler and directly modify the data in the mainContext.

Obviously, considering the maintenance of the existing architectural pattern and testing workflow, neither of these methods is desirable. However, if performing the data update operation in the mainContext can avoid the issue of the view not refreshing, then could we consider creating a dedicated DataHandler instance for data update operations that directly uses the mainContext?

The mainContext is provided by the ModelContainer instance and is annotated with @MainActor, meaning it can only be used on the main thread. We retrieve data in the view using this context with @Query.

Swift's Macro functionality provides the potential for implementing this approach. By exploring the code generated by the @ModelActor macro, we can gain insight into its underlying implementation mechanism and make the necessary adjustments.

Let's examine the initialization method of DataHandler generated by the @ModelActor macro:

public init(modelContainer: SwiftData.ModelContainer) {
    let modelContext = ModelContext(modelContainer)
    self.modelExecutor = DefaultSerialModelExecutor(modelContext: modelContext)
    self.modelContainer = modelContainer
}

This initialization method creates a new ModelContext instance via ModelContext(modelContainer) and sets the actor's execution environment to be associated with this context (using the same thread). Therefore, we can consider adding a new constructor to DataHandler, which allows us to provide a solution without significantly altering the current development mode.

Temporary Solution

Our temporary solution involves extending the DataHandler class and adjusting DataProvider to ensure that data update operations are carried out in the mainContext on the main thread.

First, we add a new constructor to DataHandler:

@MainActor
public init(modelContainer: ModelContainer, mainActor _: Bool) {
  let modelContext = modelContainer.mainContext
  modelExecutor = DefaultSerialModelExecutor(modelContext: modelContext)
  self.modelContainer = modelContainer
}

This constructor is annotated with @MainActor to ensure that the modelContainer.mainContext is directly bound to the actor's executor. We introduced an unused parameter to avoid conflicts with the existing constructor signature.

Next, we add a new helper method in DataProvider to generate DataHandler instances that are bound to the mainContext:

public func dataHandlerWithMainContextCreator(preview: Bool = false) -> @Sendable @MainActor () async -> DataHandler {
  let container = preview ? previewContainer : sharedModelContainer
  return { DataHandler(modelContainer: container, mainActor: true) }
}

Next, we define a new environment key and extend EnvironmentValues to inject the new helper method:

public struct MainActorDataHandlerKey: EnvironmentKey {
  public static let defaultValue: @Sendable @MainActor () async -> DataHandler? = { nil }
}

extension EnvironmentValues {
  public var createDataHandlerWithMainContext: @Sendable @MainActor () async -> DataHandler? {
    get { self[MainActorDataHandlerKey.self] }
    set { self[MainActorDataHandlerKey.self] = newValue }
  }
}

In the root view of the application, we inject this new environment value:

WindowGroup {
  ContentView()
    .environment(\.createDataHandler, dataProvider.dataHandlerCreator())
    // new
    .environment(\.createDataHandlerWithMainContext, dataProvider.dataHandlerWithMainContextCreator())
}

In ItemView, we introduce and use this new environment value to perform data update operations:

struct ItemView: View {
  @Environment(\.createDataHandler) private var createDataHandler
  @Environment(\.createDataHandlerWithMainContext) private var createDataHandlerWithMainContext
  let item: Item
  var body: some View {
    VStack {
      Text("\(item.timestamp.timeIntervalSince1970)")
      HStack {
        Button("Update Timestamp") {
          updateItemTimestamp()
        }
                ....
      }
    }
    .buttonStyle(.bordered)
  }

  @MainActor
  private func updateItemTimestamp() {
    let id = item.id
    let date = Date.now
    Task { @MainActor in
      if let dataHandler = await createDataHandlerWithMainContext() {
        try? await dataHandler.updateItem(id: id, timestamp: date)
      }
    }
  }
}

Ensure that the corresponding environment values are also injected into the preview environment:

#Preview {
  let dataProvider = DataProvider()
  return ItemViewPreviewContainer()
    .environment(\.createDataHandler, dataProvider.dataHandlerCreator(preview: true))
    .environment(\.createDataHandlerWithMainContext, dataProvider.dataHandlerWithMainContextCreator(preview: true))
    .modelContainer(dataProvider.previewContainer)
}

In this way, we can ensure that data update operations are conducted within a DataHandler instance that is bound to the mainContext on the main thread, while other operations continue to be executed on non-main threads. Although this requires special handling for update operations, it is a viable compromise solution without altering the existing architecture. I hope that this issue can be resolved by the official update soon.

Special Reminder: Since its first version (iOS 17.0), SwiftData has been fixing some known issues in almost every version, but new problems might also be introduced. Therefore, when you run the demo project provided in the article, and the project is running on different system versions or compiled with different versions of Xcode, you might encounter results that are inconsistent with expectations (for example, not being able to see new data after clicking the add button, or the app crashes when pushed to the background, etc.). We still need to wait for Apple to further address these issues. Nevertheless, I believe the data manipulation logic introduced in the article is correct. To ensure the method introduced in this article is used in a stable and reliable manner in the current project, please create all DataHandlers through createDataHandlerWithMainContext (i.e., building DataHandler with the main context).

Conclusion

In this article, we explored how to adopt a new mindset to build SwiftUI applications using SwiftData. When we start using a new framework, especially those developed on the foundation of older frameworks, we cannot simply transplant old experiences and habits directly. We need to think deeply about how to leverage the advantages of the new framework while integrating the latest programming concepts to create more efficient, modern applications.

Each update to a framework is not only a challenge but also an opportunity. It requires developers to step out of their comfort zones, re-examine, and learn the potential and best practices of new tools. By doing so, we not only enhance our personal skills but also provide better products for our users. As a modern data management framework, SwiftData offers developers greater flexibility and powerful features, making data handling more intuitive and efficient.

With the continuous evolution of Swift and SwiftUI, combined with frameworks like SwiftData, developers are empowered to create safer, more responsive, richer, and more interactive applications. Therefore, keeping up with the latest development trends and learning to utilize the powerful features of these new tools is essential for every developer committed to improving their skills and product quality.

Tips and Considerations for Using Lazy Containers in SwiftUI

Fatbobman( 东坡肘子 ) — Tue, 19 Mar 2024 00:21:09 +0000

In the SwiftUI framework, lazy layout containers such as List and LazyVStack provide a method for efficiently displaying large datasets. These containers are ingeniously designed to dynamically build and load views only when necessary, thereby significantly optimizing the app's performance and memory efficiency. This article will explore some practical tips and important considerations aimed at enhancing developers' ability to leverage SwiftUI's lazy containers for improved app responsiveness and resource management.

Custom Implementation Conforming to RandomAccessCollection

In some cases, our data source may not be directly compatible with SwiftUI's ForEach constructor. Since ForEach requires the data source to conform to the RandomAccessCollection protocol to support efficient random access index operations, we need to customize a data type that conforms to this protocol for the incompatible data source, thereby optimizing performance and memory usage.

Taking the OrderedDictionary from the Swift Collection library as an example, it combines the efficient key-value storage of dictionaries with the characteristics of ordered collections. Directly converting it to an array might lead to unnecessary memory increase, especially when dealing with large datasets. By customizing a type that conforms to the RandomAccessCollection protocol, we can effectively manage memory while maintaining efficient data processing capabilities.

Below is an example of implementing and using such a customized collection:

// Create DictDataSource, the minimal implementation conforming to RandomAccessCollection
final class DictDataSource<Key, Value>: RandomAccessCollection, ObservableObject where Key: Hashable {
    typealias Index = Int

    private var dict: OrderedDictionary<Key, Value>

    init(dict: OrderedDictionary<Key, Value>) {
        self.dict = dict
    }

    var startIndex: Int {
        0
    }

    var endIndex: Int {
        dict.count
    }

    subscript(position: Int) -> (key: Key, value: Value) {
        dict.elements[position]
    }
}

// Usage
let responses: OrderedDictionary<Int, String> = [
    200: "OK",
    403: "Access forbidden", 
    404: "File not found",
    500: "Internal server error",
]

struct OrderedCollectionsDemo: View {
    @StateObject var dataSource = DictDataSource(dict: responses)
    var body: some View {
        List {
            ForEach(dataSource, id: \.key) { element in
                Text("\(element.key) : \(element.value)")
            }
        }
    }
}

Using this method, we not only optimized the processing efficiency of large datasets but also reduced memory usage, enhancing the overall responsiveness of the application. Besides OrderedDictionary, other custom data structures like linked lists, trees, etc., can also implement a random-access data source adapter in a similar manner, to better cooperate with the use of ForEach.

Implementing Infinite Data Loading

In the development process, we often encounter scenarios that require implementing infinite data loading, meaning dynamically loading new data sets based on user scrolling or demand. This mechanism not only helps optimize memory usage but also significantly enhances user experience, especially when dealing with large amounts of data.

By introducing a custom implementation of RandomAccessCollection, we can embed dynamic loading logic directly at the data source level. The DynamicDataSource class shown below follows the RandomAccessCollection protocol and automatically triggers the loading of more data as it approaches the end of the data.

struct Item: Identifiable, Sendable {
  let id = UUID()
  let number: Int
}

final class DynamicDataSource: RandomAccessCollection, ObservableObject {
  typealias Element = Item
  typealias Index = Int

  @Published private var items: [Item]
  private var isLoadingMoreData = false
  private let threshold = 10 // Set the threshold to trigger loading more data

  init(initialItems: [Item] = []) {
    items = initialItems
  }

  var startIndex: Int {
    items.startIndex
  }

  var endIndex: Int {
    items.endIndex
  }

  func formIndex(after i: inout Int) {
    i += 1
    // Trigger the loading of more data when accessing elements within the threshold distance from the end of the array
    if i >= (items.count - threshold) && !isLoadingMoreData && !items.isEmpty {
      loadMoreData()
    }
  }

  subscript(position: Int) -> Item {
    items[position]
  }

  private func loadMoreData() {
    guard !isLoadingMoreData else { return }

    isLoadingMoreData = true

    // Simulate asynchronously loading new data
    Task {
      try? await Task.sleep(for: .seconds(1.5))
      let newItems = (0 ..< 30).map { _ in Item(number: Int.random(in: 0 ..< 1000)) }
      await MainActor.run { [weak self] in
        self?.items.append(contentsOf: newItems)
        self?.isLoadingMoreData = false
      }
    }
  }
}

The demonstration of its use in the view is as follows: as the user scrolls, new data will be dynamically loaded into the list:

struct DynamicDataLoader: View {
  @StateObject var dataSource = DynamicDataSource(initialItems: (0 ..< 50).map { _ in Item(number: Int.random(in: 0 ..< 1000)) })
  var body: some View {
    List {
      ForEach(dataSource) { item in
        Text("\(item.number)")
      }
    }
  }
}

Through the aforementioned method, we have successfully decoupled the dynamic data loading logic from the view rendering logic, making the code structure clearer and easier to maintain. The applicability of this implementation pattern is very broad; it can be used for data simulation and can be easily extended to accommodate more practical needs, such as loading data from the internet or implementing pagination of data.

When strict checking of asynchronous compilation is enabled, the demonstration code above may trigger a compiler warning: “Capture of 'self' with non-sendable type 'DynamicDataSource' in a @Sendable closure.” This warning is due to capturing self in a closure that may involve concurrent execution, where the type of self, DynamicDataSource, does not conform to the Sendable protocol. Considering that @StateObject ensures that the instance always runs on the main thread, and all modifications to the instance's properties occur on the main thread, using @unchecked Sendable to annotate DynamicDataSource to eliminate the warning is safe in this specific scenario.

The Impact of the `id` Modifier on List's Lazy Loading Mechanism

In SwiftUI, the List view relies on a lazy loading mechanism to optimize performance and user experience. The lazy loading ensures that instances of the subviews are only created and loaded into the view hierarchy when they are about to appear in the visible area. However, in certain situations, this optimization mechanism might be unintentionally disrupted, especially when the id modifier is used on the subviews.

Consider the following example, where we have added an id modifier to ItemSubView. As a result, the List instantiates all the child views immediately, although it only renders the content (evaluates the body) of the currently visible subviews:

struct LazyBrokenView: View {
  @State var items = (0 ..< 50).map { Item(number: $0) }
  var body: some View {
    List {
      ForEach(items) { item in
        ItemSubView(item: item)
          .id(item.id)
      }
    }
  }
}

struct ItemSubView: View {
  let item: Item
  init(item: Item) {
    self.item = item
    print("\(item.number) init")
  }

  var body: some View {
    let _ = print("\(item.number) update")
    Text("\(item.number)")
      .frame(height: 30)
  }
}

Although the lazy loading mechanism of List only renders the visible views, instantiating all child views immediately in the case of large datasets can cause significant performance overhead, severely affecting the app's initial loading efficiency.

If the use of id is unavoidable, such as when using ScrollViewReader or in other scenarios where unique identification of views is required, consider adopting alternative methods to mitigate the loss of lazy loading features. For more optimization tips, refer to Demystifying SwiftUI List Responsiveness: Best Practices for Large Datasets.

While the id modifier impacts the lazy loading feature of List, its use in other lazy layout containers like LazyVStack, LazyVGrid is safe.

Moreover, the new features of ScrollView introduced in WWDC2023, such as scrollPosition(id:), can trigger similar effects as id in Lists, and should be used cautiously with large datasets. For more details, consider reviewing Deep Dive into the New Features of ScrollView in SwiftUI 5.

In summary, when leveraging the advantages of SwiftUI's lazy containers, we must be aware of these potential pitfalls, especially in scenarios requiring the display of large datasets, as they could significantly impact the app’s performance and user experience.

SwiftUI Only Retains the Top-Level State of ForEach Subviews in Lazy Containers

A crucial detail to note when using SwiftUI's lazy containers, especially when the subviews are composed of multi-layered view structures created through ForEach, is that SwiftUI only retains the state of the top-level views when they reappear after leaving the visible area.

This means, in the following code example, where RootView is a subview within a ForEach loop containing another view ChildView, according to SwiftUI's design, only the state located in RootView will be maintained when it re-enters the visible area, while the state nested inside ChildView will be reset:

struct StateLoss: View {
  var body: some View {
    List {
      ForEach(0 ..< 100) { i in
        RootView(i: i)
      }
    }
  }
}

struct RootView: View {
  @State var topState = false
  let i: Int
  var body: some View {
    VStack {
      Text("\(i)")
      Toggle("Top State", isOn: $topState)
      ChildView()
    }
  }
}

struct ChildView: View {
  @State var childState = false
  var body: some View {
    VStack {
      Toggle("Child State", isOn: $childState)
    }
  }
}

Initially, I thought this behavior was a bug, but according to feedback from exchanges with Apple engineers, it is actually an intentional design decision. From the design philosophy of SwiftUI, this choice is rational. To strike a balance between rendering efficiency and resource consumption, maintaining the state of all subviews in the view hierarchy of a lazy container with a complex view structure and numerous subviews could significantly reduce efficiency. Hence, the decision to only preserve the state of the top-level subviews is considered a sensible design choice.

Therefore, for structures with multi-layered subviews and rich state, the recommended practice is to elevate all relevant states to the top-level view, ensuring the correct maintenance of the state:

struct RootView: View {
  @State var topState = false
  @State var childState = false
  let i: Int
  var body: some View {
    VStack {
      Text("\(i)")
      Toggle("Top State", isOn: $topState)
      ChildView(childState: $childState)
    }
  }
}

struct ChildView: View {
  @Binding var childState: Bool
  var body: some View {
    VStack {
      Toggle("Child State", isOn: $childState)
    }
  }
}

Such a practice not only adheres to SwiftUI's design principles but also ensures that the application's state is correctly managed and preserved, even in complex view hierarchies.

SwiftUI's Passive Memory Resource Release for Specific State Types

In the common understanding of Swift developers, setting an optional value type variable to nil should trigger the system to reclaim the resources occupied by the original data. Therefore, some developers attempt to use this mechanism to save memory when dealing with lazy views that might consume significant resources. The following example illustrates this approach:

struct MemorySave: View {
  var body: some View {
    List {
      ForEach(0 ..< 100) { _ in
        ImageSubView()
      }
    }
  }
}

struct ImageSubView: View {
  @State var image: Image?
  var body: some View {
    VStack {
      if let image {
        image
          .resizable()
          .frame(width: 200, height: 200)
      } else {
        Rectangle().fill(.gray.gradient)
          .frame(width: 200, height: 200)
      }
    }
    .task {
      // Simulate loading different images
      if let uiImage = createImage() {
        image = Image(uiImage: uiImage)
      }
    }
    .onDisappear {
      // Set to nil when leaving the visible area
      image = nil
    }
  }

  func createImage() -> UIImage? {
    let colors: [UIColor] = [.black, .blue, .yellow, .cyan, .green, .magenta]
    let color = colors.randomElement()!
    let size = CGSize(width: 1000, height: 1000)
    UIGraphicsBeginImageContextWithOptions(size, false, 0)
    color.setFill()
    UIRectFill(CGRect(origin: .zero, size: size))
    let image = UIGraphicsGetImageFromCurrentImageContext()
    UIGraphicsEndImageContext()
    return image
  }
}

Even though the state is set to nil, in lazy containers, certain types of data (such as Image, UIImage, etc.) do not immediately release the memory space they occupy unless they completely exit the lazy container view. In this case, by changing the state type, the eagerness of resource recycling can be improved:

struct ImageSubView: View {
  @State var data:Data?
  var body: some View {
    VStack {
      if let data,let uiImage = UIImage(data: data) {
        Image(uiImage: uiImage)
          .resizable()
          .frame(width: 200, height: 200)
      } else {
        Rectangle().fill(.gray.gradient)
          .frame(width: 200, height: 200)
      }
    }
    .task {
      // Simulate loading different images, converting them into the Data type
      if let uiImage = await createImage() {
        data = uiImage
      }
    }
    .onDisappear {
      data = nil
    }
  }

  func createImage() async -> Data? {
    let colors: [UIColor] = [.black, .blue, .yellow, .cyan, .green, .magenta]
    let color = colors.randomElement()!
    let size = CGSize(width: 1000, height: 1000)
    UIGraphicsBeginImageContextWithOptions(size, false, 0)
    color.setFill()
    UIRectFill(CGRect(origin: .zero, size: size))
    let image = UIGraphicsGetImageFromCurrentImageContext()
    UIGraphicsEndImageContext()
    return image?.pngData()
  }
}

In the code mentioned above, by changing the state to be held as Optional<Data>, the system can properly reclaim the resources occupied once the state is set to nil, thereby improving memory usage.

For a detailed analysis and discussion of the issue, refer to Memory Optimization Journey for a SwiftUI + Core Data App.

With this approach, we can effectively control memory usage, particularly when large amounts of data or resources are loaded by lazy views, ensuring the application's performance and responsiveness.

Some readers might consider using the feature of lazy containers, which only retains the top-level state, to address memory usage issues. Unfortunately, for these specific types, even if the state is "forgotten," the memory they occupy is not released promptly. Therefore, this method is not suitable for resolving the issue of memory not being actively released for certain types.

Conclusion

While SwiftUI offers great convenience to developers, making it easier to create dynamic and responsive user interfaces, understanding and leveraging the working mechanism of its lazy layout containers is still key to developing efficient, high-performance SwiftUI applications. This article aims to help developers better master these techniques, optimize their SwiftUI applications, and ensure they can provide rich functionality while maintaining a smooth user experience and efficient resource usage.

Tips and Considerations for Using Lazy Containers in SwiftUI

Fatbobman( 东坡肘子 ) — Tue, 19 Mar 2024 00:21:09 +0000

Custom Implementation Conforming to RandomAccessCollection

Below is an example of implementing and using such a customized collection:

// Create DictDataSource, the minimal implementation conforming to RandomAccessCollection
final class DictDataSource<Key, Value>: RandomAccessCollection, ObservableObject where Key: Hashable {
    typealias Index = Int

    private var dict: OrderedDictionary<Key, Value>

    init(dict: OrderedDictionary<Key, Value>) {
        self.dict = dict
    }

    var startIndex: Int {
        0
    }

    var endIndex: Int {
        dict.count
    }

    subscript(position: Int) -> (key: Key, value: Value) {
        dict.elements[position]
    }
}

// Usage
let responses: OrderedDictionary<Int, String> = [
    200: "OK",
    403: "Access forbidden", 
    404: "File not found",
    500: "Internal server error",
]

struct OrderedCollectionsDemo: View {
    @StateObject var dataSource = DictDataSource(dict: responses)
    var body: some View {
        List {
            ForEach(dataSource, id: \.key) { element in
                Text("\(element.key) : \(element.value)")
            }
        }
    }
}

Implementing Infinite Data Loading

struct Item: Identifiable, Sendable {
  let id = UUID()
  let number: Int
}

final class DynamicDataSource: RandomAccessCollection, ObservableObject {
  typealias Element = Item
  typealias Index = Int

  @Published private var items: [Item]
  private var isLoadingMoreData = false
  private let threshold = 10 // Set the threshold to trigger loading more data

  init(initialItems: [Item] = []) {
    items = initialItems
  }

  var startIndex: Int {
    items.startIndex
  }

  var endIndex: Int {
    items.endIndex
  }

  func formIndex(after i: inout Int) {
    i += 1
    // Trigger the loading of more data when accessing elements within the threshold distance from the end of the array
    if i >= (items.count - threshold) && !isLoadingMoreData && !items.isEmpty {
      loadMoreData()
    }
  }

  subscript(position: Int) -> Item {
    items[position]
  }

  private func loadMoreData() {
    guard !isLoadingMoreData else { return }

    isLoadingMoreData = true

    // Simulate asynchronously loading new data
    Task {
      try? await Task.sleep(for: .seconds(1.5))
      let newItems = (0 ..< 30).map { _ in Item(number: Int.random(in: 0 ..< 1000)) }
      await MainActor.run { [weak self] in
        self?.items.append(contentsOf: newItems)
        self?.isLoadingMoreData = false
      }
    }
  }
}

The demonstration of its use in the view is as follows: as the user scrolls, new data will be dynamically loaded into the list:

struct DynamicDataLoader: View {
  @StateObject var dataSource = DynamicDataSource(initialItems: (0 ..< 50).map { _ in Item(number: Int.random(in: 0 ..< 1000)) })
  var body: some View {
    List {
      ForEach(dataSource) { item in
        Text("\(item.number)")
      }
    }
  }
}

When strict checking of asynchronous compilation is enabled, the demonstration code above may trigger a compiler warning: “Capture of 'self' with non-sendable type 'DynamicDataSource' in a @Sendable closure.” This warning is due to capturing self in a closure that may involve concurrent execution, where the type of self, DynamicDataSource, does not conform to the Sendable protocol. Considering that @StateObject ensures that the instance always runs on the main thread, and all modifications to the instance's properties occur on the main thread, using @unchecked Sendable to annotate DynamicDataSource to eliminate the warning is safe in this specific scenario.

The Impact of the `id` Modifier on List's Lazy Loading Mechanism

struct LazyBrokenView: View {
  @State var items = (0 ..< 50).map { Item(number: $0) }
  var body: some View {
    List {
      ForEach(items) { item in
        ItemSubView(item: item)
          .id(item.id)
      }
    }
  }
}

struct ItemSubView: View {
  let item: Item
  init(item: Item) {
    self.item = item
    print("\(item.number) init")
  }

  var body: some View {
    let _ = print("\(item.number) update")
    Text("\(item.number)")
      .frame(height: 30)
  }
}

If the use of id is unavoidable, such as when using ScrollViewReader or in other scenarios where unique identification of views is required, consider adopting alternative methods to mitigate the loss of lazy loading features. For more optimization tips, refer to Demystifying SwiftUI List Responsiveness: Best Practices for Large Datasets.

While the id modifier impacts the lazy loading feature of List, its use in other lazy layout containers like LazyVStack, LazyVGrid is safe.

SwiftUI Only Retains the Top-Level State of ForEach Subviews in Lazy Containers

struct StateLoss: View {
  var body: some View {
    List {
      ForEach(0 ..< 100) { i in
        RootView(i: i)
      }
    }
  }
}

struct RootView: View {
  @State var topState = false
  let i: Int
  var body: some View {
    VStack {
      Text("\(i)")
      Toggle("Top State", isOn: $topState)
      ChildView()
    }
  }
}

struct ChildView: View {
  @State var childState = false
  var body: some View {
    VStack {
      Toggle("Child State", isOn: $childState)
    }
  }
}

Therefore, for structures with multi-layered subviews and rich state, the recommended practice is to elevate all relevant states to the top-level view, ensuring the correct maintenance of the state:

struct RootView: View {
  @State var topState = false
  @State var childState = false
  let i: Int
  var body: some View {
    VStack {
      Text("\(i)")
      Toggle("Top State", isOn: $topState)
      ChildView(childState: $childState)
    }
  }
}

struct ChildView: View {
  @Binding var childState: Bool
  var body: some View {
    VStack {
      Toggle("Child State", isOn: $childState)
    }
  }
}

Such a practice not only adheres to SwiftUI's design principles but also ensures that the application's state is correctly managed and preserved, even in complex view hierarchies.

SwiftUI's Passive Memory Resource Release for Specific State Types

struct MemorySave: View {
  var body: some View {
    List {
      ForEach(0 ..< 100) { _ in
        ImageSubView()
      }
    }
  }
}

struct ImageSubView: View {
  @State var image: Image?
  var body: some View {
    VStack {
      if let image {
        image
          .resizable()
          .frame(width: 200, height: 200)
      } else {
        Rectangle().fill(.gray.gradient)
          .frame(width: 200, height: 200)
      }
    }
    .task {
      // Simulate loading different images
      if let uiImage = createImage() {
        image = Image(uiImage: uiImage)
      }
    }
    .onDisappear {
      // Set to nil when leaving the visible area
      image = nil
    }
  }

  func createImage() -> UIImage? {
    let colors: [UIColor] = [.black, .blue, .yellow, .cyan, .green, .magenta]
    let color = colors.randomElement()!
    let size = CGSize(width: 1000, height: 1000)
    UIGraphicsBeginImageContextWithOptions(size, false, 0)
    color.setFill()
    UIRectFill(CGRect(origin: .zero, size: size))
    let image = UIGraphicsGetImageFromCurrentImageContext()
    UIGraphicsEndImageContext()
    return image
  }
}

struct ImageSubView: View {
  @State var data:Data?
  var body: some View {
    VStack {
      if let data,let uiImage = UIImage(data: data) {
        Image(uiImage: uiImage)
          .resizable()
          .frame(width: 200, height: 200)
      } else {
        Rectangle().fill(.gray.gradient)
          .frame(width: 200, height: 200)
      }
    }
    .task {
      // Simulate loading different images, converting them into the Data type
      if let uiImage = await createImage() {
        data = uiImage
      }
    }
    .onDisappear {
      data = nil
    }
  }

  func createImage() async -> Data? {
    let colors: [UIColor] = [.black, .blue, .yellow, .cyan, .green, .magenta]
    let color = colors.randomElement()!
    let size = CGSize(width: 1000, height: 1000)
    UIGraphicsBeginImageContextWithOptions(size, false, 0)
    color.setFill()
    UIRectFill(CGRect(origin: .zero, size: size))
    let image = UIGraphicsGetImageFromCurrentImageContext()
    UIGraphicsEndImageContext()
    return image?.pngData()
  }
}

For a detailed analysis and discussion of the issue, refer to Memory Optimization Journey for a SwiftUI + Core Data App.

With this approach, we can effectively control memory usage, particularly when large amounts of data or resources are loaded by lazy views, ensuring the application's performance and responsiveness.

Some readers might consider using the feature of lazy containers, which only retains the top-level state, to address memory usage issues. Unfortunately, for these specific types, even if the state is "forgotten," the memory they occupy is not released promptly. Therefore, this method is not suitable for resolving the issue of memory not being actively released for certain types.

Conclusion

A Deep Dive Into Observation: A New Way to Boost SwiftUI Performance

Fatbobman( 东坡肘子 ) — Thu, 29 Feb 2024 23:26:25 +0000

At WWDC 2023, Apple introduced a new member of the Swift standard library - the Observation framework. Its appearance is expected to alleviate the long-standing issue of unnecessary updates to SwiftUI views for developers. This article will comprehensively and thoroughly explore the Observation framework in a Q&A format, including its reasons for creation, usage methods, workings, and precautions.

Why create the Observation framework

Before Swift 5.9, Apple did not provide developers with a unified and efficient mechanism for observing changes to reference type properties. KVO is limited to use by NSObject subclasses, Combine cannot provide precise observation at the property level, and neither can achieve cross-platform support.

In addition, in SwiftUI, the source of truth for reference type data sources is implemented using the ObservableObject protocol based on the Combine framework. This leads to a large number of unnecessary view refreshes in SwiftUI, which affects the performance of SwiftUI applications.

To address these limitations, the Observation framework was introduced in Swift 5.9. Compared to existing KVO and Combine, it has the following advantages:

It is applicable to all Swift reference types, not just NSObject subclasses, and provides cross-platform support.
Provides precise observation at the property level without the need for special annotations on observable properties.
Reduces unnecessary view updates in SwiftUI and improves application performance.

How to Declare an Observable Object

Using the Combine framework, we can declare an observable reference type as follows:

class Store: ObservableObject {
    @Published var firstName: String
    @Published var lastName: String
    var fullName: String {
        firstName + " " + lastName
    }

    @Published private var count: Int = 0

    init(firstName: String, lastName: String, count: Int) {
        self.firstName = firstName
        self.lastName = lastName
        self.count = count
    }
}

When the firstName, lastName, and count of the instance change, @Published will send notifications through objectWillChange(ObjectWillChangePublisher) to inform all subscribers that the current instance is about to change.

Using the Observation framework, we will use a completely different declaration:

@Observable
class Store {
    var firstName: String = "Yang"
    var lastName: String = "Xu"
    var fullName: String {
        firstName + " " + lastName
    }

    private var count: Int = 0

        init(firstName: String, lastName: String, count: Int) {
        self.firstName = firstName
        self.lastName = lastName
        self.count = count
    }
}

Add @Observalbe annotation before the class declaration, and there is no need to specify that the Store type should comply with a certain protocol.
There is no need to use @Published to annotate properties that can trigger notifications. Any stored property that is not specifically annotated can be observed.
Computed properties can be observed (in the example, fullName can also be observed).
For properties that do not want to be observed, they need to be annotated with @ObservationIgnored in front of them.

// count cannot be observed
@ObservationIgnored
private var count: Int = 0

All properties must have literal default values, even if a custom init method is provided.

Compared to the Combine-based declaration, Observation makes the declaration of observable objects more concise and intuitive, while also providing support for observing computed properties.

What did @Observable do

Unlike other common keywords that start with @ (such as the @Published property wrapper and @available conditional compilation), @Observable here represents a macro.

Macros are a new feature added in Swift 5.9. They allow developers to manipulate and process Swift code at compile time. Developers can provide a macro definition that will execute during compilation and modify, add, or remove code from the source code.

In Xcode 15, right-click on @Observable and select "Expand Macro" to see the code generated by the @Observable macro:

@Observable
class Store {
    @ObservationTracked
    var firstName: String = "Yang" {
        get {
            access(keyPath: \.firstName)
            return _firstName
        }

        set {
            withMutation(keyPath: \.firstName) {
                _firstName = newValue
            }
        }
    }

    @ObservationTracked // This code can also be expanded here.
    var lastName: String = "Xu"
    var fullName: String {
        firstName + " " + lastName
    }

    @ObservationIgnored
    private var count: Int = 0

    init(firstName: String, lastName: String, count: Int) {
        self.firstName = firstName
        self.lastName = lastName
        self.count = count
    }

    @ObservationIgnored private let _$observationRegistrar = ObservationRegistrar()

    internal nonisolated func access<Member>(
        keyPath: KeyPath<Store, Member>
    ) {
        _$observationRegistrar.access(self, keyPath: keyPath)
    }

    internal nonisolated func withMutation<Member, T>(
        keyPath: KeyPath<Store, Member>,
        _ mutation: () throws -> T
    ) rethrows -> T {
        try _$observationRegistrar.withMutation(of: self, keyPath: keyPath, mutation)
    }

    @ObservationIgnored private var _firstName: String = "Yang"

    @ObservationIgnored private var _lastName: String = "Xu"
}

extension Store: Observable {}

As can be seen, the Observable macro adjusts our original declaration. In the Store, an ObservationRegistrar structure is declared to maintain and manage the relationship between observable properties and observers. Stored properties are rewritten as computed properties, and the original value is saved in a version with the same name but with the _ prefix. In the get and set methods, observers are registered and notified through _$observationRegistrar. Finally, the macro adds code to make the observable object conform to the Observable protocol (similar to Sendable, it does not provide any implementation, but serves only as an identifier).

How to Use Observable Objects in Views

Declaring Observable Objects in Views

Unlike a Source of Truth that conforms to the ObservableObject protocol, we use @State in views to ensure the lifecycle of observable objects.

@Observable
class Store {
   ....
}

struct ContentView: View {
    @State var store = Store()
    var body: some View {
       ...
    }
}

Injecting Observable Objects into the View Hierarchy Using Environment

Compared to the Source of Truth that adheres to the ObservableObject protocol, Observable Objects declared using the Observation framework have more diverse and flexible options for environment injection.

Injecting instances through environment

@Observable
class Store {
   ....
}

struct ObservationTest: App {
    @State var store = Store()
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(store)
        }
    }
}

struct ContentView: View {
    @Environment(Store.self) var store // Inject through environment in view
    var body: some View {
       ...
    }
}

Customize EnvironmentKey

struct StoreKey: EnvironmentKey {
    static var defaultValue = Store()
}

extension EnvironmentValues {
    var store: Store {
        get { self[StoreKey.self] }
        set { self[StoreKey.self] = newValue }
    }
}

struct ContentView: View {
    @Environment(\.store) var store // Inject through environment in view
    var body: some View {
       ...
    }
}

Inject optional values

struct ObservationTest: App {
    @State var store = Store()
    var body: some Scene {
        WindowGroup {
            ContentView()
                .environment(store)
        }
    }
}

struct ContentView: View {
    @Environment(Store.self) var store:Store? // Inject through environment in view
    var body: some View {
       if let firstName = store?.firstName  {
                Text(firstName)
       }
    }
}

Among them, both custom EnvironmentKey and injection of optional values perfectly solve the problem of Preview crashes caused by forgetting to inject. Especially EnvironmentKey gives developers the ability to provide default values.

Perhaps some people may feel confused why the injection method of observable objects declared using the Observation framework is similar to that of value types, while reference types that comply with the ObservableObject protocol require the use of methods that indicate Object to inject (StateObject, EnvironmentObject). Won't this cause confusion?

It can be expected that in the development of iOS 17+ applications, the scenarios where observable objects declared through the Observation framework and observable objects that comply with the ObservableObject protocol appear simultaneously will become less and less. Therefore, soon, reference types and value types will be highly unified in their injection forms (there will almost never be a scenario where environmentObject or StateObject are used).

Passing Observable Objects in Views

struct ContentView: View {
    @State var store = Store()
    var body: some body {
        SubView(store: store)
    }
}

struct SubView:View {
    let store:Store
    var body: some body {
       ....
    }
}

Both let and var can be used.

Creating a Binding Type

The Binding type provides SwiftUI with the ability to implement two-way data binding. Using the Observation framework, we can create the corresponding Binding type for a property in the following ways.

Method One:

struct ContentView: View {
    @State var store = Store()
    var body: some body {
        SubView(store: store)
    }
}

struct SubView:View {
    @Bindable var store:Store
    var body: some body {
       TextField("",text:$store.name)
    }
}

Method Two:

struct SubView:View {
    var store:Store
    var body: some body {
       @Bindable var store = store
       TextField("",text:$store.name)
    }
}

Method Three：

struct SubView:View {
    var store:Store
    var name:Binding<String>{
        .init(get: { store.name }, set: { store.name = $0 })
    }
    var body: some body {
       TextField("",text:name)
    }
}

Does the Observation framework support older versions of SwiftUI?

Not supported.

How to observe observable objects

The Observation framework provides a global function called withObservationTracking. With this function, developers can track whether the properties of an observable object have changed.

Function signature:

func withObservationTracking<T>(
    _ apply: () -> T,
    onChange: @autoclosure () -> () -> Void
) -> T

Test 1:

@Observable
class Store {
    var a = 10
    var b = 20
    var c = 20
}

let sum = withObservationTracking {
    store.a + store.b
} onChange: {
    print("Store Changed a:\(store.a) b:\(store.b) c:\(store.c)")
}

store.c = 100

// No output

store.b = 100

// Output
// Store Changed a:10 b:20 c:100

store.a = 100

// No output

Test 2:

withObservationTracking {
   print(store)
   DispatchQueue.main.asyncAfter(deadline: .now() + 0.3){
      store.a = 100
   }
} onChange: {
    print("Store Changed")
}

store.b = 100

// No output

store.a = 100

// No output

In the official documentation for withObservationTracking provided by Apple, the function is explained as follows:

apply: A closure that contains properties to track
onChange: The closure invoked when the value of a property changes
Returns: The value that the apply closure returns if it has a return value; otherwise, there is no return value

However, the description is too simple, and there are still some confusing points:

How does withObservationTracking determine which properties in the apply closure can be observed?
Why do some observable properties in the apply closure not trigger callbacks after being modified? (Test 2)
Is the observation behavior created by withObservationTracking disposable or persistent?
When is the onChange closure invoked? Does "when the value of a property changes" mean before or after the property is changed?

Fortunately, the Observation framework is part of the Swift 5.9 standard library. We can learn more information by examining its source code.

What is the observation principle of the Observation framework?

By reading the code, we can understand the process of creating observations with withObservationTracking. I will summarize it as follows:

Creating observation phase

withObservationTracking creates an _AccessList in the current thread's _ThreadLocal.value.
The apply closure is executed.
When the observable property of an observable object is called (triggered by the apply closure), the access method is used to save the correspondence between the observable property and the callback closure in the ObservationRegistrar of the observable object instance (the callback closure here is used to call the onChange closure in withObservationTracking).
withObservationTracking saves the correspondence between the observable property and the onChange callback closure in _AccessList.

When the observed property is about to change

The observed property will call the willSet method in ObservationRegistrar and find the callback closure corresponding to the current property KeyPath.
By calling the closure, the onChange closure is called in the thread initiated by withObservationTracking.
After the onChange closure is called, the information corresponding to the _AccessList in the current thread of withObservationTracking is cleared.
Clear the correspondence between the properties and the callback closures related to this observation operation in ObservationRegistrar.

Conclusion

By sorting out, we can get the following conclusions:

Only observable properties that are read (by calling their get method) in the apply closure will be observed (which explains the issue in test 2).
The observation operation created by withObservationTracking is a one-time behavior. Any observable property changes will end this observation after calling the onChange function.
The onChange closure is called before the property value changes (in the willSet method).
Multiple observable properties can be observed in one observation operation. Any property value changes will end this observation.
The observation behavior is thread-safe. withObservationTracking can run in another thread, and the onChange closure will run in the thread initiated by withObservationTracking.
Only observable properties can be observed. Observable objects that only appear in the apply closure will not create observation operations (which explains test 2).

Currently, the Observation framework does not provide an API for creating continuous observation behavior. Perhaps this part of the function will be added in later versions.

How to observe property changes in SwiftUI views

Based on the workings of the Observation framework, we can speculate that SwiftUI probably creates a connection between observable properties and view updates using the following methods:

struct A:View {
   var body: some View {
       ...
   }
}

let bodyValue = withObservationTracking {
    viewA.body
} onChange: {
    PreparingToRe-evaluateTheBodyValue()
}

As summarized in the previous text, we concluded that "only observable properties that are read within the apply closure (by calling their get method) will be observed." Therefore, we can draw the following conclusion:

Text(store.a) // Changes in store.a will trigger a re-evaluation of the body.

Button("Hi"){
    store.b = "abc" // Changes in store.b will not trigger a re-evaluation of the body.
}

Can a class annotated with @Observable still conform to the ObservableObject protocol?

Yes, it can. However, there may be conflicts between the @Published property wrapper and the @Observable macro. To resolve this, we can use withObservationTracking.


@Observable
final class Store: ObservableObject {
    var name = ""
    var age = 0

    init(name: String = "", age: Int = 0) {
        self.name = name
        self.age = age
        observeProperties()
    }

    private func observeProperties() {
        withObservationTracking {
            let _ = name
            let _ = age
        } onChange: { [weak self] in
            guard let self else { return }
            objectWillChange.send()
            observeProperties()
        }
    }
}

If necessary, you can use custom macros to complete the repetitive work of introducing all observable properties in the observeProperties method.

Can @Obervable and ObservableObject coexist in a view?

Yes. In a view, observable objects can be declared in different ways and still coexist. SwiftUI will choose the corresponding observation method based on how the observable objects are injected into the view.

For example, in the previous text, we created an observable object that satisfies two observation approaches at the same time. Depending on how it is injected, SwiftUI will adopt different update strategies.

@State var store = Store() // Decide whether to re-evaluate the body finely based on changes in properties.

@StateObject var store = Store() // Whenever the property (@Published) changes, the body will be reevaluated.

Does Observable support nesting (where the property of one Observable is another Observable)?

Support.

Since @Published only supports value types, it is difficult to implement nested logic for observable objects that conform to the ObservableObject protocol:

class A:ObservableObject {
    @Published var b = B()
}

class B:ObserableObject {
    @Published var a = 10
}

let a = A()
a.b.a = 100 // Does not trigger view update

I once wrote a @PublishedObject property wrapper to solve this problem. For more information, please read the article "Going Beyond @Published:Empowering Custom Property Wrappers". In principle, @PublishedObject uses the objectWillChange of the external object A (enclosing instance) to notify A's subscribers when the property of B changes. In other words, a highly coupled approach is used to achieve nesting of observable objects.

However, nesting of observable objects created through the Observation framework is much simpler. When creating an observation operation with withObservationTracking, every observable property that is read will actively create a relationship with the subscriber. It can be correctly tracked regardless of its position in the relationship chain or how it exists (such as arrays, dictionaries, etc.).

For example:

@Observabl
class A {
   var a = 1
   var b = B()
}

@Observable
class B {
   var b = 1
}

let a = A()

withObservationTracking {
   let _ = a.b.b
} onChange: {
    print("update")
}

For the above code, both of the following two methods will invoke the onChange closure (only called once).

a.b.b = 100

// or

a.b = B()

In the line let _ = a.b.b, observations are created for two observable properties from different objects and different levels, a.b and b.b. This is the strength of the Observation framework.

Observation: Has the performance issue of ObservableObject been resolved?

Yes, the Observation framework has improved the performance of observable objects in SwiftUI from two aspects:

By observing observable properties in views instead of observable objects, a lot of unnecessary view updates can be reduced.
Compared to the publisher-subscriber model of Combine, the callback mechanism of Observation is more efficient.

However, because the Observation framework does not yet support creating sustainable observation behaviors, views need to recreate observation operations every time they are evaluated. We need more time to evaluate whether this will cause new performance issues.

Will the Observation framework affect SwiftUI programming habits?

For me, yes.

For example, currently, developers usually use structs to build the state model of the application. After using the Observation framework, in order to implement property-level observation, we should use the Observation framework to create observable objects, and even build the state model with nested observable objects.

In addition, many of the optimization techniques we used in the views will also change. For example, when using ObservableObject, we will reduce unnecessary refresh by only introducing data that is useful for the current view.

For more optimization techniques for views, please read the article "How to Avoid Repeating SwiftUI View Updates".

class Store:ObservableObject {
    @Published var a = 1
    @Published var b = "hello"
}

struct Root:View {
    @StateObject var store = Store()
    var body: some View {
        VStack{
            A(a: store.a)
            B(b: store.b)
        }
    }
}

struct A:View {
    let a:Int    // only get a(Int)
    var body:some View {
        Text("\(store.a)")
    }
}

struct B:View { // only get b(String)
    let b:String
    var body:some View {
        Text(store.b)
    }
}

When store.b changes, only the Root and B views will be re-evaluated.

After switching to the Observation framework, the optimization strategy mentioned above will no longer be the optimal solution. Instead, the previously discouraged method is more suitable for the new observable objects.

@Observabl
class Store {
    var a = 1
    var b = "hello"
}

struct Root:View {
    @State var store = Store()
    var body: some View {
        VStack{
            A(store: store)
            B(store: store)
        }
    }
}

struct A:View {
    let store: Store
    var body:some View {
        Text("\(store.a)")
    }
}

struct B:View {
    let store: Store
    var body:some View {
        Text(store.b)
    }
}

Only properties that appear in the body and are read will trigger a view update. After modification, only the B view will be re-evaluated when store.b changes.

As the Observation framework is still a new thing, its API is also constantly evolving. As more and more SwiftUI applications are converted to this framework, developers will summarize more experience of use.

Conclusion

Through the discussion in this article, readers should have gained a better understanding of the Observation framework and how it can improve the performance of SwiftUI. Although the Observation framework is currently tightly integrated with SwiftUI, with the enrichment of its API, it is believed that it will appear in more and more application scenarios, not just limited to SwiftUI.

GeometryReader: Blessing or Curse?

Fatbobman( 东坡肘子 ) — Wed, 28 Feb 2024 22:58:56 +0000

GeometryReader has been present since the birth of SwiftUI, playing a crucial role in many scenarios. However, from the very beginning, some developers have held a negative attitude towards it, believing it should be avoided as much as possible. Especially after the recent updates of SwiftUI added some APIs that can replace GeometryReader, this view has further strengthened. This article will dissect the "common problems" of GeometryReader to see if it is really so unbearable, and whether those performances criticized as "not meeting expectations" are actually due to problems with the developers' "expectations" themselves.

Some Criticisms of GeometryReader

The main criticisms developers have towards GeometryReader focus on the following two points:

GeometryReader destroys the layout: This view holds that, since GeometryReader will occupy all available space, it might ruin the overall layout design.
GeometryReader can't get the correct geometry information: This view holds that, in certain situations, GeometryReader may not be able to obtain precise geometry information, or the information it obtains may be unstable when the view doesn't change visually.

In addition, some people believe that:

Over-reliance on GeometryReader can make the view layout rigid, losing the flexibility advantage of SwiftUI.
GeometryReader breaks the concept of SwiftUI's declarative programming, requiring direct operation of the view framework, which is closer to imperative programming.
GeometryReader consumes a lot of resources when updating geometric information, which may cause unnecessary repetitive calculations and view reconstruction.
Using GeometryReader requires a lot of auxiliary code to calculate and adjust the framework, which increases the amount of coding, and reduces the readability and maintainability of the code.

These criticisms are not entirely unreasonable, and a considerable part of them has been improved or resolved through the new API in the SwiftUI version update. However, the view that GeometryReader disrupts the layout and cannot obtain correct information is usually caused by the developer's insufficient understanding and improper use of GeometryReader. Next, we will analyze and discuss these views.

Before publishing this article, I posted a tweet asking for everyone's opinion on GeometryReader. Based on the responses, there seems to be a higher proportion of negative impressions towards it.

Difficult to use, try to avoid 28.8%, Very useful 9.3%, Love-hate relationship 34.7%, What is GeometryReader? 27.1%

What is GeometryReader?

Before we delve into the negative views mentioned above, we first need to understand the function of GeometryReader and the reason for designing this API.

This is Apple's official documentation for GeometryReader:

A container view that defines its content as a function of its own size and coordinate space.

Strictly speaking, I don't fully agree with the above description. This is not because there are factual errors, but because this statement may lead to user misunderstanding. In fact, the name "GeometryReader" is more in line with its design goal: a geometry information reader.

To be precise, the main function of GeometryReader is to obtain the size, frame and other geometric information of the parent view. The phrase "defines its content" in the official document is likely to make people mistakenly think that the main function of GeometryReader is to actively influence the subview, or that the geometric information it obtains is mainly used for the subview. However, it should be seen as a tool for obtaining geometric information. Whether this information should be applied to the subview is entirely up to the developer.

Perhaps if it had been designed in the following way from the beginning, misunderstandings and misuse of it could have been avoided.

@State private proxy:GeometryProxy

Text("Hello world")
    .geometryReaer(proxy:$proxy)

If we change to a View Extension-based approach, the role of geometryReader can be described as: It provides the size, frame, and other geometric information of the view it is applied to. It is an effective way for the view to get its own geometric information. This description can effectively prevent the misunderstanding that geometric information is mainly applied to subviews.

As for why not to adopt the Extension approach, the designer might have considered the following two factors:

Passing information upward through Binding is not the primary design method of the current official SwiftUI API.
Passing geometric information to the upper view may cause unnecessary view updates. Passing information downward can ensure that updates only occur in the GeometryReader's closure.

Is GeometryReader a layout container? What is its layout logic?

Yes, but its behavior is somewhat different.

Currently, GeometryReader exists as a layout container, with the following layout rules:

It is a multi-view container, with its default stacking rules similar to ZStack
It returns the parent view's proposed size as its own required size to the parent view
It passes the parent view's proposed size as its own proposed size to the child view
It places the child view's origin (0,0) at the origin of the GeometryReader
Its ideal size (Ideal Size) is (10,10)

If you ignore the function to get geometric information, the layout behavior of a GeometryReader is very close to the following code.

GeometryReader { _ in
  Rectangle().frame(width:50, height:50)
  Text("abc").foregroundStyle(.white)
}

It is basically equivalent to the following code:

ZStack(alignment: .topLeading) {
    Rectangle().frame(width: 50, height: 50)
    Text("abc").foregroundStyle(.white)
}
.frame(
    idealWidth: 10,
    maxWidth: .infinity,
    idealHeight: 10,
    maxHeight: .infinity,
    alignment: .topLeading
)

Simply put, GeometryReader will occupy all the space provided by the parent view, and aligns the origin of all child views with the origin of the container (i.e., placed in the upper left corner). This unconventional layout logic is one of the reasons why I do not recommend using it directly as a layout container.

GeometryReader does not support the adjustment of alignment guides, so the above description uses the origin.

However, this does not mean that GeometryReader cannot be used as a view container. In some cases, it may be more suitable than other containers. For example:

struct PathView: View {
    var body: some View {
        GeometryReader { proxy in
            Path { path in
                let width = proxy.size.width
                let height = proxy.size.height

                path.move(to: CGPoint(x: width / 2, y: 0))
                path.addLine(to: CGPoint(x: width, y: height))
                path.addLine(to: CGPoint(x: 0, y: height))
                path.closeSubpath()
            }
            .fill(.orange)
        }
    }
}

When drawing a Path, the information provided by GeometryReader (dimensions, origin) perfectly meets our needs. Therefore, for subviews that need to fill the space and align with the origin, GeometryReader is very suitable as a layout container.

GeometryReader completely ignores the request size of the subview. In this respect, it treats subviews in the same way as overlay and background.

In the above description of the layout rules of GeometryReader, we pointed out that its ideal size is (10,10 ). Some readers may not understand its meaning. The ideal size refers to the request size returned by the subview when the parent view's proposed size is nil (unspecified mode). If you don't understand this setting of GeometryReader, in some scenarios, developers may feel that GeometryReader does not fill all the space as expected.

For example, if you execute the following code, you can only get a rectangle with a height of 10:

struct GeometryReaderInScrollView: View {
    var body: some View {
        ScrollView {
            GeometryReader { _ in
                Rectangle().foregroundStyle(.orange)
            }
        }
    }
}

This is because ScrollView's logic in proposing sizes to child views is different from most layout containers. In the non-scrolling direction, ScrollView provides all available sizes on that dimension to the child view. However, in the scrolling direction, the proposed size it provides to the child view is nil. Since the ideal size of the GeometryReader is (10,10), the required size it returns to ScrollView in the scroll direction is 10. At this point, the behavior of GeometryReader is consistent with Rectangle. Therefore, some developers might think that GeometryReader does not fill up all the available space as expected. But in fact, its display result is completely correct, this is the correct layout result.

Therefore, in this situation, we usually only use the size with definite value dimensions (explicit size mode, proposed size has values) to calculate the size of another dimension.

For example, if we want to display pictures in ScrollView at a ratio of 16:9 (even if the ratio of the picture itself does not conform to this):

struct GeometryReaderInScrollView: View {
    var body: some View {
        ScrollView {
            ImageContainer(imageName: "pic")
        }
    }
}

struct ImageContainer: View {
    let imageName: String
    @State private var width: CGFloat = .zero
    var body: some View {
        GeometryReader { proxy in
            Image("pic")
                .resizable()
                .aspectRatio(contentMode: .fill)
                .onAppear {
                    width = proxy.size.width
                }
        }
        .frame(height: width / 1.77)
        .clipped()
    }
}

First, we use GeometryReader to get the proposed width provided by ScrollView and calculate the required height based on this width. Then, we adjust the required size height that GeometryReader submits to ScrollView through frame. In this way, we can get the desired display result.

In this demonstration, the Image perfectly meets the previous requirement of filling the space and aligning the origin, so it is completely fine to use GeometryReader as a layout container directly.

This section includes a lot of knowledge about the size and layout of SwiftUI. If you are not very familiar with this, I suggest you continue to read the following articles: SwiftUI Layout: The Mystery of Size, SwiftUI Layout: The Mystery of Size, Alignment in SwiftUI: Everything You Need to Know.

Why can't GeometryReader get the correct information?

Some developers might complain that GeometryReader cannot obtain the correct size (always returns 0,0), or returns an abnormal size (such as negative numbers), leading to layout errors.

For this, we first need to understand the layout principles of SwiftUI.

SwiftUI's layout is a negotiation process. The parent view provides a proposed size to the child view, and the child view returns a required size. Whether the parent view places the child view based on its required size, or the child view returns a required size based on the proposed size provided by the parent view, depends entirely on the predefined rules of the parent and child views. For example, for VStack, it sends information about explicit, unspecified, maximum, and minimum proposed sizes in the vertical dimension to its child views and obtains the required sizes of the child views at different proposed sizes. VStack combines the priority of the views and the proposed size given by its parent view to provide a final proposed size to the child views during layout.

In some complex layout scenarios, or in certain devices or system versions, the layout may require multiple rounds of negotiation to achieve a stable result, especially when views need to rely on the geometry information provided by GeometryReader to re-determine their position and size. Therefore, this may cause GeometryReader to continuously send new geometry information to the child views until a stable result is obtained. If we still use the information retrieval method in the previous code, we won't be able to obtain the updated information.

.onAppear {
    width = proxy.size.width
}

Therefore, the correct way to obtain information is:

.task(id: proxy.size.width) {
    width = proxy.size.width
}

In this way, even if the data changes, we can keep updating the data. Some developers have reported that they are unable to retrieve new information when the screen orientation changes. This is why. task(id:) covers both onAppear and onChange scenarios and is the most reliable way to get data.

Also, in some cases, GeometryReader may return negative dimensions. If these negative numbers are directly passed to frame, it may result in layout abnormalities (Xcode will warn developers in purple during debugging). Therefore, to further avoid this extreme situation, you can filter out the data that does not meet the requirements when passing the data.

.task(id: proxy.size.width) {
    width = max(proxy.size.width, 0)
}

Since GeometryProxy does not conform to the Equatable protocol, and in order to minimize the re-evaluation of views caused by information updates, developers should only pass the currently needed information.

As for how to pass the obtained geometric information (for example, the @State used in the above or through PreferenceKey), it depends on the developer's programming habits and scene requirements.

Usually, we use GeometryReader + Color.clear in overlay or background to obtain and pass geometric information. This not only ensures the accuracy of information acquisition (size, position is completely consistent with the view to be obtained), but also does not cause additional visual impact.

extension View {
    func getWidth(_ width: Binding<CGFloat>) -> some View {
        modifier(GetWidthModifier(width: width))
    }
}

struct GetWidthModifier: ViewModifier {
    @Binding var width: CGFloat
    func body(content: Content) -> some View {
        content
            .background(
                GeometryReader { proxy in
                    let proxyWidth = proxy.size.width
                    Color.clear
                        .task(id: proxy.size.width) {
                            $width.wrappedValue = max(proxyWidth, 0)
                        }
                }
            )
    }
}

Note: If you want to pass information through PreferenceKey, it's best to do it in overlay. Because in some system versions, data passed from background cannot be obtained by onPreferenceChange.

struct GetInfoByPreferenceKey: View {
    var body: some View {
        ScrollView {
            Text("Hello world")
                .overlay(
                    GeometryReader { proxy in
                        Color.clear
                            .preference(key: MinYKey.self, value: proxy.frame(in: .global).minY)
                    }
                )
        }
        .onPreferenceChange(MinYKey.self) { value in
            print(value)
        }
    }
}

struct MinYKey: PreferenceKey {
    static func reduce(value: inout CGFloat, nextValue: () -> CGFloat) {
        value = nextValue()
    }
    static var defaultValue: CGFloat = .zero
}

In some cases, the values obtained through GeometryReader may cause you to fall into an endless loop, resulting in unstable views and performance losses, for example:

struct GetSize: View {
    @State var width: CGFloat = .zero
    var body: some View {
        VStack {
            Text("Width = \(width)")
                .getWidth($width)
        }
    }
}

Strictly speaking, the root of this problem lies in Text. Since the default font width is not fixed, it can't form a stable dimension negotiation result. The solution is simple, it can be solved by adding .monospaced() or using a fixed-width font.

Text("Width = \(width)")
    .monospaced()
    .getWidth($width)

The example of character jitter comes from the article Safely Updating The View State on SwiftUI-Lab.

Performance issues with GeometryReader

Understanding when the GeometryReader gets geometric information can help you understand its impact on performance. As a view, GeometryReader can only pass the acquired data to the code in the closure after it has been evaluated, laid out, and rendered. This means that if we need to use the information it provides to adjust the layout, we must first complete at least one round of evaluation, layout, and rendering processes, then acquire the data, and adjust the layout based on these data. This process will cause the view to be re-evaluated and laid out multiple times.

Due to the lack of layout containers such as LazyGrid in early SwiftUI, developers could only implement various custom layouts through GeometryReader. When the number of views is large, this will cause serious performance issues.

Since SwiftUI has supplemented some previously missing layout containers, the large-scale impact of GeometryReader on performance has been alleviated. Especially after allowing custom layout containers that comply with the Layout protocol, the above problems have been basically solved. Unlike GeometryReader, layout containers that meet the layout protocol can obtain the proposed size of the parent view and the required size of all subviews at the layout stage. This can avoid a large number of view updates caused by the repeated transmission of geometric data.

However, this does not mean that there are no precautions when using GeometryReader. In order to further reduce the impact of GeometryReader on performance, we need to pay attention to the following two points:

Only let a few views be affected by the changes in geometric information
Only pass the required geometric information

The above two points are in line with our consistent principle of optimizing the performance of SwiftUI views, that is, controlling the scope of the impact of state changes.

Layout in the SwiftUI way

Due to the negative views on GeometryReader, some developers try to find other ways to avoid using it. However, have you ever thought that in many scenarios, GeometryReader is not the best solution. Instead of avoiding it, why not use a more SwiftUI way to layout.

GeometryReader is often used in scenarios where the ratio needs to be limited, such as making the view occupy 25% of the available space, or calculating the height based on the given aspect ratio as mentioned above. When dealing with similar requirements, we should prioritize thinking about layout solutions in a way that aligns with SwiftUI's mindset, rather than relying on specific geometric data for calculations.

For example, we can use the following code to meet the requirement of limiting the aspect ratio of the image mentioned above:

struct ImageContainer2: View {
    let imageName: String
    var body: some View {
        Color.clear
            .aspectRatio(1.77, contentMode: .fill)
            .overlay(alignment: .topLeading) {
                Image(imageName)
                    .resizable()
                    .aspectRatio(contentMode: .fill)
            }
            .clipped()
    }
}

struct GeometryReaderInScrollView: View {
    var body: some View {
        ScrollView {
            ImageContainer2(imageName: "pic")
        }
    }
}

Create a base view that meets the aspect ratio through aspectRatio, and then place the Image in the overlay. In addition, because overlay supports setting alignment guides, it can adjust the alignment of the image more conveniently than GeometryReader.

In addition, GeometryReader is often used to allocate space for two views in a certain proportion. For such requirements, there are also other methods to handle it. The following code implements the allocation of 40% and 60% width (the height depends on the tallest subview):

struct FortyPercent: View {
    var body: some View {
        Grid(horizontalSpacing: 0, verticalSpacing: 0) {
            // placeholder
            GridRow {
                ForEach(0 ..< 5) { _ in
                    Color.clear.frame(maxHeight: 0)
                }
            }
            GridRow {
                Image("pic")
                    .resizable()
                    .aspectRatio(contentMode: .fit)
                    .gridCellColumns(2)
                Text("Fatbobman's Swift Weekly").font(.title)
                    .gridCellColumns(3)
            }
        }
        .border(.blue)
        .padding()
    }
}

However, in terms of simply placing two views in a specific space according to a certain proportion (ignoring the size of the subviews), GeometryReader is still one of the best solutions (the overall height of the Grid solution is determined by the subviews).

struct RatioSplitHStack<L, R>: View where L: View, R: View {
    let leftWidthRatio: CGFloat
    let leftContent: L
    let rightContent: R
    init(leftWidthRatio: CGFloat, @ViewBuilder leftContent: @escaping () -> L, @ViewBuilder rightContent: @escaping () -> R) {
        self.leftWidthRatio = leftWidthRatio
        self.leftContent = leftContent()
        self.rightContent = rightContent()
    }

    var body: some View {
        GeometryReader { proxy in
            HStack(spacing: 0) {
                Color.clear
                    .frame(width: proxy.size.width * leftWidthRatio)
                    .overlay(leftContent)
                Color.clear
                    .overlay(rightContent)
            }
        }
    }
}

struct SplitHStackDemo: View {
    var body: some View {
        RatioSplitHStack(leftWidthRatio: 0.25) {
            Rectangle().fill(.red)
        } rightContent: {
            Color.clear
                .overlay(
                    Text("Hello World")
                )
        }
        .border(.blue)
        .frame(width: 300, height: 60)
    }
}

This chapter is not implying that developers should avoid using GeometryReader, but is reminding developers that SwiftUI has many other layout methods.

Please read the articles Layout in SwiftUI Way and Several Ways to Center Views in SwiftUI to understand that SwiftUI has multiple layout methods for the same requirement.

Appearance and Essence: The size may not be the same

In SwiftUI, some modifiers are adjustments made to the view at the rendering level after layout. In the article SwiftUI Layout — Cracking the Size Code, we have discussed the issue of the "Appearance and Essence" of dimensions. For example, the following code:

struct SizeView: View {
    var body: some View {
        Rectangle()
            .fill(Color.orange.gradient)
            .frame(width: 100, height: 100)
            .scaleEffect(2.2)
    }
}

During layout, the required size for Rectangle is 100 x 100, but at the rendering stage, after being processed by scaleEffect, it will eventually present a 220 x 220 rectangle. Since scaleEffect is adjusted after the layout, even if you create a layout container that complies with the Layout protocol, you cannot know its rendering size. In this case, GeometryReader plays its role.

struct SizeView: View {
    var body: some View {
        Rectangle()
            .fill(Color.orange.gradient)
            .frame(width: 100, height: 100)
            .printViewSize()
            .scaleEffect(2.2)
    }
}

extension View {
    func printViewSize() -> some View {
        background(
            GeometryReader { proxy in
                let layoutSize = proxy.size
                let renderSize = proxy.frame(in: .global).size
                Color.clear
                    .task(id: layoutSize) {
                        print("Layout Size:", layoutSize)
                    }
                    .task(id: renderSize) {
                        print("Render Size:", renderSize)
                    }
            }
        )
    }
}

// OUTPUT：
Layout Size: (100.0, 100.0)
Render Size: (220.0, 220.0)

The size property of GeometryProxy returns the layout size of the view, whereas the frame.size returns the rendered size of the view.

visualEffect: You can obtain geometric information without using GeometryReader

Considering that developers often need to get GeometryProxy of local views, and it's too cumbersome to continuously encapsulate GeometryReader, therefore, in WWDC 2023, Apple added a new modifier to SwiftUI: visualEffect.

visualEffect allows developers to directly use the GeometryProxy of the view in the closure without disrupting the current layout (without changing its ancestors and descendants) and apply some specific modifier to the view.

var body: some View {
    ContentRow()
        .visualEffect { content, geometryProxy in
            content.offset(x: geometryProxy.frame(in: .global).origin.y)
        }
}

visualEffect only allows modifiers that comply with the VisualEffect protocol to be used within the closure, ensuring safety and effect. Simply put, SwiftUI makes modifiers that only act on the "appearance" (rendering level) comply with the VisualEffect protocol and prohibits the use of all modifiers that can affect the layout (for example: frame, padding, etc.) in closures.

We can create a rough imitation version of visualEffect (without limiting the types of modifiers that can be used) with the following code:

public extension View {
    func myVisualEffect(@ViewBuilder _ effect: @escaping @Sendable (AnyView, GeometryProxy) -> some View) -> some View {
        modifier(MyVisualEffect(effect: effect))
    }
}

public struct MyVisualEffect<Output: View>: ViewModifier {
    private let effect: (AnyView, GeometryProxy) -> Output
    public init(effect: @escaping (AnyView, GeometryProxy) -> Output) {
        self.effect = effect
    }

    public func body(content: Content) -> some View {
        content
            .modifier(GeometryProxyWrapper())
            .hidden()
            .overlayPreferenceValue(ProxyKey.self) { proxy in
                if let proxy {
                    effect(AnyView(content), proxy)
                }
            }
    }
}

struct GeometryProxyWrapper: ViewModifier {
    func body(content: Content) -> some View {
        content
            .overlay(
                GeometryReader { proxy in
                    Color.clear
                        .preference(key: ProxyKey.self, value: proxy)
                }
            )
    }
}

struct ProxyKey: PreferenceKey {
    static var defaultValue: GeometryProxy?
    static func reduce(value: inout GeometryProxy?, nextValue: () -> GeometryProxy?) {
        value = nextValue()
    }
}

Compare with visualEffect:

struct EffectTest: View {
    var body: some View {
        HStack {
            Text("Hello")
                .font(.title)
                .border(.gray)

            Text("Hello")
                .font(.title)
                .visualEffect { content, proxy in
                    content
                        .offset(x: proxy.size.width / 2.0, y: proxy.size.height / 2.0)
                        .scaleEffect(0.5)
                }
                .border(.gray)
                .foregroundStyle(.red)

            Text("Hello")
                .font(.title)
                .myVisualEffect { content, proxy in
                    content
                        .offset(x: proxy.size.width / 2.0, y: proxy.size.height / 2.0)
                        .scaleEffect(0.5)
                }
                .border(.gray)
                .foregroundStyle(.red)
        }
    }
}

Summary

With the continuous improvement of SwiftUI features, the direct use of GeometryReader may become less and less. However, without a doubt, GeometryReader is still an important tool in SwiftUI. Developers need to correctly apply it to the appropriate scene.

Concurrent Programming in SwiftData

Fatbobman( 东坡肘子 ) — Sun, 25 Feb 2024 16:00:00 +0000

Concurrent programming in Core Data may not be difficult, but it is full of traps. Even with ample experience in Core Data, a slight negligence can introduce vulnerabilities into the code, making the application unsafe. As the successor to Core Data, SwiftData provides a more elegant and secure mechanism for concurrent programming. This article will introduce how SwiftData addresses these issues and offers developers a better experience with concurrent programming.

The content of this article will make use of concurrency features like async/await, Task, and Actor in Swift. Readers are expected to have some experience with Swift concurrency programming.

Using Serial Queues to Avoid Data Race

We often say that managed object instances (NSManagedObject) and managed object contexts (NSManagedObjectContext) in Core Data are not thread-safe. So why do unsafe problems occur? How does Core Data solve this problem?

Actually, the main point of insecurity lies in data race (simultaneous modification of the same data in a multi-threaded environment). Core Data avoids data race issues by operating on managed object instances and managed object context instances in a serial queue. This is why we need to place the operation code within the closures of perform or performAndWait.

For the view context and the managed object instances registered within it, developers should perform operations on the main thread queue. Similarly, for private contexts and the managed objects registered within them, we should perform operations on the serial queue created by the private context. The perform method will ensure that all operations are performed on the correct queue.

Read the article Several Tips on Core Data Concurrency Programming to learn in detail about different types of managed object contexts, serial queues, the usage of perform, and other considerations for concurrency programming in Core Data.

In theory, as long as we strictly adhere to the aforementioned requirements, we can avoid most concurrency issues in Core Data. Therefore, developers often write code similar to the following:

func updateItem(_ item: Item, timestamp: Date?) async throws {
    guard let context = item.managedObjectContext else { throw MyError.noContext }
    try await context.perform {
        item.timestamp = timestamp
        try context.save()
    }
}

When there are a lot of perform methods in the code, it reduces the code's readability. This is also a problem that many developers complain about.

Don’t miss out on the latest updates and excellent articles about Swift, SwiftUI, Core Data, and SwiftData. Subscribe to Fatbobman’s Swift Weekly and receive weekly insights and valuable content directly to your inbox.

How to create a ModelContext using a private queue?

In Core Data, developers can use a very explicit way to create different types of managed object contexts:

// view context - main queue concurrency type
let viewContext = container.viewContext
let mainContext = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)

// private context - private queue concurrency type
let privateContext = container.newBackgroundContext()

let privateContext = NSManagedObjectContext(concurrencyType: .privateQueueConcurrencyType)

Even in a private context, operations can be performed directly without the need for explicit creation.

container.performBackgroundTask{ context in
    ...
}

However, SwiftData has made adjustments to the creation logic of ModelContext (a wrapped version of NSManagedObjectContext). The type of the newly created context depends on the queue it is in. In other words, a ModelContext created on the main thread will automatically use the main thread queue (com.apple.main-thread), while a ModelContext created on other threads (non-main threads) will use a private queue.

Task.detached {
    let privateContext = ModelContext(container)
}

Please note that when creating a new task through Task.init, it inherits the execution context of its parent task or actor. This means that the following code will not create a ModelContext that uses a private queue:

// In SwiftUI View
Button("Create New Context"){
    let container = modelContext.container
    Task{
        // Using main queue, not background context
        let privateContext = ModelContext(container)
    }
}

SomeView()
    .task {
        // Using main queue, not background context
        let privateContext = ModelContext(modelContext.container)
    }

This is because in SwiftUI, the body of a view is annotated with @MainActor, so it is recommended to use Task.detached to ensure that the ModelContext is created and used on a non-main thread with a private queue.

In the main thread, the ModelContext created is an independent instance, different from the context instance provided by the mainContext property of the ModelContainer instance. Although they both operate on the main queue, they manage separate sets of registered objects.

Actor: More elegant implementation of serial queue

From version 5.5 onwards, Swift introduced the concept of Actors. Similar to serial queues, they can be used to solve data race issues and ensure data consistency. Compared to running through the perform method on a specific serial queue, Actors provide a more advanced and elegant implementation approach.

Each Actor has an associated serial queue for executing its methods and tasks. This queue is based on GCD, and GCD is responsible for underlying thread management and task scheduling. This ensures that the methods and tasks of the Actor are executed in a serial manner, meaning that only one task can be executed at a time. This guarantees that the internal state and data of the Actor are thread-safe at all times, avoiding issues with concurrent access.

Although in theory it is possible to use Actors to restrict code to the context and operations of managed objects, this approach was not adopted in previous versions of Swift due to the lack of custom Actor executors. Fortunately, Swift 5.9 addresses this shortcoming and allows SwiftData to provide a more elegant concurrent programming experience through Actors.

Custom Actor Executors: This proposal introduces a basic mechanism for customizing Swift Actor executors. By providing instances of executors, Actors can influence the execution location of their tasks while maintaining the mutual exclusivity and isolation guaranteed by the Actor model.

Thanks to the new feature "macros" in Swift, it is very easy to create an Actor in SwiftData that corresponds to a specific serial queue:

@ModelActor
actor DataHandler {}

By adding more data manipulation logic code to the Actor, developers can safely use the instance of the Actor to manipulate data.

extension DataHandler {
    func updateItem(_ item: Item, timestamp: Date) throws {
        item.timestamp = timestamp
        try modelContext.save()
    }

    func newItem(timestamp: Date) throws -> Item {
        let item = Item(timestamp: timestamp)
        modelContext.insert(item)
        try modelContext.save()
        return item
    }
}

You can use the following method to invoke the code mentioned above:

let handler = DataHandler(modelContainer: container)
let item = try await handler.newItem(timestamp: .now)

Afterwards, no matter which thread calls the methods of DataHandler, these operations will be performed in a specific serial queue. Developers no longer have to struggle with writing a lot of code containing perform.

Do you remember the considerations we discussed in the previous section about creating a ModelContext? The same rules apply when creating an instance using the ModelActor macro. The type of serial queue used by the newly created Actor instance depends on the thread that creates it.

Task.detached {
    // Using private queue
    let handler = DataHandler(modelContainer: container)
    let item = try await handler.newItem(timestamp: .now)
}

The Secret of the ModelActor Macro

ModelActor, what magic does it possess? And how does SwiftData ensure that the execution sequence of the Actor remains consistent with the serial queue used by ModelContext?

By expanding the ModelActor macro in Xcode, we can see the generated complete code:

actor DataHandler {
    nonisolated let modelExecutor: any SwiftData.ModelExecutor
    nonisolated let modelContainer: SwiftData.ModelContainer
    init(modelContainer: SwiftData.ModelContainer) {
        let modelContext = ModelContext(modelContainer)
        modelExecutor = DefaultSerialModelExecutor(modelContext: modelContext)
        self.modelContainer = modelContainer
    }
}

extension DataHandler: SwiftData.ModelActor {}

ModelActor Protocol Definition:

// The code below is not generated by ModelActor
public protocol ModelActor : Actor {

    /// The ModelContainer for the ModelActor
    /// The container that manages the app’s schema and model storage configuration
    nonisolated var modelContainer: ModelContainer { get }

    /// The executor that coordinates access to the model actor.
    ///
    /// - Important: Don't use the executor to access the model context. Instead, use the
    /// ``context`` property.
    nonisolated var modelExecutor: ModelExecutor { get }

    /// The optimized, unonwned reference to the model actor's executor.
    nonisolated public var unownedExecutor: UnownedSerialExecutor { get }

    /// The context that serializes any code running on the model actor.
    public var modelContext: ModelContext { get }

    /// Returns the model for the specified identifier, downcast to the appropriate class.
    public subscript<T>(id: PersistentIdentifier, as as: T.Type) -> T? where T : PersistentModel { get }
}

Through the code, it can be seen that there are mainly two operations performed during the construction process:

Create a ModelContext instance using the provided ModelContainer.

The thread on which the constructor runs determines the serial queue used by the created ModelContext, which in turn affects the execution queue of the Actor.

Based on the newly created ModelContext, create a DefaultSerialModelExecutor (custom Actor executor).

DefaultSerialModelExecutor is an Actor executor declared by SwiftData. Its main responsibility is to use the serial queue used by the incoming ModelContext instance as the execution queue for the current Actor instance.

In order to determine if the DefaultSerialModelExecutor functions as expected, we can verify it using the following code:

import SwiftDataKit

actor DataHandler {
    nonisolated let modelExecutor: any SwiftData.ModelExecutor
    nonisolated let modelContainer: SwiftData.ModelContainer
    init(modelContainer: SwiftData.ModelContainer) {
        let modelContext = ModelContext(modelContainer)
        modelExecutor = DefaultSerialModelExecutor(modelContext: modelContext)
        self.modelContainer = modelContainer
    }

    func checkQueueInfo() {
        // Get Actor run queue label
        let actorQueueLabel = DispatchQueue.currentLabel
        print("Actor queue:",actorQueueLabel)
        modelContext.managedObjectContext?.perform {
            // Get context queue label
            let contextQueueLabel = DispatchQueue.currentLabel
            print("Context queue:",contextQueueLabel)
        }
    }
}

extension DataHandler: SwiftData.ModelActor {}

// get current dispatch queue label
extension DispatchQueue {
    static var currentLabel: String {
        return String(validatingUTF8: __dispatch_queue_get_label(nil)) ?? "unknown"
    }
}

SwiftDataKit will allow developers to access the Core Data objects underlying SwiftData elements.

In the checkQueueInfo method, we respectively retrieve and print the execution sequence of the current actor and the name of the queue corresponding to the managed object context.

Task.detached {
    // create handler in non-main thread
    let handler = DataHandler(modelContainer: container)
    await handler.checkQueueInfo()
}

// Output
Actor queue: NSManagedObjectContext 0x600003903b50
Context queue: NSManagedObjectContext 0x600003903b50

When creating a DataHandler instance on a non-main thread, the managed object context will create a private serial queue named NSManagedObjectContext + address, and the execution queue of the actor will be the same as it.

Task { @MainActor in
    // create handler in main thread
    let handler = DataHandler(modelContainer: container)
    await handler.checkQueueInfo()
}

// Output
Actor queue: com.apple.main-thread
Context queue: com.apple.main-thread

When creating a DataHandler instance on the main thread, both the managed object context and the actor are on the main thread queue.

Based on the output, it can be seen that the execution queue of the Actor is exactly the same as the queue used by the context, confirming our previous speculation.

SwiftData ensures that operations are executed on the correct queue by using Actors, which can also provide inspiration for Core Data developers. Consider implementing similar functionality in Core Data by using a custom Actor executor.

Accessing Data through PersistentIdentifier

In Core Data's concurrent programming, in addition to performing operations on the correct queue, another important principle is to avoid passing NSManagedObject instances between contexts. This rule also applies to SwiftData.

If you want to operate on the storage data corresponding to a PersistentModel in another ModelContext, you can solve it by passing the PersistentIdentifier of the object. PersistentIdentifier can be seen as the SwiftData implementation of NSManagedObjectId.

The following code will attempt to retrieve and modify the corresponding data by passing in a PersistentIdentifier:

extension DataHandler {
    func updateItem(identifier: PersistentIdentifier, timestamp: Date) throws {
        guard let item = self[identifier, as: Item.self] else {
            throw MyError.objectNotExist
        }
        item.timestamp = timestamp
        try modelContext.save()
    }
}

let handler = DataHandler(container:container)
try await handler.updateItem(identifier: item.id, timestamp: .now )

In the code, we use a subscript method provided by the ModelActor protocol. This method first tries to find the corresponding PersistentModel from the ModelContext held by the current actor. If it doesn't exist, it will attempt to retrieve it from the row cache and persistent storage. You can think of it as the equivalent version of Core Data's existingObject(with:) method. Interestingly, this method that directly accesses the persistent storage is only implemented in the ModelActor protocol. From this perspective, the development team of SwiftData is also consciously guiding developers to use this kind of data operation logic (ModelActor).

Additionally, ModelContext also provides two methods to retrieve PersistentModel through PersistentIdentifier. registeredModel(for:) corresponds to the registeredObject(for:) method in NSManagedObjectContext, while model(for:) corresponds to the object(with:) method in NSManagedObjectContext.

func updateItemInContext(identifier: PersistentIdentifier, timestamp: Date) throws {
    guard let item = modelContext.registeredModel(for: identifier) as Item? else {
        throw MyError.objectNotInContext
    }
    item.timestamp = timestamp
    try modelContext.save()
}

func updateItemInContextAndRowCache(identifier: PersistentIdentifier,timestamp: Date) throws {
    if let item = modelContext.model(for: identifier) as? Item {
        item.timestamp = timestamp
        try modelContext.save()
    }
}

The differences between these three methods are as follows:

existingObject(with:)

If the specified object is detected in the context, this method will return that object. Otherwise, the context will retrieve and return a fully instantiated object from persistent storage. Unlike the object(with:) method, this method will never return an object in a fault state. If the object is neither in the context nor in persistent storage, this method will throw an error. In simple terms, unless the data does not exist on persistent storage, it will always return an object in a non-fault state.

registeredModel(for:)

This method can only return objects that are already registered in the current context (with the same identifier). If the object is not found, it returns nil. When the return value is nil, it does not necessarily mean that the object does not exist in persistent storage, but rather that it is not registered in the current context.

model(for:)

Even if the object is not registered in the current context, this method will still return an empty fault state object - a placeholder object. When the user actually accesses this placeholder object, the context will try to retrieve data from persistent storage. If the data does not exist, it may cause the application to crash.

The Second Line of Defense

Not every developer will strictly follow the expected way of concurrent programming in SwiftData (ModelActor). As the code becomes more complex, there may be accidental access or modification of PersistentModel properties on other queues. Based on the experience with Core Data, such access will inevitably lead to application crashes when the debugging parameter com.apple.CoreData.ConcurrencyDebug 1 is enabled.

For more debugging parameters, please read the article Core Data with CloudKit: Troubleshooting.

But in SwiftData, despite receiving some warning messages (Capture non-sendable), the above operations do not cause any issues and allow normal data access and modification. Why is that?

The following code will modify the properties of an Item object on the main thread from a non-main thread. After clicking the button, the property modification will be successful.

Button("Modify in Wrong Thread") {
    let item = items.first!
    DispatchQueue.global().async {
        print(Thread.current)
        item.timestamp = .now
    }
}

If you have read the previous article Unveiling the Data Modeling Principles of SwiftData, you may remember that it mentioned SwiftData provides Get and Set methods for PersistentModel and BackingData, which not only read and set properties but also have the ability to schedule tasks in a queue (ensuring thread safety). In other words, even if we modify properties on the wrong thread (queue), these methods will automatically switch the operation to the correct queue. Through further experimentation, we discovered that this scheduling ability exists at least at the implementation level of the BackingData protocol.

Button("Modify in Wrong Thread") {
    let item = items.first!
    DispatchQueue.global().async {
        item.persistentBackingData.setValue(forKey: \.timestamp, to: Date.now)
    }
}

This section does not encourage bypassing ModelActor for data operations, but through these details, we can see that the SwiftData team has made a lot of effort to avoid thread safety issues.

Summary

Perhaps some people, like me, upon learning about the new concurrency programming approach in SwiftData, would first feel delighted, followed by an indescribable sensation. After some time of reflection, I seem to have found the reason for this peculiar feeling - code style. Obviously, the data processing logic commonly used in Core Data does not fully apply to SwiftData. So, how can we write code that has a more SwiftData flavor? How can we make the data processing code better align with SwiftUI? These are the topics we will study in the future.

Exploring All Property Wrappers in SwiftUI

Fatbobman( 东坡肘子 ) — Sun, 25 Feb 2024 16:00:00 +0000

In this article, we will explore several property wrappers that are frequently used and crucial in SwiftUI development. This article aims to provide an overview of the main functions and usage considerations of these property wrappers, rather than a detailed usage guide.

The property wrappers in Swift language and the birth of SwiftUI occurred in the same year. SwiftUI fully leverages this feature, offering developers a series of property wrappers that greatly simplify the development process. In this series of four articles, we have thoroughly reviewed all the property wrappers provided by SwiftUI as of iOS 17, aiming to help developers use SwiftUI more efficiently and conveniently. We hope this content provides valuable guidance and assistance when using SwiftUI.

1 @State

@State is one of the most commonly used property wrappers in SwiftUI, primarily used for managing private data within a view. It's particularly suited for storing value-type data such as strings, integers, enums, or struct instances.

@State is used to manage a view's private state.
It's mainly used for storing value-type data (lifespan consistent with the view).

1.1 Typical Use Cases

@State is the ideal choice when a view update is triggered by changes in data within the view.
It's commonly used for simple UI component state management, such as switch states, text input, etc.
If data does not require complex cross-view sharing, @State can simplify state management.

1.2 Considerations

Try to use @State only within the view, and consider it as a private property of the view, even if not explicitly marked as private.
@State provides a two-way data binding pipeline for wrapped data, accessible using the $ prefix.
@State is not suitable for storing large amounts of data or complex data models; in these cases, @StateObject or other state management solutions are more appropriate.
Property wrappers are essentially structs. The @ prefix is used to wrap other data; without @, it represents its own type. For more details, refer to John Sundell and Antoine van der Lee, or read @State Research in SwiftUI.
When assigning values in the constructor, access the raw value of @State using an underscore _ for assignment.

@State var name: String
init(text: String) {
    // Assign to the underscore version, wrapping it with the State type itself
    _name = State(wrappedValue: text)
}

@State variables can only be assigned once in the view's constructor, and subsequent adjustments should be made within the view's body. See How to Avoid Repeating SwiftUI View Updates.
If there's no need to modify the value in the current view or in child views (through @Binding), there's no need to use @State.
In some cases, @State is also used to store non-value types, such as reference types, to ensure their uniqueness and lifespan.

@State var textField: UITextField?
TextField("", text: $text)
    .introspect(.textField, on: .iOS(.v17)) {
        // Holding the UITextField instance
        self.textField = $0
    }

@State in the Observation framework ensures that @Observable instances have a lifespan no shorter than the view itself. For detailed information, see A Deep Dive Into Observation: A New Way to Boost SwiftUI Performance.
@State is thread-safe and can be modified on non-main threads.

@State var text: String = ""
Button("Change") {
    // No need to switch back to the main thread
    Task.detached {
        text = "hi"
    }
}

Don’t miss out on the latest updates and excellent articles about Swift, SwiftUI, Core Data, and SwiftData. Subscribe to Fatbobman’s Swift Weekly and receive weekly insights and valuable content directly to your inbox.

2 @Binding

@Binding is a property wrapper in SwiftUI used for implementing two-way data binding. It creates a two-way connection between a value (like a Bool) and the UI elements that display and modify these values.

@Binding does not hold the data directly but provides a wrapper for read and write access to other data sources.
It allows UI elements to directly modify the data and reflect these changes.

2.1 Typical Use Cases

@Binding is mainly used with UI components that support two-way data binding, such as in combination with TextField, Stepper, Sheet, and Slider.
It is suitable for situations where you need to directly modify the data in a parent view from a child view.

2.2 Considerations

Use @Binding cautiously; it's unnecessary if a child view only needs to respond to data changes without modifying them.
In complex view hierarchies, passing @Binding through multiple levels can make data flow hard to track, in which case other state management methods should be considered.
Ensure the data source for @Binding is reliable, as an incorrect data source can lead to inconsistencies or application crashes. Since @Binding is just a conduit, it doesn’t guarantee that the corresponding data source will exist when called.
Developers can customize Binding by providing get and set methods.

let binding = Binding<String>(
    get: { text },
    // Limit the length of the string
    set: { text = String($0.prefix(10)) }
)

Creating extensions for Binding type can greatly enhance development efficiency and flexibility. For more, read: SwiftUI Binding Extensions.

// Convert a Binding<V?> to a Binding<Bool>
extension Binding {
    static func isPresented<V>(_ value: Binding<V?>) -> Binding<Bool> {
        Binding<Bool>(
            get: { value.wrappedValue != nil },
            set: {
                if !$0 { value.wrappedValue = nil }
            }
        )
    }
}

In the Observation framework, @Bindable can be used to create a corresponding Binding interface for @Observable instances. For details, see A Deep Dive Into Observation: A New Way to Boost SwiftUI Performance.
When declaring constructor parameters, the wrapped value type of Binding (return type of the get method) needs to be explicitly specified, like Binding<String>.
@Binding is not an independent data source. It's merely a reference to already existing data. The view is only updated when the get method reads values that can trigger a view update (like @State, @StateObject), which is crucial for custom Binding.

struct Test: View {
    let a = A()
    var body: some View {
        let binding = Binding<String>(
            get: { a.name },
            set: { a.name = $0 }
        )
        // Although A conforms to the ObservableObject protocol, since it's not associated with the view using StateObject, the Binding created for its properties will also not trigger a view update
        Text(binding.wrappedValue)
        TextField("input:", text: binding)
    }

    class A: ObservableObject {
        @Published var name: String = ""
    }
}

3 @StateObject

@StateObject is a property wrapper in SwiftUI for managing instances of objects conforming to the ObservableObject protocol. It ensures these instances have a lifecycle that is at least as long as the current view's lifecycle.

@StateObject is specifically used for managing instances that conform to the ObservableObject protocol.
The annotated object instance remains unique throughout the entire lifecycle of the view, meaning it won't be recreated even if the view updates.

3.1 Typical Use Cases

@StateObject is typically used at the top of the view hierarchy to create and maintain ObservableObject instances.
It's commonly used for data models or business logic that need to persist throughout the entire lifecycle of the view.
Compared to @State, @StateObject is more suitable for managing complex data models and their associated logic.

3.2 Considerations

The conditions triggering a view update with @StateObject include assigning values to properties marked with @Published (regardless of whether the new value is different from the old) and invoking the objectWillChange publisher.
Use @StateObject only in views that must respond to changes in instance properties. If you only need to read data without observing changes, consider other options.
Introducing @StateObject implies that all related operations occur on the main thread (as SwiftUI implicitly adds @MainActor to the view), including asynchronous operations. Code that needs to run on a non-main thread should be separated from the view code.

struct B: View {
    // Using StateObject is equivalent to adding @MainActor to the current view
    @StateObject var store = Store()
    var body: some View {
        Button("Main Thread") {
            Task.detached {
                await printThreadName()
                // output <_NSMainThread: 0x60000170c000>{number = 1, name = main}
            }
        }
    }

    func printThreadName() async {
        print(Thread.current)
    }
}

If an instance is created in a context where the view's lifespan is guaranteed (such as at the app level), and there is no need to respond to changes in that instance's properties at the current level, @StateObject may not be necessary.

struct DemoApp: App {
    // Since the lifespan of the view at this level is consistent with the application, and if there's no need to respond to changes in 'store', StateObject is not required
    let store = Store()

    var body: some Scene {
        WindowGroup {
            Test()
                .environmentObject(store)
        }
    }
}

4 @ObservedObject

@ObservedObject is a property wrapper in SwiftUI used to create a connection between a view and instances of ObservableObject, mainly for introducing external ObservableObject instances during the view's lifespan.

@ObservedObject does not own the observed instance and does not guarantee its lifespan.
@ObservedObject can switch its associated instance during the view's lifespan.

4.1 Typical Use Cases

Often used in conjunction with @StateObject, where a parent view creates an instance using @StateObject, and a child view introduces this instance through @ObservedObject, responding to changes in the instance.
Suitable for scenarios where dynamic switching of instances is needed. For example, in a NavigationSplitView, selecting different instances in the sidebar dynamically changes the data source in the detail view. For more details, please read StateObject and ObservedObject.

// Define a data model conforming to the ObservableObject protocol
class DataModel: ObservableObject, Identifiable {
    let id = UUID()
}

struct MyView: View {
    @State private var items = [DataModel(), DataModel()]

    var body: some View {
        VStack {
            // Switch the DataModel instance associated with MySubView
            Button("Replace Model") {
                items.reverse()
            }
            MySubView(model: items.first!)
        }
    }
}

// Subview
struct MySubView: View {
    // Introduce an external ObservableObject instance with @ObservedObject
    @ObservedObject var model: DataModel 

    var body: some View {
        VStack {
            // Display the UUID of the current DataModel instance
            // When the 'items' array in MyView changes, the displayed UUID here will update, showcasing the dynamic switching capability of @ObservedObject
            Text(model.id.uuidString)
        }
    }
}

Used in views to introduce ObservableObject instances whose lifespans are ensured by external frameworks or code, such as introducing NSManagedObject instances from Core Data.

4.2 Considerations

In iOS 13, due to the absence of @StateObject, @ObservedObject was the only choice, which could lead to unexpected results due to the inability to guarantee the lifespan of the instance. To avoid such issues, one could hold the instance using @State in a higher-level view (where stability isn't a concern), and then introduce it in the view where it's used via @ObservedObject.
When introducing instances of ObservableObject provided by third parties, it's crucial to ensure that the object referenced by @ObservedObject is available throughout the entire lifespan of the view. Otherwise, it might lead to runtime errors.

5 @EnvironmentObject

@EnvironmentObject is a property wrapper used in SwiftUI to create a connection between the current view and an ObservableObject instance passed down through the environment from a higher-level view. It provides a convenient way to introduce shared data across different view hierarchies without explicitly passing it through each view's constructor.

5.1 Typical Use Cases

Ideal for sharing the same data model across multiple views, such as user settings, themes, or application states.
Suitable for building complex view hierarchies where multiple views need access to the same ObservableObject instance.

5.2 Considerations

Before using @EnvironmentObject, ensure that the corresponding instance has been provided upstream in the view hierarchy (using the .environmentObject modifier). Failure to do so will result in a runtime error.
The conditions that trigger view updates for @EnvironmentObject are the same as those for @StateObject and @ObservedObject.
Like @ObservedObject, @EnvironmentObject supports dynamically switching the associated instance.

struct MyView: View {
    @State private var items = [DataModel(), DataModel()]
    var body: some View {
        VStack {
            Button("Replace Model") {
                // Switch the instance associated with the child view MySubView
                items.reverse()
            }
            MySubView()
                .environmentObject(items.first!)
        }
    }
}

struct MySubView: View {
    @EnvironmentObject var model: DataModel // Dynamically switch associated instance
    var body: some View {
        VStack {
            Text(model.id.uuidString)
        }
    }
}

Only introduce @EnvironmentObject when necessary, as it can trigger unnecessary view updates. Often, multiple views from different levels observe and respond to the same instance, and proper optimization is required to avoid performance degradation in the application. This is a reason why many developers are wary of @EnvironmentObject.
In a view hierarchy, only one instance of the same type of environment object is effective.

@StateObject var a = DataModel()
@StateObject var b = DataModel()

MySubView()
    .environmentObject(a) // The one closer to the view is effective
    .environmentObject(b)

6 @Environment

@Environment is a property wrapper used by views to read, respond to, and invoke specific values from the environment. It allows views to access data, instances, or methods provided by SwiftUI or the app environment.

6.1 Typical Use Cases

When needing to access and respond to environment values provided by the system or higher-level views, such as interface style (dark/light mode), device orientation, or font size (typically corresponding to value types).
When accessing and invoking SwiftUI's ModelContext (corresponding to reference types).
When using methods provided by the system, such as dismiss or openURL (encapsulated via the struct's callAsFunction method).

6.2 Considerations

Compared to the complex logic handled by instances provided by @EnvironmentObject, data introduced by @Environment typically has more specific functionality.
Developers can create custom environment values by defining a custom EnvironmentKey. Like system-provided environment values, they can define various types (value types, Bindings, reference types, methods). For more details, see Custom SwiftUI Environment Values Cheatsheet.

public struct ContainerEnvironmentKey: EnvironmentKey {
    // Default value for the example environment key
    public static var defaultValue = ContainerEnvironment(containerName: "Default")
}

public extension EnvironmentValues {
    var overlayContainer: ContainerEnvironment {
        get { self[ContainerEnvironmentKey.self] }
        set { self[ContainerEnvironmentKey.self] = newValue }
    }
}

In SwiftUI, the definition style similar to EnvironmentKey is used in many ways. Once mastered, it's easy to grasp others, such as PreferenceKey (for child-to-parent view communication), FocusedValueKey (for values based on focus), and LayoutValueKey (for child-to-layout container communication).
Due to the presence of default values, @Environment won't cause an app crash due to missing values, but this can also lead to developers forgetting to inject values.
Unlike @EnvironmentObject, lower-level views cannot modify the EnvironmentValue values passed down from ancestor views.
Multiple properties of the same type but with different names can be created in EnvironmentValue by defining different EnvironmentKeys.

Summary

@StateObject, @ObservedObject, and @EnvironmentObject are specifically used for associating instances that conform to the ObservableObject protocol.
While @StateObject can sometimes replace @ObservedObject and offer similar functionality, they each have unique use cases. @StateObject is typically used for creating and maintaining instances, whereas @ObservedObject is for introducing and responding to already existing instances.
In environments with iOS 17+ where applications primarily rely on the Observation and SwiftData frameworks, the use of these three property wrappers might be relatively less frequent.
@State and @Environment are not limited to storing value types but can also be used for other types.
@Environment provides a relatively safer method to introduce environmental data because it can offer default values through EnvironmentValue. This reduces the risk of application crashes due to missing data injections.
In the context of the Observation framework, @State and @Environment become the primary property wrappers. Whether it's value types or @Observable instances, both can be introduced into views through these wrappers.
Custom Bindings offer great flexibility, allowing developers to implement complex logic between data sources and UI components that depend on Bindings with concise code.

Each property wrapper has its unique use cases and advantages. Choosing the right tool is crucial for building efficient and maintainable SwiftUI applications. As often mentioned in software development, no single tool is a panacea, but using them appropriately can greatly enhance our development efficiency and application quality.