iOS development in India is a niche with disproportionate rewards: fewer iOS engineers, fewer iOS jobs, but some of the best-designed consumer apps in India (CRED, Swiggy, Zerodha) are iOS-first products. This guide covers Swift and iOS interview questions for Indian product companies in 2026.
Swift language fundamentals
Swift interview questions:
1. Value types vs reference types: Value types (structs, enums, tuples): copied on assignment; each copy is independent. Reference types (classes): shared reference; multiple variables can point to the same object. Swift's fundamental design: prefer value types (structs) for data models; use classes when you need inheritance, reference semantics, or deinitialisation. Most of Swift's standard library (Array, Dictionary, String) is implemented as structs.
2. Optionals: An Optional<T> is a type that can hold either a value of type T or nil. Two ways to unwrap: if let: safe conditional unwrapping; guard let: early exit; ! force unwrap (avoid: crashes if the value is nil). Optional chaining: user?.profile?.address?.city returns nil if any step is nil instead of crashing.
3. Memory management and ARC: Swift uses Automatic Reference Counting (ARC) to manage memory for class instances. Every strong reference increments the retain count; the object is deallocated when the count reaches 0. Retain cycle: two objects hold strong references to each other; neither is deallocated. Fix with [weak self] (the reference becomes nil when the object is deallocated) or [unowned self] (the reference is never nil; crashes if the object was deallocated). Common retain cycle: a class holds a closure as a property, and the closure captures self strongly.
4. Swift concurrency (async/await and actors): Swift 5.5 introduced native async/await concurrency. async functions can suspend without blocking a thread. await suspends the calling function until the async function completes. Task: creates a concurrent task that runs asynchronously. TaskGroup: fan-out and collect results from multiple concurrent tasks. Actors: a new Swift concurrency primitive that protects mutable state from concurrent access: all accesses to an actor's properties are serialised on the actor's thread. MainActor: ensures code runs on the main thread (for UI updates).
UIKit vs SwiftUI and iOS app lifecycle
UIKit and SwiftUI interview questions:
1. UIKit (imperative UI): UIKit is the original iOS UI framework. UI is described imperatively (step-by-step instructions to the framework: create a button, set its title, add a target-action, add it to the view hierarchy). Key classes: UIViewController (manages a screen), UIView (the base class for all visible UI elements), UITableView (vertical scrolling list; replaced by UICollectionView for more complex layouts). Auto Layout: constraint-based layout system that adapts to different screen sizes. viewDidLoad: called after the view is loaded into memory; set up initial state and add views.
2. SwiftUI (declarative UI): SwiftUI (iOS 13+) is Apple's modern declarative UI framework. UI is described as a function of state: when state changes, SwiftUI automatically recomputes the UI. Key property wrappers: @State (local mutable state in a View struct), @Binding (two-way binding to a parent's state), @ObservedObject (observe a reference type that publishes changes via @Published), @StateObject (own and observe an ObservableObject; created once per view), @EnvironmentObject (shared state injected via the environment hierarchy).
3. SwiftUI vs UIKit: when to use each: SwiftUI: new projects targeting iOS 16+; simpler interfaces; teams new to iOS (lower barrier to entry). UIKit: complex, highly custom UI (e.g., a fully custom camera interface); existing UIKit codebases; features with no SwiftUI equivalent. Most real iOS projects in India use both: SwiftUI for new screens, UIKit for complex or legacy screens, and UIViewRepresentable / UIViewControllerRepresentable to bridge UIKit components into SwiftUI.
4. App lifecycle: SceneDelegate (iOS 13+): manages the lifecycle of a single scene (window). AppDelegate: manages app-level events (push notification registration, URL handling). SwiftUI App struct (@main): the entry point for SwiftUI-first apps; replaces AppDelegate and SceneDelegate for most tasks.
iOS architecture patterns: MVVM and Clean Architecture
iOS architecture interview questions:
1. MVC (Model-View-Controller) and its problems: MVC is UIKit's default pattern. In practice, the ViewController becomes a 'Massive View Controller' that handles networking, business logic, database access, and UI updates. This makes ViewControllers hard to test and hard to maintain as they grow.
2. MVVM (Model-View-ViewModel): The ViewModel handles business logic and data transformation; the View (ViewController or SwiftUI View) only handles presentation; the ViewModel exposes state as observable properties. With SwiftUI: @Published properties in an ObservableObject ViewModel; the SwiftUI View observes with @StateObject or @ObservedObject. With UIKit: Combine publishers or Delegates/Closures for ViewModel-to-View communication. Benefit: ViewControllers become thin; ViewModels are testable (no UIKit dependencies).
3. Clean Architecture / Clean Swift (VIP): Added by Robert C. Martin ('Uncle Bob'). In iOS Clean Architecture: Interactors (business logic), Presenters (formatting data for display), ViewControllers (display only), Repositories (data access abstraction), Use Cases (single business operation). Benefits: each layer has a single responsibility; testable in isolation. Used at companies that build large, long-lived iOS apps (CRED, Swiggy, Zomato likely use some variant for their complex features).
4. Coordinator pattern: Coordinators manage navigation flow between screens. The Coordinator is responsible for instantiating ViewControllers and pushing/presenting them; ViewControllers do not know about each other. Benefits: navigation logic is extracted from ViewControllers; easy to reroute the user flow (e.g., redirect to login before accessing a feature).
Practise iOS Swift interview questions with HireStepX's AI voice interviewer. Get scored feedback on your explanations of Swift memory management, SwiftUI, and iOS architecture patterns. First 2 sessions free.
Practice freeNetworking, persistence, and testing in iOS
iOS practical topics:
1. Networking: URLSession: the built-in iOS networking API. For REST APIs: URLSession.shared.data(from: url) with async/await. Codable: Swift protocol for automatic JSON encoding/decoding (structs and classes that conform to Codable work with JSONDecoder and JSONEncoder automatically). Popular networking libraries: Alamofire (adds convenience methods over URLSession; very popular in India); Moya (typed API abstraction layer built on Alamofire).
2. Core Data: Core Data is Apple's object-graph persistence framework (backed by SQLite). NSManagedObject (entities), NSManagedObjectContext (in-memory workspace), NSPersistentContainer (the stack). Fetch requests: NSFetchRequest to query entities. SwiftData (iOS 17+): Apple's modern replacement for Core Data using Swift macros; simpler API. For most apps: UserDefaults for small key-value data; Keychain for sensitive data (tokens, passwords); Core Data or SwiftData for complex relational data; SQLite directly (via GRDB or SQLite.swift) for apps that need full SQL control.
3. Push notifications: APNs (Apple Push Notification service) is the gateway for push notifications on iOS. Register for remote notifications in AppDelegate; receive the device token; send the token to your server; your server sends notifications via APNs. Firebase Cloud Messaging (FCM) is commonly used in India as a wrapper around APNs (and Google Play Services for Android): one API for both platforms.
4. Testing in iOS: XCTest: Apple's built-in unit and UI test framework. Unit tests: test Interactors, ViewModels, and Repositories in isolation (mock dependencies with protocols). UI tests: drive the app through XCUIApplication and assert on XCUIElement states. Performance tests: measure() block to benchmark code. Test target: separate from the app target; unit tests should not import UIKit.
Frequently asked questions
Explore more