• View Controllers
• Views and ViewModels
• Screens/Modules
• Background tasks and UI
• Across the app (via singletons, UserDefaults, etc.)

Swift offers multiple techniques, depending on context (UIKit, SwiftUI, architecture). Here’s a full breakdown:

1. Passing Data Between View Controllers (UIKit)

1.1 Forward Passing (Parent Child)

Example:

class ProfileViewController: UIViewController {
    var username: String?  // 🔹 Property to receive data
}

let profileVC = ProfileViewController()
profileVC.username = "shomil"  // Pass data before push
navigationController?.pushViewController(profileVC, animated: true)

1.2 Backward Passing (Child Parent)

Using Delegate Pattern:

protocol SettingsDelegate: AnyObject {
    func didUpdateTheme(to darkMode: Bool)
}

class SettingsViewController: UIViewController {
    weak var delegate: SettingsDelegate?

    func toggleTheme() {
        delegate?.didUpdateTheme(to: true)
    }
}

1.3 Using Closures (Callback)

class DetailViewController: UIViewController {
    var onDataUpdate: ((String) -> Void)?

    func saveChanges() {
        onDataUpdate?("Updated Data")
    }
}

2. Using Segues (Storyboard)

In prepare(for:sender:), set data before navigation:

override func prepare(for segue: UIStoryboardSegue, sender: Any?) {
    if let destination = segue.destination as? DetailVC {
        destination.data = "Some text"
    }
}

3. Using ViewModel (MVVM)

In MVVM, data flows from Model ➡ ViewModel ➡ View
class UserViewModel {
    let name: String

    init(user: User) {
        self.name = user.firstName + " " + user.lastName
    }
}

struct UserView: View {
    let viewModel: UserViewModel
    var body: some View {
        Text(viewModel.name)
    }
}

4. Using Singleton (Global Access)

class AppData {
    static let shared = AppData()
    var isLoggedIn = false
}
Access from anywhere:
AppData.shared.isLoggedIn = true

5. Using NotificationCenter

Post and listen for broadcast messages (loose coupling):

NotificationCenter.default.post(name: .dataUpdated, object: "New Value")
NotificationCenter.default.addObserver(self, selector: #selector(updateUI), name: .dataUpdated, object: nil)

6. UserDefaults / Keychain (Persistent Transfer)

• UserDefaults: For small, non-sensitive data
• Keychain: For secure data like tokens, passwords

UserDefaults.standard.set("Shomil", forKey: "username")
let name = UserDefaults.standard.string(forKey: "username")

7. API/Network Transfer

For remote data transfer (JSON, REST APIs):

URLSession.shared.dataTask(with: url) { data, response, error in
    // Parse JSON, return model
}

8. Data Transfer in SwiftUI

Use @State, @Binding, @ObservedObject, @EnvironmentObject to pass and share data.

struct ChildView: View {
    @Binding var isOn: Bool
}
@ObservedObject var viewModel = ProfileViewModel()

Conclusion

Swift gives you many ways to pass data, from simple property setting to advanced patterns like delegates and closures. Choosing the right method depends on direction, complexity, and architecture. To implement clean and efficient data flow, you can hire Swift developers who are experienced with both UIKit and SwiftUI patterns.

The post How to Pass Data From One VC to Another in Swift? appeared first on CMARIX QandA.

Basic Definitions of Classes and Structures in Swift

Structure (struct)

• Value type: copied when assigned or passed.
• Stored in the stack (usually, if small/simple).
• Preferred for small, lightweight models.

struct Person {
    var name: String
}

Class

• Reference type: passed by reference.
• Stored in the heap.
• Supports inheritance, deinitializers, and identity checks.

class Person {
    var name: String
}

Key Differences Between Struct vs Class in iOS

Value vs Reference Behavior

1. Struct (Value Type)

struct User {
    var name: String
}
var user1 = User(name: "Alice")
var user2 = user1
user2.name = "Bob"
print(user1.name) // "Alice"
print(user2.name) // "Bob"

Changing user2 doesn’t affect user1 because structs are copied.

2. Class (Reference Type)

class User {
    var name: String
    init(name: String) {
        self.name = name
    }
}

var user1 = User(name: "Alice")
var user2 = user1
user2.name = "Bob"

print(user1.name) // "Bob"
print(user2.name) // "Bob"

Both user1 and user2 point to the same object in memory.

Conclusion

Use structs when you need simple, independent copies of data. Use classes when you need shared references, inheritance, or lifecycle control. For best architecture decisions in your app, consider hiring an iOS developer who understands when to use each effectively.

The post Explain Classes vs Structures in Swift appeared first on CMARIX QandA.

It lets you run time-consuming tasks in the background (like API calls, file reading, or image processing) while keeping the UI smooth and responsive.

Why Use GCD?

• Prevents UI from freezing by offloading work to background threads.
• Makes your app more responsive.
• Helps you run tasks in parallel.
• Enables scheduling and delayed execution.

Main Concepts in Grand Central Dispatch

1. Dispatch Queues

A dispatch queue is an object that manages the execution of tasks serially or concurrently.

2. Sync vs Async

Common GCD Examples in Swift

1. Perform Background Task, Then Update UI

DispatchQueue.global(qos: .background).async {
    // Background task (e.g., download, compute)
    
    DispatchQueue.main.async {
        // Update UI on main thread
    }
}

2. Delay Execution

DispatchQueue.main.asyncAfter(deadline: .now() + 2.0) {
    print("Executed after 2 seconds")
}

3. Create a Custom Serial Queue

let serialQueue = DispatchQueue(label: "com.myapp.serial")
serialQueue.async {
    print("Task 1")
}
serialQueue.async {
    print("Task 2") // Runs after Task 1
}

4. Create a Concurrent Queue

let concurrentQueue = DispatchQueue(label: "com.myapp.concurrent", attributes: .concurrent)
concurrentQueue.async {
    print("Task A")
}
concurrentQueue.async {
    print("Task B") // Can run in parallel with Task A
}

Quality of Service (QoS)

Specifies the priority level of tasks:

When to Use GCD

• Network/API calls
• File I/O operations
• Image processing
• Timers, animations, progress bars
• Offloading heavy calculations

Conclusion

GCD helps keep background tasks running with most efficiency. This keeps the iOS app UI responsive and smooth. It simplifies concurrency and improves overall performance. To make the most of it, hire an iOS developer with strong GCD experience.

The post What is GCD (Grand Central Dispatch) in iOS? appeared first on CMARIX QandA.

Understanding iOS lifecycle helps you get better at:

• Loading data
• Updating UI
• Managing memory
• Debugging navigation issues

UIViewController Life Cycle Flow in iOS

Here’s the sequence of key methods in the UIViewController life cycle:

1. init(coder:) or init(nibName:bundle:)

• Called when a view controller is initialized.
• You rarely override this unless doing custom setup at creation.

2. loadView()

• Creates the view hierarchy programmatically.
• You usually don’t override this if using Storyboards/XIBs.

3. viewDidLoad()

This runs when the view is loaded into memory.

Use it to:

• Do setup that only needs to happen once
• Create and set up views
• Make early network calls or load basic data

override func viewDidLoad() {
    super.viewDidLoad()
    print("✅ viewDidLoad called")
}

4. viewWillAppear(_:)

Called just before the view shows up on screen.

Use it to:

• Refresh data or update the UI
• Start basic animations
• Show or hide parts of the UI as needed

5. viewDidAppear(_:)

Gets called after the view is fully on screen.

Best used for:

• Running tasks that require the view to be visible
• Logging screen views for analytics
• Starting animations or timers that shouldn’t run off-screen

6. viewWillDisappear(_:)

Called just before the view is removed (e.g., navigating away).

Ideal for:

• Saving state
• Stopping animations or video
• Dismissing keyboards

7. viewDidDisappear(_:)

Called after the view has been removed from the screen.

Ideal for:

• Releasing resources
• Stopping services (e.g., location, camera)

Additional Life Cycle Methods

Summary Table

Final Words

The ViewController life cycle lets you control what happens as a screen appears, updates, and disappears. It’s key for loading data, updating UI, and freeing up resources. When you hire iOS developers who know this flow well, your app runs smoother and stays more stable.

The post Explain ViewController Life Cycle in iOS appeared first on CMARIX QandA.

MVC – Model-View-Controller

Structure

• Model: Business logic and data (e.g., structs, API results, persistence).
• View: UI elements (Storyboard/XIB/SwiftUI/ViewController’s UI code).
• Controller: Connects the Model and View, handles user input, and updates UI.

Problem in iOS: “Massive View Controller”

In iOS, UIViewController often acts as both View and Controller, leading to bloated classes.

Example:

class UserModel {
    var name: String
}

class UserViewController: UIViewController {
    var model: UserModel!

    override func viewDidLoad() {
        super.viewDidLoad()
        nameLabel.text = model.name
    }
}

MVVM – Model-View-ViewModel

Structure

• Model: Same as MVC.
• View: UI layer (ViewController or SwiftUI View).
• ViewModel: Transforms model data for the view. Binds data and handles logic/UI state.

Key Concepts

• Data binding: UI updates automatically when ViewModel data changes (especially in SwiftUI or using Combine, RxSwift, or KVO).
• Improves testability by removing logic from the View.

Example:

// Model
struct User {
    let firstName: String
    let lastName: String
}

// ViewModel
class UserViewModel {
    private let user: User
    var fullName: String {
        "\(user.firstName) \(user.lastName)"
    }
    init(user: User) {
        self.user = user
    }
}

// View
class UserViewController: UIViewController {
    var viewModel: UserViewModel!

    override func viewDidLoad() {
        super.viewDidLoad()
        nameLabel.text = viewModel.fullName
    }
}

MVP – Model-View-Presenter

Structure

• Model: Business/data logic.
• View: Interface layer (UI elements + protocols).
• Presenter: Handles logic and updates the View via a protocol interface.

Communication:

• View Presenter via protocols.
• Presenter Model directly.
• View is kept dumb (no business logic).

Example:

// View Protocol
protocol UserView: AnyObject {
    func showName(_ name: String)
}

// Presenter
class UserPresenter {
    weak var view: UserView?
    var user: User

    init(view: UserView, user: User) {
        self.view = view
        self.user = user
    }

    func loadUser() {
        let fullName = "\(user.firstName) \(user.lastName)"
        view?.showName(fullName)
    }
}

// ViewController
class UserViewController: UIViewController, UserView {
    var presenter: UserPresenter!

    override func viewDidLoad() {
        super.viewDidLoad()
        presenter.loadUser()
    }

    func showName(_ name: String) {
        nameLabel.text = name
    }
}

Summary Comparison

Final Words

Choosing the right design pattern depends on your project’s needs and the tools you’re using. MVC is simple but often leads to bloated view controllers. MVVM works well with data binding in SwiftUI or Combine, making it great for modern iOS apps. MVP, on the other hand, keeps your views clean and logic-driven through protocols—ideal for UIKit-heavy apps. When you hire iOS developers who understand these patterns, you get code that’s easier to scale, test, and maintain over time.

The post Explain MVC, MVVM, and MVP Design Patterns in Swift appeared first on CMARIX QandA.

The SOLID Principles

Detailed Examples in Swift

Single Responsibility Principle (SRP)

Bad:

class UserManager {
    func saveUser() { /* save to DB */ }
    func sendEmail() { /* send welcome email */ }
}

Good (Separate responsibilities):

class UserStorage {
    func saveUser() { /* save to DB */ }
}

class EmailService {
    func sendWelcomeEmail() { /* send email */ }
}

Open/Closed Principle (OCP)

Bad:

class PaymentProcessor {
    func pay(type: String) {
        if type == "card" { /* pay with card */ }
        else if type == "wallet" { /* pay with wallet */ }
    }
}

Good (open for extension via protocol):

protocol PaymentMethod {
    func pay()
}

class CardPayment: PaymentMethod {
    func pay() { /* card logic */ }
}

class WalletPayment: PaymentMethod {
    func pay() { /* wallet logic */ }
}

class PaymentProcessor {
    func process(payment: PaymentMethod) {
        payment.pay()
    }
}

Liskov Substitution Principle (LSP)

You should be able to replace a subclass with its parent class without unexpected behavior.

class Bird {
    func fly() {}
}

class Penguin: Bird {
    override func fly() {
        // ❌ Penguins can't fly!
    }
}
Fix by separating behavior:
protocol Bird {}
protocol FlyingBird: Bird {
    func fly()
}

class Sparrow: FlyingBird {
    func fly() { /* can fly */ }
}

class Penguin: Bird {
    // no fly()
}

Interface Segregation Principle (ISP)

Avoid fat protocols.

Bad:

protocol Printer {
    func printDocument()
    func scanDocument()
    func faxDocument()
}

Good (split into smaller protocols):
protocol Printable {
    func printDocument()
}

protocol Scannable {
    func scanDocument()
}

Dependency Inversion Principle (DIP)

High-level modules rely on abstractions. They do not rely on concrete classes.

Bad:

class APIService {
    func fetchData() { }
}

class Dashboard {
    let api = APIService()
}

Good (inject dependency via protocol):
protocol DataService {
    func fetchData()
}

class APIService: DataService {
    func fetchData() { }
}

class Dashboard {
    let service: DataService
    init(service: DataService) {
        self.service = service
    }
}

Conclusion

Following SOLID principles helps you write iOS code that is easier to test, extend, and maintain. Each principle solves a common design problem and encourages clean architecture, especially in Swift projects using protocols and classes. When you hire iOS developers who apply these principles, your codebase stays organized and scalable as your app grows.

The post What Are SOLID Principles in iOS Development and Why Should You Use Them? appeared first on CMARIX QandA.

Error Handling Workflow

• Define an Error type (usually an enum conforming to the Error protocol)
• Use throw to raise an error
• Use try to call a throwing function
• Use do-catch to handle the error

Step-by-Step Breakdown of Error Handling in Swift with an Example

Define an Error Type

enum FileError: Error {
    case fileNotFound
    case unreadable
    case encodingFailed
}

Throw an Error in a Function

func readFile(name: String) throws -> String {
    guard name == "data.txt" else {
        throw FileError.fileNotFound
    }
    return "File content"
}

Handle the Error with do-try-catch

do {
    let content = try readFile(name: "wrong.txt")
    print(content)
} catch FileError.fileNotFound {
    print("⚠ File not found.")
} catch {
    print("⚠ An unknown error occurred: \(error)")
}

Choosing the Right try Approach in Swift

let result = try? readFile(name: "data.txt") // Optional("File content")
let force = try! readFile(name: "data.txt")  // Unsafe if error is thrown

Custom Error Messages

You can conform your error enum to LocalizedError or CustomStringConvertible to provide better messages:

extension FileError: LocalizedError {
    var errorDescription: String? {
        switch self {
        case .fileNotFound: return "The file could not be found."
        case .unreadable: return "The file is unreadable."
        case .encodingFailed: return "The file could not be encoded."
        }
    }
}

Conclusion

Error handling in Swift lets you manage issues like network errors or bad input without crashing the app. When you hire Swift developers who use do-try-catch well, your app becomes more stable and reliable.

The post How to Handle Errors in Swift? appeared first on CMARIX QandA.

Closure Syntax

{ (parameters) -> returnType in
    // code
}

Example of a Simple Closure

let greet = {
    print("Hello, Swift!")
}
greet()  // Output: Hello, Swift!

Closure with Parameters and Return Type

let add: (Int, Int) -> Int = { (a, b) in
    return a + b
}
let result = add(3, 5) // 8

Closure as Function Parameter (e.g., Completion Handler)

func performTask(completion: () -> Void) {
    print("Task started")
    completion()
    print("Task ended")
}

performTask {
    print("Task in progress...")
}

Trailing Closure Syntax

If the last parameter of a function is a closure, you can use trailing closure syntax:

performTask {
    print("Using trailing closure")
}

Capturing Values

Closures can capture and store variables from the surrounding scope:

func makeCounter() -> () -> Int {
    var count = 0
    return {
        count += 1
        return count
    }
}

let counter = makeCounter()
print(counter()) // 1
print(counter()) // 2

Memory Management with Closures (Capture Lists)

Closures capture strongly by default, which can lead to retain cycles especially in classes.

Retain Cycle Example

class MyClass {
    var name = "Swift"
    var closure: (() -> Void)?

    func setup() {
        closure = {
            print(self.name)
        }
    }
}
Fix with [weak self] or [unowned self]
closure = { [weak self] in
    print(self?.name ?? "nil")
}

Shorthand Argument Names

Swift allows you to omit parameter names and use $0, $1, etc.

let numbers = [1, 2, 3]
let doubled = numbers.map { $0 * 2 } // [2, 4, 6]

Conclusion

Closures make Swift code more flexible by allowing you to pass around blocks of logic and capture values from context. When you hire iOS developers who understand how closures work, including memory management and capture lists, your app becomes cleaner, faster, and easier to maintain.

The post What are Closures in Swift? appeared first on CMARIX QandA.

ARC keeps a count of how many strong references a class instance has. When the count drops to zero (i.e., no part of your code is holding a strong reference to it), the instance is automatically deallocated and its memory is freed.

Key Concepts of Memory Management in Swift

Strong Reference

• Default type of reference.
• Increases reference count.
• Prevents the object from being deallocated.

class Person {
    var name: String
    init(name: String) {
        self.name = name
        print("\(name) is initialized")
    }
  deinit {
        print("\(name) is deinitialized")
    }
}

var person1: Person? = Person(name: "John") // ref count = 1
person1 = nil // ref count = 0 → deinit called

Retain Cycle (Strong Reference Cycle)

Occurs when two class instances hold strong references to each other, preventing ARC from deallocating them.

class Person {
    var pet: Dog?
}

class Dog {
    var owner: Person?
}

Weak Reference

• Does not increase reference count.
• Used to break retain cycles.
• Must be declared as optional (?).
• Automatically set to nil if the referenced object is deallocated.

class Person {
    var name: String
    weak var pet: Dog? // weak to prevent retain cycle
    ...
}

Unowned Reference

• Like weak, but never becomes nil.
• Used when one object always expects the other to exist during its lifetime.

class CreditCard {
    unowned let owner: Customer
    ...
}

Conclusion

Swift uses ARC to manage memory, but you need to understand how strong, weak, and unowned references work to avoid issues. When you hire Swift developers who know these concepts well, your app is more likely to run smoothly without memory leaks or crashes.

The post What is Memory Management in Swift? appeared first on CMARIX QandA.

iOS App Life Cycle States

Key Life Cycle Methods (UIKit – AppDelegate)

In apps using UIKit (iOS 12 and earlier, or without SwiftUI), lifecycle methods are in AppDelegate.swift.

1. didFinishLaunchingWithOptions

func application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: ...) -> Bool

Called when the app is launched. Use it for setup (API keys, analytics, etc.).

2. applicationDidBecomeActive

func applicationDidBecomeActive(_ application: UIApplication)

Called when the app becomes active (e.g., after launch or returning from background).

3. applicationWillResignActive

func applicationWillResignActive(_ application: UIApplication)

Called when the app is about to move from active to inactive state (e.g., call, home button).

4. applicationDidEnterBackground

func applicationDidEnterBackground(_ application: UIApplication)

Called when the app goes to background. Save user data here.

func applicationWillEnterForeground(_ application: UIApplication)

Called as the app is moving from background to active state.

func applicationWillTerminate(_ application: UIApplication)

Called when the app is about to be killed. Save data if needed.

SwiftUI App Life Cycle (iOS 14+)

In SwiftUI, AppDelegate is optional. You use the @main struct and modifiers like:

@main
struct MyApp: App {
    var body: some Scene {
        WindowGroup {
            ContentView()
        }
        .onAppear {
            print("App appeared")
        }
        .onChange(of: scenePhase) { newPhase in
            switch newPhase {
            case .active: print("App is active")
            case .inactive: print("App is inactive")
            case .background: print("App is in background")
            default: break
            }
        }
    }

    @Environment(\.scenePhase) private var scenePhase
}

Conclusion

Understanding the iOS application life cycle is key to building stable and responsive apps. Whether you’re using UIKit with AppDelegate or SwiftUI with scenePhase, handling each state correctly ensures smooth transitions, proper resource management, and a better user experience. When you hire Swift developers with proper understanding of the app life cycle, you reduce crashes, improve performance, and build apps that behave well in real-world scenarios.

The post Explain Application Life Cycle in iOS appeared first on CMARIX QandA.