# Tokyo day
![landing.jpg](https://api.flyingharley.dev/uploads/landing_494fbdafa0.jpg) ![airport.jpg](https://api.flyingharley.dev/uploads/airport_31970fafb8.jpg)
_Landed at Narita Airport - Tokyo_


![city-1.jpg](https://api.flyingharley.dev/uploads/city_1_39cedd25f6.jpg)
_Heading to hotel_
![city-2.jpg](https://api.flyingharley.dev/uploads/city_2_72e7e40eab.jpg)
![lake.jpeg](https://api.flyingharley.dev/uploads/lake_66d45909fd.jpeg)



![dishes-1.jpg](https://api.flyingharley.dev/uploads/dishes_1_9567288e83.jpg)
_First lunch..._

Walking a lot...
![street-2.jpg](https://api.flyingharley.dev/uploads/street_2_e281b83dad.jpg)
![street-1.jpg](https://api.flyingharley.dev/uploads/street_1_7958206b78.jpg)
_Crowded street_


![pagoda-1.jpg](https://api.flyingharley.dev/uploads/pagoda_1_8a2fb44b0b.jpg)
_Senso-ji_

![pagoda-2.jpeg](https://api.flyingharley.dev/uploads/pagoda_2_47a21070cf.jpeg)
![mrt.jpg](https://api.flyingharley.dev/uploads/mrt_b4903f9e3c.jpg)

# Hack days
Heading to LY office... 
Just walk... 🚶‍♂️🚶‍♂️🚶‍♂️
![office-building.jpg](https://api.flyingharley.dev/uploads/office_building_752765f673.jpg)
![office-building-2.jpg](https://api.flyingharley.dev/uploads/office_building_2_41e4f3514a.jpg)
_There it is! Tokyo Garden Terrace Kioicho_


![office-1.jpg](https://api.flyingharley.dev/uploads/office_1_750887d6c3.jpg)
_Finally found Brown and his friends..._


![office-3.jpg](https://api.flyingharley.dev/uploads/office_3_5a1fed86c2.jpg)
![office-2.jpg](https://api.flyingharley.dev/uploads/office_2_91165c3629.jpg)

![hackday-start.jpg](https://api.flyingharley.dev/uploads/hackday_start_ecbc14c751.jpg)
_It's hack time!_

![hackday-1.jpg](https://api.flyingharley.dev/uploads/hackday_1_e4ac2ca0a9.jpg)
![working.jpg](https://api.flyingharley.dev/uploads/working_749fd8ab5e.jpg)
_Didn't realize we were quite serious 😅_

![toy-1.jpg](https://api.flyingharley.dev/uploads/toy_1_df10f535ce.jpg)
_Let's see what's inside this little cute toy..._
![toy-2.jpg](https://api.flyingharley.dev/uploads/toy_2_9f57f5304e.jpg)
_When it became a real mess... 🤯_

![foods-2.jpg](https://api.flyingharley.dev/uploads/foods_2_2685a4e6a0.jpg)
![foods.jpg](https://api.flyingharley.dev/uploads/foods_49653426df.jpg)
_Break time 🤤_

### Presentation
After 2 days, time for presentation & exhibition...

![presentation-2.jpg](https://api.flyingharley.dev/uploads/presentation_2_f69e1d3a24.jpg)
_So many incredible ideas which can blow our mind..._

![presentation.jpg](https://api.flyingharley.dev/uploads/presentation_88a98931c1.jpg)
_There were only 90 seconds. Fortunately, I managed to catch my breath..._
![exhibition.jpg](https://api.flyingharley.dev/uploads/exhibition_30e7b07511.jpg)
![competition-1.jpeg](https://api.flyingharley.dev/uploads/competition_1_8a25b18bc1.jpeg)
We did a great job, bros! 💪


large_event-hackday-start.jpg

medium_event-hackday-start.jpg

small_event-hackday-start.jpg

thumbnail_event-hackday-start.jpg

event-hackday-start.jpg

Earlier of this month, I and my teammates participated in a hackathon organized by LY Corp, which was open to all employees from LY's global offices. 
It was an incredible experience with many exciting moments. Let's take a look...

My business trip to Japan in 2025


## 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

All Posts

My business trip to Japan in 2025

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

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

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

Storage Optimization on MacOS for Developer

Swift Concurrency and Legacy Primitives: A Balancing Act