
<LeadParagraphWrapper>
For many years, we have leaned on UIKit to design user interfaces, but SwiftUI is now gaining momentum as a powerful alternative. 
SwiftUI not only reduces the amount of code needed to create the same UI, but it also saves developers from the trouble of debugging auto layout problems. 
To fully understand and adopt this shift, we need to adjust our mindset accordingly.
</LeadParagraphWrapper>

### Event-Driven Approach
UIKit offers an imperative, event-driven user interface where views are built through a series of events that perform various operations and eventually combine to create what appears on the screen. 
This means you need to manage all state changes during events such as when view is loaded or button is pressed. 
The main disadvantage of this approach is the difficulty of maintaining synchronization between the user interface and its state. 
Each time the state changes, you have to manually adjust views—adding, showing, or hiding them—to keep everything aligned with the current state. 

Let’s say we have a list that retrieves its data from a backend service. 
The user can press a button to get the most updated list. Let’s take a look at how this would be represented in UIKit.

![images/event-driven-diagram](/images/posts/4/event-driven-diagram.jpeg)

> To sync your UI with the current data, you must call `tableView.reloadData()`. If we don’t make this call, the prior work becomes meaningless.

This process shows that the view controller handles many tasks. In a more complex app, this can make the view controller very large and hard to manage. 
You’ll need to write code and set up logic for how the view controller, view, and events interact. Since you are responsible for the entire process, you must also think about performance.

### Data-Driven Aproach

SwiftUI is a declarative, data-driven UI framework. But what does `declarative` really mean? In an imperative world, you’re responsible for all aspects, such as layout, behavior, and data binding. 
In contrast, a declarative world lets you specify what you want, and the framework manages the details. It’s like assembling furniture yourself (imperative) versus buying a pre-assembled piece from a store (declarative). 
With a data-driven framework, the view controller is no longer needed. The state, directly controls what is displayed to the user. Let’s see the same example in SwiftUI.

![images/data-driven-diagram](/images/posts/4/data-driven-diagram.jpeg)

The list data is tied to the view, so any changes to the list automatically update the UI. When user tap the button, we just update the state, and the view refreshes with the new list—no controller needed. This is what makes it "data-driven”.

> UI = f(state)

In SwiftUI, the UI is a function of the model’s state. To update the UI, you no longer directly manipulate the individual UI components. Instead, you bind the UI elements to underlying models. 

It’s easy to grasp the basics of SwiftUI, but what happens behind the scenes is less clear. 
To minimize this lack of clarity and write effective code, there are key concepts we need to understand.


### View Identity

In UIKit, views are class type, and thanks to nature of reference type, each view has its own pointer for identification.

![images/view-indetity](/images/posts/4/view-indetity.jpeg)

In SwiftUI, views are structs and do not use pointers. To keep things efficient, SwiftUI needs to know if views are the same or distinct. 
This helps the framework handle transitions smoothly and render views correctly when their values are updated. A view is a struct that conforms to the `view` protocol, unlike a class that inherits from a base class like `UIView`. 
This means that your view doesn’t inherit any stored properties. It is allocated on the stack and passed by value.

View identity is crucial for understanding SwiftUI's rendering process. 
SwiftUI uses two methods to identify views: explicit identity and structural identity. Let’s explore both approaches.

### Explicit Identity

Views can be identified through custom identifiers.This is something you might notice when iterating over views in a ForEach loop. 
Explicit identity can be set using `.id(...)`, which ties a view’s identity to a specific value.

``` swift
func id<ID>(_ id: ID) -> some View where ID : Hashable
```

Let’s take a look an example:

``` swift
struct OlympicsMedalList: View {
    let Countires = [Country(name: “Türkiye”, capital: “Ankara”, medalCount: 10),
                      Country(name: “Spain”, capital: “Madrid”, medalCount: 15),
                      Country(name: “Italy”, capital: “Rome”, medalCount: 20)
]
    
    var body: some View {
        ScrollView {
            ForEach(Countires, id: \.name) { country in
                RowView(country: country)
            }
        }
    }
}
```

RowView will be identified by the name, as each country name is intended to be unique.

#### Tips for Using Explicit Identity:

- Use unique and stable identifiers to avoid bugs.
- Only apply explicit identity when necessary, as overuse can impact performance.
- Ensure identifiers remain consistent, especially when data is updated from external sources.

### Structural Identity

All SwiftUI views need an identity. If a view doesn’t have an explicit identity, it will have a structural identity. 
Structural identity is determined by the view’s type and its position in the hierarchy. 
SwiftUI uses this hierarchy to provide an implicit identity for the views.

``` swift
struct LogoView: View {
    	@state var isLoading: Bool = true

    var body: some View {
        if isLoading {
            progressView()
        } else {
            LogoImage()
        }
    }
}

print(Mirror(reflecting: LogoView(user: nil).body))
// Mirror for _ConditionalContent<progressView, LogoImage>
```

This approach results in two entirely distinct views depending on the boolean state. 
In reality, SwiftUI creates an instance of ConditionalContent behind the scenes. 
This ConditionalContent view manages the display of one view or another based on the condition. 
Even if these views are not distinct but rather instances of the same view with different parameters, they will still have different identities.

``` swift
struct LogoView: View {
    	@state var isLoading: Bool = true

    var body: some View {
        if isLoading {
            LogoImage
                     .mode(.loading)
        } else {
            LogoImage
                    .mode(.success(data))
        }
    }
}
```

By using an if statement in this example, we conditionally enable or disable the view. 
SwiftUI will handle the creation and destruction of views according to the state of the condition. 
The process may look accurate, but it leads to losing the state of the ComplexView instance during condition changes because SwiftUI regenerates the view within the if statement branches. 
Additionally, it may cause unwanted animations during the view transitions. Apple recommends keeping the view's identity by using conditionals in view modifiers, rather than using if/else statements.

``` swift
struct LogoView: View {
    	@state var isLoading: Bool = true

    var body: some View {
            LogoImage
                     .mode(isLoading ?  .loading :  .success(data))
    }
}
```

Effective use of structural identity is crucial for optimizing your app and decreasing the number of bugs.

### View Hierarchy

The fundamental UI element in SwiftUI is a View. How well we define and manage its state significantly influences the app’s performance and visual quality.

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

A computed body property defines the content of the view. 
SwiftUI builds a hierarchy of views. When SwiftUI renders a view, it retrieves the view's body. 
If the view includes custom subviews, SwiftUI will also need to fetch the body of each nested custom view to display everything properly. Here’s an example:

![images/view-hierarchy](/images/posts/4/view-hierarchy.jpeg)

SwiftUI can't keep asking for view bodies endlessly, it needs to break recursion at some point. 
It needs a core set of primitive views that can be rendered directly without requiring their body. 
In this example, recursion terminates when SwiftUI requests the body of `Text`, `Image` or `Spacer`. 
SwiftUI’s primitive components does not require further body requests for rendering. This is managed by the `Never` type:

![images/never-diagram](/images/posts/4/never-diagram.jpeg)

The type Never is an object type with no values and cannot be constructed. 
It is primarily used in Swift functions that terminate execution. 
Additionally, since the compiler needs to handle every object as a view, `Never` is considered a `View`.

``` swift
extension Never: View {
  public typealias Body = Never
  public var body: Never { get }
}
```

When SwiftUI faced with a view that has a Never body, it knows exactly when to halt, effectively breaking the recursion.

### Lifetime

When a view's identity changes, it marks the end of its lifetime. 
The lifetime of a view is closely linked to its identity, so to maintain consistent state, you must ensure that its identity is properly assigned. 
However, when a view's property changes, the view itself remains the same. 
The identity of the view stays constant; only the state of the view has been updated. 
When a view appears on the screen (after onAppear is called), any updates to the view generate new values, but SwiftUI still considers it the same view. 
This means the view's identity and lifetime remain unchanged. 
The view's lifetime ends when its identity changes or when it is removed from the screen (after onDisappear is called).

#### Key points:

- A view remains active for as long as its identity is valid.
- You manage the lifetime of a view by controlling its identity.
- Always assign a stable identity to your data.
- Every pixel you see on the screen is defined by a view. What makes SwiftUI views special is their declarative, compositional, and state-driven nature.
- Refactoring your SwiftUI code is fine because extracting subviews has almost no performance cost. SwiftUI views and traditional UI views both create parts of the interface. In SwiftUI, a view requires just one property: body, which is itself a view.

### Conclusion
In summary, SwiftUI is more than just a new tool for building apps; it’s a new way of thinking about app development. 
SwiftUI helps you write cleaner code, manage app state more easily, and smooth integration across Apple’s ecosystem. 
SwiftUI is not write once run everywhere, it is learn once run everywhere.
Based on my experience with SwiftUI, I can tell you it’s a powerful tool that redefines how you build apps. Dive into SwiftUI and discover how it can simplify your development process and improve your user experiences.

SwiftUI: Transform Your Developer Mindset


<LeadParagraphWrapper>
There are several phases involved in launching an application, most of which the system handles automatically. 
The operating system calls methods in your app delegate during the launch sequence, allowing you to prepare your app for user interaction. 
The system provides some initial instances and an initial interface to run.
</LeadParagraphWrapper>

### The Entry Point

 When the app launches, the system knows where to find compiled binary within the app bundle. 
 Thanks to `info.plist` in the same bundle, this file has an executable file key(`CFBundleExecutable`) whose value is the name of the app’s binary.

 The system loads the binary and links any required frameworks. Now it needs to execute a code from the app’s binary to launch it. But where?

The answer would be obvious if this app were an Objective-C program. 
Objective-C is derived from C programing language, so the entry point is main function. Objective-C project would have a `main.m` file containing the main function:

``` swift
int main(int argc, char *argv[]) {
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil,
                                 NSStringFromClass([AppDelegate class]));
    }
}
```

The main function performs two tasks:
- It creates an environment for memory management, thanks to `@autoreleasepool`.
- It executes the `UIApplicationMain` function, which enables your application to use its bootstraps to set itself up and running.

If our app is Swift program, it has no `main` function. Rather, Swift has a specific attribute: `@main`. You can see it in the `AppDelegate.swift` file where AppDelegate class is defined.

``` swift
@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        return true
    }
}
```

Basically, this property handles all of the functionality Objective-C main.m file: it creates an entry point that executes `UIApplicationMain` to launch the app.

> Note: Swift 5.3 introduced the @main term; this attribute was formerly known as @UIApplicationMain.

It would be very uncommon, but you can create a `main.swift` file like Objective-C main file. 
Delete the `@main` attribute and instead use main file. This file, main.swift, gets special treatment, so the name is critical.

This file has also another special ability, it will execute code at the top level of the file, outside any function body. Other swift files, all executable code lives in a function. 
From a specific angle, computer programs just calls functions in the related files. Swift equivalent of the Objective-C call to UIApplicationMain, like this:

``` swift
import UIKit
UIApplicationMain(
    CommandLine.argc, CommandLine.unsafeArgv, nil,
    NSStringFromClass(AppDelegate.self)
)
```
You are calling the UIApplicationMain function in a iOS application. 
**The main task of your application is this function call.** 
All your application really does is make one massive call to UIApplicationMain.

![images/AppStateTransitions](/images/posts/2/LaunchSequence.jpeg)

### SwiftUI App Life Cycle

By default, when you make a new SwiftUI application, there is no `AppDelegate` class in the application that is generated. It has been replaced by an struct that conforms to the `App` protocol. Similar to how SwiftUI creates structs for views, it also use struct for launch process with a `@main` attribute. 

``` swift
import SwiftUI

@main
struct SwiftUIApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
    }
}
```
You might need to revert to the previous version of the UIApplicationDelegate ability - possibly to handle push notification registration or or 3rd party library integration(Firebase etc.). 

First, create a AppDelegate class that inherits from “NSObject” and conforms to the “UIApplicationDelegate” protocol, like this:

``` swift
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(_ application: UIApplication, 
                    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil) -> Bool {
        configureApp()
        return true
    }

    private func configureApp() {
        // Add any configuration steps here.
        print("Application launched!")
    }
}
```
After that, you can add a reference to the AppDelegate file in your App.swift file with `UIApplicationDelegateAdaptor` property wrapper.

``` swift
@main
struct SwiftUIApp: App {
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate

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

### App State Transitions

The state transitions can be tracked by implementing UIApplicationDelegate callbacks with AppDelegate or SceneDelegate, it depends on how new the project is.

![images/AppStateTransitions](/images/posts/2/AppStateTransitions1.jpeg)

### Pre-warming

With iOS15 and later, the system might decide to pre-warm your app before the user tries to open it. 
This process minimizes the length of time the user has to wait before the app is usable. 
Pre-warming runs the launch sequence of an application until `main()` calls `UIApplicationMain` methods, but not beyond that point. 
This helps the system to build and cache any low-level structures that are needed.

Once your app is prewarmed by the system, its launch sequence is halted until the app starts or the system kills the prewarmed app from memory in order to reclaim resources. 
The system can prewarm your app after every device reboot. 

If your application runs code before the calling `UIApplicationMain` methods, such as <a href="https://developer.apple.com/documentation/objectivec/nsobject/1418815-load" target="_blank" rel="noopener">load()</a>, be careful when assuming which resources and services are available. 
For instance, keychain items could not be available because their data protection policies need an unlocked device status.

#### Key Points

- **Entry Point:** Objective-C programs have a traditional main function, while Swift programs use the `@main` attribute or a `main.swift` file to initiate the application launch sequence.
- **SwiftUI App Lifecycle:** SwiftUI apps replace the traditional `AppDelegate` with a struct conforming to the `App` protocol, simplifying the initialization process with a `@main` attribute.
- **Pre-warming:** iOS 15 introduced app pre-warming, which initiates parts of the launch sequence to reduce user wait times.
- **Executable File Identification:** The system identifies the executable file of an app through the info.plist file, crucial for locating and launching the application's binary.

Tagged with #lifecycle

SwiftUI: Transform Your Developer Mindset

The App Launch Sequence