No detection
No warnings
Prevents

If you’ve enabled Swift 6 language mode, you’ve likely seen errors about:

• Actor isolation
• Sendable
• Crossing concurrency boundaries
• MainActor violations

These are not annoyances. They are the compiler actively protecting your app from race conditions.

This article explains Swift concurrency the way it actually works internally, with mental models, diagrams, and practical examples.

The Big Picture: Swift Concurrency Architecture

Swift concurrency is built on three pillars:

Actors → Protect mutable state
Isolation → Enforce ownership boundaries
Sendable → Ensure safe data transfer

Together, they eliminate data races.

First, What Problem Are We Solving?

A data race happens when multiple threads access and modify the same memory simultaneously.

class Counter {
    var value = 0

    func increment() {
        value += 1
    }
}

Now imagine:

DispatchQueue.global().async {
    counter.increment()
}

DispatchQueue.global().async {
    counter.increment()
}

Thread 1 reads value = 0
Thread 2 reads value = 0

Thread 1 writes value = 1
Thread 2 writes value = 1

Final value = 1 instead of 2.

This is a data race. GCD does not prevent this. Swift concurrency does.

Pillar 1: Actors — Protect Mutable State

Actors are reference types that ensure only one task can access their mutable state at a time.

actor Counter {

    var value = 0

    func increment() {
        value += 1
    }
}

let counter = Counter()

Task {
    await counter.increment()
}

Swift guarantees safe access.

No locks needed. No DispatchQueue needed.

Actor Mailbox — The Most Important Internal Concept

Every actor has a mailbox.

Mailbox is an internal queue that stores incoming requests.

Task { await counter.increment() }
Task { await counter.increment() }
Task { await counter.increment() }

[increment]
[increment]
[increment]

Actor processes them one by one:

value = 1
value = 2
value = 3

This prevents race conditions.

Important truth: Actors do NOT execute methods immediately. They enqueue requests in mailbox.

Actor Isolation — Ownership of State

Isolation means:

Only the actor that owns the state can access it directly.

Example:

actor BankAccount {

    var balance = 1000

    func withdraw(amount: Int) {
        balance -= amount
    }
}

This is illegal:

account.balance -= 100

Compiler error.

Correct way:

await account.withdraw(amount: 100)

Why?

Because balance belongs exclusively to BankAccount actor. This ownership prevents race conditions.

Global Actors and MainActor

Some actors represent global execution domains.

//This guarantees execution on main thread.
@MainActor
class ViewModel {

    var title = ""

    func update() {
        title = "Updated"
    }
}

Pillar 2: Sendable — Safe Data Transfer Between Actors

Sendable ensures a type can safely cross concurrency boundaries.

Concurrency boundary examples:

• actor → actor
• task → actor
• thread → actor

//Unsafe example:
class User {

    var name: String
}

This is dangerous because multiple actors could modify same instance.

Swift prevents this. Safe example:

struct User: Sendable {

    let name: String
}

Struct creates copy. No shared mutable state. Safe.

Compiler enforcement example:

actor UserManager {

//If User is class, Swift 6 error appears.
    func update(user: User) {}
}

// FIX
struct User: Sendable {
    let name: String
}

What Isolation and Sendable Together Achieve

Isolation protects memory access.

Sendable protects memory transfer.

Together, they eliminate unsafe shared state.

How Swift Concurrency Is Different From GCD

This is the most important conceptual shift.

// GCD example:
queue.async {
    self.value += 1
}

// Swift concurrency equivalent:
actor Counter {
    var value = 0
}

Strict Concurrency in Swift 6

Swift 6 enforces compile-time safety.

class Manager {
    var value = 0
    func update() {
        Task {
            value += 1
        }
    }
}

// Error: Mutation of captured var in concurrently executing code

Fix:

actor Manager {
    var value = 0
    func update() {
        value += 1
    }
}

Preconcurrency — Supporting Legacy Code

Many libraries were written before Swift concurrency existed.

class LegacyAPI {
    func fetch(completion: @escaping (String) -> Void) {}
}

@preconcurrency import LegacyLibrary

This tells compiler:

This code was written before concurrency safety existed. Trust developer. It allows gradual migration.

MainActor violation:

// wrong
Task {
    viewModel.title = "Hello"
}

// Correct
Task {
    await MainActor.run {
        viewModel.title = "Hello"
    }
}

Best Practices

Use actors for shared mutable state.

Prefer structs over classes.
Use MainActor for UI.
Avoid shared mutable state.
Trust compiler errors.

Mental Model That Makes Everything Click

Imagine actor as a bank teller.

Mailbox → people waiting in line
Isolation → only teller accesses bank account
Sendable → safe documents passed to teller
Compiler → security guard enforcing rules

Interview Questions and Answers

Question: What is actor mailbox?

Answer:

Mailbox is an internal queue that stores requests to actor. Actor processes them sequentially, preventing race conditions.

Question: What is isolation?

Answer:

Isolation ensures only the owning actor can directly access its mutable state.

Question: Why is Sendable needed?

Answer:

Sendable ensures safe transfer of data between concurrency domains, preventing shared mutable state.

Question: Why is Swift concurrency safer than GCD?

Answer:

Swift concurrency provides compile-time race detection, while GCD relies on programmer discipline.

Question: What is preconcurrency?

Answer:

It allows legacy code to work without strict concurrency enforcement, enabling gradual migration.

As a new learner diving into the world of React development, you’re embarking on an exciting journey filled with endless possibilities. However, navigating this journey can be overwhelming, especially when faced with the complexities of a powerful library like React. Fortunately, there’s a guiding light to illuminate your path: Akshay Saini’s “Namaste React” video series.

What is “Namaste React”?

“Namaste React” isn’t just another video series — it’s your gateway to mastering React development from the ground up. Designed with new learners in mind, this comprehensive series breaks down the complicated parts of React into digestible lessons, making it accessible and enjoyable for beginners like us. With Akshay as our guide, we’ll explore React’s core concepts, build real-world projects, and gain the confidence to tackle any React challenge that comes our way.

Key Features of “Namaste React”:

Beginner-Friendly Approach: Akshay Saini takes a step-by-step approach to teaching React, starting with the fundamentals and gradually building upon them. Concepts are explained in a clear and concise manner, making them easy to understand for beginners.

Practical Examples: Throughout the series, Akshay demonstrates real-world examples of React applications, showing how to implement common features and solve common challenges faced by developers.

Hands-on Exercises: To reinforce learning, each video includes hands-on exercises that allow viewers to practice what they’ve learned. These exercises help developers gain practical experience with React and build confidence in their skills.

Depth and Breadth: The “Namaste React” series covers a wide range of topics, including React components, state management, routing, hooks, context, and more. Akshay delves deep into each topic, providing a thorough understanding of React’s core concepts and best practices.

Engaging Presentation: Akshay Saini’s teaching style is engaging and approachable, making learning React an enjoyable experience. His enthusiasm for the subject shines through in every video, inspiring viewers to dive deeper into the world of React development.

Below are few instances explaining how Akshay’s video helped:

In one of his videos, Akshay introduces the concept of React components, which are the building blocks of React applications. He explains that components are reusable, self-contained units of UI that can be composed together to build complex user interfaces.

To illustrate this concept, Akshay creates a simple React application with two components: a Header component and a Footer component. In the video, he demonstrates how to create each component using functional components, a feature introduced in React.

// Header component
const Header = () => {
  return (
    <header>
      <h1>Welcome to my React App</h1>
    </header>
  );
};

// Footer component
const Footer = () => {
  return (
    <footer>
      <p>&copy; 2024 My React App</p>
    </footer>
  );
};

Akshay then explains how to compose these components together to create the main application layout. He demonstrates how to import and use the Header and Footer components within the main App component.

// App component
const App = () => {
  return (
    <div>
      <Header />
      <p>Main content goes here</p>
      <Footer />
    </div>
  );
};

Throughout the video, Akshay provides clear explanations of each step, highlighting important concepts such as component composition, JSX syntax, and the role of functional components in React development. He also encourages viewers to follow along and experiment with the code, reinforcing their understanding through hands-on practice.

By the end of the video, I have gained a good understanding of React components and how to create and compose them to build dynamic user interfaces(As beginner). I have also learned best practices for structuring React applications and are well-equipped to continue exploring React development with confidence.

Akshay Saini’s “Namaste React” video series stands out from other creators’ content in several ways:

Clear and Engaging Teaching Style: Akshay’s teaching style is known for its clarity and engagement. He explains complex concepts in a simple and straightforward manner, making them easy to understand for learners of all levels. His enthusiasm for the subject shines through in every video, keeping viewers engaged and motivated throughout the learning process.

Comprehensive Coverage: The “Namaste React” series covers a wide range of topics, from the basics of React to more advanced concepts. Akshay takes a comprehensive approach to teaching React, ensuring that viewers gain a thorough understanding of the library and its capabilities. Whether you’re a beginner or an experienced developer, there’s something for everyone in the series.

Practical Examples and Hands-on Exercises: Akshay provides practical examples and hands-on exercises throughout the series, allowing viewers to apply what they’ve learned in real-world scenarios. By working through these exercises, learners gain practical experience with React and build confidence in their skills.

Focus on Best Practices: Akshay emphasises best practices throughout the series, teaching viewers not only how to use React but also how to use it effectively. He covers topics such as component composition, state management, and performance optimisation, helping viewers develop a solid foundation in React development.

As you embark on your React journey with Akshay Saini’s “Namaste React” video series, remember that learning to code is not just about mastering a new technology — it’s about embracing the joy of discovery, the thrill of problem-solving, and the satisfaction of creating something meaningful. With Akshay’s expert guidance and your own dedication, there’s no limit to what you can achieve. The best part of this course is, it only costs ₹2300/-.

Link to his website: https://namastedev.com/

Because MVVM can separate concerns and provides data binding support, it has become a prevalent method of organising code in most modern mobile as well as web applications. But while projects become more complex, developers face tight coupling between layers, challenges in testing, and the need to keep separation clear.

Contrarily, Clean Architecture focuses on dividing responsibilities, being independent from external frameworks and ensuring that the code can be tested. It provides specific instructions on how best to split up your code into distinct layers with defined roles leading to less error-prone designs which allow for better maintenance and expansion.

This blogs will take you through the process of moving from MVVM to Clean Architecture. Specifically, we will explain what clean architecture entails including its guiding principles; we will also outline its constituents as opposed to MVVM. Besides this, there are strategies that can be used for rewriting existing MVVM-based codes so that it follows principles of a clean architecture as well as making development smoother and easier maintenance.

{
  "data": [
    {
      "id": "bitcoin",
      "rank": "1",
      "symbol": "BTC",
      "name": "Bitcoin",
      "supply": "18824943.0000000000000000",
      "maxSupply": "21000000.0000000000000000",
      "marketCapUsd": "1104472461633.1075176780327501",
      "volumeUsd24Hr": "66566480087.0421125881533446",
      "priceUsd": "58602.6054006234050000",
      "changePercent24Hr": "0.3583330721187001",
      "vwap24Hr": "57638.2622376795013008"
    },
    // More assets...
  ],
  "timestamp": 1649297859407
}

We will work on above JSON response to mock our code.
https://docs.coincap.io/

struct AssetData: Codable {
    let data: [Asset]
    let timestamp: TimeInterval
}

struct Asset: Codable {
    let id: String
    let rank: String
    let symbol: String
    let name: String
    let supply: String
    let maxSupply: String
    let marketCapUsd: String
    let volumeUsd24Hr: String
    let priceUsd: String
    let changePercent24Hr: String
    let vwap24Hr: String
}

This will be our model structure for the same.

import UIKit

class AssetListViewController: UIViewController {
    @IBOutlet weak var collectionView: UICollectionView!
    
    let viewModel = AssetListViewModel()
    
    // Declare diffable data source
    var dataSource: UICollectionViewDiffableDataSource<Section, Asset>!
    
    enum Section {
        case main
    }
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        collectionView.collectionViewLayout = createLayout()
        
        // Initialize and configure diffable data source
        dataSource = UICollectionViewDiffableDataSource<Section, Asset>(collectionView: collectionView) { collectionView, indexPath, asset in
            return collectionView.dequeueConfiguredReusableCell(using: self.createCellRegistration(), for: indexPath, item: asset)
        }
        
        viewModel.fetchAssets()
        
        viewModel.$assets
            .sink { [weak self] assets in
                self?.applySnapshot(assets: assets)
            }
            .store(in: &viewModel.cancellables)
        
        // Handle errors
        viewModel.$error
            .sink { error in
                if let error = error {
                    print("Error fetching assets: \(error)")
                }
            }
            .store(in: &viewModel.cancellables)
    }
    
    private func createLayout() -> UICollectionViewLayout {
        let layout = UICollectionViewCompositionalLayout { _, _ in
            let itemSize = NSCollectionLayoutSize(widthDimension: .fractionalWidth(1), heightDimension: .estimated(50))
            let item = NSCollectionLayoutItem(layoutSize: itemSize)
            let group = NSCollectionLayoutGroup.horizontal(layoutSize: itemSize, subitem: item, count: 1)
            let section = NSCollectionLayoutSection(group: group)
            return section
        }
        return layout
    }
    
    private func createCellRegistration() -> UICollectionView.CellRegistration<UICollectionViewListCell, Asset> {
        return UICollectionView.CellRegistration<UICollectionViewListCell, Asset> { cell, indexPath, asset in
            var contentConfiguration = UIListContentConfiguration.valueCell()
            contentConfiguration.text = asset.name
            contentConfiguration.secondaryText = "\(asset.symbol) - \(asset.priceUsd)"
            cell.contentConfiguration = contentConfiguration
        }
    }
    
    private func applySnapshot(assets: [Asset]) {
        var snapshot = NSDiffableDataSourceSnapshot<Section, Asset>()
        snapshot.appendSections([.main])
        snapshot.appendItems(assets)
        dataSource.apply(snapshot, animatingDifferences: true)
    }
}

extension AssetListViewController: UICollectionViewDelegate {
    func collectionView(_ collectionView: UICollectionView, didSelectItemAt indexPath: IndexPath) {
        guard let asset = dataSource.itemIdentifier(for: indexPath) else { return }

        //On tapping cell data is loaded in AssetDetailViewController 
        guard let asset = dataSource.itemIdentifier(for: indexPath) else { return }
        coordinator?.showAssetDetail(asset: asset)
    }
}

This is our view controller to present the data.

class APIUtility {
    static let shared = APIUtility()
    
    private init() {}
    
    func fetchAssets() -> AnyPublisher<AssetData, Error> {
        guard let url = URL(string: "http://api.coincap.io/v2/assets") else {
            return Fail(error: NSError(domain: "Invalid URL", code: 0, userInfo: nil)).eraseToAnyPublisher()
        }
        
        return URLSession.shared.dataTaskPublisher(for: url)
            .map { $0.data }
            .decode(type: AssetData.self, decoder: JSONDecoder())
            .eraseToAnyPublisher()
    }
}


class AssetListViewModel: ObservableObject {
    @Published var assets: [Asset] = []
    @Published var error: Error?
    private var cancellables = Set<AnyCancellable>()
    
    func fetchAssets() {
        APIUtility.shared.fetchAssets()
            .receive(on: DispatchQueue.main)
            .sink { completion in
                if case let .failure(error) = completion {
                    self.error = error
                }
            } receiveValue: { assetData in
                self.assets = assetData.data
            }
            .store(in: &cancellables)
    }
}

protocol Coordinator {
    func start()
    func showAssetDetail(asset: Asset)
    // Add other navigation methods as needed
}

class MainCoordinator: Coordinator {
    private let navigationController: UINavigationController
    
    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }
    
    func start() {
        let assetListViewController = AssetListViewController.instantiate()
        assetListViewController.coordinator = self
        navigationController.pushViewController(assetListViewController, animated: false)
    }
    
    func showAssetDetail(asset: Asset) {
        let assetDetailViewController = AssetDetailViewController.instantiate()
        assetDetailViewController.asset = asset
        navigationController.pushViewController(assetDetailViewController, animated: true)
    }
}

extension UIViewController {
    static func instantiate() -> Self {
        let storyboard = UIStoryboard(name: "Main", bundle: nil)
        return storyboard.instantiateViewController(withIdentifier: String(describing: self)) as! Self
    }
}

A little bonus, let’s inject the asset using a property wrapper:

@propertyWrapper
struct InjectAsset {
    var asset: Asset
    
    init(wrappedValue: Asset) {
        self.asset = wrappedValue
    }
    
    var wrappedValue: Asset {
        get { return asset }
        set { asset = newValue }
    }
}

class AssetDetailViewController: UIViewController {
    // Use the property wrapper to inject the asset
    @InjectAsset var asset: Asset
    
    override func viewDidLoad() {
        super.viewDidLoad()
        print("Asset name: \(asset.name)")
    }
}

How Clean Architecture is different from MVVM-C?

Clean Architecture and MVVM-C (Model-View-ViewModel-Coordinator) are both architectural patterns used in iOS development, but they serve different purposes and have different focuses. Here’s how they compare:

MVVM-C (Model-View-ViewModel-Coordinator):

1. Model: Represents the data model of the application.
2. View: Represents the user interface (UI) of the application.
3. ViewModel: Acts as an intermediary between the View and the Model. It exposes data from the Model to the View in a format suitable for presentation and translates user interactions from the View into actions that affect the Model.
4. Coordinator: Handles navigation and flow between different screens (ViewControllers) in the application. It typically abstracts away the navigation logic from the ViewControllers.

Characteristics:
1. Separation of Concerns: MVVM-C separates concerns by assigning specific responsibilities to each component. Views focus on UI rendering, ViewModels handle business logic, and Coordinators manage navigation flow.
2. Testability: MVVM-C promotes testability by isolating business logic from UI code, making it easier to write unit tests for ViewModels and Coordinators.
3. Reusability: Components in MVVM-C, especially ViewModels, can be reused across different parts of the application, promoting code reuse and maintainability.

Clean Architecture:

Clean Architecture, as proposed by Robert C. Martin (Uncle Bob), emphasises a clear separation of concerns and independence of the application’s business logic from external concerns like UI frameworks and database frameworks. It consists of multiple layers, including:

1. Entities: Represents the core business logic and data structures of the application.
2. Use Cases: Contains application-specific business rules and logic. It defines actions that can be performed within the application.
3. Interface Adapters: Converts data from the Use Cases into a format suitable for presentation in the UI and vice versa. This layer includes Presenters (or ViewModels), which are responsible for preparing data for display.
4. Frameworks & Drivers: Contains external frameworks, such as UI frameworks (e.g., UIKit) and database frameworks. These frameworks are considered implementation details and are kept separate from the core business logic.

Characteristics:

1. Decoupling: Clean Architecture promotes loose coupling between different components of the application, making it easier to modify and maintain the codebase.
2. Dependency Inversion Principle (DIP): Components in Clean Architecture depend on abstractions rather than concrete implementations, allowing for easier substitution and testing.
3. Isolation of Concerns: Each layer in Clean Architecture has a specific responsibility, and dependencies flow inward toward the core business logic, enforcing a clear separation of concerns.

Differences:

1. Focus: MVVM-C focuses more on structuring UI-related code and managing navigation flow, while Clean Architecture focuses on designing the core business logic of the application.
2. Layered Architecture vs. Pattern: Clean Architecture is an architectural design principle that can be applied to various design patterns, including MVVM-C. MVVM-C, on the other hand, is a specific pattern that addresses UI architecture and navigation flow.
3. Granularity: Clean Architecture provides a more granular separation of concerns with its layered approach, whereas MVVM-C combines ViewModel and Coordinator responsibilities into one layer for managing UI logic and navigation.

In summary, while MVVM-C and Clean Architecture share some similarities in promoting separation of concerns and testability, they serve different purposes and can be complementary in structuring iOS applications. Developers can choose the one that best fits the requirements and complexity of their projects.

Now let’s jump into converting our project from MVVM-C to Clean Architecture.

To comply with the Clean Architecture principles, this code will be split into three sections: Presentation, Domain and Data. Each of these segments will have its own duties ensuring that the system is better organized and easier to test. Here is a step by step guide on how to refactor AssetListViewController and AssetDetailViewController so that they work in this structure.

Presentation Layer:

• Contains UI-related logic and components.
• UIViewController instances reside in this layer.
• Handles user input and presents data to the user.

Domain Layer:

• Contains business logic and use cases.
• Defines entities and business rules.

Data Layer:

• Handles data retrieval and persistence.
• Communicates with external sources like APIs or databases.

Presentation Layer:

import UIKit

protocol AssetListViewProtocol: AnyObject {
    func presentFetchedAssets(_ assets: [Asset])
    func displayError(_ error: Error)
}

class AssetListViewController: UIViewController, AssetListViewProtocol {
    var presenter: AssetListPresenterProtocol!
    
    override func viewDidLoad() {
        super.viewDidLoad()
        presenter.viewDidLoad()
    }
    
    // Implement AssetListViewProtocol methods
    func displayAssets(_ assets: [Asset]) {
        // Update UI with assets
    }
    
    func displayError(_ error: Error) {
        // Display error message
    }
}

// MARK: - AssetListPresenter

protocol AssetListPresenterProtocol {
    var view: AssetListViewProtocol? { get set }
    func fetchAssets()
}

class AssetListPresenter: AssetListPresenterProtocol {
    weak var view: AssetListViewProtocol?
    let interactor: AssetListInteractorProtocol
    
    init(interactor: AssetListInteractorProtocol) {
        self.interactor = interactor
    }
    
    func fetchAssets() {
        interactor.fetchAssets()
    }
    
    func presentFetchedAssets(_ assets: [Asset]) {
        view?.displayAssets(assets)
    }
    
    func presentError(_ error: Error) {
        view?.displayError(error)
    }
}

// MARK: - AssetListInteractor

protocol AssetListInteractorProtocol {
    var presenter: AssetListPresenterProtocol? { get set }
    func fetchAssets()
}

class AssetListInteractor: AssetListInteractorProtocol {
    weak var presenter: AssetListPresenterProtocol?
    let assetService: AssetServiceProtocol
    
    private var cancellables = Set<AnyCancellable>()
    
    init(assetService: AssetServiceProtocol) {
        self.assetService = assetService
    }
    
    func fetchAssets() {
        assetService.fetchAssets()
            .sink(receiveCompletion: { [weak self] completion in
                if case let .failure(error) = completion {
                    self?.presenter?.presentError(error)
                }
            }, receiveValue: { [weak self] assets in
                self?.presenter?.presentFetchedAssets(assets)
            })
            .store(in: &cancellables)
    }
}

protocol AssetServiceProtocol {
    func fetchAssets() -> AnyPublisher<[Asset], Error>
}

struct AssetDataResponse: Codable {
    let data: [Asset]
}

Domain Layer:

struct Asset {
    let id: String
    let name: String
    let symbol: String
    let priceUsd: String
}

Data Layer:

class AssetService: AssetServiceProtocol {
    func fetchAssets() -> AnyPublisher<[Asset], Error> {
        guard let url = URL(string: "http://api.coincap.io/v2/assets") else {
            return Fail(error: URLError(.badURL)).eraseToAnyPublisher()
        }
        
        return URLSession.shared.dataTaskPublisher(for: url)
            .map(\.data)
            .decode(type: AssetDataResponse.self, decoder: JSONDecoder())
            .map(\.data)
            .eraseToAnyPublisher()
    }
}

Conclusion:

Both MVVM-C and Clean Architecture are valid architectural patterns for iOS development, and the choice between them depends on factors such as project requirements, team expertise, and personal preferences. It’s essential to evaluate the specific needs and goals of your project and consider factors such as complexity, maintainability, testability, and scalability when selecting an architecture. Ultimately, the “better” architecture is the one that best fits the needs of your project and team.

I will recommend to read below blogs/Book for more information.

References:
https://betterprogramming.pub/ios-clean-architecture-using-swiftui-combine-and-dependency-injection-for-dummies-2e44600f952b

https://www.hackingwithswift.com/articles/71/how-to-use-the-coordinator-pattern-in-ios-apps

MVVM+Coordinators IOS Architecture Tutorial

https://www.oreilly.com/library/view/clean-architecture-a/9780134494272/

Q. What is the purpose of the map operator in Combine Swift?

Answer: The map operator transforms each element emitted by a publisher by applying a closure to it, producing a new value. It allows for the conversion of one type of value to another or the modification of values emitted by a publisher.

Q. Explain the difference between the map and flatMap operators in Combine. Provide examples to illustrate your explanation.

Answer: The map operator transforms each element emitted by a publisher independently, while the flatMap operator flattens nested publishers and merges their emissions into a single stream. For example, map would transform each integer emitted by a publisher into a string, while flatMap could handle nested publishers and flatten their emissions into a single stream.

Q. How does the filter operator work in Combine? Provide a scenario where you would use it.

Answer: The filter operator evaluates each element emitted by a publisher against a predicate closure. It only allows elements that satisfy the predicate to pass through. For example, you could use the filter operator to filter out even numbers from a stream of integers.

Q. What is the role of the merge operator in Combine? How does it handle multiple publishers?

Answer: The merge operator combines emissions from multiple publishers into a single stream. It subscribes to all publishers simultaneously and forwards values from any of them to its downstream subscriber as they arrive. This allows you to merge streams of data from different sources, such as user input events and network responses.

Q. Describe the behavior of the flatMap operator when working with sequences of publishers. Provide an example scenario where you would use it.

Answer: The flatMap operator subscribes to each publisher emitted by a sequence of publishers and merges their emissions into a single stream. It's useful when you have a sequence of asynchronous operations that produce publishers, and you want to flatten their emissions into a single stream. For example, you could use flatMap to handle a sequence of network requests where each request emits a publisher of response data.

Q. Explain the purpose of the compactMap operator in Combine. How does it differ from the map operator?

Answer: The compactMap operator applies a transformation to each element emitted by a publisher and filters out any resulting nil values. It's similar to the map operator but automatically handles optional values, unwrapping them and discarding nil results. This is useful when you want to transform optional values emitted by a publisher into non-optional values.

Q. What is backpressure, and how does Combine handle it? Discuss the role of the buffer and throttle operators in managing backpressure.

Answer: Backpressure occurs when a downstream subscriber is unable to keep up with the rate of emissions from an upstream publisher, leading to a buildup of unprocessed data. Combine handles backpressure by using strategies such as buffering, throttling, or dropping emissions. The buffer operator buffers emitted values and delivers them to the downstream subscriber at a controlled rate, while the throttle operator limits the rate of emissions by discarding values emitted too frequently.

Q. How does the combineLatest operator work in Combine? Provide an example scenario where you would use it.

Answer: The combineLatest operator combines the most recent values emitted by multiple publishers into a single stream, producing a new value whenever any of the combined publishers emit a value. It's useful for scenarios where you need to react to changes in multiple sources of data simultaneously, such as updating UI elements based on the latest user input and network responses.

Q. Discuss the difference between the switchToLatest and flatMapLatest operators in Combine. When would you use each of them?

Answer: Both switchToLatest and flatMapLatest operators subscribe to each publisher emitted by an upstream publisher, but they handle new emissions differently. switchToLatest cancels the previous subscription as soon as a new publisher is emitted, while flatMapLatest cancels the previous subscription only when a new publisher emits a value. You would use switchToLatest when you want to ignore emissions from previous publishers and only react to emissions from the latest publisher, while flatMapLatest is useful when you want to process emissions from each publisher sequentially, with only the emissions from the latest publisher being forwarded downstream.

Q. Explain the purpose of the scan operator in Combine. Provide an example scenario where you would use it to maintain state.

Answer: The scan operator applies an accumulation closure to each element emitted by a publisher, maintaining a state that is updated with each emission. It's useful for maintaining and updating state over time, such as calculating running totals or aggregating values. For example, you could use scan to calculate the cumulative sum of values emitted by a publisher.

Understanding Combine Swift:

• Definition: Combine Swift is a powerful framework introduced by Apple, revolutionizing reactive programming in Swift.
• Principles: It operates on the principles of reactive programming, enabling developers to handle asynchronous events and data streams efficiently.
• Core Components: Combine comprises essential components like Publishers, Subscribers, and Operators, each playing a crucial role in data flow and manipulation.

Essential Concepts in Combine Swift:

In preparing for Combine Swift interviews, it’s crucial to have a deep understanding of its core concepts. Let’s explore these concepts further with examples:

Publishers and Subscribers:

Definition: Publishers emit values over time, and subscribers receive and handle these values. This mechanism forms the backbone of reactive programming in Combine.

import Combine

let publisher = Just("Hello, World!") // Publisher emitting a single value
let subscriber = Subscribers.Sink<String, Never>(
    receiveCompletion: { completion in
        // Handle completion (not applicable in this case)
    },
    receiveValue: { value in
        print(value) // Output: Hello, World!
    }
)

publisher.subscribe(subscriber)

Operators:

Definition: Operators in Combine transform, combine, or manipulate the data emitted by publishers, allowing for powerful data processing pipelines.import Combine

let numbers = [1, 2, 3, 4, 5]
let publisher = numbers.publisher

publisher
 .map { $0 * 2 } // Double each number
 .filter { $0.isMultiple(of: 3) } // Filter multiples of 3
 .sink { value in
 print(value) // Output: 6
 }
 .store(in: &cancellables)

Error Handling:

Definition: Combine provides operators to handle errors emitted by publishers, ensuring graceful error propagation and recovery within data processing pipelines.

import Combine

enum CustomError: Error {
    case someError
}

let publisher = Fail<Int, CustomError>(error: .someError)

publisher
    .mapError { error in
        return "An error occurred: \(error)" // Map the error to a user-friendly message
    }
    .sink(
        receiveCompletion: { completion in
            switch completion {
            case .finished:
                print("Finished") // This won't be called in this case
            case .failure(let error):
                print(error) // Output: An error occurred: someError
            }
        },
        receiveValue: { value in
            // This won't be called in this case
        }
    )
    .store(in: &cancellables)

Integration with SwiftUI and UIKit:

Combine Swift seamlessly integrates with both SwiftUI and UIKit, providing developers with powerful tools to build reactive and interactive user interfaces. Let’s explore how Combine enhances the development experience in both frameworks:

Integration with SwiftUI:

Declarative UI Programming: SwiftUI’s declarative approach to UI programming aligns perfectly with Combine’s reactive paradigm. Developers can use Combine to handle asynchronous operations, data updates, and state management seamlessly within SwiftUI views.

Data Binding: Combine enables bidirectional data binding in SwiftUI, allowing changes in data to automatically update the UI and vice versa. Publishers can emit values, and SwiftUI views can react to these changes instantly, ensuring a responsive and dynamic user experience.

Event Handling: SwiftUI events, such as user interactions or lifecycle events, can be captured and processed using Combine publishers. This enables developers to handle user input, network requests, and other asynchronous tasks directly within SwiftUI views.

import SwiftUI
import Combine

class ViewModel: ObservableObject {
    @Published var count = 0
    
    func increment() {
        count += 1
    }
}

struct ContentView: View {
    @ObservedObject var viewModel: ViewModel
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment") {
                viewModel.increment()
            }
        }
    }
}

struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView(viewModel: ViewModel())
    }
}

Integration with UIKit:

Combine and UIKit Interoperability: While UIKit follows an imperative programming model, developers can still leverage Combine to introduce reactive features into UIKit-based applications. Combine publishers can be integrated seamlessly with UIKit components like UIViews, UIViewControllers, and UIKit-based libraries.

Asynchronous Operations: Combine simplifies asynchronous operations in UIKit applications by providing a unified API for handling asynchronous tasks, such as network requests, user input processing, and data updates.

State Management: Combine facilitates state management in UIKit applications, enabling developers to propagate state changes across different parts of the application efficiently. This ensures consistency and coherence in the user interface, even in complex UIKit-based architectures.

import UIKit
import Combine

class ViewModel {
    @Published var isLoading = false
    private var cancellables = Set<AnyCancellable>()
    
    func fetchData() {
        isLoading = true
        
        URLSession.shared.dataTaskPublisher(for: URL(string: "https://api.example.com/data")!)
            .map { $0.data }
            .decode(type: MyData.self, decoder: JSONDecoder())
            .receive(on: DispatchQueue.main)
            .sink(receiveCompletion: { _ in
                self.isLoading = false
            }, receiveValue: { data in
                // Handle received data
            })
            .store(in: &cancellables)
    }
}

Testing Strategies for Combine Code:

As an interviewee preparing for Combine Swift interview questions, it’s essential to demonstrate a thorough understanding of testing strategies for Combine code. Let’s delve deeper into the unit testing aspect:

Unit Testing Combine Code:

• Purpose: Unit tests play a critical role in ensuring the correctness, reliability, and maintainability of Combine code. They validate the behavior of individual components or units of code in isolation, helping detect and prevent regressions.
• Setup: Begin by setting up XCTest cases dedicated to testing Combine code. Import the necessary modules (import Combine) and create test cases for each component or functionality you want to verify.
• Testing Publishers: Write tests to verify the behavior of publishers, including their ability to emit values, complete successfully, or fail with errors. Utilize XCTestExpectation or XCTestExpectation.waitForExpectations(timeout:) for testing asynchronous publishers.
• Testing Subscribers: Test subscribers to ensure they receive and handle events emitted by publishers correctly. Validate that subscribers react appropriately to value emissions, completion events, and errors.
• Testing Combine Pipelines: Verify the behavior of Combine pipelines by chaining operators and comparing the resulting output against expected values. Employ XCTest assertions to check the output of the pipeline.
• Handling Asynchronous Operations: Given that Combine deals with asynchronous operations, ensure that your unit tests handle asynchronous behavior effectively. Leverage XCTestExpectation or XCTestExpectation.waitForExpectations(timeout:) to wait for asynchronous tasks to complete.
• Error Handling: Write tests to validate error handling mechanisms within Combine pipelines. Test scenarios where publishers emit errors, and verify that subscribers handle errors appropriately using error handling operators such as mapError, catch, or replaceError.

import XCTest
import Combine

class CombineUnitTests: XCTestCase {
    var cancellables = Set<AnyCancellable>()

    func testCombinePipeline() {
        // Given
        let inputPublisher = Just(5)
        let expectedOutput = 10
        
        // When
        let outputPublisher = inputPublisher
            .map { $0 * 2 }
        
        // Then
        let expectation = XCTestExpectation(description: "Pipeline Output Matches Expected Value")
        
        outputPublisher
            .sink { value in
                XCTAssertEqual(value, expectedOutput)
                expectation.fulfill()
            }
            .store(in: &cancellables)
        
        wait(for: [expectation], timeout: 1)
    }
    
    // Additional tests for error handling, asynchronous operations, etc.
}

Debugging Techniques for Combine Code in Tests:

• Logging and Print Statements: Use print statements or logging frameworks to log intermediate values or events within Combine pipelines during test execution, aiding in tracing and debugging.
• Breakpoints: Set breakpoints in XCTest cases to pause execution and inspect the state of Combine components (publishers, subscribers, etc.) at various points in the test, facilitating debugging.
• Visualization Tools: Utilize Xcode’s Debug View Hierarchy and Debug Memory Graph to visualize Combine pipelines and identify potential issues with memory management or subscription lifecycles during test debugging.

Debugging Techniques for Combine Code:

Understanding debugging techniques is essential for troubleshooting issues and ensuring the reliability of Combine code. Let’s explore debugging strategies with examples:

Print statements provide valuable insights into the execution flow and intermediate values within Combine pipelines.

import Combine

let numbers = [1, 2, 3, 4, 5]
let publisher = numbers.publisher

publisher
    .map { $0 * 2 } // Double each number
    .sink { value in
        print(value) // Output: 2, 4, 6, 8, 10
    }
    .store(in: &cancellables)

Breakpoints:

• Usage: Set breakpoints in XCTest cases or within your code to pause execution and inspect the state of Combine components at various stages.
• Example: Place breakpoints at critical points in your Combine pipeline to analyse the values emitted by publishers, operators, or subscribers.

Visualisation Tools:

• Usage: Utilise Xcode’s Debug View Hierarchy and Debug Memory Graph to visualise Combine pipelines and identify potential issues with memory management or subscription lifecycles.
• Example: Use the Debug Memory Graph to inspect the lifecycle of Combine components, ensuring proper memory management and subscription handling.

import Combine

let numbers = [1, 2, 3, 4, 5]
let publisher = numbers.publisher

publisher
    .map { $0 * 2 } // Double each number
    .filter { $0.isMultiple(of: 3) } // Filter multiples of 3
    .sink { value in
        print(value) // Output: 6
    }
    .store(in: &cancellables)

In this example, we’re debugging a Combine pipeline that doubles each number in the array and filters out multiples of 3. By adding print statements or breakpoints, we can inspect the intermediate values at each stage of the pipeline and ensure the expected output.

Real-world Application and Project-based Questions:

• Scenario-based Challenges: Interviewers often present real-world scenarios and ask candidates to design Combine-based solutions, assessing their problem-solving skills and understanding of Combine framework.
• Project Integration Tasks: Integrating Combine into existing projects or enhancing functionalities using Combine principles may be part of the interview process, evaluating candidates’ practical application of Combine concepts.

Scenario-based Challenge:

• Scenario: Imagine you’re developing a weather application that fetches weather data from a remote API. The application needs to display real-time weather updates and provide the user with the option to refresh the data manually.
• Question: How would you implement the data fetching and refreshing functionality using Combine Swift? Consider error handling, asynchronous operations, and UI updates.

import Combine

class WeatherViewModel: ObservableObject {
    @Published var weather: Weather?
    @Published var isLoading = false
    private var cancellables = Set<AnyCancellable>()
    
    func fetchData() {
        isLoading = true
        
        URLSession.shared.dataTaskPublisher(for: URL(string: "https://api.example.com/weather")!)
            .map { $0.data }
            .decode(type: Weather.self, decoder: JSONDecoder())
            .receive(on: DispatchQueue.main)
            .sink(receiveCompletion: { _ in
                self.isLoading = false
            }, receiveValue: { weather in
                self.weather = weather
            })
            .store(in: &cancellables)
    }
}

Project Integration Tasks:

• Scenario: You’re tasked with integrating Combine Swift into an existing project that relies heavily on asynchronous operations, such as network requests, database queries, and user input processing. The project also involves updating the UI based on real-time data changes.
• Question: How would you integrate Combine into the existing project architecture to improve code maintainability, responsiveness, and scalability? Provide examples of how Combine can be used to handle asynchronous tasks and update the UI dynamically.

import Combine

class ViewModel {
    @Published var isLoading = false
    private var cancellables = Set<AnyCancellable>()
    
    func fetchData() {
        isLoading = true
        
        URLSession.shared.dataTaskPublisher(for: URL(string: "https://api.example.com/data")!)
            .map { $0.data }
            .decode(type: MyData.self, decoder: JSONDecoder())
            .receive(on: DispatchQueue.main)
            .sink(receiveCompletion: { _ in
                self.isLoading = false
            }, receiveValue: { data in
                // Handle received data
            })
            .store(in: &cancellables)
    }
}

There is a part two of this article, where we will be covering question related to operators in combine.

https://medium.com/@arunk.pattanayak/part-2-conquering-combine-swift-interviews-a-developers-guide-a1795682b73c

Understanding Dependency Injection:

Before diving into Resolver, let’s briefly review dependency injection. Dependency injection is a design pattern where objects receive their dependencies from external sources rather than creating them internally. This allows for better separation of concerns and facilitates easier testing and maintenance.

What is Resolver?

Resolver is a lightweight dependency injection framework for Swift. It simplifies the management of dependencies by providing a convenient way to register, resolve, and manage dependencies throughout your codebase. With Resolver, you can easily inject dependencies into your classes, structs, and SwiftUI views.

How Resolver Works Behind the Scenes:

At its core, Resolver operates on a simple principle: registration and resolution. Here’s how Resolver works behind the scenes:

Registration:

In Resolver, you register your dependencies using the Resolver.register method. Dependencies can be registered as concrete types or protocols.

Resolver.register { MyServiceImplementation() as MyService }

Resolution:

Once dependencies are registered, you can resolve them wherever they are needed in your code. Resolver provides various methods for resolving dependencies, including property injection, constructor injection, and manual resolution.

class MyViewModel: ObservableObject {
    @Injected var myService: MyService
}

Automatic Injection:

Resolver supports automatic injection, where dependencies are automatically injected into properties marked with @Injected. This reduces boilerplate code and simplifies the dependency injection process.

class MyViewModel: ObservableObject {
    @Injected var myService: MyService
}

Scopes:

Resolver allows you to define scopes for dependencies, such as singleton, graph, and shared. Scopes determine how instances of dependencies are created and managed, providing flexibility and control over the lifecycle of objects.

Resolver.register { MyServiceImplementation() as MyService }
        .scope(.singleton)

Pros of Using Resolver:

Resolver offers several advantages for managing dependencies in Swift applications, making it a valuable tool for developers. Let’s explore some of the key benefits:

Promotes Modularity and Separation of Concerns:

Resolver encourages the separation of concerns by decoupling components and their dependencies. By explicitly defining dependencies and injecting them into components, Resolver helps create modular, loosely-coupled code that is easier to understand, maintain, and extend. This modularity facilitates code reuse and promotes cleaner architecture design.

Improves Testability:

Dependency injection is a fundamental principle of test-driven development (TDD) and promotes writing testable code. Resolver makes it easy to replace real dependencies with mock objects or stubs during testing, allowing developers to isolate components and write comprehensive unit tests. By injecting dependencies explicitly, tests become more focused, predictable, and maintainable, leading to higher test coverage and more robust codebases.

Reduces Boilerplate Code:

Resolver simplifies the process of dependency injection by automatically resolving dependencies and injecting them into components. With property injection, constructors, and automatic injection, developers can reduce boilerplate code and focus on writing business logic. Resolver’s concise syntax and powerful features streamline the dependency injection process, resulting in cleaner, more readable code.

Facilitates Scalability and Flexibility:

As applications evolve and grow in complexity, managing dependencies becomes increasingly challenging. Resolver provides a flexible and scalable solution for managing dependencies, allowing developers to register and resolve dependencies dynamically at runtime. By supporting different scopes (e.g., singleton, graph, shared), Resolver offers fine-grained control over the lifecycle of objects, ensuring efficient resource management and optimal performance.

Encourages Best Practices:

Resolver encourages best practices such as protocol-oriented programming (POP) and inversion of control (IoC). By defining dependencies as protocols and registering implementations dynamically, Resolver promotes abstraction and decoupling, making code more flexible, reusable, and extensible. Additionally, Resolver’s support for automatic injection and scoping helps enforce good architectural patterns and coding standards, leading to cleaner, more maintainable codebases.

Community Support and Active Development:

Resolver is an open-source project with a growing community of developers contributing to its development and improvement. With regular updates, bug fixes, and new features, Resolver continues to evolve and adapt to the changing needs of the Swift ecosystem. The active community and extensive documentation provide valuable resources and support for developers using Resolver in their projects.

Dependency injection is a powerful technique for managing dependencies and improving the overall design and testability of your Swift applications. The Resolver framework provides a convenient and efficient way to implement dependency injection in Swift projects. By understanding how Resolver works behind the scenes and leveraging its features, you can write cleaner, more modular, and more testable code.

MediumArticles/Resolver.swift at main · ArunK001/MediumArticles

Resolver has been deprecated as of 2023 and now replaced with Factory 2.0.

The main reason for covering this is to start with DI concepts. In next post I’will cover Factory 2.0.

Reference:

Resolver GitHub Repository: https://github.com/hmlongco/Resolver

From Apple Docs:

This protocol provides a blueprint for a content configuration object, which encompasses default styling and content for a content view. The content configuration encapsulates all of the supported properties and behaviors for content view customization. You use the configuration to create the content view.

Sounds like we are already able to do all these without UIContentConfiguration, isn’t it?

To clarify let’s discuss, how UIContentConfiguration is going to help.

1. when you’re building a completely custom view hierarchy inside your cells, you can still use the system configurations to help. Because configurations are so lightweight, you can use them as a source of default values for things like fonts, colors, and margins that you copy over to your custom views, even if you never apply the configuration directly itself.
2. We can reuse the same content view between UITableView, UICollectionView, and UIStackView.
3. Supports diffable data sources and traditional data sources.
4. UICollectionView cell registration methods, forgoing classic APIs such as identifiers and UICollectionViewDatasource supports UIContentConfiguration (e.g: UICollectionViewCompositionalLayout.list(using: listConfiguration)).
5. For list types i.e. UITableView and UICollectionView we can use UIListContentConfiguration.
6. Managing different UI states like selected, and highlighted becomes easier with UIContentConfiguration.

Exploring UIContentConfiguration:

There are two parts to this

1. UIContentConfiguration: an object that produces a content view.
2. UIContentView: a view with a settable property that is a content configuration.

UIContentConfiguration and UIContentView both are protocols.

UIContentConfiguration has two methods:

func makeContentView() -> UIView & UIContentView()

func updated(for state: UIConfigurationState) -> Car

UIContentView has one variable:

var configuration: UIContentConfiguration

Let’s start implementing UIContentConfiguration:

I have taken the Car structure, which shows the name and color of the car. When use selects any vehicle, we want to change the states of the cell.

Let implement UIContentView:

We have taken a custom content view, which is a subclass of UIView, and implemented UIContentView.

This class depends on the Car class to get values and configurations. Whenever we send a new configuration this class updates its UI configuration based on new changes.

Now, coming to our view controller:

There isn’t much, we have created and configured UITableView, UITableViewDiffableDataSource, and NSDiffableDataSouceSnapshot.

This is what our custom cell looks like:

In our custom cell, we need to override the updateConfiguration(using:) method to start updating your UI whenever there is a new configuration added.

I hope this helps you to start updating your code with UIContentConfiguration.

References:

• The Developer's Guide to Cell Content Configuration in iOS 14 - BiTE Interactive
• Apple Developer Documentation

“Dependency Injection” Sounds fancy, Isn’t it?

When I heard about it, thought it was a tricky concept and could be challenging to learn. So, in this article, we will see if it’s challenging to learn.

There are three ways we can use dependency injection in swift:

1. Initialiser injection
2. Method injection
3. Property injection

Now that we know the types, I believe some people already have realized that they know these terms but without realizing it’s a form of “Injection”.

Before learning about dependency injection, let’s see what kind of problems it solves.

Let’s see this code:

What are we doing with the above code

• We have defined two modules BaseNetworkModule to handle network calls, and BaseImageDownloder to download images.
• MyViewController is using the base classes to use the above functionality.

Now, let’s say we need to replace BaseNetworkModule and BaseImageDownloder with something else.

• Now that our code is tightly coupled with these modules it will be difficult to make modifications if needed.
• If we need to test MyViewController with mock modules, we will not be able to do so.

Now that we know the problems, let’s explore how Dependency Injection will help us solve these concerns.

1. Initialiser Injection

In the above code instead of initializing the networkModule and imageDownloder module within the class, we are assigning those variables using its init(networkModule: imageDownloder:) method.

By doing so we are not dependent on MyViewContoller to initialize them and this gives us more control over what object to pass.

Let’s consider this unit test case

We have easily replaced our networkModule and imageDownloder with mock models.

Now it’s more flexible to change dependent objects as per requirement. In the above code snippet, we have replaced ImageDowloader with LocalImageLoader class.

If we are using an initializer to inject dependencies that are called Initialiser Dependency Injection.

2. Method Injection

This is similar to using Initialiser Dependency Injection, but instead of using an initializer, we will have methods to inject dependencies.

Let’s how does it look like in code.

You can see, that we have a new method where we have two parameters networkModule and imageDownloder, and we are assigning these values to our dependencies.

This may come in handy when we are using storyboard or xib files.

The problem with this type of dependency injection is, that it’s easy to forget to implement those methods and if we are not mindful, we can change dependency unknowingly.

3. Property Injection

Dependencies can also be implemented using internal or public properties.

This gives us the flexibility of modifying dependencies as required, but this is vulnerable to unintended modification.

So, now the big question “What’s dependency injection?”

This is injecting dependencies into an object instead of the object creating its dependencies.

Now I hope Dependency Injection doesn’t sound so complicated anymore.

There is a third-party powerful light-weight dependency injection library:

GitHub - hmlongco/Resolver: Swift Ultralight Dependency Injection / Service Locator framework

As next part of this dependency injection section, I’ll be covering the above library. If you want to learn the above library, bookmark this section for an update.

Candidates are asked to answer these question to check their knowledge in application states and if needed how they can utilise this knowledge.

What are the iOS application states?
There are 5 application states in iOS application.

· Not-Running: The application is not running.

· Inactive: The application is in foreground but not receiving events.

· Active: The application is in foreground and receiving events.

· Background: The application is running on background and executing codes.

· Suspended: The application is in background and not executing codes. Usually, it happens after 5 seconds application stays in background state, but this can be extended.

What is Not-Running state?

When application is not launched or system terminates/purges/shuts it down, is called Not-Running state.

What are Inactive and Active state?

Inactive: The app is running in the foreground but is currently not receiving events. (It may be executing other code though.) An app usually stays in this state only briefly as it transitions to a different state. Application can go to inactive state upon receiving calls/sms. This can also happen while moving to different state. During this state we can not interact with UI. This is represented with UIApplication.State.inactive.

Active: This is the normal state of the application where application stays in foreground and receives events. We can only go to this state from Inactive State. This is represented with UIApplication.State.active.

What is an Event?

Most events sent to an iOS application are encapsulated in an event object — an instance of the UIEvent class. Events in iOS represent fingers touching (UITouch) views of an application or the user shaking the device. Distributing and handling events is the job of responder objects, which are instances of the UIResponder class. The UIApplication, UIViewController, UIWindow, and UIView classes (and your own RTAppDelegate) all inherit from UIResponder.(Apple Doc)

Explain state transitions?

Application can transition in following ways.
Not-running -> Inactive -> Active -> Inactive -> Background -> Inactive -> Active

How can you send application to Background state?

Application can be send to background state by
1. Clicking screen lock button
2. Entering into multi tasking screen
3. Tapping on home button/ by swiping up.
4. System presents alert (e.g: low battery alert)

How do you check application states?

Explain suspended state?

Application enters in this state from Background State (Inactive gets invoked in between) by OS. During this state application stays in memory but does not execute any code. As the application does not do anything during this state, battery life does not get impacted. Application will not get notified while entering to suspended state.

If any application needs memory and system is low on memory, OS may decide to terminate the application from suspended state.

How long does application stays in Background state before getting suspended?

Usually application stays in background mode for about 5 seconds in general cases before going to suspended state, but we can request OS to extend time if required using capabilities.
There are processes which can run for infinite time in background.
- Apps that play audible content to the user while in the background, such as a music player app.
-Apps that keep users informed of their location at all times, such as a navigation app.

Also there are applications which come to background mode as required.
- Apps that support Voice over Internet Protocol (VoIP).
- Newsstand apps that need to download and process new content
- Apps that receive regular updates from external accessories

How to know if application entered foreground or background state?

Using notification we can know when application enters foreground or background modes.

How do you request additional background time?

Using beginBackgroundTaskWithExpirationHandler, we can request additional time for background task.
Call this method when leaving a task unfinished might be detrimental to your app’s user experience. For example, call this method before writing data to a file to prevent the system from suspending your app while the operation is in progress.
Each call to this method must be balanced by a matching call to the endBackgroundTask: method. You can find remaining time by using backgroundTimeRemaining. If you don't call endBackgroundTask: for each task before time expires, the system kills the app.

AppDelegate function that are related to application states?

optional func applicationDidBecomeActive(_ application: UIApplication)

optional func applicationWillResignActive(_ application: UIApplication)

optional func applicationWillEnterForeground(_ application: UIApplication)

optional func applicationDidEnterBackground(_ application: UIApplication)

optional func applicationWillTerminate(_ application: UIApplication)

What happens during launch of an application?

User Taps on the icon -> main() -> @main -> Load main UI file -> Initialisation (willFinishLaunchingWithOptions)-> Restore UI state -> Finish Initialisation (didFinishLaunchingWithOptions) -> Running

What happens during background state?

Did enter Background -> Can run in background?

Yes -> handle events (execute code) -> Sleep/Suspend

No -> Suspend -> If there is a memory warning -> Terminate

How to enable background mode and implement it?

Go to project settings.

Click on signing and capabilities -> +Capabilities -> Background Modes

Now you can see the available background modes. Check the ones you require.

Go to info.plist file and add Permitted background task scheduler identifiers and add your identifiers.

Import BackgroundTask to your class and you can use BGTaskScheduler to register you background operation.

How to make API calls in backgound?

In order to implement background fetch, there are three things you must do:

• Check the box Background fetch in the Background Modes of your app’s Capabilities.
• Use setMinimumBackgroundFetchInterval(_:) to set a time interval appropriate for your app.
• Implement application(_:performFetchWithCompletionHandler:) in your app delegate to handle the background fetch.

What are the differences in iOS 13 with application life cycle?

In iOS 13 application life cycle handle differently with UIWindowSceneDelegate.

- (void)sceneDidBecomeActive:(UIScene *)scene {
}
- (void)sceneWillResignActive:(UIScene *)scene {
}

We can use these method to handle Inactive and Active states.

We can control this behaviour by Application Scene Manifest in application’s info.plist file.

References:
https://www.dummies.com/web-design-development/mobile-apps/handling-events-while-your-ios-application-is-executing/

https://developer.apple.com/library/archive/documentation/General/Conceptual/Devpedia-CocoaApp/EventHandlingiPhone.html

https://hackernoon.com/application-life-cycle-in-ios-12b6ba6af78b

https://www.iosiqa.com/2019/05/application-states.html

https://medium.com/@chinthaka01/the-execution-states-of-an-ios-application-84e117132e27

https://www.raywenderlich.com/5817-background-modes-tutorial-getting-started