
## Part 2: Behind the Scene of ObservableObject and MVVM Implementation

### Behind the Scene of **ObservableObject**

#### Construction and Internal Mechanism

**ObservableObject** is a protocol in the Combine framework that allows reference types to work with SwiftUI's reactive data binding system. When a class conforms to **ObservableObject**, Combine automatically creates an **objectWillChange** publisher. This publisher notifies subscribers just before any property marked with **@Published** changes. The publisher, called **ObservableObjectPublisher**, is a specialized version of **PassthroughSubject** that emits events without any data.

![SwiftUI ObservableObject Internal Mechanism and Data Flow](https://api.flyingharley.dev/uploads/observable_Object_46f52ece4e.jpg)
*SwiftUI ObservableObject Internal Mechanism and Data Flow*

This is achieved through runtime introspection, where the Combine framework inspects the class to find **@Published** properties. For each of these properties, Combine connects the **objectWillChange** publisher, linking property changes to notifications. The **@Published** property wrapper itself is a computed property that calls **objectWillChange.send()** in its setter before updating the stored value.

The timing of these notifications is "will change" rather than "did change," which is done for performance reasons. Early SwiftUI betas used a "did change" model, but this was changed to "will change" to allow for better coalescing of updates. [As discussed in a community forum, this change lets SwiftUI group multiple property changes into a single view update, improving rendering performance](https://www.reddit.com/r/swift/comments/gb8742/reasoning_behind_observableobjects/).

#### Property Wrapper Integration and Lifecycle

The way **ObservableObject** works with SwiftUI property wrappers like **@ObservedObject** and **@StateObject** involves complex lifecycle management. **@ObservedObject** creates a subscription to the **ObservableObject**'s **objectWillChange** publisher, but it doesn't control the object's lifecycle. It assumes that something else is keeping a strong reference to the object.

![A flowchart illustrating when to use @ObservedObject versus @StateObject in SwiftUI views.](https://api.flyingharley.dev/uploads/flow_chart_8496e52ddd.jpg)
*A flowchart illustrating when to use @ObservedObject versus @StateObject in SwiftUI views.*

**@StateObject**, on the other hand, both manages the subscription and owns the object's lifecycle. When a view uses **@StateObject**, SwiftUI allocates memory for the object and keeps it alive for as long as the view exists. This ensures that the same object instance is used even when the view is recreated, preventing state loss.

Both **@ObservedObject** and **@StateObject** conform to the [**DynamicProperty**](https://developer.apple.com/documentation/swiftui/dynamicproperty) protocol, which is the foundation for SwiftUI property wrappers involved in the view update cycle. This protocol requires an **update()** method that SwiftUI calls before re-rendering a view's body, allowing property wrappers to refresh their state.

The subscription system uses Combine's cancellation features to manage memory. When a view is deallocated, SwiftUI automatically cancels its subscriptions to prevent memory leaks. However, this only works if the property wrapper itself is deallocated correctly, which depends on proper usage.

### MVVM Implementation with **ObservableObject**

#### Lifecycle Management Challenges

Using **ObservableObject** for MVVM in SwiftUI brings up some lifecycle management issues. These arise from the fact that SwiftUI views are value types (structs) that can be recreated often, while **ObservableObject** instances are reference types (classes) that should persist.

Understanding how different property wrappers manage memory is key to avoiding lost state. With **@StateObject**, SwiftUI takes ownership of the object's lifecycle, creating it once when the view first appears and keeping it until the view is gone.

```swift
struct CounterView: View {
    @StateObject private var viewModel = CounterViewModel()
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment") {
                viewModel.incrementCounter()
            }
            Text("View recreated: \(UUID())")
        }
    }
}

class CounterViewModel: ObservableObject {
    @Published var count = 0
    
    init() {
        print("ViewModel created: \(Date())")
    }
    
    func incrementCounter() {
        count += 1
    }
}
```

In contrast, **@ObservedObject** does not manage the object's lifecycle. It assumes that the object is being kept alive by some other part of the application. This can be a problem if developers mistakenly think **@ObservedObject** works like **@StateObject**. If a parent view updates and recreates a child view that uses **@ObservedObject**, the child view might lose its connection to the original object if it isn't being retained elsewhere.

A common mistake is creating an **ObservableObject** inline inside a view's initializer or as a computed property when using **@ObservedObject**.

```swift
// Problematic pattern - object will be recreated on every view update
struct ProblematicView: View {
    @ObservedObject var viewModel = CounterViewModel() // Wrong usage
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment") {
                viewModel.incrementCounter()
            }
        }
    }
}
```

This leads to the **CounterViewModel** being recreated every time the parent view updates, which resets its state and can cause confusing behavior.

#### Property Wrapper Selection and Best Practices

The differences between **@StateObject** and **@ObservedObject** come down to their design and intended use. **@StateObject** uses SwiftUI's internal storage to cache the object instance, ensuring that even when the view struct is recreated, the same object reference is maintained.

Behind the scenes, **@StateObject** uses SwiftUI's storage system to keep object references across view updates. When a view is first created, **@StateObject** allocates memory and initializes the object once. On subsequent view recreations, it retrieves the cached object, ensuring state consistency.

```swift
struct ParentView: View {
    @State private var toggleState = false
    
    var body: some View {
        VStack {
            // This view will be recreated when toggleState changes
            // but @StateObject ensures viewModel persists
            ChildViewWithStateObject()
            
            Button("Toggle Parent State") {
                toggleState.toggle()
            }
            
            Text("Parent state: \(toggleState)")
        }
    }
}

struct ChildViewWithStateObject: View {
    @StateObject private var viewModel = PersistentViewModel()
    
    var body: some View {
        VStack {
            Text("Value: \(viewModel.value)")
            Button("Increment") {
                viewModel.increment()
            }
        }
        .onAppear {
            print("Child view appeared with viewModel: \(viewModel.id)")
        }
    }
}

class PersistentViewModel: ObservableObject {
    @Published var value = 0
    let id = UUID()
    
    func increment() {
        value += 1
    }
}
```

**@ObservedObject**, however, doesn't provide storage management. It simply observes an existing object. It's designed for cases where the object's lifecycle is managed externally, such as by a parent view or a dependency injection container. The key is that **@ObservedObject** expects the object to remain valid while it's being observed.

This distinction is important because of how SwiftUI updates views. When a view needs to be redrawn, SwiftUI creates a new instance of the view struct. At this point, **@StateObject** retrieves the cached object from its managed storage, while **@ObservedObject** expects the same object to be passed in from an external source.

```swift
struct DataFlowExample: View {
    @StateObject private var dataSource = DataSource()
    
    var body: some View {
        VStack {
            // Correct: Pass the StateObject-managed instance to children
            DisplayView(dataSource: dataSource)
            ModificationView(dataSource: dataSource)
        }
    }
}

struct DisplayView: View {
    @ObservedObject var dataSource: DataSource
    
    var body: some View {
        Text("Current data: \(dataSource.currentValue)")
    }
}

struct ModificationView: View {
    @ObservedObject var dataSource: DataSource
    
    var body: some View {
        Button("Update Data") {
            dataSource.updateValue()
        }
    }
}

class DataSource: ObservableObject {
    @Published var currentValue = "Initial"
    
    func updateValue() {
        currentValue = "Updated at \(Date().timeIntervalSince1970)"
    }
}
```

This pattern ensures that the **DataSource** instance is created and owned by the parent view using **@StateObject**, and child views observe that same instance using **@ObservedObject**.

#### State Persistence and Memory Management
As ObservableObject is implemented by reference type, it requires developers to be mindful of potential retain cycles, especially when using closures or delegates.

```swift
class NetworkService: ObservableObject {
    @Published var isLoading = false
    @Published var data: String = ""
    
    private var cancellables = Set<AnyCancellable>()
    
    func fetchData() {
        isLoading = true
        
        // Potential retain cycle if not handled properly
        URLSession.shared.dataTaskPublisher(for: URL(string: "https://api.example.com")!)
            .map { $0.data }
            .sink(
                receiveCompletion: { [weak self] _ in
                    self?.isLoading = false
                },
                receiveValue: { [weak self] data in
                    self?.data = String(data: data, encoding: .utf8) ?? ""
                }
            )
            .store(in: &cancellables)
    }
    
    deinit {
        cancellables.removeAll()
    }
}
```

The use of _[weak self]_ in closures prevents retain cycles that could keep the **NetworkService** instance alive even after its view is gone.

That's all about this part. We've seen that the traditional implementation of MVVM in SwiftUI relies on the ObservableObject protocol, which uses Combine's objectWillChange publisher to notify views of state changes from @Published properties. Effective state management requires using @StateObject to create and own the ViewModel, ensuring its persistence throughout the view's lifecycle, while child views use @ObservedObject to simply observe it. Misusing these wrappers often leads to state loss, a common pitfall for developers. Additionally, because ObservableObjects are reference types, developers are responsible for manually preventing memory leaks and retain cycles, typically by using [weak self] in closures.

In the next part, we will discover the _@Observable_ macro and its benefits.

large_Architectural Diagram Blue.jpeg

medium_Architectural Diagram Blue.jpeg

small_Architectural Diagram Blue.jpeg

thumbnail_Architectural Diagram Blue.jpeg

Architectural Diagram Blue.jpeg

MVVM Architecture in SwiftUI: From ObservableObject to @Observable - Part 2

## Part 1: The MVVM and its integration with SwiftUI Development

### Understanding MVVM Architecture Fundamentals

#### Core Concepts and Components

The **Model-View-ViewModel (MVVM)** is an architectural pattern, originally from Microsoft architects *Ken Cooper* and *Ted Peters*, designed to separate the graphical user interface from the business logic. It organizes an application into three key layers to improve how easy it is to maintain and test.

-   The **Model** is responsible for the application's data and business logic, such as domain objects and data access.
-   The **View** is the user interface that users see and interact with, responsible for displaying data and capturing user actions.
-   The **ViewModel** serves as a bridge between the Model and the View. It prepares data from the Model to be displayed in the View and handles user interactions and presentation logic.

![MVVM Architecture Pattern Components and Data Flow](https://api.flyingharley.dev/uploads/MVVM_Pattern_9d0942fa4f.png)

*MVVM Architecture Pattern Components and Data Flow - [wikipedia](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93viewmodel)*

The main goal of MVVM is to eliminate direct dependencies between the View and the Model. This separation keeps Views from being tied to specific Model implementations, which allows for greater flexibility and reusability. The ViewModel acts as a converter, transforming data from the Model into a format that the View can easily use. In this way, it functions as a mediator, organizing access to back-end logic based on what the View needs.

#### Architectural Benefits and Rationale

MVVM addresses several common problems in application development, particularly with user interfaces. One of the main reasons for its creation was to remove UI code from the view layer by using data binding. [This approach, as detailed here, allows UI/UX designers to focus on the interface while developers work on the business logic](https://www.ramotion.com/blog/what-is-mvvm/). This separation of responsibilities helps teams work in parallel and can significantly boost productivity.

#### MVVM for iOS Development
For iOS development, we also care about the navigation between "screens" and their hierarchy, hence a separate *Coordinator* is needed. Those can be described with this cool diagram:

![MVVM-C.png](https://api.flyingharley.dev/uploads/MVVM_C_d637bdddbc.png)
*[App Architecture - iOS Application Design Patterns in Swift](https://www.objc.io/books/app-architecture)*

##### Advantages of MVVM over MVC

To fully appreciate MVVM, it's helpful to compare it to its predecessor, Model-View-Controller (MVC). In the MVC pattern, the **Controller** is responsible for handling user input and updating both the **Model** and the **View**. 

While MVC separates concerns, it often leads to a tight coupling between the View and the Controller. The Controller can become a massive class that handles all the logic, making it difficult to test and maintain. This is especially true in UI frameworks where the View and Controller are often closely linked.

MVVM improves on MVC in several key ways:

1.  **Enhanced Separation of Concerns**: MVVM introduces the **ViewModel**, which acts as a more specialized intermediary than the Controller. The **ViewModel** is responsible for preparing and providing data for the **View**, but it has no direct reference to the **View** itself. This decoupling is a significant improvement, and the modular design makes it easier to test individual components in isolation, leading to more reliable and maintainable code.

2.  **Data Binding**: This is a core advantage of **MVVM**. The **View** is automatically updated when the **ViewModel**'s data changes, thanks to data binding. This eliminates a large amount of boilerplate code that would otherwise be needed to manually update the **View** from the **Controller**. In SwiftUI, this is achieved through property wrappers like _@StateObject_ and _@ObservedObject_ (and more recently _@State_ with _@Observable_ objects). In UIKit or AppKit, it's usually one of the reactive frameworks such as **Combine**, **RxSwift**, ...

3.  **Improved Testability**: Because the **ViewModel** is not tied to the UI, it can be tested independently of any UI components without requiring complex UI component mocking. This makes unit testing the application's logic much simpler and more robust compared to testing a Controller that might be tightly coupled with the UI framework's APIs.

4.  **Better for Collaboration and Reusability**: The clear separation allows UI designers to work on the View while developers work on the **ViewModel** and **Model**, with less chance of conflicts. Additionally, MVVM promotes code reuse since **ViewModels** can be shared across multiple Views or even different platforms. This is particularly useful in cross-platform development, where business logic can remain consistent while the UI is adapted for each platform.

#### SwiftUI-Specific Advantages

SwiftUI's declarative programming style works very well with the principles of MVVM. The combination of SwiftUI's reactive data binding and MVVM's separation of concerns leads to better-organized and more maintainable apps. [A key benefit, as noted in the SwiftUI Cookbook, is that the framework's built-in data binding eliminates much of the boilerplate code that was traditionally needed to sync ViewModels with Views](https://www.kodeco.com/books/swiftui-cookbook/v1.0/chapters/2-understanding-observableobject-observedobject). This lets developers focus on the application's logic rather than on manual state synchronization, which results in cleaner, more concise code.

The declarative nature of SwiftUI also benefits from MVVM's structured approach to state management. Views can declaratively bind to ViewModel properties, and they will automatically update when the underlying data changes, without needing manual refresh calls. This reactive system keeps the UI synchronized with the application's state while maintaining a clear separation between the presentation and business logic layers. The pattern also helps in organizing complex view hierarchies by allowing related views to share common view models through dependency injection or as environment objects.

Let's take some conceptual code examples to illustrate the difference.

__Conceptual MVC-like approach in SwiftUI:__
In a pure MVC, the controller would handle the logic. In SwiftUI, views are more central, but one might be tempted to put logic inside the view, which acts a bit like a controller.

```swift
// A view doing too much, like a combined View-Controller
struct CounterView_PoorSeparation: View {
    @State private var count = 0

    var body: some View {
        VStack {
            // View logic
            if count > 10 {
                Text("Count is large!")
            } else {
                Text("Count: \(count)")
            }
            
            Button("Increment") {
                // Business logic inside the view
                self.increment()
            }
        }
    }

    // Business logic mixed in
    private func increment() {
        // Here we might have more complex logic, like checks or API calls
        self.count += 1
    }
}
```
The view above mixes presentation logic (the "if" statement) with business logic (the "increment" function). This becomes hard to test and reuse.

__MVVM approach in SwiftUI:__
With MVVM, we separate this logic cleanly.

```swift
// The Model
struct Counter {
    var value: Int = 0
}

// The ViewModel
class CounterViewModel: ObservableObject {
    @Published private var counter = Counter()
    
    var displayText: String {
        if counter.value > 10 {
            return "Count is large!"
        } else {
            return "Count: \(counter.value)"
        }
    }

    func increment() {
        // All business logic is here, testable and separate.
        counter.value += 1
    }
}

// The View
struct CounterView_MVVM: View {
    @StateObject private var viewModel = CounterViewModel()

    var body: some View {
        VStack {
            Text(viewModel.displayText) // View only displays data from ViewModel
            Button("Increment") {
                viewModel.increment() // View only sends actions to ViewModel
            }
        }
    }
}
```
In the MVVM example, the "CounterView_MVVM" is simple and only responsible for layout. The "CounterViewModel" contains all the presentation and business logic, and it is easily testable without needing any UI. This separation makes MVVM a more robust choice for modern application development.

That's it for this part! In the next part, we will dive deeper into the MVVM Implementation with SwiftUI and its _ObservableObject_ protocol and more. Stay tuned!

This article provides a deep dive into the Model-View-ViewModel (MVVM) architecture, beginning with its fundamental principles and its advantages over the classic Model-View-Controller (MVC) pattern. It then explores the integration of MVVM within SwiftUI, covering both the traditional `ObservableObject` implementation and the modern `@Observable` macro. The discussion details the inner workings of `ObservableObject`, its lifecycle challenges, and common implementation patterns. Subsequently, it transitions to the `@Observable` macro, highlighting its performance benefits, simplified syntax, and best practices, complete with code examples. The article also addresses potential drawbacks, offers guidance on choosing between the two models, and concludes with a look at the ongoing evolution of architectural patterns in the SwiftUI ecosystem.

MVVM Architecture in SwiftUI: From ObservableObject to @Observable - Part 1

large_Race Road Paths Minimalism.jpeg

medium_Race Road Paths Minimalism.jpeg

small_Race Road Paths Minimalism.jpeg

thumbnail_Race Road Paths Minimalism.jpeg

Race Road Paths Minimalism.jpeg

Swift Concurrency offers powerful tools for writing asynchronous code that's more readable and maintainable than traditional callback-based approaches. However, beneath its elegant syntax lies a complex system that can create serious issues when misused. The cooperative thread pool, actor isolation, and bridging mechanisms introduce subtle pitfalls that can lead to deadlocks, memory leaks, and unexpected runtime behavior.

This article explores the challenges developers face with Swift Concurrency and provides guidance for avoiding common pitfalls that can compromise application stability and performance.

 Swift Concurrency is great, but... - Part 1

## The "System Size" Problem

![full-storage.jpg](https://api.flyingharley.dev/uploads/full_storage_6b7209427b.jpg)

If you're a Mac user, you've probably noticed that mysterious "System Data" category eating up your storage space like a teenager raiding the fridge. While it sounds fancy, it's really just a folder where your Mac keeps its digital housekeeping stuff – think of it as your computer's junk drawer filled with caches and log files. For iOS developers, there's one particular storage glutton to watch out for: Xcode. This app-making toolkit is like that friend who comes to crash on your couch for a few days but somehow leaves their stuff everywhere. As you work, Xcode sprinkles temporary files and support documents all over your drive like breadcrumbs, quietly munching away at your available space. Don't worry, though – I will show you exactly what these files are and how to clean them up, so you can get back to building amazing apps without your Mac giving you the dreaded "disk full" warning.

## Developer Storage

These files are created by Xcode during development. 

### Derived Data

**Derived data is Xcode's workspace where it stores temporary files generated while building and indexing a project**. This includes intermediate build files, generated indexes, module caches, logs, and symbol caches. It speeds up the build process and enables Xcode features like code completion and syntax highlighting. You can delete the entire Derived Data folder or selectively delete data for projects you are no longer working on.  This folder is located at:

```swift
~/Library/Developer/Xcode/DerivedData
```

### System Setting > General > Storage > Xcode Cache

![xcode-cache.jpg](https://api.flyingharley.dev/uploads/xcode_cache_7db448cc84.jpg)

Xcode cache stores various temporary files that Xcode uses during development. It locates at:

```swift
~/Library/Developer/CoreSimulator/Caches
```

You can save tons of GBs when delete it if you're working on many huge projects.

### Device Support

**These files are necessary for Xcode to communicate with physical iOS devices connected to your Mac**. They are created every time you connect a device with a new iOS version. These files are around 2.5 GB each. You can delete older versions; Xcode will regenerate them if needed. They are located in this directory:  

```swift
~/Library/Developer/Xcode/iOS DeviceSupport/
```

### Old Archives 

**Archives are the finished products of your apps, packaged up and ready for distribution**.  They include debug symbols which are needed to symbolicate crash logs. You should back them up, but you may not need to keep all of them locally.  You can delete them through Xcode or in Finder.  They are stored in the following directory, organized by the date they were created:

```swift
~/Library/Developer/Xcode/Archives/
```
### SwiftUI Preview

SwiftUI previews generate temporary files to render the preview of your SwiftUI views.
- Delete directly by removing this directory: 
```swift 
~/Library/Developer/Xcode/UserData/***Previews***
```
- Or using command: 

```swift
xcrun simctl --set previews delete all
```


- If there is an error with simctl:

```swift
sudo xcode-select -s /Applications/Xcode.app
```

- **Note:** Quit Xcode before doing the above steps.

## System Storage

![system-storage.jpg](https://api.flyingharley.dev/uploads/system_storage_c3d1d09020.jpg)

### Cache

**The Cache directory stores data used by all installed applications**, including Xcode. You may find large cache files for apps you no longer use. The Cache directory is located at: 

```swift
~/Library/Caches
```

### Old Core Simulator Devices

**Simulator devices are virtual iOS devices used for testing apps during development**.  As new Xcode versions and new iOS versions are released, old simulator devices accumulate and take up a lot of space. It is safe to delete any devices that you don't use. **Deleting unused simulator devices is one of the most effective ways to reclaim storage space**. You can potentially free up between 20 GB to 150 GB by doing this. Simulator devices are located in this folder: 

```swift
~/Library/Developer/CoreSimulator/Devices
```

You need to be careful, only delete the device you don't use any more. Or just reset them instead by select Simulator -> Device -> Erase All Content and Settings

![erase.jpg](https://api.flyingharley.dev/uploads/erase_933c6ddc9e.jpg)

## Introducing [EZClean](https://apps.apple.com/vn/app/ezclean-for-developers/id6581486175?mt=12)



If you're too lazy to manually do the above cleaning stuffs, try using [EZClean](https://apps.apple.com/vn/app/ezclean-for-developers/id6581486175?mt=12). It's a tool designed to help iOS developers manage Xcode storage and reclaim disk space by suggesting you to delete unused and temporary files. EZClean can scan your system for files like old simulator devices, device support files, and derived data, ... and allow you to delete them safely and easily. Here's what makes EZClean your new best friend:

- It's like having x-ray vision for your Mac – shows you where all your developer files are hiding
- Does the cleanup for you by just one click
- Hangs out in your menu bar like a helpful butler, ready to clean up whenever you need
- Has a "Instant clean" button for those "oh crud, I'm running out of space" moments, right on your menu bar!
- Completely free – no ads, no "upgrade to pro" popups, no nonsense
 
So go ahead – download it, give [EZClean](https://apps.apple.com/vn/app/ezclean-for-developers/id6581486175?mt=12) a spin and discover what life's like on the other side of developer stress. Instead of wrestling with storage warnings and playing hide-and-seek with rogue junk files, you can focus on what you actually signed up for: building cool apps.

Happy coding!


large_cover.jpeg

medium_cover.jpeg

small_cover.jpeg

thumbnail_cover.jpeg

cover.jpeg

Storage Optimization on MacOS for Developer

Swift Concurrency, introduced in WWDC21, offers a safer and more efficient approach to asynchronous programming compared to _Grand Central Dispatch_ (GCD). However, integrating _Swift Concurrency_ with older primitives like _NSLock_ and _GCD queue_ requires careful consideration to avoid potential pitfalls.



### 1. Swift Concurrency vs. GCD



Swift Concurrency distinguishes itself from GCD in its threading model and its approach to handling blocked threads.



**Threading Model:**



*  **GCD:** GCD employs a thread-pool model where threads are dynamically created and managed by the system. This can lead to **thread explosion**, particularly with concurrent queues, where the system might overcommit by creating more threads than CPU cores. GCD dynamically adjusts the number of threads based on system load and available resources.

  *  Example:

    ```swift

    let queue = DispatchQueue.global(qos: .background)

    for i in 0..<100 { 

     queue.async { 

      // Perform some lengthy task, such as:

      print("Task \(i) is running on thread: \(Thread.current)")

      Thread.sleep(forTimeInterval: 2) // Simulate a long-running task

     }

    }
    ```

    This code could potentially create 100 threads, even if the device has fewer cores. Each task is dispatched to the global concurrent queue, and GCD might create a new thread for each task, especially if the tasks are CPU-bound or blocking. This can lead to performance issues due to excessive context switching and resource contention.

*  **Swift Concurrency:** Swift Concurrency, by default, utilizes a **cooperative thread pool** limited to the number of CPU cores. It uses cooperative multitasking, where tasks voluntarily yield control to allow other tasks to run, thus efficiently utilizing CPU cores and preventing thread explosion.

  *  Example:

    ```swift

    func lengthyTask() async {

      print("Lengthy task is running on thread: \(Thread.current)")

      await Task.sleep(nanoseconds: 2_000_000_000) // Simulate a long-running task

    }

    func anotherLengthyTask() async {

      print("Another lengthy task is running on thread: \(Thread.current)")

      await Task.sleep(nanoseconds: 1_000_000_000) 
    }

    async let task1 = lengthyTask()

    async let task2 = anotherLengthyTask()

    await task1
    await task2
    ```

    This code leverages the cooperative thread pool and ensures efficient utilization of CPU cores. When _await_ is encountered, the current thread can be potentially freed up to execute other tasks while waiting for the awaited task to complete. This helps prevent the creation of unnecessary threads and minimizes context switching overhead.



**Handling Blocked Threads:**



*  **GCD:** When a thread in GCD is blocked, the system might spin up new threads to handle remaining tasks, potentially exacerbating thread explosion.

  *  Example:

    ```swift

    let queue = DispatchQueue.global()

    queue.sync {

     // This blocking operation will halt the current thread

     let url = URL(string: "https://www.example.com/large_file.zip")! 

     let data = try Data(contentsOf: url) // Download a large file (blocking)

     print("Downloaded data size: \(data.count) bytes")

    }
    ```

    If this occurs within a concurrent queue with multiple tasks, GCD might create additional threads to continue processing tasks. Downloading a large file can take a significant amount of time, during which the thread executing this code is blocked, waiting for the download to complete. In a GCD-based system, if other tasks are enqueued on the same concurrent queue, GCD might create new threads to handle those tasks, potentially leading to thread explosion. To understand more about Excessive Context Switching & Thread Explosion, take a look at this incredible [WWDC explanation](https://developer.apple.com/videos/play/wwdc2017/706/) at 11:03.

*  **Swift Concurrency:** Swift Concurrency replaces blocked threads with lightweight _continuations_ These continuations track the resumption points of suspended tasks, enabling threads to efficiently switch between work items without the overhead of full thread context switches.


![wwdc-gcd-thread.jpg](https://api.flyingharley.dev/uploads/wwdc_gcd_thread_82c1c5d328.jpg)
*With GCD, when a thread is blocked, many threads will be created and Context Switches occurred*

![wwdc-swiftconcurrency.jpg](https://api.flyingharley.dev/uploads/wwdc_swiftconcurrency_a768fbc1d4.jpg)
*With Swift Concurrency, there will be only one thread for each CPU core*

  *  Example:

    ```swift

    let url = URL(string: "https://www.example.com/large_file.zip")!

    do {

      let data = try await Data(contentsOf: url)

      print("Downloaded data size: \(data.count) bytes")

    } catch {

      print("Failed to download data: \(error)")

    }
    ```

    Using _await_ allows the current thread to be freed while waiting for the file data, avoiding thread blocking and allowing the thread to potentially handle other tasks. The _await_ keyword signals a potential suspension point. When the code execution reaches _await_ the current task can be suspended, and the thread can be used to execute other tasks. Once the awaited operation (downloading the file) is complete, the task is resumed, and the execution continues from the suspension point.



### 2. Safe Primitives vs. Legacy Primitives

![primitives.jpg](https://api.flyingharley.dev/uploads/primitives_4f7179124b.jpg)

When adopting Swift Concurrency, it's crucial to prioritize performance and understand the implications of await on atomicity. The recommended approach is to utilize safe primitives like _await_, _Actors_, and _Task groups_, which are compiler-enforced. These primitives ensure thread safety and help avoid common concurrency issues.

While primitives like _os_unfair_lock_ and _NSLock_ can be used in synchronous code for short, well-defined critical sections, they require caution. Using them within asynchronous contexts or for long-running operations can lead to deadlocks and violate the **runtime contract of forward progress**.

Unsafe primitives such as _DispatchSemaphore_, _pthread_cond_, _NSCondition_, and _pthread_rw_lock_ are strongly discouraged. These primitives hide dependency information from the Swift runtime, potentially causing unpredictable behavior and making debugging difficult.
To identify the use of unsafe primitives during development, run your app with the environment variable _LIBDISPATCH_COOPERATIVE_POOL_STRICT_=1. This modified debug runtime helps enforce the invariant of forward progress and can flag potential issues.
But we should use Actors whenever possible. They offer a safer and more efficient alternative to locks and serial queues for mutual exclusion. They guarantee that only one method call is executed at a time, protecting the actor's state from data races. Actors also support efficient thread hopping and prioritization, ensuring responsiveness and avoiding priority inversions.

So why shouldn't we use Actors at any time? In reality, there are situations where using these might not be ideal, such as when **modifying and reading individual properties** within a type such as class... In this case, actors aren't quite the right tool because:

- **Granularity of Access**: Actors are designed to protect their entire state. Every method call on an actor is executed serially, ensuring that only one thread can access the actor's properties at a time. This is great for preventing data races when working with multiple properties. However, if you only need to synchronize access to a single property, using an actor might introduce unnecessary overhead.
- **Order of Operations**: You can't guarantee the order in which operations will run on an actor. If you have a sequence of operations that must be performed in a specific order on a single property, using an actor might not be the best solution.

Let's consider an example: Imagine you have a class representing a counter:

```swift
class Counter {
    private var count = 0
    
    func increment() {
        count += 1
    }
    
    func decrement() {
        count -= 1
    }
    
    func getValue() -> Int {
        return count
    }
}
```

If you want to ensure that increment and decrement operations are synchronized, using an actor might be an option. However, it will also make reading the value using **getValue** subject to the actor's serialization, potentially impacting performance if there are frequent read operations.
In such cases, alternative synchronization mechanisms like atomics, dispatch queues, or locks can be more appropriate. These mechanisms allow you to synchronize access to specific properties without affecting the entire object's state.
For instance, you could use a [_ManagedAtomic_](https://www.swift.org/blog/swift-atomics/) to synchronize access to the count property:
```swift
import SwiftAtomics

class Counter {
    private var count = ManagedAtomic<Int>(0)
    
    func increment() {
        count.wrappingIncrement(ordering: .sequentiallyConsistent)
    }
    
    func decrement() {
        count.wrappingDecrement(ordering: .sequentiallyConsistent)
    }
    
    func getValue() -> Int {
        return count.load(ordering: .sequentiallyConsistent)
    }
}
```

Here, [_ManagedAtomic_](https://www.swift.org/blog/swift-atomics/) ensures that increment, decrement, and read operations on the count property are atomic and synchronized, without requiring the entire _Counter_ class to be an actor.
Therefore, while actors are powerful tools for concurrent programming, they might not always be the most efficient or flexible solution. When dealing with individual properties that require synchronized access, consider using alternative synchronization mechanisms like atomics, dispatch queues, or locks. Remember to carefully evaluate the trade-offs and choose the approach that best suits your specific needs.

### 3. Deadlock Scenario: GCD Queues and Swift Concurrency



#### Problem Description



Integrating Swift Concurrency with GCD can lead to deadlock scenarios, especially when tasks are blocked inside GCD queues. Understanding how GCD queues work and how they differ from Swift Concurrency is crucial to avoid these issues.



#### GCD Queue



- **Serial Queue**: Executes tasks one at a time in the order they are added. This ensures that tasks do not run concurrently and are processed sequentially.

  

- **Concurrent Queue**: Allows multiple tasks to execute simultaneously. Tasks are started in the order they are added, but they can run in parallel and complete in any order. _GCD_ concurrent queues can **overcommit** by creating more threads than there are available hardware threads to ensure work progresses.



#### Swift Concurrency



- **Task & Continuation**: A _Task_ represents a unit of asynchronous work that can be awaited. Together with _Continuation_, they allow asynchronous code that doesn't use _async/await_ to be integrated into Swift's concurrency model by capturing the continuation of an operation. In this context, it can be used to integrate GCD.



- **Non-Overcommitting**: Swift Concurrency does not expect blocking and will **not overcommit** CPU cores. This means it efficiently manages resources but can lead to deadlocks if tasks are blocked.



#### Problem When Swift Concurrency Task Is Blocked Inside GCD Queue



When a Swift Concurrency task is blocked inside a GCD queue, it can lead to a deadlock if the queue is waiting for a thread from the thread pool to dispatch a task, but no threads are available because they are all blocked.



#### Code Example: Read & Write Patterns Using GCD Concurrent Queue



```swift

import XCTest

final class BarrierTests: XCTestCase {

  func test() async {

    let subsystem = Subsystem()

    await withTaskGroup(of: Void.self) { group in

      for index in 0 ..< 100 {

        group.addTask { subsystem.performWork(id: index) }

      }

      await group.waitForAll()

    }

  }

}


final class Subsystem {

  let queue = DispatchQueue(label: "my concurrent queue", attributes: .concurrent)

  func performWork(id: Int) {

    if id % 10 == 0 { write(id: id) }

    else { read(id: id) }

  }

  func write(id: Int) {

    print("schedule exclusive write \(id)")

    queue.async(flags: .barrier) { print(" execute exclusive write \(id)") } // Asynchronous write with barrier

    print("schedule exclusive write \(id) done")

  }

   
  func read(id: Int) {

    print("schedule read \(id)")

    queue.sync { print(" execute read \(id)") } // Synchronous read, blocking the caller

    print("schedule read \(id) done")

  }

}

```
Ref: https://forums.swift.org/t/deadlock-when-using-dispatchqueue-from-swift-task/66058/25


#### Explanation

- **Multiple Synchronous Reads**: Allowed with the concurrent queue, blocking the caller.

- **Barrier for Writes**: The write operation is dispatched asynchronously with a barrier, ensuring it can only proceed when no other reads or writes are running concurrently.


While the code might not immediately cause a deadlock, it has the potential to do so when:


1. An event triggers multiple read and write operations.

2. A large number of read operations start from a Swift Concurrency context, consuming available threads.

3. A write operation is triggered, making an asynchronous call to the concurrent queue under the _.barrier_ option.

4. The queue waits for a thread from the thread pool to dispatch the write operation, but **no threads are available due to blocking reads**. Since Swift Concurrency won't overcommit (create more threads), the barrier isn't cleared, leading to a deadlock.



#### Observations


- **GCD and Swift Concurrency**: They seem to share the same thread pools, which can exacerbate the issue.



- **Deadlock Consequences**: When this deadlock occurs, **subsequent tasks will not be dispatched, leading to program malfunction**. The main thread (MainActor) may still work and receive events, but other threads will not make progress.



Here are some rule of thumbs & considerations:

- **Avoid Blocking**: Do not block work inside Swift Concurrency, such as using _.sync_ on another GCD queue, especially for future work that is not actively running but enqueued (e.g., async dispatch with a barrier). This violates the runtime contract of "Forward progress" we mentioned before.


- **Limit Task Creation**: Avoid creating too many Swift Concurrency tasks using **Task** blocks or **TaskGroup**, as unexpected blocking can easily lead to deadlocks, especially when interacting with legacy frameworks.



- **Minimize Mixing**: Try to avoid mixing Swift Concurrency and GCD, as it can lead to unexpected behavior and be difficult to debug.


With the discussion so far, we can easily figure out the solution which is simply avoid using the concurrent queue for read-write pattern. Instead, we could use _NSLock_ (with caution) or _pthread_rw_lock_ (not recommended).

### 4. Summary
Swift Concurrency provides powerful tools for writing safer and more efficient concurrent code. Developers should prioritize the use of safe primitives like _await_, _Actors_, and _Task groups_ as they offer compiler-enforced safety and help manage concurrency effectively.
While traditional synchronization mechanisms like locks (_NSLock_, _os_unfair_lock_) and dispatch queues are still available, it's important to exercise caution when using them in Swift Concurrency. They can introduce deadlock risks if not handled properly, especially when interacting with asynchronous operations.


large_balancer.jpeg

medium_balancer.jpeg

small_balancer.jpeg

thumbnail_balancer.jpeg

balancer.jpeg

Swift Concurrency, introduced in WWDC21, offers a safer and more efficient approach to asynchronous programming compared to Grand Central Dispatch (GCD). However, integrating Swift Concurrency with older primitives like NSLock and GCD requires careful consideration to avoid potential pitfalls

Swift Concurrency and Legacy Primitives: A Balancing Act

# Protocol Extension Method Dispatching in Swift

## Introduction to Method Dispatch Types

Method dispatch is the mechanism a program uses to determine which implementation of a function to execute when that function is called. **Swift employs four types of method dispatch, each with trade-offs between speed and flexibility**:

*   **Inlining:** This is the fastest and least flexible type of dispatch. It involves replacing a function call with the function's code, eliminating the overhead associated with making the call. This optimization is most effective when the compiler has all the information it needs to determine the result of the function call at compile time, such as when working with hardcoded values or simple operations.

*   **Static Dispatch:** Also known as direct dispatch, static dispatch is the second fastest and second least flexible type of dispatch. It occurs when the function's memory address is known at compile time. This allows the compiler to directly jump to that address without needing to perform a runtime lookup. Static dispatch is typically used for functions within structs, enums, and final classes, where the compiler can guarantee which implementation will be used.

*   **Table Dispatch:** This type of dispatch is used to implement polymorphism, which is the ability of a single type to have multiple forms. In table dispatch, the function to be called is determined at runtime by looking up its address in a table. Swift implements two flavors of table dispatch: **virtual table dispatch** for class hierarchies and **protocol witness table dispatch** for protocols.

    *   **Virtual Table Dispatch:** Virtual tables are used to dispatch methods on class hierarchies. When a class is created, it includes a hidden data structure called a virtual table, which contains pointers to the implementations of all the methods defined in the class and its superclasses. When a method is called on an object, the runtime uses the object's virtual table to find the correct implementation of the method to execute. This allows subclasses to override methods from their superclasses and have their implementations called even when the method is called on a variable typed as the superclass. This is because the specific type of the object is not known until runtime.

    *   **Protocol Witness Table Dispatch:** Protocol witness tables work similarly to virtual tables but are used for protocols. When a type conforms to a protocol, it creates a witness table that contains pointers to the implementations of all the required methods of the protocol. When a method is called on a variable typed as a protocol, the runtime uses the variable's witness table to find the correct implementation of the method to execute.

*   **Message Dispatch:** This is the slowest and most flexible type of dispatch. It uses the Objective-C runtime and allows for dynamic method lookup at runtime. This means that the implementation of a method can be changed at runtime, even after the code has been compiled. Message dispatch is invoked using the _@objc_ and _dynamic_ keywords in Swift. This type of dispatch is useful for interoperability with Objective-C code and for implementing features like Key-Value Observing (KVO).

In this article, we will focus on Protocol Witness Table Dispatch. For further information on method dispatch in Swift, please refer to those great articles:

*   [The Swift Method Dispatch Deep Dive](https://jacob.bartlett.dev/blog/swift-method-dispatch)
*   [Swift Protocol Extensions Method Dispatch](https://medium.com/@leandromperez/swift-protocol-extensions-method-dispatch-7e28d7a68b8c)
*   [Method Dispatch in Swift — RaizException — Raizlabs Developer Blog](https://www.raizlabs.com/dev/method-dispatch-in-swift/)
*   [Method Dispatch in Protocol Extensions — Ole Begemann](https://oleb.net/blog/2014/07/swift-protocol-extensions/)

## Protocol Witness Table Dispatch

Protocol witness table dispatch is the mechanism by which Swift implements polymorphism for protocols. **When a type conforms to a protocol, it generates a witness table that includes pointers to the implementations of the protocol's required methods**.  During runtime, when a protocol requirement is invoked on an instance of a conforming type, Swift references the corresponding function pointer in the witness table and directs the execution flow to that memory location.

**Points to remember**:

*   **Abstract vs. Concrete Types**: Protocol witness table dispatch is employed when interacting with abstract protocol types, such as _any MyProtocol_. When a concrete type adhering to the protocol is used, the compiler often opts for static dispatch due to the compile-time knowledge of the implementation. 

![Screenshot 2024-12-05 at 23.07.22.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_07_22_a87c0ab297.png)
Explanation:

    - The speak() method is a requirement of the Speaker protocol, so it will use dynamic dispatch when called on a variable of type any Speaker, even though there is a default implementation in the extension.

      - When genericSpeaker.speak() is called, the runtime checks the protocol witness table associated with the concrete type (Human) to find the correct implementation of speak(), which results in printing "Hello there!".

      - When humanSpeaker.speak() is called, the compiler knows at compile time that the type is Human, so it can use static dispatch directly to the Human implementation of speak()


*   **Default Implementations in Protocol Extensions**: Methods defined within protocol extensions, but not explicitly declared as requirements in the protocol's definition, leverage static dispatch. Consequently, invoking these methods on an abstract protocol type will directly execute the implementation from the extension. This is in contrast to requirement methods defined in protocol extensions, which use dynamic dispatch and can be customized by conforming types.
![Screenshot 2024-12-05 at 23.13.29.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_13_29_166e78d3a9.png)

Explanation:

    - makeSound() is a protocol requirement, so it uses dynamic dispatch, and the Dog implementation overrides the default extension implementation.
     
      - eat() is not a requirement. It's only defined in the extension, so it uses static dispatch. Regardless of the concrete type of animal, calling eat() will always execute the code in the extension
### Example and Dispatch Flow

![Screenshot 2024-12-05 at 23.17.44.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_17_44_12f80c1e8e.png)

**Explanation of the dispatch flow**:

1.  _myProtocolImplement_ is declared as an abstract protocol type (_any MyProtocol_).

2.  _myProtocolImplement.foo(i1: 1, i2: "2")_ is invoked. Because _myProtocolImplement_ is an abstract type, the runtime will use protocol witness table dispatch.

3.  The runtime inspects the witness table associated with the concrete type of _myProtocolImplement_, which is _MyStruct_ in this case, to locate the implementation of _foo(i1:i2:)_.

4.  Within the witness table, the runtime discovers the function pointer corresponding to _MyStruct_'s implementation of _foo(i1:i2:)_.

5.  Execution then jumps to this memory address, leading to the execution of _print("MyStruct foo")_.

**Outcome**: "MyStruct foo" is printed.

**Why this happens**:

Despite the protocol extension offering a default implementation for _foo(i1:i2:)_, _MyStruct_ also provides its own implementation. **When a conforming type provides a specific implementation for a protocol requirement, this implementation supersedes the default implementation in the extension**. This principle underscores a fundamental concept in protocol-oriented programming: conforming types retain the ability to customize their behavior, even when default implementations are available.

## The Perils of Default Parameters in Protocol Extensions

While protocol extensions in Swift offer a powerful mechanism for extending functionality, using default parameters within them requires careful consideration. The compiler's inability to safeguard against potential pitfalls, coupled with the possibility of infinite recursion, necessitates a cautious approach when employing this pattern.

Let's illustrate this with an example:

![Screenshot 2024-12-05 at 23.30.38.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_05_at_23_30_38_6fbc41b7e5.png)

Here, invoking _myProtocolImplement.foo()_ is intended to execute the _.foo(i1: Int, i2: String)_ method of _MyStruct_ with the default values of _1_ for _i1_ and _"2"_ for _i2_. However, this seemingly convenient approach can lead to dangerous runtime behavior.

**Recursive Calls and Their Consequences**:

The compiler provides no safeguards to prevent potential issues arising from this pattern. Consider the following scenarios:

*   **Missing Implementation**: If we forget to implement the _foo(i1: Int, i2: String)_ method inside _MyStruct_, the program will still compile.

![Screenshot 2024-12-06 at 22.56.18.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_06_at_22_56_18_7910114b0b.png)

*   **Parameter Mismatch**: If we modify the parameters of the _foo_ method in _MyStruct_, such as changing the type of _i2_ to _Int_, resulting in _foo(i1: Int, i2: Int)_, the program will again compile without errors.

In both of these cases, we encounter a critical runtime problem – an infinite loop of recursive calls.

**The Root of the Problem**:

The method dispatch mechanism in this context solely searches for the method implementation within the protocol extension.  **The _foo(i1: Int = 1, i2: String = "2")_ method ends up repeatedly calling itself, ultimately resulting in a crash**. This behavior arises because when the variable's inferred type is the protocol, the dynamically dispatched implementation from the extension is always invoked. If the conforming type doesn't explicitly override the default parameter, the default implementation from the protocol extension will be used, leading to the recursive call.

**Strategies to Mitigate the Risks**:

To avoid these potentially disastrous situations, consider the following strategies:

1.  **Avoidance:** The safest course of action is to completely avoid the use of default parameters within protocol extensions.

2.  **Renaming:** Alternatively, we can rename the method that has default parameters to differentiate it from the required protocol method. For example, instead of _foo(i1: Int = 1, i2: String = "2")_, we could use _fooDefault(i1: Int = 1, i2: String = "2")_. This prevents the recursive call issue, as the default implementation in the extension is now clearly distinct from the required method in the protocol.

![Screenshot 2024-12-06 at 22.58.55.png](https://api.flyingharley.dev/uploads/Screenshot_2024_12_06_at_22_58_55_eef7d5b0f4.png)

## In Conclusion

Swift's protocol extensions are a potent tool for expanding functionality. However, exercising caution when incorporating default parameters within them is crucial. The absence of compiler-enforced safeguards and the potential for infinite recursion demand a mindful approach. By acknowledging these risks and implementing appropriate mitigation strategies, we can ensure the robustness and reliability of our code.


large_Table-dispatch.jpg

medium_Table-dispatch.jpg

small_Table-dispatch.jpg

thumbnail_Table-dispatch.jpg

Table-dispatch.jpg


While Swift protocol extensions offer the convenience of default parameter values and other cool things, this seemingly simple feature can introduce unexpected behavior due to the dynamic nature of protocol method dispatch

Protocol Extension Method Dispatching in Swift


Closure, a [reference type](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/closures/#Closures-Are-Reference-Types), is among the most powerful features in Swift. We often use them daily in various ways, such as passing them as arguments to other functions, dispatching tasks asynchronously, and more. Another capability we are familiar with is capturing values, which will be discussed in this memo.

## Capturing in Closure

Capturing is a powerful feature, but it can be tricky at times, especially for beginners. To understand capturing, let's first explore what "capture" means.

As we may already know, Closures (or Closure Expressions) are the foundational form of [Functions](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/functions). Functions are essentially special cases of closures with fully defined names, parameter types, return types, and more. Closures have the unique ability to "capture and store references to any constants and variables from the context in which they are defined." More importantly, Swift manages all the memory management involved in capturing for us. Cool!

However, that doesn't mean we can use it freely without any consideration! We might have encountered this common mistake when using closure capturing with *self*, like this:

![Screenshot 2024-10-29 at 22.29.14.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_29_at_22_29_14_cc6fefeca8.png)

It's clear enough to understand what's happening. The body of the "closure" has "captured" the self of "Foo", creating a cycle that cannot be broken automatically. We need to gain more insight into capturing to avoid mistakes and to harness its power for greater development efficiency.

The example above is just one form of capturing. In fact, there is another form, which involves "nested functions", as shown below:

![Screenshot 2024-10-29 at 22.37.00.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_29_at_22_37_00_a7efa6b0d3.png)
Each function defines a **scope** or **context** containing its body and parameters. In other words, the "inner function" defines an "inner context", just as the "outer function" defines an "outer context". As defined by Apple's documentation:

>A closure can capture constants and variables from the surrounding context in which it’s defined. The closure can then refer to and modify the values of those constants and variables from within its body, even if the original scope that defined the constants and variables no longer exists.

Returning to our example above, the **runningTotal** belongs to the "outer context" or the context of the **makeIncrementer** function, and it was captured by the "inner context". This allows the inner **incrementer** function to freely modify this captured variable within its body. But is that enough? There is actually a more important aspect related to the "lifetime" of that captured variable. We all know that a function’s scope, along with its local variables, will terminate after it returns. Thanks to the capturing capability, we still have access to them. This is how Swift effectively manages memory for us.

But have you ever wondered if this "refer to and modify" capability of capturing applies to value types? We are definitely familiar with "refer to and modify" reference types such as Classes. However, in the above example, our **runningTotal** variable is a value type of **Int**! We know that value types are typically copied when passed around, such as when used as function arguments or even just when assigning the value to another variable, like this:

![Screenshot 2024-10-29 at 23.07.39.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_29_at_23_07_39_936ce722c7.png)

That's what makes closures different. In fact, **runningTotal** is considered a "local variable", and it is not copied when captured from the same or an inner scope where it was defined.

So, how do we "force" it to be copied? The answer lies in using [**Capture Lists**](https://docs.swift.org/swift-book/documentation/the-swift-programming-language/expressions#Capture-Lists). Let's compare the two examples below:

![Screenshot 2024-10-29 at 23.32.22.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_29_at_23_32_22_840643c53c.png)

In the first example, the variable **a** is freely modifed by the **foo** closure.

![Screenshot 2024-10-29 at 23.35.52.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_29_at_23_35_52_bbf5dc6f0d.png)

In the second example, the "inner" **a** becomes a constant after being defined inside the capture list. This new **a** is a copy of the original **a**. Therefore, any modifications to the original **a** won't affect the copied one.
## Utilizing Capturing for state management
### Using for state manipulation inside immutable value type

In situations where we need to manage state within a value type such as a Struct, it can be tempting to do something like this:

![Screenshot 2024-10-29 at 23.46.01.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_29_at_23_46_01_f6e71ae23c.png)

It's clear that we are not allowed to do so. Instead, we can modify it slightly:

![Screenshot 2024-10-29 at 23.46.56.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_29_at_23_46_56_44fb2761a2.png)

Of course, this approach is limited, as the **currentValue** state variable is only used within the current closure or other closures. If we need broader state manipulation, such as using it as a property, we might need to consider other approaches, such as using Class or Actor for better thread safety.

However, this approach is quite handy, especially when used with Combine, like this:

![Screenshot 2024-10-30 at 00.16.58.png](https://api.flyingharley.dev/uploads/Screenshot_2024_10_30_at_00_16_58_369b8abfdd.png)

In conclusion, closures in Swift offer powerful capabilities for capturing and managing state, but they come with nuances that require careful consideration. Understanding how closures capture variables, especially in the context of value types versus reference types, is crucial for efficient and error-free code.

References:
https://www.swiftbysundell.com/articles/swifts-closure-capturing-mechanics/
https://docs.swift.org/swift-book/documentation/the-swift-programming-language/closures#Escaping-Closures

large_closure-cover.jpeg

medium_closure-cover.jpeg

small_closure-cover.jpeg

thumbnail_closure-cover.jpeg

closure-cover.jpeg

Capturing is a powerful feature, but it can be tricky at times, especially for beginners. To understand capturing, let's first explore what "capture" means.

Some things to note about capturing in Swift Closure

SwiftUI, Apple's declarative framework for building user interfaces, has revolutionized the way developers create apps for iOS, macOS, watchOS, and tvOS. By allowing developers to describe the UI using Swift code, SwiftUI offers a more intuitive and less error-prone approach compared to the traditional UIKit. But what exactly happens behind the scenes to make this magic work? In this article, we'll peel back the layers and explore the core principles that underpin SwiftUI.


# The Declarative Syntax
At the heart of SwiftUI is its declarative syntax. Unlike imperative programming, where you describe step-by-step how to achieve a result, declarative programming allows you to describe what you want the UI to look like, and SwiftUI handles the rest. For instance, in SwiftUI, you might write:

```
Text("Hello, World!")
    .font(.largeTitle)
    .padding()
```

This code describes a text view with larget font and padding, without specifying how to create, configure, or update that view. SwiftUI uses this declarative syntax to build a hierarchy of views, which it then renders to the screen.


**So how can it render views?**

Most of the time we don't need to care about that. However, behind the scenes, SwiftUI relies on a sophisticated rendering engine using your instructions to render. For iOS, these instructions are translated into UIKit components, which are then rendered to the screen. This translation layer allows SwiftUI to leverage the performance and capabilities of the underlying platform while providing a more modern and expressive API.
SwiftUI has something called the attribute graph, which includes more than just the rendered views; it also contains the state and tracks dependencies.

**How can SwiftUI understand what to render?**

When you describe your UI in SwiftUI, the framework constructs a tree of views. This view tree is then transformed into a series of platform-specific instructions before delivered to the rendering engine. We leverage many things in the [View protocol](https://developer.apple.com/documentation/swiftui/view) such as [View Builder](https://developer.apple.com/documentation/swiftui/viewbuilder), [View Modifier](https://developer.apple.com/documentation/swiftui/viewmodifier), ... to construct the views that we want to display. When we use declarative syntax to describe that, the framework understands it and constructs a tree of views. This hierarchical structure allows SwiftUI to understand the relationships between different UI elements. One important thing to keep in mind is the tree of view definition is just a struct and will be thrown away after use. Therefore, it can be created over and over again when needed.
But this is not enough, SwiftUI also needs to know **when** and **why** it should update the views. In order to do so, there are some terms called _Identity_, _Lifetime_ and _Dependency_. We will cover them now.


# The essential elements of SwiftUI
## Identity
SwiftUI uses identity to efficiently manage and render views by recognizing whether elements are the same or distinct across state changes. This is achieved through the [Identifiable](https://developer.apple.com/documentation/swift/identifiable) protocol and the **id(_:)** modifier, which assign unique identifiers to views. By leveraging these identities, SwiftUI can perform efficient diffing to determine which views have changed, been added, or removed, minimizing unnecessary updates. This mechanism is crucial for dynamic views like lists, where items can be added or removed, ensuring smooth animations, efficient rendering, and a responsive user interface.

![view-identity.png](https://api.flyingharley.dev/uploads/view_identity_f2d87a14d4.png)

Take an example of animation of the view above. When SwiftUI understand that view is actually the same view, it can smoothly transition the view with animation across multiple positions from top to bottom, instead of remove then insert another view, causing UI flick.


#### Kinds of identity
In SwiftUI, there are two types of identity: explicit and implicit (also known as structural identity). Explicit identity is assigned using the Identifiable protocol or the id(_:) modifier, providing a unique identifier for each view. Implicit identity, or structural identity, is derived from the view's position in the hierarchy and its type. This allows SwiftUI to efficiently track and update views. 

![structural-id.png](https://api.flyingharley.dev/uploads/structural_id_c1f924b346.png)


In contrast, UIKit relies on explicit identity through pointers, where each view is uniquely identified by its memory address

![pointer-id.png](https://api.flyingharley.dev/uploads/pointer_id_0c5dfd2c96.png)

As a rule of thumb, we usually want to keep our view identity as **stable** as we can. Not only does this ensure smooth transitions, but it also helps in preserving states, which is known as Lifetime (a topic we will discuss later)

Moreover, using a type eraser such as [AnyView](https://developer.apple.com/documentation/swiftui/anyview) will hide the view structure from the compiler. While type erasers can be useful for certain scenarios, they can potentially impact performance and optimizations, as the compiler loses information about the specific types of views being used. This loss of type information can hinder SwiftUI's ability to efficiently manage and update the view hierarchy.

One of the scenarios when it's tempting to use AnyView is when we need to return different types of views from a single function or property:

![anyview-usage.png](https://api.flyingharley.dev/uploads/anyview_usage_0808ea1146.png)

With the help of [@ViewBuilder](https://developer.apple.com/documentation/swiftui/viewbuilder), we can simplify the logic and avoid using AnyView:

![avoid-anyview.png](https://api.flyingharley.dev/uploads/avoid_anyview_f96068d49a.png)

## Lifetime
Lifetime helps the framework to track the existence of views and data over time. By understanding the lifecycle of a view, SwiftUI can manage resources more effectively, ensuring that views are created, updated, and destroyed at the appropriate times. This tracking is crucial for maintaining state consistency and ensuring smooth transitions. Proper management of view lifetimes helps in preserving the state and optimizing performance, as the framework can make informed decisions about when and how to update the UI.

![view-value.png](https://api.flyingharley.dev/uploads/view_value_ee634b20b4.png)

In other words, the same view with same identity can have many states _S1_, _S2_, ..., _Sn_ called **view value** during the time _T1_, T2_, ..., _Tn_. We call this the duration of the identity. When we defining view property wrapper such as @State or @StateObject inside views, we leave SwiftUI to manage them for us. SwiftUI relies on the lifetime to determine whether to preserve that value or destroy it and create a new one, which can lead to data loss if not managed correctly. With that in mind, we can conclude that _the **State lifetime** is the **View lifetime**_

## Dependencies
Dependencies help SwiftUI understand when and why to update views. When these dependencies change, they trigger the reevaluation of the body property, resulting in a new view hierarchy. This mechanism ensures that the UI remains in sync with the underlying data, providing a responsive and dynamic user experience. By leveraging dependencies like @State, @Binding, and @ObservedObject, SwiftUI can efficiently manage and update views based on the current state and data changes.

![dependencies.png](https://api.flyingharley.dev/uploads/dependencies_7f0dfdd1c4.png)

When an action triggered, the data as a dependency changes, causing the views be updated to reflect that. This can be described as a _data flow_ in SwiftUI.

![data-flow.png](https://api.flyingharley.dev/uploads/data_flow_1fb4fe5899.png)

The data flow in SwiftUI is designed to be unidirectional, ensuring a clear and predictable path for state changes. At the core of this system are property wrappers like [@State](https://developer.apple.com/documentation/swiftui/state), [@Binding](https://developer.apple.com/documentation/swiftui/binding), and [@ObservedObject](https://developer.apple.com/documentation/swiftui/observedobject), which manage the state within views. Data flows from parent views to child views, with state and bindings act as a source of truth ensuring that any changes propagate through the view hierarchy. When a state changes, SwiftUI automatically triggers a re-evaluation of the affected views' body properties, updating the UI accordingly. This unidirectional data flow simplifies state management, reduces the likelihood of bugs, and enhances the maintainability of SwiftUI applications.

On iOS 17, things will get simpler and more straightforward with the help of [Observation framework](https://developer.apple.com/documentation/Observation) by replacing ObservableObject in your data model type and so on. But we will have a separate article for that.

# Conclusion

SwiftUI relies on identity, both explicit and implicit, to recognize and manage views, ensuring smooth transitions and state preservation. The concept of lifetime helps SwiftUI track the existence of views and data, making informed decisions about when to retain or recreate state. Dependencies such as @State, @Binding, and @ObservableObject play a crucial role in triggering view updates and maintaining a synchronized UI. While type erasers like AnyView can simplify code, they can also impact performance by hiding view structures from the compiler. The unidirectional data flow in SwiftUI ensures a clear and predictable path for state changes, reducing bugs and enhancing maintainability.

By understanding how SwiftUI works behind the scenes, developers can leverage its capabilities to build efficient and responsive user interfaces for their SwiftUI applications, ensuring better performance and user experience.


large_declarative-one.jpg

medium_declarative-one.jpg

small_declarative-one.jpg

thumbnail_declarative-one.jpg

declarative-one.jpg

SwiftUI, Apple's declarative framework for building user interfaces, has revolutionized the way developers create apps for iOS, macOS, watchOS, and tvOS. By allowing developers to describe the UI using Swift code, SwiftUI offers a more intuitive and less error-prone approach compared to the traditional UIKit. But what exactly happens behind the scenes to make this magic work? In this article, we'll peel back the layers and explore the core principles that underpin SwiftUI.

SwiftUI Fundamentals: How It Works Behind the Scenes

In this post, we will walk you through some steps to build your own Copilot integrating to Xcode and VS Code, running locally on your device so you will not be worried about network or token prices while still being able to enjoy the benefits of AI supports for your productivity.

All of the tools used in this post are open source and free to use, including an open source LLM (Large Language Model) to help you generate code and other tools which can help you run that LLM as a local service and integrate it with your IDE such as Xcode or VS Code. At the end of this article, you can get the final bash file for running all steps at once including installing tools and setup running environment.
# Table of content
- Prerequisites
- Steps to integrate with VS Code 
- Steps to integrate with Xcode IDE
- Further steps
### Prerequisite 
- a MacBook with as least **16GB** of RAM. This is recommended to have smooth experience as coding requires many tools opened concurrently, while running a LLM requires a minimum **~4GB** of RAM.
- Python environment setup. It is recommended to have a Python version in **Homebrew**. If not, run this command in the terminal (assuming it is `zsh`) 
  
```console
brew install python
```
-  A downloaded LLM. We are going to use [ollama](https://github.com/jmorganca/ollama) to run our LLM locally as a service. It's quite simple to setup and use. We will go select a LLM from the [library](https://ollama.ai/library) (or other sources with other formats such as GGUF). In this case, we use the _codellama-7b_  model. Follow the installation guide to install _ollama_ (just download the zip file, extract it and drag the file into Application directory)

We then download the _codellama-7b_ and test it by this command

```console
ollama run codellama
```

Wait for the download to complete and try the model by typing some messages:

![Screenshot 2023-12-24 at 23.40.51.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_24_at_23_40_51_2f53043165.png)

Close the terminal. One important thing to note here is that the _ollama_ server will run as a background service on port **11434** by default. Just verify that it's running by this command: 

```console
sudo lsof -i :11434
```
![Screenshot 2023-12-24 at 23.48.18.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_24_at_23_48_18_ebb05f7ba8.png)

### Steps to integrate with VS Code

VS Code is a very popular IDE which supports numerous extensions to boost productivity, especially in the domain of Copilot. [Continue](https://continue.dev/) is a free but powerful extension which provides the ability of customizing the backed LLM for our needs, even with the remote or local LLM server like _ollama_. Checkout the [document](https://marketplace.visualstudio.com/items?itemName=Continue.continue) for its cool features such as code editing, code or file referenced as context, and more.
By a few simple steps, we can integrate the _ollama_ LLM server mentioned earlier to create a fully local Copilot experience.

Open the **Extension** tab from VS Code, search for "Continue" and install this extension. After that, open the configuration file to include our LLM server created in the previous steps:
- Step 1: Open the extension's "config.json" file at path: _~/.continue/config.json_ (we can quickly search and open the file by using **Cmd + P** hot key and typing the file name)
- Step 2: Include the following code inside the "models" array (assuming we are using the _codellama_ LLM as shown earlier):

```js
{
      "title": "Code Llama",
      "provider": "ollama",
      "model": "codellama"
}
```
Save the file and restart VS Code, we can see the option to switch to our recently added LLM like below:

![Screenshot 2023-12-25 at 21.36.51.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_21_36_51_6ee50e346d.png)

Please refer to [Continue document](https://continue.dev/docs/walkthroughs/codellama#ollama) for more details.

### Steps to integrate with Xcode IDE
We will use [CopilotForXcode](https://github.com/intitni/CopilotForXcode) as an extension for the Xcode IDE. It offers many functionalities similar to those found in **Continue**, but using a local LLM requires additional steps to make it works. This is due to the current version only supports OpenAI API or at least OpenAI compatible API.

To address this, we will need a **proxy** which can convert LLM server's API into OpenAI-compatible format. For this purpose, we will use [liteLLM](https://docs.litellm.ai/docs/proxy) proxy.

- **Step 1**: Create a running proxy service. Let's start by defining a _config.yaml_ file to enable it to work with our previously set up _ollama_ server as a proxy server
  - [Install](https://docs.litellm.ai/docs/) the liteLLM by this command:

```console
pip install litellm
```

or use the below if it is python3:
```console
pip3 install litellm
```

  - Paste the following code into the newly created file:

```yaml
model_list: 
  - model_name: codellama-litellm
     litellm_params:
      model: ollama/codellama
      api_base: http://0.0.0.0:11434
      api_key: "any"

```
Note that the **api_base** includes the address and port of the _ollama_ server.
Please refer to [this](https://docs.litellm.ai/docs/providers/ollama) for more details
  - Start the liteLLM proxy server by the following command:

```console
litellm --config ./config.yaml
```
  - The server will run on port **8000** by default and you should see this:

![Screenshot 2023-12-25 at 22.08.34.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_22_08_34_984db39adb.png)

This **8000** port will be used to receive requests from the CopilotForXcode in the next step.
- **Step 2**: Install the CopilotForXcode and redirect its requests into our created proxy server in Step 1.
  - Install and give the needed permissions for the extension as mentioned in their [document](https://github.com/intitni/CopilotForXcode?tab=readme-ov-file#install)
  - Open the extension and configure the local server:

![Screenshot 2023-12-25 at 22.13.12.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_22_13_12_80a666a3dc.png)

Note that we use **localhost** instead of **0.0.0.0** to avoid the error for **App Transport Security policy**.
  - We can test the request by clicking the **Test** button and check the response:

![Screenshot 2023-12-25 at 22.13.28.png](https://api.flyingharley.dev/uploads/Screenshot_2023_12_25_at_22_13_28_f2f4a5f785.png)

  - Then click the **Save** button and back to our Xcode IDE and start using the Copilot!

For simplifying the steps to start the server every time we do coding from now on, let's put them into a simple bash script:
```bash

#!/bin/bash

# Start the ollama server in a new window
(ollama serve &)

# Wait for the server to start listening on port 11434
while ! nc -z localhost 11434; do sleep 0.1; done

# Run the litellm command in the current window
litellm --config ./config.yaml

```

Finally, you can get the bash file for running all the above steps [here](https://github.com/hieupham9809/local-copilot). Every time we need to run that server, just running that bash file and we're good to go!

### Further steps
This approach has some limitations:
- Need more efforts to configure for each LLM, despite many LLM server like _ollama_ does support [importing from other file formats](https://github.com/jmorganca/ollama/blob/main/docs/import.md) such as **GGUF**
- The offline LLM won't be up to date with newest changes & improvement for technical stuffs and it relies on every update/fine-tuning of the current model to get latest updates

Besides that, it's worth to try and it's also good enough for increasing our productivity without being worried about the token costs, etc ... We can think about the way to support Internet searching/crawling based on our needs to make our Copilot more useful. 

large_copilot-thumb.jpeg

medium_copilot-thumb.jpeg

small_copilot-thumb.jpeg

thumbnail_copilot-thumb.jpeg

copilot-thumb.jpeg

In this post, we will walk you through some steps to build your own Copilot integrating to Xcode and VS Code, running locally on your device so you will not be worried about network or token prices while still being able to enjoy the benefits of AI supports for your productivity.

Build a copilot running locally on IDEs by using ollama and liteLLM

After comprehending the complex and demanding tasks involved in the [build process](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2), we can now shift our focus to the importance of build performance and how to enhance it by adhering to best practices. This will assist the build system in working more efficiently, providing us, as developers, with additional time to implement our cool features.
The article is divided into 3 parts:
1. [Understanding the general build system and some terminologies (part 1)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-1)
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. **How can we help the Xcode build system (part 3)**

# The build performance
In previous parts, we may have observed that build performance can be influenced by various factors. Some of these factors include  the **dependency order**, the **complexity of expressions**, the **build script** and the **Objective-C/Swift interfaces**.

## The dependency order
![parallel-build-saving-time.png](https://api.flyingharley.dev/uploads/parallel_build_saving_time_39b9fdc91d.png)
We are all aware that processing tasks in parallel, as opposed to one by one or sequentially, leads to increased speed. This is particularly crucial with the support of modern multicore devices; it would be inefficient in terms of both resources and time not to harness their potential. Fortunately, we have a couple of methods to achieve this.

The first method involves enabling the _Parallelize Build_ option in the Scheme editing menu. This allows Xcode to simultaneously build targets that are independent of each other, ultimately enhancing the overall build speed. However, it's important to note that this option is not activated by default, and its use does not guarantee that there will be no build issues, especially in projects with intricate dependencies. It is advisable to test this option to identify potential errors and carefully weigh the trade-off between improved build time and build stability.

![enable-parallel-build.png](https://api.flyingharley.dev/uploads/enable_parallel_build_a9b2968136.png)

The next method involves examining how we have configured dependencies within Xcode. As discussed in the previous article, dependencies are configured through the _Build phase_ in the target setting by _Target Dependencies_ (explicit) and _Link Binary with Libraries_. With a deeper understanding of build dependencies and the current Project/Workspace build configurations, we can enhance build performance by implementing parallelization. The [talk](https://developer.apple.com/videos/play/wwdc2018/408/) from WWDC18 provides us some strategies to "break down" some dependencies that hider parallelization  during the build process.

We can begin by addressing what they refer to as the "Do Everything" dependency. In this example it's the **Test target**, which tests numerous components including **Game**, **Shaders**, **Utilities** requiring it to be built last.

![test-target-before.png](https://api.flyingharley.dev/uploads/test_target_before_5312781f42.png)

We then "break down" the **Test target** into small targets to test each of the above components separately. By doing so, each test target only needs to have dependency on its corresponding component, enable it to be built at an earlier stage.

![test-target-after.png](https://api.flyingharley.dev/uploads/test_target_after_8cefd3a6ba.png)

The next type of dependency is what they refer to as "Nosy Neighbors". This type of dependency to a target needs to exist but it only requires a small portion of that target. By just simply "move" that thing out of the target and create their own target, we can get more parallelism and even significant impact on the overall build timeline.

![break-down-common-code.png](https://api.flyingharley.dev/uploads/break_down_common_code_568ddd68bc.png)

And the last one is what they call the "Forgotten Ones". These are dependencies that we simply forgot to remove or clean up, a common situation that occurs frequently. For instance, there might be a scenario where we initially import another target to access some utility methods. Over time, we may replace those methods with others or decide that we no longer need them. However, we might forget to remove the import statement for that target, leading to a redundant dependency.

## Build Scripts

Build scripts provide a convenient way to customize the build process, such as generating assets or moving files. It is recommended to execute them only when necessary, as running these scripts incurs a cost. It is crucial to note that the Xcode Build System relies on entities known as **input files** and **output files** to determine whether it needs to execute a script. Apple highly recommends declaring these **input files** and **output files**, and you can find detailed guidelines in their [documentation](https://developer.apple.com/documentation/xcode/running-custom-scripts-during-a-build). Some of the rules the build system employs to trigger a script rerun include: **no declared input files or changes in input files**, **missing output files**, and so on.

## The complexity of expressions

_Type inference_ is one of the convenient features not only in Swift but also in modern programming languages nowadays. It can help us avoid boilerplate code and have them easy to read as it will be shorter. However, it's not always useful. Take a look at this example:

![implicit-type.png](https://api.flyingharley.dev/uploads/implicit_type_dbc755125f.png)

It seems short enough but not easy to reason about. It takes more efforts from both the compiler and other developers to figure out which type this **bigNumber** is, as the **pow** method inside this expression doesn't tell anything about that. We can improve this very easily by just simply put the **Double** type after the variable name.

We might also face with this situation while coding: we edit our code with some cool ideas and press the build button. Everything seems okay until we found that the compiler takes longer time to compile our code. Finally, it gives up with the error said that it was unable to type-check our expression in reasonable time. This is not the compiler's fault. This is our responsibility to look back our code and there is definitely some unnecessary complexity here.

![complex-expression-build.png](https://api.flyingharley.dev/uploads/complex_expression_build_4d649a60fc.png)

The provided code should not be accepted in the reviewing process, even if the compiler were somehow strengthened enough to handle it. A clearer and more "Swifty" alternative exists, as demonstrated below:

![complex-expression-fix.png](https://api.flyingharley.dev/uploads/complex_expression_fix_8f77c714bd.png)

When coding in Swift, it's crucial to consider the use of _AnyObject_. While it may be tempting due to its convenience, where we simply utilize methods and properties from the object and let the compiler do the rest, this approach comes with a cost. As Swift processes all source files from the current target and others, it must search for methods and properties to call in this manner. It does so because if there is no matched implementation, it will result in an error. To address this, we can use _Protocol_ instead of _AnyObject_. This allows the compiler to precisely determine what to call, and it provides opportunities to verify whether all implementing types correctly implement those methods and properties.

![avoid-using-any-object.png](https://api.flyingharley.dev/uploads/avoid_using_any_object_66bc38b5d7.png)

## The Swift's file dependency and the Objective-C/Swift interfaces

We might already be aware that **Caching** is a straightforward way to improve performance when handling repetitive tasks, in this case the rebuild process. By reducing the amount of work needed for each rebuild task, we can save time for the compiler. In Swift, the compiler determines which files should be rebuilt based on _file dependencies_ within a module. In simple terms, if a file is changed, files depending on it are more likely to be rebuilt as well, unless the changes are in function bodies and do not affect the file's interface. In the case of **Cross-Target Dependencies**, the entire dependent target will be rebuilt instead.

![cross-target-dependency.png](https://api.flyingharley.dev/uploads/cross_target_dependency_843c5c8d7d.png)

However, these considerations apply specifically to Swift dependencies and Swift targets. In real-world scenarios, we often have mixed Swift and Objective-C interfaces, as illustrated by this diagram:

![mixed-source-dependencies.png](https://api.flyingharley.dev/uploads/mixed_source_dependencies_4dba335b72.png)

With information from the [previous article](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2#:~:text=time%20as%20well.-,The%20compilers,-Clang), from left to right, we can see that Swift files depend on Objective-C headers (.h files) through the _Bridging header_, and the Objective-C implementations (.m) depend on those Swift files by using the _Generated header_. If we want to reduce the amount of work on rebuild, we need to shrink the content of _Bridging header_ files and _Generated header_ files as much as possible. For example, by using the _private_ keyword in Swift code, we can prevent it from being unnecessarily exposed in the _Generated header_. Or we can use _categories_ to break up the interface in the _Bridging header_, avoiding some internal types in Objective-C code from being exposed to Swift unexpectedly.

![minimal-bridging-header.png](https://api.flyingharley.dev/uploads/minimal_bridging_header_2aa96fcbaf.png)
![categories-to-break-header.png](https://api.flyingharley.dev/uploads/categories_to_break_header_0fd5c206d6.png)

## And one more thing
Xcode also has a useful feature called **Build With Timing Summary**. We might notice the build performance decreasing just by a "feeling" or when there is a significant time consumed during building. This build option will display more details about each build task and the duration it takes for its build. Simply triggering the build with timing summary will give us more information about what's going on there.

![build-with-timing-summary.png](https://api.flyingharley.dev/uploads/build_with_timing_summary_1863bce30f.png)

# What can the compiler tell us when something goes wrong?
By default, if Xcode encounters an error during a build, it reports the error and stops immediately. We can force it to keep going with the build by the “Continue building after errors” setting in the General tab of Xcode preferences. It then continues to build and reports errors for the rest of our project's files. However, as an error can be the cause of other errors, and we might only be interested in the error causing the issue (root cause), displaying all of the errors can be unnecessary, making it sometimes hard to debug and fix the issue.

Whenever an error occurs, Xcode tries its best to tell us as much information as it can. We first need to switch to Xcode’s issue navigator or use **Cmd-5**. Most of the time, we will see the problem here just by reading the error log and navigating to the source code. If it's not, for example, the **link issue** from the linker, when it fails to look for the symbols needed when linking. In that case, we will need to get more details about the issue by using the **report navigator** (Cmd-9) and see what symbols are missing (sometimes we might need to click the log icon to see where those symbols are referenced from).

![detail-build-error.png](https://api.flyingharley.dev/uploads/detail_build_error_be605958ee.png)

And that's it. In this part, we've walked through some best practices to help the build system to be more efficient by understanding what is does behind the scenes. Those are simple fixes, but they can significantly improve build performance, allowing us to spend less time building and more time coding.

large_xcode-build-part-3.jpeg

medium_xcode-build-part-3.jpeg

small_xcode-build-part-3.jpeg

thumbnail_xcode-build-part-3.jpeg

xcode-build-part-3.jpeg

After understanding [the build process behind the scenes](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2) as well as its complex and heavy tasks, its time for us - as our main purpose of this series - to understand how the build performance important is, and how we can gain better performance by following some of the best practices which help the build system do their works more efficient, giving us as developer more free time to implement our cool features.

The article is divided into 3 parts:
1. [Understanding the general build system and some terminologies (part 1)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-1)
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. **How can we help the Xcode build system (part 3)**

Understanding the Xcode build system - Part 3 - How can we help the Xcode build system

large_xcode-build-system-p2.jpeg

medium_xcode-build-system-p2.jpeg

small_xcode-build-system-p2.jpeg

thumbnail_xcode-build-system-p2.jpeg

xcode-build-system-p2.jpeg

Building app is a complicated process that requires many tasks needed to be done to make an completed cool app and release it to user. Fortunately, the Xcode IDE handles most of the work behind the scenes, so all we need to do is to click the "Build" button on the toolbar and focus on our development. However, in order to use this efficiently, it is important to understand the process, as there may be times when we need to troubleshoot build errors. In this part, we will take a closer look at Xcode's build system, what it does automatically for us, and what we can do to make the build process more efficient and reliable.

Understanding the Xcode build system - Part 2

As we might notice, accessing files on disk is one of the slowest operations on any devices, especially with a huge number of files, even with small files. In this article, I will discuss about the challenges we were facing during the time of maintenance the Chat data storage feature of the LINE iOS app, and how we improve the performance issue by proposing the new way of managing chat storage that can also help improve user experience while using this feature.
For more details, [please follow to this article](https://engineering.linecorp.com/en/blog/new-way-of-managing-chat-storage-in-the-ios-version-of-line).

large_IMG_D9B7BE299A1F-1.jpeg

medium_IMG_D9B7BE299A1F-1.jpeg

small_IMG_D9B7BE299A1F-1.jpeg

thumbnail_IMG_D9B7BE299A1F-1.jpeg

IMG_D9B7BE299A1F-1.jpeg

Introduce a new way for storing chat data and for quickly getting storage size. Improve UX by providing user a new way for managing their chat more efficiently

The new way of managing Chat storage in the iOS version of LINE

Building app is the thing that we do everyday, especially while development. In this article, we will take a closer look at Xcode's build system, what it does automatically for us, and what we can do to make the build process more efficient and reliable.
The article is divided into 3 parts:
1. **Understanding the general build system and some terminologies (part 1)**
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. [How can we help the Xcode build system (part 3)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-3-how-can-we-help-the-xcode-build-system)

# Some terminologies
## Software build
According to [Wikipedia](https://en.wikipedia.org/wiki/Software_build):
> a build is the process of converting source code files into standalone software artifact(s) that can be run on a computer, or the result of doing so.

In our context, a smartphone is also a "computer" as well. As a software engineering, we do "coding" everyday, and the result of this process is to create a program which can run on our device
## Framework and Library
We might have heard many times about **Framework** and **Library** everyday and they sometimes can be used interchangeably, but they actually have different meanings. The main difference can simply described by this image:

![framework_library_main_difference.png](https://api.flyingharley.dev/uploads/framework_library_main_difference_1a97e1ee1f.png)

For more understanding, I'd recommend you to read this interesting [article](https://www.linkedin.com/pulse/module-package-library-framework-real-life-example-mohammad-ibrahim/).

In iOS development using XCode, those terms mentioned above have slightly more specific meanings.

**Library** is a collection of _object files_ (_.o_ files) that a program can link to. There are two types of library in iOS: **Static library** and **Dynamic library**. Static library as its name stands for, is packed into the main executable and linked at compile time and basically it only contains executable code. Object files in this kind of library are archived into _.a_ file. And since this kind of library is linked at compile time, it will not be **reused** or **shared** between programs.
To improve the above limitation, we also have **Dynamic library** which is referenced by the linker at runtime, so it is not copied into a program. And instead of _.a_ file, dynamic libraries are _.dylib_ files.

At WWDC23, Apple has introduced a [new generation of Library](https://developer.apple.com/videos/play/wwdc2023/10268/) which **inherits** from the above ones called **Mergeable Library**, which makes dynamic libraries become **mergeable**. It takes advantages from both **Static library** and **Dynamic library**. Similar to Dynamic library, it reduces the works of the static linker comparing to Static library (as the **merging** process will be faster than **linking** statically), which helps the build become faster too. Moreover, many dynamic libraries are able to be **merged** into only one, meaning there are less things to do for the dynamic linker, thus improves the app launching as well. It's also able to reduce the size after the merging process.

**Framework** is the one we might be more familiar with e.g. UIKit, CoreData, ... We use them everyday of iOS development. Unlike libraries, frameworks are structured directories containing code, sub-directories, shared libraries, and other support files e.g. assets files, ... Similar to the above principles, the key different between a library and a framework is that the framework can "call" our code, which can be define as **Inversion of Control**. 
And similar to **Library**, we also have **Static framework** and **Dynamic framework**.

**Static frameworks** are linked during build time and **Dynamic frameworks** are linked at runtime. The important thing to note that there is different between **user-provided dynamic frameworks** and **system-provided dynamic frameworks** where we have to embed the user-provided ones within our app bundle and they can not be updated independently from our app like the system-provided ones. For example, an app built with Swift 5.0 will run on systems that have a Swift 5 standard library installed, as well as those with a Swift 5.1 or Swift 6.

![abi-stability.png](https://api.flyingharley.dev/uploads/abi_stability_f0fddf278f.png)

Obviously, the **dynamic framework** can help reduce the app size as well, but it depends on specific situation. Moreover, both **dynamic framework** and **static framework** have trade-offs on performance. The **static framework** has faster startup but slower build times. While the **dynamic framework** can be size-efficient as it can avoid library duplications inside the app bundle. In general, it is recommend to use **static framework** when possible. For more details, I'd like to suggest this [article](https://www.emergetools.com/blog/posts/static-vs-dynamic-frameworks-ios-discussion-chat-gpt)

# Xcode build system
## What is a build system
A **build system** is a collection of software tools that are used to facilitate the build process. We might have heard about many build systems before e.g. GNU Make, CMake, Buck, Bazel, Gradle ... and our Xcode build system. With the helps of build systems, our developer life is more easier and thus we can focus on our development. Bazel's [documentation](https://bazel.build/basics/build-systems#what_is_a_build_system)  has a very straightforward definition about this:

>Fundamentally, all build systems have a straightforward purpose: they transform the source code written by engineers into executable binaries that can be read by machines. Build systems aren't just for human-authored code; they also allow machines to create builds automatically, whether for testing or for releases to production. In an organization with thousands of engineers, it's common that most builds are triggered automatically rather than directly by engineers.

## Why do we need it?
Obviously, most engineers don't need to care about build system when they are learning to code. We usually starts by using the compiler directly to compile our code e.g. _gcc_, _javac_, _swiftc_, ... and our code just works. However this is only a few files and on bigger projects, things are not just simple like that. We might have to deal with many files, many libraries and frameworks, even with many programming languages and many compilers. The build process now is no longer a single-step process. We now need to care about what is called _dependencies_, the orders between them to make sure the build process works properly and correctly. Without the help of the build system, this process will be error-prone and things can easily get out of hand.

So how about using shell scripts in order to automatically do the above tasks? Well, you can get what you want by using shell scripts to automate things. However, we still have to face with other problems including the scalability problem as follow:
- **Tedious**: Shell scripts can become tedious to write and maintain as the project grows in complexity.
- **Slow**: Shell scripts can be slow, especially if they rebuild dependencies every time they are run.
- **Difficult to release**: It can be difficult to release a project that is built using shell scripts, as there are many steps involved and it can be easy to make mistakes.
- **Vulnerable to disaster**: If your hard drive crashes, you may lose all of your build scripts and other important files.
- **Difficult to scale**: It can be difficult to scale a project that is built using shell scripts, as each developer needs to have their own environment set up.
- **Not portable**: Shell scripts are specific to the operating system and shell environment that they are written for. This can make it difficult to use them on other systems.
- **Not robust**: Shell scripts are not as robust as other types of build systems. They are more likely to be affected by errors and unexpected input.
- ...

That's why we not only need a **tool**, but also a **system** to avoid any hassle.

## SDKs
**SDK** stands for _software development kit_. Also known as a devkit, the SDK is a set of software-building tools for a specific platform, including the building blocks, debuggers and, often, a framework or group of code libraries such as a set of routines specific to an operating system (OS). For example, for every official release of Xcode, it is usually included SDKs for platforms such as iOS SDK, watchOS SDK, tvOS SDK and newly visionOS SDK.

## Xcode Command Line Tools
> This is a package enables UNIX-style development via Terminal by installing command line developer tools, as well as macOS SDK frameworks and headers. Many useful tools are included, such as the Apple LLVM compiler, linker, and Make. If you use Xcode, these tools are also embedded within the Xcode IDE.

Behind the scenes, the Xcode IDE use this tool for the build process. This tool also contains some crucial utilities for software development, not only for softwares running on Apple devices. For example the c++ compiler, gcc, git, etc ... are also included. More details about it are described at [here](https://mac.install.guide/commandlinetools/8.html)

## Xcode build system and other build systems

### Xcode
As defined by [Apple](https://developer.apple.com/documentation/xcode/build-system), the Xcode build system manages the tools that transform your code and resource files into a finished app. It organizes the source code and assets in a structure with many terms we might have been familiar with e.g. Project, Workspace, Target, Asset Catalog, Dependencies, ... through the Xcode IDE. They not only help us increase productivity ourself, but also help us with the maintenance and scalability in the future. We will dive deeper into this later in the next section.

Note that the Xcode IDE is totally different with the Xcode build system as it not only contains the Xcode build system but also other tools for development such as code editor, xib editor, debugger and so on.

The Xcode build system is a very useful tool for our development to make a completed app, but it is not the only way. This interesting [Article](https://medium.com/@vojtastavik/building-an-ios-app-without-xcodes-build-system-d3e5ca86d30d) describes how we can build and install an iOS app into the Simulator and Device as well **without** using the Xcode IDE at all.

### Bazel
[Bazel](https://bazel.build/about/intro) is a Google's open-source build and test tool similar to other build systems that have been mentioned before. It uses a human-readable, high-level build language, in this case it is Starlark - a [domain-specific language](https://en.wikipedia.org/wiki/Domain-specific_language) (DSL). It offers the some advantages such as **fast but reliable** by using caches and parallelism, **multiple platforms** (Linux, macOS, Windows), **scalable and efficient for huge project** and **very extensible** (we can use it for development not only in iOS but also in other system, with different language and framework by using **rule** e.g. Android, C / C++, Java, Python, Scala, etc ...) See more details about how to use it especially for [iOS development](https://github.com/bazelbuild/rules_apple/blob/master/doc/tutorials/ios-app.md).

### Buck2
[Buck2](https://github.com/facebook/buck2) is an upgrade to the original [Buck build system](https://buck.build/) ("Buck1") designed by Meta. It is the build system similar to Bazel (distributed compilation with Remote Execution API) and Buck1 but with some improvements such as **2x faster**, **tracks dependencies with far better accuracy** than Buck1, **support for ultra-large repositories through filesystem virtualization**, ...

There is a fact that those above tools can not replace Xcode, they all use some of the Xcode tools such as Xcode IDE, Xcode Command Line tool for the build process.

In the next part, we will go to more details about the Xcode project structure and how it organizes things.

# References
https://www.linkedin.com/pulse/module-package-library-framework-real-life-example-mohammad-ibrahim/
https://medium.com/@m.tabrizi/ios-library-vs-framework-30866c41f100
https://www.emergetools.com/blog/posts/static-vs-dynamic-frameworks-ios-discussion-chat-gpt
https://medium.com/swlh/a-brief-introduction-to-build-systems-1e45cb1cf667

large_Designer image.jpg

medium_Designer image.jpg

small_Designer image.jpg

thumbnail_Designer image.jpg

Designer image.jpg

Building app is the thing that we do everyday, especially while development. In this article, we will take a closer look at Xcode's build system, what it does automatically for us, and what we can do to make the build process more efficient and reliable.
The article is divided into 3 parts:
**1. Understanding the general build system and some terminologies (part 1)**
2. [Understanding the Xcode build system and Xcode project structure (part 2)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-2)
3. [How can we help the Xcode build system (part 3)](https://flyingharley.dev/posts/understanding-the-xcode-build-system-part-3-how-can-we-help-the-xcode-build-system)

Understanding the Xcode build system - Part 1