Swift

Swift is a powerful and intuitive general-purpose programming language developed by Apple for building apps for iOS, Mac, Apple TV, and Apple Watch. It was designed to be fast, safe, and modern, replacing much of the older Objective-C codebase.

• Safety: Swift eliminates entire classes of unsafe code. Variables are always initialized before use, and arrays/integers are checked for overflow.
• Speed: Swift uses the LLVM compiler technology to transform Swift code into optimized machine code.
• Optionals: A unique feature that handles the existence (or absence) of a value, preventing "null pointer" crashes.
• Type Inference: You don't always have to specify types; Swift can often figure them out from the context.
• Closures: Self-contained blocks of functionality that can be passed around and used in your code.

In Swift, you use let for constants (values that never change) andvar for variables (values that can change).

• Constant: let pi = 3.14159
• Variable: var currentScore = 0

An Optional is a type that can hold either a value or nil (no value). It is declared by adding a question mark ? after the type.

Swift provides "Optional Binding" using if let or guard let to check for and extract a value safely.

Both are used to create custom data types, but they have key differences:

• Structs: Value types. When you copy a struct, you get a unique copy of the data. They do not support inheritance.
• Classes: Reference types. Multiple variables can point to the same instance. They support inheritance.

A protocol defines a blueprint of methods, properties, and other requirements that suit a particular task or piece of functionality. Classes, structs, or enums can then "adopt" or "conform" to that protocol.

Think of it like an Interface in other languages. It defines what an object should do, but not how it does it.

Optional chaining allows you to call properties, methods, and subscripts on an optional that might currently be nil. If the optional contains a value, the call succeeds; if it is nil, the call returns nil.

Closures are self-contained blocks of code that can be passed around. They are similar to "lambdas" in Python or Javascript.

Swift uses Automatic Reference Counting (ARC). It automatically tracks and manages your app's memory usage so you don't have to manually allocate or deallocate memory. It keeps an instance in memory as long as at least one strong reference to it exists.

In Swift, nil is fundamentally different from NULL in languages like C or Objective-C. While both represent the absence of a value, their underlying mechanics and safety profiles differ significantly.

In most languages, NULL is a pointer that points to an empty or non-existent memory address. In Swift, nil is not a pointer; it is the absence of a value of a certain type.

• Optional Wrapper: In Swift, only types explicitly marked as Optional (e.g., Int?, String?) can be nil. This forces the developer to handle the "empty" case before accessing the data, preventing the common "Null Pointer Exception."
• Value Types: Swift allows value types (like Int, Struct, or Enum) to be nil if they are wrapped in an Optional. In languages like C, NULL is typically reserved for pointers, and a standard integer cannot be NULL.
• Compile-Time Checking: The Swift compiler will not allow you to use a nil value where a non-optional value is expected. This shifts the discovery of potential bugs from the user's device (runtime) to the developer's computer (compile-time).
• Objective-C Interop: When Swift interacts with Objective-C, it translates NULL or nil pointers into Swift Optionals automatically to maintain safety standards.

Type Inference is a feature of the Swift compiler that allows it to automatically deduce the data type of a specific expression at compile-time. Instead of the developer explicitly stating the type (e.g., String or Int), the compiler examines the provided initial value to determine the type.

Swift is a statically typed language, meaning every variable must have a type. However, you don't always have to write it out.

• Cleaner, More Readable Code: Reduces "boilerplate" code. The syntax stays lightweight and "script-like" while maintaining the power of a compiled language.
• Faster Development: You can declare variables and constants quickly without constantly typing out long class or protocol names.
• Maintainability: If you change a function's return type, the variables receiving that data often update their inferred types automatically (provided they remain compatible with the rest of the code).
• Safety without Effort: Even though you aren't writing the type, the compiler still enforces strict type-checking. Once a type is inferred, it cannot be changed to a different type later.

• Initial Value Required: Type inference only works if you provide an initial value at the time of declaration. If you declare a variable without a value, you must use a type annotation (e.g., var price: Double).
• Default Logic: Swift has "preferred" types for literals. For example, a decimal number like 3.14 will always be inferred as a Double rather than a Float unless specified otherwise.

A Tuple is a lightweight grouping of multiple values into a single compound value. Unlike arrays, the values within a tuple can be of different types, and their size is fixed once defined.

While both group data, they serve different architectural purposes.

You can access data inside a tuple using positional indices or named elements .

• By Index: response.0 returns 404.
• By Name: let user = (name: "Alice", age: 30); print(user.name)
• Decomposition: ```swift let (code, message) = response print("Status: (code)")

Use a Tuple when:

• Returning Multiple Values: Ideal for a function that needs to return more than one piece of data without the overhead of defining a new class or struct.
• Temporary Grouping: Useful for local operations, like iterating through a dictionary where you get a (key, value) tuple.
• Pattern Matching: Highly effective in switch statements to check multiple conditions at once.

• Modeling Data: If the data represents a "thing" in your app (e.g., User, Product, Post).
• Persistence: If you need to pass the data between many different parts of your app.
• Encapsulation: If you need the data to perform actions (methods) or have complex validation logic.

Generics are a powerful tool in Swift that allow you to write flexible, reusable functions and types that can work with any type, subject to requirements you define. They avoid code duplication by using "placeholders" instead of specific types (like Int or String).

Without generics, you would have to write multiple versions of the same logic for different data types. With generics, you write the logic once.

• Type Parameters: Represented by a placeholder name (often <T>, <Element>, or <Key>) inside angle brackets.
• Generic Functions: A single function that can accept different types of arguments.
• Generic Types: Structures, classes, and enumerations that can work with any type (e.g., Swift's Array and Dictionary are actually generic collections).
• Type Constraints: You can limit generics to only work with types that inherit from a specific class or conform to a protocol (e.g., <T: Equatable>).

A "Stack" is a classic example. Instead of creating an IntStack and a StringStack, you create one Stack<Element>.

• Flexibility: It can hold integers, strings, or custom objects.
• Consistency: Once you define a Stack<Int>, Swift ensures you only push integers into it, maintaining strict type safety.

The Nil-Coalescing Operator (??) is a shorthand operator used to safely unwrap an Optional. It attempts to access the value inside an optional, but provides a default value to fall back on if the optional is nil.

The operator is placed between two values: a ?? b.

• a: An optional value (the value you'd like to use).
• b: A non-optional value (the backup if a is empty).

It effectively compresses a multi-line if-else statement into a single line of code.

• The "Long" Way:
• The Swift Way (??):

• Readability: It makes code much more concise and easier to follow, especially when dealing with multiple optionals.
• Type Safety: The operator ensures that the resulting variable is a non-optional type, meaning you can use it immediately without further checking.
• Short-Circuiting: If the first value is not nil, the second expression is never even evaluated, which can save processing time if the default value requires a function call to generate.

In Swift, these three primary collection types are used to store groups of values. While they all hold data, they differ significantly in how they organize that data and the performance of their operations.

1. Arrays

Use an Array when the order of your data matters (e.g., a list of high scores or a queue of tasks).

• Access: let firstItem = items[0]
• Characteristics: Elements are stored in a linear sequence. Accessing an element by its index is very fast ($O(1)$), but searching for a specific value requires checking every item ($O(n)$).

2. Sets

Use a Set when you need to ensure an item only appears once or when you need to perform high-speed membership testing.

• Requirements: Elements must conform to the Hashable protocol.
• Math Operations: Sets excel at mathematical operations like intersection, union, and subtracting.
• Access: if mySet.contains("Apple") { ... }

3. Dictionaries

Use a Dictionary when you want to associate a specific identifier (key) with a piece of data (value) (e.g., a user ID associated with a profile).

• Requirements: Keys must be Hashable.
• Access: let age = ages["John"]
• Result: Accessing a value by a key returns an Optional, because the key might not exist in the dictionary.

• Array: A "To-Do" list where the first task should stay at the top.
• Set: A list of unique "tags" for a blog post where you don't care about the order.
• Dictionary: A "Glossary" where you look up a definition (Value) using a word (Key).

Both if let and guard let are used for Optional Binding (unwrapping an optional safely). However, they differ in their control flow and how they handle the scope of the unwrapped variable.

1. if let (The "Conditional" Approach)

Use if let when you want to perform an action only if the optional contains a value, but you also want the function to continue even if the value is nil.

• Logic: "If this value exists, do this specific thing with it."
• Example:

Use guard let to ensure a value exists before proceeding with the rest of the function. It is often used at the beginning of functions to handle "unhappy paths" first.

• Logic: "This value MUST exist for me to continue; otherwise, I'm stopping right here."
• Example:

• Use guard let for inputs and requirements. It makes your "happy path" (the main logic) easier to read by getting error handling out of the way early.
• Use if let for quick, one-off checks where the rest of the function doesn't depend on that specific variable.

In Swift, the switch statement is far more powerful than in other languages. It isn't limited to simple equality checks; it uses Pattern Matching to inspect complex data structures and extract values simultaneously.

Swift can match patterns based on ranges, types, and tuple compositions.

1. Tuple and Value Binding

You can use a switch to decompose a tuple and use its internal values immediately. You can use an underscore (_) as a wildcard to ignore specific parts of the pattern.

A where clause allows you to refine a match with extra logic. This ensures a case only executes if a specific condition is met, even if the pattern matches.

In Swift, switch statements must be exhaustive. This means you must cover every possible value of the type being switched.

• If you are switching on an Enum, you must cover all cases.
• If you are switching on an Int or String, you almost always need a default case to handle the infinite remaining possibilities.

Unlike C or Java, Swift does not "fall through" to the next case by default. Once a match is found, the code executes and exits the switch. If you explicitly want the next case to run, you must use the fallthrough keyword.

In Swift, properties associate values with a particular class, structure, or enumeration. The primary distinction lies in whether the property actually holds data or calculates it on the fly.

1. Stored Properties

These are the most common properties. They store constant or variable values as part of an instance.

• Example: A User struct storing a username string.
• Property Observers: You can add willSet or didSet to react when the value changes.

2. Computed Properties

These provide a getter and an optional setter to retrieve and set other properties indirectly.

• The Getter (get): Required. It defines how to calculate the property's value.
• The Setter (set): Optional. It allows you to update other properties when this property is assigned a value. If no setter is provided, it is a read-only computed property.

Imagine a Square struct where the area depends entirely on the side length.

• Use Stored Properties for the "Source of Truth"—the fundamental data that defines your object (e.g., a person's birthdate).
• Use Computed Properties for data that can be derived from existing information (e.g., a person's current age based on their birthdate) or to provide a simpler interface for complex data.

Property Observers observe and respond to changes in a property’s value. They are called every time a property's value is set, even if the new value is the same as the current value.

They are primarily used on Stored Properties to keep other parts of your app in sync or to perform validation/logging when data changes.

You define these blocks inside the curly braces of a stored property declaration.

• Not for Initializers: Observers are not called when the property is first initialized. They only trigger during subsequent assignments.
• Avoid Infinite Loops: You can assign a value to the property within its own didSet. While this won't trigger the observer again (preventing a loop), it should be used sparingly for things like value clamping.
• Inheritance: You can add observers to an inherited property (whether stored or computed) by overriding the property in a subclass.
• Default Parameter Names: If you don't provide a custom name (like newSteps in the example above), Swift provides the defaults newValue for willSet and oldValue for didSet.

• UI Updates: Automatically refreshing a Label or View when the underlying data model changes.
• Data Validation: Checking if a value (like a percentage) is within a valid range (0-100) and correcting it if necessary.
• Synchronization: Updating a database or saving to UserDefaults as soon as a variable is modified.
• Logging: Tracking state changes for debugging purposes.

In Swift, self is a property that refers to the current instance of a class, structure, or enumeration. It is essentially the object saying, "I am talking about my own property or method."

In most cases, Swift allows you to omit self because the compiler assumes you are referring to a property of the current instance. However, there are specific scenarios where the compiler requires it to prevent ambiguity or to handle memory safely.

1. Disambiguation (Initializers)

If your initializer has a parameter name that matches a property name, you must use self to tell the compiler which is which.

When using an @escaping closure (a block of code that runs later, like a network request), you must use self. This forces you to think about memory management.

• Why: The closure needs to "capture" the instance to ensure it still exists when the code finally runs.
• Syntax: self.property = value or [weak self].

In a mutating method of a struct, you can assign a completely new instance to self.

When you want to refer to the type itself rather than an instance of the type, you use .self.

• Example: UITableViewCell.self refers to the class type, often used for registering cells in lists.

Apple’s official style guidelines suggest not using self unless it is required. This makes the code cleaner and highlights the specific places where self is actually necessary (like in closures), making those critical memory-management spots easier to spot.

Extensions in Swift allow you to add new functionality to an existing class, structure, enumeration, or protocol type. This includes types you didn’t write yourself, such as built-in Swift types (e.g., String, Int) or Apple's frameworks (e.g., UIButton).

Extensions are a primary tool for "Clean Code" in Swift. They allow you to break down large files into logical, manageable sections.

• You CAN add:
• Computed properties (read-only or read-write).
• New instance and type methods.
• New initializers (specifically "convenience" initializers for classes).
• Subscripts.
• Nested types.
• Protocol conformances.
• You CANNOT add:
• Stored properties (Extensions cannot increase the memory footprint of an instance).
• Property observers (willSet/didSet) to existing stored properties.
• Designated initializers to a class (only convenience ones).

Instead of having one giant ProfileViewController, you can split it by responsibility:

• Readability: Using // MARK: - with extensions creates a visual map in Xcode’s Jump Bar, making navigation easier.
• Retroactive Modeling: You can make a type conform to a protocol even if you don't have access to the original source code.
• Reusability: You can create a library of extensions (e.g., a String+Validation.swift file) and share it across multiple projects.

Protocol-Oriented Programming is a design paradigm introduced by Apple at WWDC 2015. While Object-Oriented Programming (OOP) focuses on what an object is (inheritance), POP focuses on what an object can do (behavior). It leverages protocols and protocol extensions to create flexible, modular, and reusable code.

In traditional OOP, you often end up with a deep inheritance tree where a subclass inherits properties it doesn't need. POP solves this by allowing types to "pick and choose" behaviors via protocols.

• Protocol Extensions: The "secret sauce" of POP. You can provide a default implementation for protocol methods. This means any type conforming to the protocol gets that functionality for free without writing a single line of code.
• Composition over Inheritance: Instead of one giant Superclass, you create small protocols like Flyable, Runnable, and Swimmable. A Duck struct can conform to all three, while a Dog only conforms to Runnable and Swimmable.
• Value Type Friendly: Unlike inheritance (which requires Classes), protocols work perfectly with Structs, which are safer and faster in Swift.

• Avoids the "Pyramid of Doom": You don't get stuck with rigid parent-child relationships that are hard to change later.
• Testability: Since protocols define an interface, it is much easier to create "Mock" objects for unit testing.
• Clean Code: It promotes the "Interface Segregation Principle," meaning no type is forced to depend on methods it does not use.

In Swift, Enums with Associated Values allow you to store additional information alongside each case. While a standard enum simply represents a choice (e.g., North, South, East, West), an enum with associated values can attach specific data to those choices.

Think of a standard enum as a list of labels, and an enum with associated values as a list of containers. Each container can hold different types and amounts of data.

Consider a "Result" from a network request. You want to know if it succeeded (with data) or failed (with an error message).

To get the data out of an enum case, you use a switch statement or an if case let statement with pattern matching.

• Using Switch:
• Using If Case Let:

• Contextual Information: You don't just know what happened; you know the details why or how it happened.
• Type Safety: The compiler ensures you handle the correct data types associated with each specific case.
• State Management: Highly effective for managing UI states (e.g., .empty, .error(String), .populated([User])) in a single, clean variable.

A Failable Initializer is an initializer that can return nil if initialization fails. In Swift, you define this by adding a question mark after the init keyword (init?).

It is used when the input parameters might be invalid, or when an external requirement (like a file or database) is missing, preventing the object from being created successfully.

A common example is a Person struct that requires a non-empty name. If an empty string is provided, the initializer "fails" and returns nil.

• Return nil: You must explicitly write return nil at the point where you determine initialization should fail.
• Propagation: A failable initializer can delegate to another failable initializer. If the delegate fails, the whole initialization process fails immediately.
• Overriding: A failable initializer can be overridden by a non-failable one in a subclass, but a non-failable one cannot be overridden by a failable one.
• Native Examples: Swift’s built-in types use this often. For example, Int("ABC") returns nil because "ABC" cannot be converted to a number.

• Data Validation: When creating an object from a Dictionary or JSON where a required key might be missing.
• Range Checks: When an input must be within a specific range (e.g., an Age struct that only accepts 0-120).
• Resource Availability: When an object depends on a file or hardware resource that may not be available.

Access Control restricts access to parts of your code from code in other source files and modules. This allows you to hide the implementation details of your code and specify a preferred interface through which that code can be accessed and used.

Swift provides five levels of access control. They are tiered from the most restrictive (private) to the most expansive (open).

1. The Default: Internal

If you do not specify an access level, Swift defaults to internal. This means your code can be used anywhere within your app or framework, but it won't be accessible to external apps that import your framework.

• private: Use this for logic that is strictly internal to a single class or struct. Even an extension in the same file can access it if it's in the same declaration.
• fileprivate: Use this when you have two separate classes in the same file that need to talk to each other, but you want to hide them from the rest of the project.

These are critical when building libraries (like a CocoaPod or Swift Package):

• public: Others can use your class, but they cannot create a subclass of it or override its methods.
• open: The most permissive level. Use this when you want developers to be able to inherit from your class and customize its behavior.

A best practice in Swift development is to always use the most restrictive access level possible.

• Start with private.
• Loosen it to internal only if another part of your app needs it.
• Only use public or open if you are building a library for other developers.

Automatic Reference Counting (ARC) is Swift’s memory management system. It automatically tracks and manages your app’s memory usage by keeping track of how many "strong references" point to each class instance. When the reference count drops to zero, ARC deallocates the instance to free up memory.

ARC only applies to Reference Types (Classes). It does not apply to Value Types (Structs and Enums), as those are copied when passed around.

To manage memory effectively and prevent "memory leaks," Swift provides three types of references:

A "Retain Cycle" occurs when two class instances hold strong references to each other. Because neither count can ever reach zero, they stay in memory forever, causing a memory leak.

• The Solution: Use a weak or unowned reference for one of the relationships to break the cycle. This is common in "Delegate" patterns and "Closures."

• ARC is compile-time logic, not a runtime "Garbage Collector" like in Java or Python. This makes Swift memory management very predictable and high-performance.
• You rarely need to think about ARC for basic code, but you must use weak references when setting up delegates or using self inside closures.

A Strong Reference Cycle (also known as a Retain Cycle) occurs when two or more class instances hold strong references to each other. Because each instance keeps the other's reference count above zero, ARC (Automatic Reference Counting) can never deallocate them, even if they are no longer needed by the rest of the app.

This results in a memory leak, where memory is occupied by "zombie" objects that cannot be reclaimed.

In Swift, references are strong by default. A cycle typically forms in parent-child relationships or delegate patterns.

• Two Class Instances: A User has an Account, and the Account has an Owner. If both properties are strong, they trap each other in memory.
• Closures: A closure stored as a property of a class that captures self strongly. The class owns the closure, and the closure owns the class.
• Delegates: A ViewController owning a Service, and the Service having a strong delegate property pointing back to the ViewController.

To break a cycle, you must change one of the references to be non-strong.

By marking the delegate or child reference as weak, the cycle is avoided:

• Increased Memory Usage: Can lead to the app being terminated by the OS (Out of Memory crash).
• Side Effects: Objects that should be dead continue to listen to notifications or run timers in the background.
• Broken Logic: deinit blocks are never called, preventing necessary cleanup.

Both weak and unowned references are used to resolve strong reference cycles by allowing one object to refer to another without increasing its reference count. The primary difference lies in how they handle memory safety and the "lifetime" of the objects involved.

1. weak References

A weak reference is used when the other instance can be deallocated while the current instance is still alive. Because the object can disappear, Swift requires weak variables to be declared as optional variables (var).

• Common Use Case: The Delegate Pattern. A view doesn't "own" its delegate; the delegate might be dismissed while the view is still active.
• Mechanism: ARC automatically sets the variable to nil the moment the instance it points to is deallocated.

An unowned reference is used when the other instance is expected to have the same lifetime or a longer lifetime than the current instance. It is treated like a non-optional value, meaning you don't have to unwrap it to use it.

• Common Use Case: Parent-Child relationships where the child cannot exist without the parent (e.g., a CreditCard and a Customer).
• Mechanism: ARC does not set the value to nil. If you try to access an unowned reference after the object is gone, your app will crash (similar to a "force unwrap").

• Choose weak if you are unsure about the relative lifetimes of the two objects, or if it is perfectly normal for the referenced object to become nil. It is the "safer" default.
• Choose unowned only when you are mathematically certain that the referenced object will never be deallocated as long as the reference is being used. This avoids the overhead of dealing with Optionals.

A Capture List is a syntax used in Swift closures to explicitly define how variables (specifically self or other class instances) should be "captured" from the surrounding scope. It is the primary tool for breaking Strong Reference Cycles within closures.

When you use a property or method inside a closure, the closure "captures" a strong reference to the instance to ensure it stays alive as long as the closure exists. If that instance also owns the closure, you get a memory leak.

You define the capture list in square brackets [] immediately before the closure’s parameters (or the in keyword).

1. Using [weak self] (Recommended)

This is the safest way. Because self might be deallocated before the closure runs, it becomes nil.

Use this only if you are certain the closure will be destroyed at the same time as the class instance.

You only need a capture list if:

1. e closure is stored as a property of a class.
2. The closure refers to self (or other properties owned by that class).
3. The closure is escaping (runs after the function it was created in returns).
Note: You do not need [weak self] for non-escaping closures like sorted(), map(), or filter(), as they are executed immediately and released.

In Swift, understanding the difference between Value Types and Reference Types is fundamental to managing memory and avoiding bugs. The distinction lies in how the data is stored and what happens when you "copy" an instance.

1. Value Types (Copy Semantics)

When you assign a value type to a new variable or pass it into a function, the data is copied. Changes made to the new copy do not affect the original.

• Behavior: Like an Excel file. If you email a copy of your spreadsheet to a coworker, they have their own version. If they delete a row, your file remains unchanged.
• Memory: Managed via the Stack, which is very fast and automatically cleaned up when the scope ends.

When you assign a reference type, you are not copying the data itself. Instead, you are copying the address (pointer) of where that data lives in memory.

• Behavior: Like a Google Doc. If you share a link with a coworker, you both see the same document. If they delete a paragraph, it disappears from your screen too.
• Memory: Managed via the Heap, requiring ARC to track how many variables are currently pointing to the object.

The behavior of let (constants) differs significantly between the two:

• In a Value Type (Struct): If you declare a struct with let, you cannot change any of its properties, even if those properties were declared as var.
• In a Reference Type (Class): If you declare a class instance with let, you cannot point that variable to a different instance, but you can still modify the variable properties inside that class.

• Use Value Types (Structs) by default. They are safer (no side effects from shared state), more predictable, and highly optimized in Swift.
• Use Reference Types (Classes) only when you specifically need a "shared identity" (e.g., a Database connection or a File Manager) or when you need to use inheritance.

Copy-on-Write (CoW) is an optimization strategy used in Swift for large value types (like Array, Set, and Dictionary). While value types are technically "copied" during assignment, CoW ensures the actual copying of data only happens when one of the instances is modified.

If the data is never changed, multiple variables will point to the same memory address, saving performance and memory.

When you assign an array to a new variable, Swift creates a new "header" for the value type, but it points to the same underlying storage as the original.

You can observe this behavior by checking the memory addresses of two arrays.

• Performance: It prevents the CPU from performing expensive "deep copies" of massive arrays unless it is absolutely necessary.
• Predictability: From a developer's perspective, it still behaves exactly like a Value Type (each variable feels independent), but it has the efficiency of a Reference Type.
• Efficiency: It makes passing large collections into functions virtually "free" in terms of memory overhead.

• Custom Structs: By default, custom structs do not have CoW. If you create a struct with many properties and pass it around, it will be copied every time.
• Implementing CoW: You can manually implement CoW in your own custom types by using a private class to wrap your data and checking isKnownUniquelyReferenced(_:) before modifying it.

Introduced in Swift 5.5, async and await are the cornerstones of Swift's modern concurrency model. They allow you to write asynchronous code—code that pauses execution while waiting for a task to finish (like a network request)—in a way that looks and reads like standard, synchronous code.

Before async/await, Swift relied on "Closures" or "Completion Handlers." This often led to deeply nested code known as the "Pyramid of Doom."

• The Old Way (Closures):
• The Modern Way (async/await):

When the compiler hits an await keyword, it "pauses" the function. Crucially, this does not block the thread. 1. Suspend: The function saves its state and gives control back to the system. 2. Yield: The thread is now free to perform other tasks (like updating the UI). 3. Resume: Once the asynchronous task finishes, the system "wakes up" the function and it continues right where it left off.

• Readability: The logic flows top-to-bottom without nesting.
• Error Handling: You can use standard do-catch blocks instead of passing Result objects into closures.
• Safety: The compiler ensures that all paths in an asynchronous function eventually return a value or throw an error.
• Performance: It uses a "cooperative thread pool," which is much more efficient than the manual thread management used in GCD (Grand Central Dispatch).

In Swift, a Task is a unit of asynchronous work. While async and await describe how code can pause, a Task is the actual container that runs that code.

Think of a Task as the bridge between synchronous and asynchronous code. Since you cannot call an async function from a standard, "normal" function (like viewDidLoad), you must wrap the call in a Task to enter the concurrent world.

There are three primary ways to initiate and manage asynchronous work depending on whether the tasks are independent or related.

Use this to call an async method from a synchronous one.

Use this when you have multiple independent tasks that can run at the same time (in parallel), but you need both results before moving forward.

Used for dynamic numbers of tasks (e.g., downloading an array of 50 images). It provides more control over a collection of concurrent work.

• Cancellation: Tasks in Swift are "cooperative." This means that if you cancel a task, it doesn't just stop instantly; it is notified it should stop. You can check Task.isCancelled inside your code to clean up resources.
• Priority: You can assign priorities to tasks (e.g., .high, .userInitiated, .background) to tell the system which work is most important for the user experience.
• MainActor: By default, a Task created in a UI context (like a View Controller) runs on the Main Actor, ensuring UI updates are safe.

Unlike Grand Central Dispatch (GCD), which can lead to "Thread Explosion" (creating too many threads), the Task system uses a fixed number of threads optimized for your device's CPU cores. This makes your app significantly more performant and energy-efficient.

Introduced in Swift 5.5, an Actor is a reference type (like a class) that provides a safe way to manage shared state in a concurrent environment. Unlike classes, actors ensure that only one task at a time can access their mutable state, effectively eliminating "Data Races."

A Data Race occurs when two or more threads try to access the same memory location simultaneously, and at least one of those accesses is a "write." This leads to unpredictable crashes, memory corruption, and logic bugs that are notoriously difficult to debug.

Actors use a mechanism called Actor Isolation. Instead of using manual "Locks" or "Semaphores" (which are prone to errors), the Swift compiler automatically enforces the following rules:

Think of an Actor as a person sitting at a desk with a "mailbox." If ten different threads want the Actor to do something, they each put a letter in the mailbox. The Actor processes the letters one by one. If you are waiting for a response, you must await your turn in the queue.

• Internal Access: Code inside the actor can access its own properties synchronously (without await).
• External Access: Code outside the actor must use await because the call might be suspended if the actor is currently busy with another task.
• The MainActor: A special, globally unique actor that always runs on the Main Thread. It is used to ensure UI updates are safe from background data races.
• You can mark a class or function with @MainActor to force it to run on the main thread.

• Shared State: When multiple parts of your app need to read and write to the same data (e.g., a Database manager, an Image Cache, or User Session data).
• Replacing Locks: If you find yourself writing DispatchQueue.sync or using NSLock to protect a variable, an Actor is almost always a better, safer choice.

The @MainActor is a globally unique actor that represents the Main Thread. In iOS, macOS, and other Apple platforms, all UI updates (like changing a label's text or pushing a view controller) must happen on the main thread.

The @MainActor attribute is a compiler-enforced way to ensure that specific classes, methods, or properties are always accessed and executed on that main thread, preventing "Main Thread Sanitizer" errors and UI glitches.

When you mark code with @MainActor, Swift's concurrency system guarantees that the code will be "hoisted" onto the main thread. If you call @MainActor code from a background thread, you are forced to use the await keyword, acknowledging that the system may need to switch threads.

Before @MainActor, we used DispatchQueue.main.async. With modern Swift, we use the attribute or a Task block.

• Safety: The compiler prevents you from accidentally updating UI from a background thread.
• Readability: It replaces "callback hell" and manual DispatchQueue calls with a simple, declarative attribute.
• Atomicity: Like any actor, it ensures that only one piece of code is modifying the UI state at a time.

• View Models: Almost all View Models (especially in SwiftUI) should be marked @MainActor because their primary job is to drive the UI.
• Delegates: UI-related delegates (like UITableViewDelegate) often benefit from being isolated to the main actor.
• Completion Handlers: When bridging old code to async/await, use @MainActor to ensure the final UI update is safe.

In Swift, error handling centers around functions that are marked with the throws keyword. When calling these functions, you must use one of three versions of try to indicate how you want to handle a potential failure.

1. try (Standard Handling)

This must be used inside a do-catch block or inside another function that also throws. It provides the most control because you can inspect the error object.

This is the most concise way to handle errors. If the function throws an error, the result is simply nil. It is often paired with if let or guard let.

This tells the compiler, "I know this function could throw an error, but I promise it won't in this specific case." It "force-unwraps" the result.

• Danger: If the function actually throws an error, your app will trigger a runtime crash.

• Use try if you want to recover from the error or show a specific message to the user based on the failure type.
• Use try? if the reason for failure doesn't matter (e.g., checking if a cache file exists).
• Use try! only for "programmer errors"—things that should be caught during development and should never happen in a live environment.

Codable is a type alias that combines two protocols: Encodable and Decodable. It was introduced to provide a standardized, type-safe way to convert Swift data structures to and from external formats, most commonly JSON.

• Decodable: Converts external data (JSON) into a Swift object.
• Encodable: Converts a Swift object into external data (JSON).

Before Codable, developers had to manually map JSON keys to properties using JSONSerialization, which was error-prone and verbose. Codable automates this process.

If your property names match the JSON keys and those properties are also Codable (like String, Int, Date), Swift handles everything for you.

Often, JSON uses snake_case (e.g., first_name) while Swift uses camelCase (firstName). You can bridge this gap using a nested enum called CodingKeys.

• JSONDecoder: The engine that turns raw Data into Swift objects. It supports strategies for handling dates (.iso8601) and key transformations (.convertFromSnakeCase).
• JSONEncoder: The engine that turns Swift objects back into Data (for sending to an API).
• PropertyListEncoder/Decoder: Used for handling .plist files (common in iOS settings).

• Key Decoding Strategy: Set decoder.keyDecodingStrategy = .convertFromSnakeCase to automatically handle JSON keys like user_id without manual mapping.
• Date Decoding Strategy: Set decoder.dateDecodingStrategy = .iso8601 to parse standard timestamp strings into Swift Date objects automatically.

Introduced in Swift 5.1, the some keyword is used to return an Opaque Return Type. This allows a function or property to hide its specific, concrete underlying type from the caller, while still allowing the compiler to know exactly what that type is.

It is most famously used in SwiftUI, where every view returns some View.

To understand some, it helps to compare it to a standard return type and a "protocol" return type (existential).

In SwiftUI, views are often composed of many nested types. Without some, the return type of a simple view might look like this: VStack <TupleView <(Text, Button <Text >, Spacer)>>.

Writing that out is impossible to maintain. The some keyword tells the compiler: "I'm returning a specific layout of views, but I don't want to type out the massive, complex name. Just treat it as 'something that conforms to View'."

An opaque type must be homogenous. You cannot return different types in the same function, even if they both conform to the protocol.

• Abstraction: You can change the internal implementation of a function (e.g., changing a List to a VStack) without breaking the code of the people calling your function.
• Type Safety: Unlike returning Any, the compiler maintains the identity of the type, allowing for better optimizations and access to associated types.
• Cleaner API: It keeps your code readable by hiding the "implementation details" of complex generic types.

• Use some when you want to hide a specific type but keep it "fixed" (Best for performance/SwiftUI).
• Use any when you truly need to store a variety of different types in a single variable or array (more flexible, but slower).

A Property Wrapper is a specialized type that adds a layer of logic between how a property is stored and how it is accessed. Introduced in Swift 5.1, they allow you to extract common logic (like data persistence, validation, or UI synchronization) into a reusable wrapper that can be applied with a simple @ attribute.

Essentially, they eliminate "boilerplate" code by moving repetitive logic into a single definition.

Property wrappers are the engine behind SwiftUI and Combine. Here are the most frequently used ones:

When you use a property wrapper, the compiler generates two extra pieces of information behind the scenes:

1. The Wrapped Value: The actual data you are storing (accessed normally).
2. The Projected Value: An additional value provided by the wrapper, accessed using the $ prefix. In SwiftUI, the projected value of @State is a Binding.

Imagine you want a property that always trims whitespace from a string. Instead of doing it manually in every setter, you create a wrapper:

• Reusability: Write complex logic (like thread safety or validation) once and apply it to any property in your project.
• Declarative Syntax: It makes the intent of your code clear. Seeing @State immediately tells a developer that the property drives the UI.
• Separation of Concerns: The class using the property doesn't need to know how the data is being stored or validated—it just uses the value.

• @State: Use for private, simple data (Strings, Ints) owned by the current view.
• @StateObject: Use for creating a complex reference type (a ViewModel) that should stay alive as long as the view exists.
• @EnvironmentObject: Use for "global" data that needs to be accessed by many different views across the app (like User Settings).

The transition from UIKit to SwiftUI represents a fundamental shift in how Apple developers build interfaces. While UIKit has been the industry standard since 2008, SwiftUI is the modern framework introduced in 2019 to streamline development across all Apple platforms.

1. Imperative vs. Declarative

• UIKit (Imperative): You are the manager. If a user logs in, you must manually find the "Welcome" label, change its text, and unhide the "Logout" button. If you forget one step, the UI gets out of sync with the data.
• SwiftUI (Declarative): You describe the end state. "If isLoggedIn is true, show the logout button." When isLoggedIn changes, SwiftUI automatically calculates the difference and updates only what is necessary.

• UIKit: Uses Auto Layout, which relies on mathematical constraints (e.g., "this button is 20px from the top"). It is powerful but can become complex and difficult to debug (the dreaded "Conflicting Constraints" log).
• SwiftUI: Uses a Proposal-based layout. Parents propose a size, children choose their size, and parents place them. This makes it much easier to build adaptive interfaces that work on both an iPhone SE and an iPad Pro.

• UIKit: Built around UIViewController. These often become "Massive View Controllers" because they handle both the UI and the business logic.
• SwiftUI: Everything is a View. Views are lightweight structs that are cheap to create and destroy. Logic is typically moved into separate "View Models" using the MVVM pattern.

• Choose SwiftUI for: New projects, rapid prototyping, and apps targeting multiple Apple platforms. It is the future of Apple development.
• Choose UIKit for: Maintenance of older apps, extremely complex custom animations not yet supported in SwiftUI, or apps that must support versions older than iOS 13.
Note: You don't have to choose just one! You can use UIHostingController to put SwiftUI views into UIKit, or UIViewRepresentable to put UIKit views into SwiftUI.

In SwiftUI, Declarative Syntax means you describe what the user interface should look like for a given state, rather than providing a sequence of commands on how to modify the UI over time.

To understand declarative syntax, it helps to compare it to the traditional imperative approach used in UIKit.

In SwiftUI, you can think of the UI as a mathematical function:

When the State (data) changes, SwiftUI re-executes the function (your body property) to produce a new description of the UI.

Every SwiftUI view is a struct that conforms to the View protocol. The only requirement is a body property that returns some View. This body contains the description of your interface.

SwiftUI identifies which views depend on which pieces of state (using property wrappers like @State). When a piece of state changes, SwiftUI knows exactly which parts of the UI "tree" need to be re-evaluated.

SwiftUI doesn't just throw away the old screen and draw a new one. It creates a new "view tree," compares it to the previous one (a process called diffing), and calculates the most efficient way to update the actual pixels on the screen.

In an imperative world, you would write code to hide/show a button. In declarative SwiftUI, you simply describe the condition inside the layout.

• Single Source of Truth: You don't have to worry about the "label" says one thing while the "database" says another. The UI always reflects the current state.
• Reduced Complexity: You don't have to manage the complex transitions between states (e.g., "If I'm in state A and go to state B, I need to hide view X, show view Y, and animate Z").
• Highly Readable: The code structure visually resembles the UI hierarchy, making it easier for teams to understand the layout at a glance.

Combine is Apple’s unified declarative framework for processing values over time. It allows your code to respond to various events—like network responses, user input, or system notifications—using a series of "operators" that can transform, filter, and combine data streams.

Before Combine, developers had to use multiple different patterns for asynchronous work (Delegates, NotificationCenter, KVO, and Closures). Combine unifies these under a single syntax.

Combine operates on a Publisher-Subscriber model. Every stream of data consists of these three components:

Imagine you want to listen to a text field, wait for the user to stop typing, and then validate the input.

Combine includes dozens of operators that make handling complex data logic easy:

• map: Converts values from one type to another.
• filter: Only allows values that meet a certain condition.
• debounce: Waits for a "silence" in the stream (perfect for search bars).
• combineLatest: Merges two publishers and emits a value whenever either changes.
• catch: Handles errors by replacing a failed stream with a new publisher.

Combine is the engine that powers ObservableObjects in SwiftUI. When you use the @Published property wrapper, it automatically creates a Combine publisher. When that property changes, SwiftUI's "subscriber" hears the change and triggers a UI refresh.

With the introduction of async/await in Swift 5.5, the use cases for Combine have shifted:

• Use async/await: For simple, "one-and-done" asynchronous tasks like a single network request.
• Use Combine: For streams of data that change over time (e.g., a search bar, a socket connection, or listening to multiple hardware sensors).

A Swift Package is a collection of Swift source files and resources bundled together in a way that makes them easy to share, version, and reuse across different projects. It is the modern, official standard for code distribution in the Apple ecosystem.

Every Swift Package contains a manifest file named Package.swift, which uses Swift code to define the package's name, its products (libraries or executables), and its dependencies.

Swift Package Manager (SPM) is the tool used to manage the distribution of Swift code. It is integrated directly into the Swift compiler and Xcode, eliminating the need for third-party tools like CocoaPods or Carthage for most projects.

1. Adding a Dependency

To add a library (like Alamofire or Kingfisher) to your project:

• Go to File > Add Package Dependencies...
• Enter the GitHub URL of the library.
• Select the Version Rule (e.g., "Up to Next Major Version").
• Xcode automatically downloads the code and links it to your target.

If you want to modularize your app code into reusable chunks:

• Go to File > New > Package...
• Define your logic in the Sources folder.
• The Package.swift file acts as the "brain," telling the compiler which files to include.

The manifest file is where the configuration happens. It generally consists of:

• name: The name of the package.
• platforms: Supported OS versions (e.g., .iOS(.v15)).
• products: The libraries or executables you are making available.
• dependencies: Other packages your code relies on.
• targets: The actual source code modules and their tests.

• No "Workspace" Bloat: You don't need a separate workspace file; dependencies are integrated directly into the .xcodeproj.
• Version Safety: SPM uses Semantic Versioning (SemVer) to ensure that updating a library doesn't accidentally break your code with incompatible changes.
• Cloud Support: Since Xcode 11, SPM works seamlessly with cloud-based CI/CD pipelines.

The Info.plist (Information Property List) is a structured configuration file that provides the iOS system with essential metadata about your application. It is a key-value store (usually formatted as an XML file) that tells the operating system how the app should behave, what permissions it requires, and how it should be identified.

Without this file, the system wouldn't know your app's name, which icon to display, or whether it’s allowed to use the camera.

1. Privacy Usage Descriptions (The "Why")

If your app tries to access the user's photos, microphone, or camera without a corresponding entry in the Info.plist, the app will crash immediately upon the request. You must provide a "Usage Description" string that the user sees in the permission alert.

• Example: NSCameraUsageDescription ? "This app needs camera access to take your profile picture."

The system uses these keys to track updates and ensure app uniqueness in the App Store.

• CFBundleIdentifier: The "Reverse DNS" string (e.g., com.company.appname) that uniquely identifies your app globally.
• CFBundleVersion: The build number (internal), while CFBundleShortVersionString is the version shown to users (e.g., 1.2.0).

By default, iOS requires apps to use secure HTTPS connections. If you need to connect to an insecure server (HTTP) during development, you must configure NSAppTransportSecurity in this file to bypass the restriction.

In modern Xcode projects (Xcode 13+), many of these settings have been moved to the Project Target > Info tab to reduce file clutter. However, a physical Info.plist file is still generated during the build process to be bundled with your app.

The Info.plist is the "Driver's License" of your app. It tells the system:

1. Who I am (Identity)
2. What I can do (Capabilities/Permissions)
3. How I look (Icons/Launch Screens)

Swift is designed to be interoperable with Objective-C, meaning you can use both languages in the same project. This allows developers to migrate older apps to Swift incrementally or use powerful legacy libraries without rewriting them from scratch.

The bridge between these two languages is managed primarily through two key files: the Bridging Header and the Generated Header.

The mechanism depends on which direction the code is flowing:

When you add an Objective-C file to a Swift project, Xcode asks to create a Bridging Header.

• How it works: You #import any Objective-C headers you want Swift to see into this file.
• The Result: The Objective-C classes, methods, and properties become available in Swift as if they were native Swift code.

Objective-C cannot see Swift code automatically. You must expose your Swift code using two steps:

• Step 1: The @objc Attribute: Mark classes (which must inherit from NSObject) and methods with @objc or @objcMembers.
• Step 2: The Generated Header: In your .m file, import the hidden header: #import "ProjectName-Swift.h".

To make Objective-C code feel more "Swift-like," developers use nullability annotations in Obj-C. This tells Swift whether an Obj-C pointer should be imported as an Optional or a Non-Optional value.

• _Nonnull: Imported as Type.
• _Nullable: Imported as Type?.

Most long-standing iOS apps (like Facebook, Instagram, or Spotify) started in Objective-C. Interoperability is the only reason these companies can adopt modern features like SwiftUI and Combine today without a complete "ground-up" rewrite.

A Key-Path is a way to refer to a property of a class or struct as a standalone value rather than accessing the property's data directly. You can think of it as a "reference to a property" or a "stored shortcut" to a specific field within a data structure.

In Swift, key-paths are strongly typed, meaning the compiler ensures that the path you are describing actually exists on the target type.

Key-paths start with a backslash (\), followed by the type name (optional if inferred), and the property chain.

1. Functional Programming (Map and Sort)

Key-paths can be used as functions in methods like map or filter. This makes the code much cleaner than using closures.

Key-paths allow you to write functions that can work on any property of a type as long as the types match.

SwiftUI uses key-paths extensively for identifying items in lists (\.id) and for animations.

There are different "flavors" of key-paths depending on whether the property is read-only or mutable:

• Type Safety: Unlike string-based keys used in Objective-C (KVC), Swift key-paths are checked at compile-time. If you rename a property, the compiler will catch every key-path that needs updating.
• Composition: You can append key-paths together to create deeper paths dynamically.
• Readability: It reduces boilerplate code in data-heavy applications, especially when dealing with sorting and filtering large arrays of models.

The defer keyword is used to define a block of code that will be executed just before the current scope (like a function, loop, or if statement) exits. It is commonly referred to as a "cleanup" mechanism, ensuring that necessary actions—like closing files or releasing locks—happen regardless of how the function finishes (whether it returns normally or throws an error).

1. Resource Cleanup (Files & Locks)

This is the most frequent use case. It prevents you from forgetting to "close" what you "opened."

Useful for toggling a "loading" state.

When you have multiple defer statements, think of them as being pushed onto a stack. The last one defined is the first one to run.

A defer block is tied to its immediate scope. If you put a defer inside an if statement, it will run as soon as that if block ends, not at the end of the entire function.

XCTest is Apple’s official framework for creating and running unit tests, performance tests, and UI tests for Xcode projects. The goal of unit testing is to verify that a specific "unit" of code (usually a single function or class) behaves exactly as expected under various conditions.

To write unit tests, you create a class that inherits from XCTestCase. Every test method must start with the word test for the test runner to recognize it.

Most unit tests follow the Arrange, Act, Assert structure to ensure clarity:

Since network requests and background tasks don't finish instantly, you use XCTestExpectation to wait for the results.

XCTest can also measure how long a piece of code takes to run. If the code becomes significantly slower in a future update, the test will fail.

• Catch Bugs Early: Find logic errors before the code even reaches the QA team.
• Refactor with Confidence: Change your internal code knowing that the tests will catch it if you break existing functionality.
• Documentation: Tests serve as a guide for other developers on how a function is intended to be used.

Swift Evolution is the community-driven process used to propose, review, and implement changes to the Swift programming language. Because Swift is an open-source language, its growth isn't decided solely by Apple; it is a transparent collaboration between Apple engineers and the global developer community via the Swift Evolution GitHub repository and the Swift Forums.

A new feature (like async/await or macros) must go through a rigorous lifecycle before it becomes part of the language:

• The Core Team: A small group of senior engineers (mostly from Apple) who have final authority over the language's direction.
• SE Numbers: Every proposal is assigned a unique number (e.g., SE-0299 was the proposal for "Static Member Lookup in Generic Contexts"). You will often see these numbers cited in technical blogs.
• Swift Forums: The central hub for all discussions. It is divided into sections like Evolution, Development, and Using Swift.

1. Transparency: Developers can see exactly why a feature was added and what alternatives were considered.
2. Stability: The process prevents "knee-jerk" changes that could break millions of lines of existing code.
3. Quality: Peer review from thousands of developers ensures that the syntax is logical and the edge cases are handled.
4. Community Ownership: It allows non-Apple employees to contribute major features, ensuring Swift remains a general-purpose language (server-side, Windows, Linux), not just an "Apple-only" tool.

• Swift.org: The official site for news and downloads.
• Evolution Dashboard: A web-based tool (available on the Swift website) that allows you to filter proposals by status (Implemented, In Review, etc.).
• GitHub: You can read the actual markdown files for every proposal ever written in the apple/swift-evolution repository.

You have officially completed 50 core iOS Interview Questions! We have covered:

• Basics: Optionals, Structs vs. Classes, Closures.
• Memory Management: ARC, Retain Cycles, Weak/Unowned.
• Concurrency: Async/await, Tasks, Actors, MainActor.
• Frameworks: SwiftUI, UIKit, Combine, XCTest.
• Deep Dives: Codable, Key-Paths, Defer, and Swift Evolution.