
<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>
Swift is a general-purpose programming language that has been widely used for client-side development in Apple-specific hardware environments. 
The contribution of the open-source developer community has extended Swift to the other platforms(Linux, Windows), hence establishing Swift as a cross-platform programming language.
</LeadParagraphWrapper>

### Expanding Boundaries

The fundamental difference between Client-side and Server-side Swift projects is their targeted platforms. 
Client-side Swift apps are only designed to run on Apple-hardware and OS’s. All client-side apps are exclusively designed for Apple products. 
This means that all the code we've written, along with any frameworks or libraries we've used, is compiled directly for the appropriate Apple hardware platforms.

The Server-side Swift world is much bigger. It's not just about macOS anymore; it also involves Ubuntu Linux, multiple cloud platforms, and Docker. 
With this expanded landscape comes the need for major architectural adjustments and a shift in project perspective. Specifically, you have to use tools and create frameworks that can function across all supported environments. 

Adding Apple platform-compiled binaries to a server-side project using Carthage or CocoaPods ensures their compatibility only if our server is running on macOS.
However, attempting to deploy the project to Linux or other platforms with these dependencies will result in a project build failure.

CocoaPods and Carthage command line tools are restricted to macOS, targeting hardware specific to Apple. At this step Swift Package Manager(SPM) comes to the stage as part of open-source Swift project.

### Opening Up Swift and Its Components

The official version of open source Swift was first launched in December 2015. 
Since then, with increased community support and development, open source Swift has continuously gained popularity and maturity. 
The effort of the open source developer community is coordinated through the Swift programming language <a href="https://github.com/apple/swift-evolution" target="_blank" rel="noopener">evolution</a> process. 

The Swift evolution process manages how new ideas are accepted, sets goals for future updates. 
It ensures Swift's robust evolution while maintaining application binary interface (ABI) stability, ensuring binary compatibility across Swift versions. 
Open source Swift includes Swift compiler, standard library, package manager, core libraries, test framework, and REPL/debugger. 
The following diagram shows the main components in open source Swift:

![images/open-source-swift](/images/posts/0/Server-SideSwiftDiagrams.jpeg)

### Swift standard library and Foundation

The Swift standard library is a Swift-only library which contains fundamental data types (like Int and Optional), protocols (like Hashable and Codable) and collections(like Array and Dictionaries). 
Every Swift file automatically imports the standard library(`import Swift`). It is open source.

Apple Foundation framework includes many features like file system access, data storage, string handling, networking, and localization functionality that are shared by all applications but are not part of the Swift standard library and language. 
Also, Foundation helps keep the Swift Standard Library focused and compact. In short, without Foundation, Swift wouldn't be the language we love. 

Apple Foundation is closed source and designed by a team at Apple with Objective-C. 
Given its closed-source nature, the question arises: How can we utilize these features in our server-side applications? A team of individuals who are behind-the-scenes leaders worked together to create a big part of Foundation. 
This became Corelibs Foundation Project.  Corelibs Foundation is a non-Objective-C reimplementation of Foundation for non-Apple platforms, particularly Linux. 
It mirrors Apple Foundation's designs as closely as possible. It's a good practice to check the project's Implementation <a href="https://github.com/apple/swift-corelibs-foundation/blob/main/Docs/Status.md" target="_blank" rel="noopener">status page</a> periodically.

### Backend Frameworks

We have explored the mindset behind server-side Swift and how it became achievable after Apple open-sourced it. 
It seems that we now have a very foundational toolkit for developing our backend applications as Swift developers. 
However, the question remains: Is this toolkit sufficient for constructing a fully-featured backend application before our hair begins to gray. 
Back-end frameworks like Vapor are essential because they provide a structured and efficient way to develop server-side applications.
 
They abstract away much of the low-level networking and infrastructure concerns, allowing developers to focus on building features and functionality. 
Vapor is an open-source web framework written in Swift, which allow us to write Web apps, and HTTP servers in Swift. 
Here's what Vapor is used for and why back-end frameworks like Vapor are necessary:

-   **Creating APIs:** Vapor is commonly used for creating APIs for web and mobile applications. APIs allow different software systems to communicate with each other, enabling data exchange.
-   **Routing:** Vapor provides a routing system that maps incoming HTTP requests to the appropriate handlers, making it easy to define endpoints for handling different types of requests.
-   **Middleware:** Middleware in Vapor allows developers to add authentication, logging, error handling, and request/response modification to their applications in a modular and reusable way.
-   **Database Integration:** Vapor integrates with various databases, including PostgreSQL, MySQL, SQLite, and MongoDB, allowing developers to store and retrieve data from their applications.
-   **Security:** Vapor includes features for implementing security best practices such as input validation, encryption, and protection against common web vulnerabilities like cross-site scripting (XSS) and SQL injection.

Swift Server-Side: Breaking Boundaries Beyond iOS


<LeadParagraphWrapper>
Application sandboxing is a critical aspect of iOS security. 
It refers to the practice of isolating an app and its associated data and resources within a secure and controlled environment. 
An iOS user can install multiple apps on a single device. Therefore, the iOS platform ensures that these apps cannot interfere with each other in terms of memory usage and data storage.

So what is the effect of that on developers? And why does the operating system sandbox applications?
</LeadParagraphWrapper>

### File System Security

Security is crucial for any modern application, and Apple offers a variety of tools for this purpose. For files, the iOS ecosystem includes three main security features: 

- **Sandboxing:** The primary purpose of sandboxing is to enhance security by isolating apps and preventing them from interfering with each other or accessing unauthorized data. By confining each app to its own sandbox, iOS ensures that even if one app is compromised, it cannot compromise other apps or the underlying operating system. Sandboxing also helps to protect user privacy by limiting access to personal and sensitive data.
- **Access control:** File and directory access is controlled by access control lists (ACLs), providing detailed specifications on permissible actions and users authorized to perform them.
- **Encryption:** Thanks to iOS's data protection feature, you can secure the files in your app and prevent unauthorized access to them. When a user activates a passcode on their mobile device, privacy is activated automatically. The system encrypts and decrypts your content in the background while you read and write to your files as usual. This process is automatic and hardware accelerated.

``` swift
do {
   try data.write(to: fileURL, options: .completeFileProtection)
}
catch {
   // Handle errors.
}
```

### Why Is Sandboxing Essential?

iOS and other Apple platforms are based on a version of Unix. 
A Unix program has the same permissions and privileges as the user who is running it. 
This made sense in the past because users had to code and load your own programs. 
But these days, we use third-party apps which we did not write ourselves. 

For Security reasons, Our apps should not have the same access as we do. 
A malicious app or innocent bug could cause havoc on our system. 
Therefore, we need to separate user’s privileges from third-party apps. 
Apple solve this issue with a strict separation between apps and the operating system. 
The outcome is `App Sandbox`.

### Introducing App Sandbox

The host device offers functionalities such as the calendar or camera that an app might want to use. 
To use them, the app needs to validate its identity and request permission from the OS and the user.

There are different types of resources that need authorization.

- **Hardware:** Microphone, Camera, sensors.
- **Data from other apps:** Photos, email, calendar and contact.
- **User files:** Files from the file system or the files app.
- **Special Functionality:** Push notifications, HomeKit access.

![images/sanboxing](/images/posts/3/sanboxing-provisioning.jpeg)

### Sandboxing and Provisioning Profile Relation

At runtime, a sandboxed app might attempt a restricted operation such as accessing the camera. Operating system intercepts this operation and makes number of checks to let an app complete a restricted operation. The operating system asks questions, and a code-signed provisioning profile answers them. These are the questions and how your app answers them.

- **Who are you?** -> `app id`, `team id`
- **Can I trust you?** -> `certificate`
- **What do you want to do?** -> `entitlements`


Provisioning profile is file embedded in the app’s binary. When you want to deploy your app to a real device, you probably faced with this code signing process. Code signing your app ensures that it comes from a known source and has not been modified since it was last signed. 

If we don’t have look at this process, sandboxing and provisioning might be easily seen as a collection of unrelated tasks.

### How Can I Find the Sandbox?

In order to ensure that your files are being saved as you expected, you may find it helpful to take a peek inside the app's sandbox during development.
In the AppDelegate class, update the `application(_:didFinishLaunchingWithOptions:)` method as shown below.


``` swift
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
    print(NSHomeDirectory())

    return true
}
```

When executed within the iOS Simulator environment, the path will take this form:

```
/Users/<user_name>/Library/Developer/CoreSimulator/Devices/<device_id>/data/
Containers/Data/Application/<app_id>
```

When executed on a physical iOS device, the path:

```
/var/mobile/Containers/Data/Application/<app_id>
```

Copy that value from the console, switch to the Finder, choose Go → Go to Folder, paste the path into the dialog that appears, and click Go.


### Inspecting the Sandbox

#### Bundle Container

This is the app’s bundle. This directory contains the app binary and all of its resources such as assets used in the app. 
You cannot write to this directory. To prevent tampering, the bundle directory is signed using cryptography at installation time, as mentioned before.

#### Data Container

It stores the data of the app for example data generated during runtime like user saving a text file, saving an image, application caches etc.
It has some sub directory like:

![images/sanboxing](/images/posts/3/sandbox.png)

1. **Document:** This is a great location to store content created by users.
Additionally, it’s also backed up to iCloud. 
The user can access the documents directory via file sharing, so it should only contain files that are appropriate for users to access.
2. **Library:** This is used for storing application-specific data that should persist between launches. Files are deleted from the device if the device does not have enough free space. Some important purpose-specific subfolders within the library folder are as follows: 
 - **Caches:** Cache data serves to enhance application performance, though it's not essential for app. This temporary data is advantageous to persist for longer durations compared to data in the tmp directory.              
 - **Preferences:** This directory stores app-specific preference files, accessed through the NSUserDefaults API. It's crucial not to manually add files to this directory; instead, use the NSUserDefaults API. Also, the directory's contents are backed up to iCloud.
3. **tmp**: You're able to temporarily store files required by the application. The operating system can automatically remove them when the application is not running.


### Allowing user’s to access SandBox document’s

After release of iOS 11, we meet with Files app.  The Files app, which allows users to manage locally stored files and files in iCloud. Additionally, this new app helps developers to allow users to access their data in  app’s sandbox documents directory.

Open info.plist and add this following keys and set the boolean values as yes

- **Application supports iTunes file sharing:** This property allow the user to access the files in sandbox documents directory through their Mac when they connect their device to their mac.

- **Supports opening documents in place:** This property will allows the user to access files directly by using their device default file manager app without need for connecting it to a Mac.

Relaunch your app to make these changes take effect. Your files should now appear in the Files app.

### In Conclusion

It's critical that you understand the purpose of the application sandbox. 
UIDocumentPickerViewController is an exception about modifying files or directories outside of sandbox but this is another story. 
Additionally, storing large files can consume a large amount of a user’s available storage, which can cause them to delete your application. 



Understanding the Power of Application Sandboxing in iOS


<LeadParagraphWrapper>
Interoperability of programming languages is the ability for two or more languages to interact as part of the same system. 
Interoperability can offer many benefits for developers. For example, the ability to reuse existing code and libraries across languages and platform, increases the portability and scalability of code. 
This can save time and effort while also improving knowledge sharing and code quality. 
There are many ways programming languages are interoperable with one another. 
Shared object models, foreign function interfaces, common runtime environments and virtual machines are some of these ways. 
For instance, web browsers frequently perform some kind of interoperability. 
Browsers parse HTML to handle information to be shown on a page, and language like JavaScript handle any real-time functionality on the page.
</LeadParagraphWrapper>

### Interoperability in Apple Ecosystem

When you’re building an app target, it is legal for a target to be a bilingual target — one that contains both Swift files and Objective-C files. 
There are several reasons why a bilingual target could be helpful: 

- You might want to use third-party code written in Objective-C or Swift.
- You might want to combine your own legacy project written in Objective-C.
- Your app itself may have been written in Objective-C originally, and now you want to migrate part of it (or all of it, in stages) into Swift. 

The critical question is how Swift and Objective-C access each other's code within a single target.

Unlike Swift, Objective-C files are unable to automatically see one another. 
Instead, each Objective-C file that needs to see another Objective-C file must be instructed explicitly to see that file, with an `#import` declaration at the top of the file.

Typically, an Objective-C class declaration is divided into two files: a header file (.h) containing the `@interface` section, and a code file (.m) containing the `@implementation` section. 
Importing is limited to `.h files` only, so if you want class members accesiable for other files, it must be defined in header files.

>Visibility of Swift and Objective-C works through header files. 

Visibility works on both way thanks to two special Objective-C header files:

### How Swift sees Objective-C

When you add a Swift file to an Objective-C target, or an Objective-C file to a Swift target, Xcode offers to create a `bridging header`. 

![images/bridging-header](/images/posts/1/bridging-header.png)

This is a `header(.h)` file in the project. Its default name is derived from the target name. 
It takes its name from the target name by default. However, the name is arbitrary. If you choose “Don’t Create”, you can create a header file manually and point to it in the Bridging Header build setting. 
If you `#import` an Objective-C header file in this bridging header, Swift will then be able to see it.

### How Objective-C sees Swift

When you build your target, the relevant top-level declarations of your Swift files are automatically translated into Objective-C and are used to construct
a `generated interface header` within the build folder for this target, deep inside your `DerivedData` folder.

![images/bridging-header](/images/posts/1/generated-interface.png)

{/* <Image alt="bridging-header" src="/images/posts/1/generated-interface.png" width = "500" height = "100"/> */}

Your Swift code is exposed to Objective-C in general through the generated interface header. 
Your Swift declarations will be visible to your own Objective-C files if you `#import` the generated interface header into every Objective-C file that requires access to them.

### Interoperability at Compile Time

 Let’s take closer look what happens when we build bilingual target at compiler level.

#### How does Swift import and use Objective-C declarations:

- The Swift compiler phases are parse, semantic analysis, SILGen, IRGen and LLVM.
- Swift compiler embeds Clang (the LLVM compiler) as a library. When you ask Swift to import a module, it attempts to load the module in Swift space by that name. If that fails, it ask Clang to load a Clang module by that name.
- The Clang Importer, a Swift compiler component, will generate comparable Swift declarations for the Clang declarations in that module. The compiler is aware that these declarations actually correspond to declarations in Clang.
- The Compiler checks if the declerations imported from Clang, it calls into Clang IRGen(LLVM’s intermediate representation, this is one of the crucial benefit of LLVM architecture) to generate the code needed. 

#### How does Swift make “@objc” declarations usable from Objective-C:

- Swift IRGen generate Objective-C-compatible metadata for these declarations. It also generate Objective-C-compatible wrapper functions—for Swift functions and methods that should be accessible from Objective-C.
- There are some runtime data structures that were intentionally developed to work with Objective-C. For instance, native Swift root classes actually inherit from a class that conforms to the NSObject protocol. Swift automatically bridges certain types between the two languages, such as NSString and String, NSArray and Array.

### To Sum Up

In a nutshell, Swift does not convert Swift code into Objective-C; nor does Clang convert Objective-C code into Swift. 
Instead, Swift and Clang both translate the source code of their respective languages into IR, which is subsequently passed to LLVM for machine code generation. 
Interoperation is enabled by various tricks. The header files which is created for visibility between swift and Objective-C is just one these tricks.








Swift and Objective-C Interoperability 

<LeadParagraphWrapper>
Swift is a general-purpose, multi-paradigm and compiled language for iOS, macOS, watchOS, tvOS, and Linux applications. Swift is the outcome of the most recent research on programming languages and created by team led by Chris Lattner at Apple.
</LeadParagraphWrapper>

Cocoa programming had always been done mostly in Objective-C, first on Mac OS and then on iOS until that point. The Cocoa frameworks that give an iOS app its functionality are based on Objective-C, they expect to be spoken to in Objective-C. For all its flaws, Objective-C was the language we  learned to live with as the price of Cocoa programming. 

Is it possible to communicate with Cocoa in a different language? This is where possibilities become reality, the answer is yes. Swift is explicitly designed to interface with most of the Cocoa APIs.

Swift is easy to learn and easy to implement, even if you’re a new programmer. Some of the key features:

-   **OpenSource:** Swift’s founders recognized that to create a defining language, the technology needed to be accessible to everyone. With this decision, Swift language gained a large community and a wide range of open source tools.
-   **Object-orientation:** Swift is a modern, object-oriented language. It is purely object-oriented: `Everything is an object`.
-   **Safety:** Swift uses a strong, static type system to ensure that types are correctly matched at compile-time, reducing runtime errors.
-   **Memory Managemen:** Swift manages memory by using Automatic Reference Counting (`ARC`), which removes typical memory management mistakes and improve efficiency.
-   **Modern Syntax:** Swift's syntax is consistent, clear, and expressive, allowing developers to write code that is easy to read and maintain.
-   **Optimized Compiler:** LLVM-based compiler optimizations enable Swift code to be compiled into highly efficient machine code.

### Stable ABI and Backward Compatibility

In March 2019, Swift 5.0 was officially released. It introduced a stable version of the application binary interface (ABI) across Apple’s platforms. 

ABI is an interface between two binary program modules. It is a collection of rules that allow applications and program parts, such as libraries or frameworks, to speak the same "binary language" and interact with one another. 
Typically, the ABI includes the following topics:

- Calling convention (how to call functions, pass arguments, return values)
- How data is represented in memory
- Processor instruction set, stack organization
- How an application should make system calls to the operating system

> You write Swift code and want to share it with many apps. You make a framework and use the Swift 3.0 compiler. Then Apple brings out Swift 4.0. You're excited and make a new app with Swift 4.0 compiler. The problem is that your project requires certain functionalities from your previous framework. Is it going to work with new project? Nope. Before `ABI stability` both pieces of code had to be compiled with the same compiler for them to communicate. So, if your framework was compiled with Swift 3.0 and your app with Swift 4.0, they wouldn't work together. Now, with "ABI stability," things have changed. A framework compiled with Swift 5.0 can communicate with an app compiled with Swift 5.1.

Before stable ABI, the complete Swift standard library and runtime were included in every Swift app that was created. 
This was because Swift was evolving rapidly, making it impractical to include its fundamentals in iOS releases. 
ABI stability refers to the ability of a language to be packaged and linked directly into the operating system.

Swift's system footprint will decrease once it becomes an ABI stable language because apps won't need to package with swift dynamic libraries, and you'll still be able to take advantage of the OS's internal optimizations. 
Another advantage of stable ABI is developers will be able to write closed-source third-party libraries and release them as pre-compiled frameworks.

### Swift in Action: Across Different Areas

Swift is adaptable and works well in a variety of programming scenarios, including server-side development, scripting, automation, and mobile app development. 
Due to its high performance, wide feature set, and clear syntax, it is becoming more and more popular among developers in different fields.

#### Swift in mobile app development

When developing apps for the iOS, iPadOS, watchOS, and tvOS platforms, Swift is mostly used. 
The following benefits highlight some advantages that developers can leverage while creating mobile applications with Swift:

- Swift has ability to integrate with Apple's SDKs and frameworks such as UIKit, AppKit, and SwiftUI.
- Clear and concise syntax makes your code more readable and maintainable.
- If additional developers are required, Swift lets you add them to your team easily, because the codebase is clear and simple, onboarding happens rather quickly.
- Safety features take center stage in Swift, such as optionals and type safety, helps developers write code that is less prone to runtime errors and vulnerabilities. This reduces the risk of crashes and security breaches in mobile apps, providing users with a more reliable and secure experience.

#### Swift in server-side development

Swift has gained interest in server-side development due to its open-source status and high-performance advantages. 
Swift can be used by developers to build RESTful APIs and web applications by utilizing server-side Swift frameworks such as Kitura, Vapor, and Perfect. 
These frameworks enable the following capabilities:

- Developing and deploying high-performance REST APIs for various client applications, including mobile apps and web apps.
- Creating web applications with server-side capabilities such as database access, authentication, file management, and more.
- Designing reusable server-side libraries that the Swift community can use or distribute across several projects.

Swift has a number of advantages for server-side development, including:

- Swift has impressive concurrency and performance support, enabling software developers to design scalable APIs and web applications.
- Safety features and error handling, improving the reliability and robustness of server-side code.
- The capacity to share code between client and server applications, which speeds up development and eliminates redundant code.

#### Swift for scripting and automation tasks

Swift is useful not only for server-side and mobile app development but also for scripting and automation tasks. 
Swift is a compiled language, which means that you typically need to compile your code into a binary before it can be executed. 
However, if you're familiar with Unix shells like Bash or Zsh, you know that scripts written in these shells can be run directly without the need for compilation. 
This is where Swift scripting comes in. By leveraging Swift's interactive shell, known as the REPL (Read-Eval-Print Loop), you can write and run Swift scripts without the need for compilation. 
This opens up a whole new world of possibilities for automating tasks and manipulating data using Swift.

Some common use cases for Swift scripting include:

- Creating and maintaining templates or configuration files.
- Manipulating data, such as transforming JSON or CSV files.
- Implementing batch procedures to big data sets.

### Final Thoughts

Swift is more than just a coding language, it's a transformative instrument empowering developers. 
It helps us to learn new programing paradigms and enhance our ability to design efficient and scalable solutions. 
Swift has changed a lot since it started, and each update has made it better for developers. 
Ultimately, Swift's evolution translates to a more enjoyable and productive coding experience, empowering us to build more reliable applications with ease.





Swift: A Language for Modern Development


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

Blog Articles

SwiftUI: Transform Your Developer Mindset

Swift Server-Side: Breaking Boundaries Beyond iOS

Understanding the Power of Application Sandboxing in iOS

Swift and Objective-C Interoperability

Swift: A Language for Modern Development

The App Launch Sequence