iOS Developer Interview Questions and Answers

iOS interviews test whether you can build production apps on Apple platforms—not syntax trivia alone.

Common formats:

• Phone screen → take-home or live coding → system design (senior) → behavioral
• Apple loops: deep Swift, frameworks, craftsmanship, collaboration
• Google iOS loops: algorithms + mobile depth + cross-platform empathy (compare with their stack when asked)

A strong candidate explains trade-offs (UIKit vs SwiftUI, Core Data vs SwiftData) with project context.

Both hire engineers to ship App Store products; emphasis varies:

Same prep core: Swift, ARC, concurrency, networking, architecture, testing.

Differentiate answers with product scale (1M DAU vs internal tool) and release cadence you have shipped.

Do not assume one company’s folklore—read the team (consumer app vs enterprise SDK).

Take-home tasks: build a small app (network + list + detail) with README and tests.

Practice explaining answers aloud; interviewers follow up on spoken reasoning more than memorized flashcards.

Pair mobile prep with senior Android interviews for cross-platform system design vocabulary.

Swift has both value types and reference types.

Prefer structs when the data represents a value:

• API response models
• Form data
• App state snapshots
• Coordinates, sizes, dates, money-like values
• SwiftUI View types

Use classes when you need identity or shared mutable state:

• UIViewController
• Delegate objects
• Shared cache/session managers
• Objects that need inheritance
• Objects with lifecycle/deinitialization behavior

Example:

struct UserProfile {
    var name: String
}

final class ImageCache {
    private var storage: [URL: UIImage] = [:]
}

Interview follow-up: Swift collections like Array, String, and Dictionary are value types but use copy-on-write internally, so copying is usually efficient until one copy is mutated.

Important nuance: a struct can contain a class reference. In that case, the struct value is copied, but the reference inside it may still point to shared mutable state.

A strong answer is:

“I use structs by default for data because value semantics reduce shared-state bugs. I use classes when I need identity, reference semantics, inheritance, Objective-C/UIKit interop, or a controlled lifecycle.”

Both if let and guard let safely unwrap optionals, but they communicate different intent.

// if let — use value only inside this branch
if let name = user?.name {
    print(name)
}

// guard let — required value; exit early if missing
func greet(_ user: User?) {
    guard let name = user?.name else { return }
    print("Hello, \(name)")
}

Example interview explanation:

func submit(user: User?) {
    guard let user else {
        showLogin()
        return
    }

    save(user)
}

Here, guard makes the happy path clear. After the guard statement, user is safely unwrapped for the rest of the function.

Avoid force unwraps in normal production paths:

// Risky
let name = user!.name

Force unwrap is acceptable only when nil is truly impossible and you can justify why, such as a storyboard outlet after view loading or a test setup where failure should crash loudly.

Implicitly unwrapped optionals like String! still appear in UIKit/Objective-C interop, but they should not be used casually.

A strong answer is:

“I use guard let when the value is required and I want to exit early. I use if let when the optional value only matters for one conditional branch. I avoid force unwrap unless nil is impossible by design.”

Swift enums with associated values let each case carry different data.

They are useful for modeling state, events, and results safely.

enum LoadState<T> {
    case idle
    case loading
    case loaded(T)
    case failed(Error)
}

This is better than multiple unrelated booleans:

var isLoading = false
var data: [User]?
var error: Error?

With separate flags, invalid states are possible:

• isLoading == true and data != nil
• error != nil and data != nil
• Not loading, no data, no error, but unclear state

With an enum, the state is explicit:

switch state {
case .idle:
    showEmpty()
case .loading:
    showSpinner()
case .loaded(let users):
    showUsers(users)
case .failed(let error):
    showError(error)
}

Common interview use cases:

• API loading state
• Login state
• Navigation flow
• Form submission state
• Deep link handling
• Network result modeling
• UI state machines

Swift checks switch exhaustiveness, so if you add a new enum case later, the compiler can force you to handle it.

A strong answer is:

“Enums with associated values help model state clearly. Instead of juggling booleans and optional values, I can represent each valid state directly and let the compiler enforce exhaustive handling.”

Protocol-oriented programming means designing around capabilities instead of deep inheritance trees.

A protocol defines what a type can do:

protocol FeedRepository {
    func fetchFeed() async throws -> [FeedItem]
}

Different types can conform:

struct RemoteFeedRepository: FeedRepository {
    func fetchFeed() async throws -> [FeedItem] {
        // call API
    }
}

struct MockFeedRepository: FeedRepository {
    func fetchFeed() async throws -> [FeedItem] {
        []
    }
}

Why it helps:

• Improves testability
• Supports dependency injection
• Avoids deep class inheritance
• Lets structs, classes, enums, and actors share behavior
• Makes code depend on abstraction, not concrete implementation

Protocol extensions can provide default behavior:

extension FeedRepository {
    func refresh() async throws -> [FeedItem] {
        try await fetchFeed()
    }
}

Interviewers often ask where protocols help in iOS apps:

• Mocking API clients in unit tests
• Abstracting persistence
• Swapping real services with fake services
• Building reusable view models
• Avoiding tightly coupled UIKit/SwiftUI code

Important nuance: protocol extensions are powerful, but they are not the same as overriding class methods. Dynamic dispatch behavior can differ depending on whether the method is a protocol requirement.

Also know modern Swift syntax:

• some Protocol means one hidden concrete type chosen by the function
• any Protocol means a boxed existential that can hold different conforming types

A strong answer is:

“Protocol-oriented programming means I define behavior with protocols and compose types around those capabilities. It helps with testability, dependency injection, and avoiding unnecessary inheritance.”

Generics let you write reusable code without losing type safety.

func first<T>(_ items: [T]) -> T? {
    items.first
}

Without generics, you may reach for Any, which loses compile-time type information:

func first(_ items: [Any]) -> Any? {
    items.first
}

Generics are used heavily in Swift and Apple APIs:

Generic constraints make code reusable but still safe:

func printIDs<T: Identifiable>(_ items: [T]) {
    for item in items {
        print(item.id)
    }
}

Interview follow-ups:

• Associated types in protocols
• Generic constraints with where
• some opaque return types
• any existential types
• Type erasure when concrete generic types become too complex

Example answer for some vs any:

A strong answer is:

“Generics let me write reusable code while preserving type information. I use them when the algorithm is the same but the data type changes, and I add constraints when the generic type must provide specific behavior.”

Codable is a type alias for Encodable and Decodable.

It lets Swift types convert to and from formats such as JSON or property lists.

struct UserDTO: Codable {
    let id: UUID
    let name: String
    let joinedAt: Date
}

Common JSON decoding:

let decoder = JSONDecoder()
decoder.dateDecodingStrategy = .iso8601

let user = try decoder.decode(UserDTO.self, from: data)

Common interview pitfalls:

Example key mapping:

struct UserDTO: Codable {
    let userID: Int
    let fullName: String

    enum CodingKeys: String, CodingKey {
        case userID = "user_id"
        case fullName = "full_name"
    }
}

A strong answer should not say “Codable always handles JSON automatically.” It handles simple cases well, but real APIs often need custom keys, date strategies, optional handling, and version-tolerant decoding.

For production apps, consider separating:

• DTO model — matches API response
• Domain model — matches app business logic
• View model — matches screen needs

A strong answer is:

“Codable gives type-safe encoding and decoding, but real APIs need careful handling of key names, dates, missing fields, and DTO-to-domain mapping. I do not let backend JSON shape leak everywhere into the app.”

The practical difference is how changes spread through the app.

A value type gives each variable its own independent value.

struct Settings {
    var theme: String
}

var a = Settings(theme: "Light")
var b = a
b.theme = "Dark"

print(a.theme) // Light
print(b.theme) // Dark

A reference type lets multiple variables point to the same instance.

final class SettingsStore {
    var theme = "Light"
}

let a = SettingsStore()
let b = a
b.theme = "Dark"

print(a.theme) // Dark
print(b.theme) // Dark

Why interviewers care:

• Value types reduce accidental shared mutation
• Reference types are useful for shared identity
• Classes are managed by ARC
• Reference cycles can cause memory leaks
• Value semantics make state easier to reason about
• Reference semantics are often needed for delegates, controllers, caches, and long-lived services

In SwiftUI, View types are structs because the view is a description of UI for a given state. Long-lived state usually belongs in a model object, observable type, actor, or service.

Modern SwiftUI note:

• Older apps often use ObservableObject with @Published
• Newer SwiftUI code may use the Observation framework with @Observable

Value vs reference also affects concurrency. Value types are often easier to pass safely, while shared mutable class instances need more care. Actors are reference types but protect their mutable state through actor isolation.

A strong answer is:

“Value types are best when I want predictable independent state. Reference types are best when identity, shared lifecycle, or shared mutable state matters. In iOS, I use value models for data and reference types for controllers, services, delegates, actors, and observable state owners.”

ARC means Automatic Reference Counting. Swift uses ARC to manage the memory of class instances.

When something holds a strong reference to a class instance, ARC keeps that instance alive. When the last strong reference goes away, ARC deallocates the instance and calls deinit.

final class UserSession {
    deinit {
        print("UserSession deallocated")
    }
}

var session: UserSession? = UserSession()
session = nil // deinit runs when no strong references remain

Important points:

• Strong references are the default
• ARC is deterministic, unlike garbage collection
• deinit runs when the last strong reference is released
• Structs and enums are value types, not ARC-managed class instances
• Reference cycles can prevent deinit from running
• weak and unowned references help break cycles

Common retain cycle:

final class Parent {
    var child: Child?
}

final class Child {
    var parent: Parent?
}

If both references are strong, neither object can be released.

Fix:

final class Child {
    weak var parent: Parent?
}

Interviewers do not only want the definition of ARC. They want to know whether you understand why memory leaks still happen in Swift.

ARC is automatic, but it is not magic. It cannot automatically solve strong reference cycles.

A strong answer is:

“ARC tracks strong references to class instances. When the last strong reference goes away, the object is deallocated. The main risk is a retain cycle, so I use weak or unowned where ownership should not be strong.”

Use weak and unowned to avoid strong reference cycles, but they have different safety rules.

Use weak when the referenced object may be deallocated first.

protocol LoginViewControllerDelegate: AnyObject {
    func loginDidFinish()
}

final class LoginViewController: UIViewController {
    weak var delegate: LoginViewControllerDelegate?
}

Use [weak self] in escaping closures when the closure may outlive the object.

network.fetchUser { [weak self] result in
    guard let self else { return }
    self.handle(result)
}

Use unowned only when the referenced object is guaranteed to live at least as long as the reference.

final class Customer {
    let card: CreditCard

    init(card: CreditCard) {
        self.card = card
    }
}

final class CreditCard {
    unowned let customer: Customer

    init(customer: Customer) {
        self.customer = customer
    }
}

In real app code, weak is usually the safer interview answer unless you can clearly prove the lifetime relationship.

Avoid this unless justified:

api.load { [unowned self] in
    self.updateUI()
}

If the view controller is dismissed before the API finishes, this can crash.

A strong answer is:

“I use weak when the reference can become nil, such as delegates and escaping closures. I use unowned only when the other object is guaranteed to outlive the reference. If I cannot prove that lifetime, I choose weak.”

A retain cycle happens when two or more objects keep each other alive through strong references.

Common sources:

• Closure captures self strongly
• Parent holds child and child holds parent
• Delegate is strong instead of weak
• Timer or CADisplayLink retains its target
• ViewModel owns a callback that captures ViewController
• Combine subscription captures self and is stored by self
• Long-running async task keeps an object alive unexpectedly

Example closure cycle:

final class ProfileViewModel {
    var onUpdate: (() -> Void)?

    func refresh() {
        onUpdate?()
    }
}

final class ProfileViewController: UIViewController {
    let viewModel = ProfileViewModel()

    override func viewDidLoad() {
        super.viewDidLoad()

        viewModel.onUpdate = {
            self.updateUI()
        }
    }
}

Here, the view controller owns the view model. The view model owns the closure. The closure owns self.

Fix:

viewModel.onUpdate = { [weak self] in
    self?.updateUI()
}

For delegates:

weak var delegate: SomeDelegate?

For timers:

• Invalidate the timer
• Use a weak target pattern
• Use closure-based APIs carefully with [weak self]

How to verify:

• Add deinit logs during debugging
• Use Xcode Memory Graph Debugger
• Use Instruments Leaks/Allocations
• Navigate away from the screen and confirm objects deallocate
• Check whether view controllers remain in memory after dismissal

Interview scenario answer:

“If a dismissed view controller is not deallocated, I would check closures, delegates, timers, and subscriptions. Then I would verify the fix with Memory Graph or Instruments, not just assume [weak self] solved it.”

A strong answer is:

“I find retain cycles by checking objects that should deallocate but do not. I usually inspect closures, delegates, timers, and subscriptions, then fix ownership with weak, cleanup, or cancellation, and verify using Xcode Memory Graph or Instruments.”

Copy-on-write is an optimization used by Swift value types such as Array, String, Dictionary, and Set.

The idea is simple:

1. Two values can share the same underlying storage
2. As long as nobody mutates, no real copy is needed
3. When one value mutates, Swift makes a separate copy if storage is shared

Example:

var a = [1, 2, 3]
var b = a        // storage can be shared

b.append(4)      // copy happens before mutation if needed

print(a)         // [1, 2, 3]
print(b)         // [1, 2, 3, 4]

Why it matters:

• Value semantics stay predictable
• Large values are not always copied immediately
• Performance stays good for many common cases
• Mutation can still trigger a real copy

Interviewers may ask this because candidates often say “structs are always copied.” That is conceptually true at the value level, but Swift can optimize storage internally.

Senior follow-up: custom COW types can use reference storage internally and check uniqueness before mutation.

isKnownUniquelyReferenced(&storage)

If storage is uniquely referenced, mutate it directly. If not, copy the storage first.

Common performance note:

• Passing arrays around is usually cheap
• Repeated mutation of shared storage can become expensive
• Large structs with reference-type properties need careful design
• Copy-on-write is an implementation optimization, not a reason to ignore data ownership

A strong answer is:

“Copy-on-write lets Swift value types share storage until mutation. It preserves value semantics while avoiding unnecessary copies, but mutation of shared storage can still trigger a real copy.”

iOS apps have historically used MVC, but many production teams use MVVM or related patterns to keep screens testable and maintainable.

In Apple-style MVC:

• Model holds data/business rules
• View displays UI
• ViewController coordinates the view and model

The problem is that UIViewController often becomes too large. It may handle:

• View lifecycle
• API calls
• Formatting
• Validation
• Navigation
• Error handling
• Analytics
• Table/collection delegates

This is why people joke that MVC becomes “Massive View Controller.”

MVVM helps by moving presentation logic into a ViewModel.

@Observable
final class ProfileViewModel {
    var name = ""
    var isLoading = false

    func load() async {
        // fetch and map data for the view
    }
}

SwiftUI works naturally with observable state. UIKit teams also use MVVM, often with closures, delegates, Combine, async/await, or coordinators.

Use MVVM for:

• Testable presentation logic
• Screens with loading/error/content states
• API-backed screens
• Complex form validation
• Shared UI state

But do not over-architect tiny screens. The pattern should reduce complexity, not add ceremony.

A strong answer is:

“MVC is common in UIKit, but ViewControllers can become too large. I use MVVM when moving presentation state and formatting into a testable ViewModel improves maintainability. For larger apps, I choose architecture based on team size, testing needs, and navigation complexity.”

The delegate pattern lets one object hand off responsibility to another object through a protocol.

It is common in UIKit and Apple frameworks.

Examples:

• UITableViewDelegate
• UICollectionViewDelegate
• URLSessionDelegate
• CLLocationManagerDelegate
• UITextFieldDelegate

Simple example:

protocol LoginViewControllerDelegate: AnyObject {
    func loginViewControllerDidFinish(_ controller: LoginViewController)
}

final class LoginViewController: UIViewController {
    weak var delegate: LoginViewControllerDelegate?

    func didTapDone() {
        delegate?.loginViewControllerDidFinish(self)
    }
}

Why weak?

The parent often owns the child view controller. If the child strongly owns its delegate, both can keep each other alive.

weak var delegate: LoginViewControllerDelegate?

Delegates are good for:

• One-to-one communication
• Parent-child screen callbacks
• Custom UI components
• Framework callbacks
• Situations where the receiver should be explicit and typed

Delegate limitations:

• Usually only one receiver
• Can become verbose
• Not ideal for broadcasting global app events
• Too many delegate methods can make APIs heavy

SwiftUI uses fewer UIKit delegates for UI, but delegate patterns still matter because many system frameworks and UIKit APIs use them heavily.

A strong answer is:

“A delegate is a typed one-to-one callback relationship defined by a protocol. I usually make delegates weak to avoid retain cycles, and I use them for parent-child UI communication or framework callbacks.”

Delegates and NotificationCenter are both communication patterns, but they solve different problems.

Use a delegate when one specific object should handle an event.

delegate?.loginViewControllerDidFinish(self)

Use NotificationCenter when many parts of the app may need to react to the same event.

NotificationCenter.default.post(name: .userDidLogout, object: nil)

Good NotificationCenter use cases:

• User logged out
• Theme changed
• Language changed
• App-wide data refresh needed
• System notifications

Bad use cases:

• Passing data between two closely related screens
• Replacing clear dependency flow
• Creating hidden app-wide event spaghetti
• Using raw string names everywhere

Safer pattern:

extension Notification.Name {
    static let userDidLogout = Notification.Name("userDidLogout")
}

Modern alternatives:

• Combine publishers
• Async sequences
• SwiftUI environment/state
• Direct dependency injection
• Store/action-based architecture

A strong answer is:

“I use delegates for typed one-to-one communication and NotificationCenter for one-to-many broadcasts. I avoid NotificationCenter for normal screen-to-screen data flow because it can hide dependencies and become difficult to debug.”

Dependency injection means a type receives its dependencies instead of creating them internally.

This improves:

• Testability
• Reusability
• Loose coupling
• Mocking/faking in tests
• Clear ownership

Prefer initializer injection for required dependencies.

protocol FeedRepository {
    func fetchFeed() async throws -> [FeedItem]
}

final class FeedViewModel {
    private let repository: FeedRepository

    init(repository: FeedRepository) {
        self.repository = repository
    }
}

In tests:

struct MockFeedRepository: FeedRepository {
    func fetchFeed() async throws -> [FeedItem] {
        [FeedItem(title: "Test")]
    }
}

Common DI styles on iOS:

Avoid creating dependencies inside the object when they need to be mocked.

// Harder to test
final class FeedViewModel {
    private let repository = RemoteFeedRepository()
}

Better:

final class FeedViewModel {
    private let repository: FeedRepository

    init(repository: FeedRepository) {
        self.repository = repository
    }
}

Singletons are not always wrong, but they should be used carefully. A global singleton can make tests order-dependent and hide dependencies.

Use singletons only for truly global system-like services or when the framework already exposes one, such as UserDefaults.standard or NotificationCenter.default.

A strong answer is:

“I prefer initializer injection with protocols because it makes dependencies explicit and easy to replace in tests. I use factories or SwiftUI environment for app wiring, and I avoid unnecessary singletons because they hide dependencies.”

The coordinator pattern moves navigation logic out of view controllers.

In UIKit, a coordinator usually owns a navigation controller and decides which screen comes next.

final class AppCoordinator {
    private let navigationController: UINavigationController

    init(navigationController: UINavigationController) {
        self.navigationController = navigationController
    }

    func start() {
        showLogin()
    }

    private func showLogin() {
        let viewController = LoginViewController()
        viewController.delegate = self
        navigationController.pushViewController(viewController, animated: true)
    }
}

Without a coordinator, view controllers often know too much:

• Which screen comes next
• How to create the next screen
• Which dependencies the next screen needs
• How to handle login/logout flow
• How to switch tabs or reset navigation

With a coordinator:

• ViewControllers stay focused on UI
• Navigation flow is easier to test
• Deep flows are easier to manage
• Screen creation is centralized
• Dependencies can be injected during screen construction

Common coordinator structure:

AppCoordinator
  LoginCoordinator
  MainTabCoordinator
  SettingsCoordinator

UIKit use cases:

• Login/onboarding flows
• Checkout flows
• Multi-step forms
• Deep navigation graphs
• Apps with many screens

SwiftUI does not usually use the classic UIKit coordinator in the same way. Similar goals can be achieved with:

• NavigationStack
• NavigationPath
• Router object
• Enum-based routes
• Observable navigation state

Example SwiftUI route idea:

enum Route: Hashable {
    case profile(User.ID)
    case settings
}

Then navigation state can be driven by a path/router.

Coordinator trade-off:

• Helpful for complex navigation
• Extra ceremony for small apps
• Can become another “god object” if not split by flow

A strong answer is:

“A coordinator owns navigation flow so view controllers do not create and push every next screen themselves. I use it in UIKit apps with complex navigation, while in SwiftUI I usually model similar routing with NavigationStack, routes, and navigation state.”

UIKit view controller lifecycle questions test whether you know where to put setup, refresh, layout, and cleanup code.

Example:

override func viewDidLoad() {
    super.viewDidLoad()
    setupViews()
    setupConstraints()
    bindViewModel()
}

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    refreshIfNeeded()
}

override func viewDidDisappear(_ animated: Bool) {
    super.viewDidDisappear(animated)
    task?.cancel()
}

Common mistakes:

• Doing heavy synchronous work in viewDidLoad
• Starting network work without cancellation
• Adding constraints repeatedly in viewDidLayoutSubviews
• Assuming viewDidLoad runs every time the screen appears
• Updating UI from a background thread
• Not handling repeated appearances after tab switch or navigation pop

Where to put common work:

Senior-level topics:

• State restoration
• Memory pressure handling
• Task cancellation when screen disappears
• Avoiding retain cycles from closures started in lifecycle methods
• Difference between view loading and view appearing

A strong answer is:

“I use viewDidLoad for one-time setup, appearance callbacks for refresh and analytics, viewDidLayoutSubviews only for frame-dependent layout work, and disappearance callbacks to pause or cancel work.”

UITableView reuses cells for performance. Instead of creating a new cell for every row, the table view keeps a reuse pool and gives you a recycled cell when needed.

let cell = tableView.dequeueReusableCell(
    withIdentifier: "ItemCell",
    for: indexPath
) as! ItemCell

cell.configure(with: items[indexPath.row])
return cell

Why reuse matters:

• Smooth scrolling
• Lower memory use
• Fewer view allocations
• Better battery/performance

Important rule: always configure the full cell state.

A reused cell may still contain old state from a previous row, so reset values such as:

• Image
• Text
• Selection state
• Loading indicator
• Hidden labels
• Accessory type
• Async image task

Example:

final class ItemCell: UITableViewCell {
    override func prepareForReuse() {
        super.prepareForReuse()
        titleLabel.text = nil
        thumbnailView.image = nil
        imageTask?.cancel()
        imageTask = nil
    }
}

Modern table updates often use diffable data sources instead of manually calling many insert/delete/reload methods.

var snapshot = NSDiffableDataSourceSnapshot<Section, Item>()
snapshot.appendSections([.main])
snapshot.appendItems(items)
dataSource.apply(snapshot, animatingDifferences: true)

Diffable data sources help avoid common update crashes like:

Invalid update: invalid number of rows in section

For image-heavy lists, also know prefetching:

• UITableViewDataSourcePrefetching
• Start image/data loading before row appears
• Cancel prefetch when row is no longer likely to appear
• Avoid updating a reused cell with an old async result

Common async image bug:

// Bad if cell is reused before image returns
cell.imageView.image = downloadedImage

Better: verify the cell still represents the same model before applying the image.

A strong answer is:

“Table views reuse cells to keep scrolling fast. I fully configure cells every time, reset state in prepareForReuse, cancel old async work, and use diffable data sources for safer list updates.”

Auto Layout calculates view positions and sizes from constraints.

Important concepts:

Example programmatic constraints:

NSLayoutConstraint.activate([
    titleLabel.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor, constant: 16),
    titleLabel.leadingAnchor.constraint(equalTo: view.leadingAnchor, constant: 16),
    titleLabel.trailingAnchor.constraint(equalTo: view.trailingAnchor, constant: -16)
])

For Auto Layout in code, remember:

titleLabel.translatesAutoresizingMaskIntoConstraints = false

Intrinsic content size example:

• A UILabel knows its natural size from its text and font
• A UIButton knows its natural size from title and content insets
• An image view may need explicit width/height if image size is not enough

Content hugging vs compression resistance:

Common interview debugging points:

• Check console for constraint conflict logs
• Use Debug View Hierarchy
• Add identifiers to constraints
• Look for missing width/height or edge constraints
• Avoid adding duplicate constraints repeatedly
• Use safe area instead of hardcoding top/bottom offsets

Do not create constraints repeatedly inside viewDidLayoutSubviews. That method can run many times.

Use viewDidLayoutSubviews only when actual frames are needed, such as:

• Updating shadow path
• Applying frame-based gradients
• Adjusting rounded corners based on final size

A strong answer is:

“Auto Layout solves constraints to determine size and position. I use intrinsic content size, hugging, compression resistance, priorities, and safe areas to build adaptive layouts, and I debug conflicts with the console and View Hierarchy.”

Storyboards and programmatic UI are both valid. A good interview answer should discuss team workflow, not personal religion.

Storyboards are useful when:

• The team is comfortable with Interface Builder
• Screens are simple
• Designers/developers benefit from visual layout
• Legacy UIKit app already uses storyboards

Programmatic UI is useful when:

• Many developers work on the same screens
• You need reusable components
• You want easier code review
• You want fewer merge conflicts
• UI is built dynamically
• Architecture uses coordinators/factories

SwiftUI changes the discussion because it is declarative and code-first:

struct ProfileView: View {
    var body: some View {
        VStack {
            Text("Profile")
            Button("Edit") {}
        }
    }
}

Many modern apps mix approaches:

• UIKit legacy screens
• SwiftUI for new features
• UIHostingController to embed SwiftUI inside UIKit
• UIViewRepresentable to use UIKit views inside SwiftUI

A strong senior answer should include migration reality. Most teams do not rewrite a stable storyboard app just because programmatic UI is fashionable.

A strong answer is:

“Storyboards are good for visual simple flows, while programmatic UI is better for large teams, reusable components, and code review. I choose based on team workflow, app size, and existing codebase—not ideology.”

SwiftUI and UIKit can coexist in the same iOS app.

Choose SwiftUI for:

• New greenfield screens
• Forms, settings, dashboards, lists
• State-driven UI
• Faster iteration
• Multi-platform UI where practical
• Teams already targeting modern iOS versions

Choose UIKit for:

• Existing UIKit apps
• Complex custom transitions
• Heavy collection/table customization
• Mature third-party UIKit SDKs
• Features where SwiftUI API support is still limiting
• Very fine-grained layout/gesture control

Interop is important:

// Embed SwiftUI in UIKit
let controller = UIHostingController(rootView: ProfileView())

// Wrap UIKit for SwiftUI
struct CameraPreview: UIViewRepresentable {
    func makeUIView(context: Context) -> UIView { UIView() }
    func updateUIView(_ uiView: UIView, context: Context) {}
}

A practical answer: use SwiftUI for new features when deployment target and team skill allow it, but keep UIKit where the existing app or required behavior makes it the safer choice.

A strong answer is:

“I prefer SwiftUI for new state-driven screens, but I still use UIKit for legacy apps, complex custom UI, or APIs where UIKit gives better control. In real apps, I often mix both using UIHostingController and representable wrappers.”

SwiftUI property wrappers define who owns the state and how changes update the view.

Example local state:

@State private var isExpanded = false

Legacy ObservableObject ownership:

@StateObject private var viewModel = ProfileViewModel()

Passed-in object:

@ObservedObject var viewModel: ProfileViewModel

Common bug:

// Bad: new object can be recreated with view updates
@ObservedObject var viewModel = ProfileViewModel()

If the view creates the object, use @StateObject in the older ObservableObject model.

Modern Observation note:

With the newer @Observable macro, many simple models can be owned with @State instead of @StateObject.

@Observable
final class ProfileModel {
    var name = ""
}

struct ProfileView: View {
    @State private var model = ProfileModel()

    var body: some View {
        Text(model.name)
    }
}

Use @EnvironmentObject carefully. It is convenient, but hidden dependencies can make previews and tests fail if the object is not injected.

A strong answer is:

“The key is ownership. @State is local value state, @Binding edits parent state, @StateObject owns a legacy observable object, @ObservedObject observes an externally owned object, and @EnvironmentObject is shared from an ancestor.”

SwiftUI views are structs because they are lightweight descriptions of UI for a given state.

They are not long-lived view objects like UIView.

struct ProfileView: View {
    let name: String

    var body: some View {
        Text(name)
    }
}

When state changes, SwiftUI can recreate the view value and compare/update the underlying rendered UI efficiently.

Important interview points:

• body can be evaluated many times
• Views should be cheap to create
• Do not store long-lived business state directly in a view struct
• Avoid expensive work inside body
• Put async work in .task, services, or ViewModels
• Use stable identity in lists

Bad pattern:

var body: some View {
    Text(expensiveCalculation())
}

Better:

• Precompute in model/ViewModel
• Use cached state
• Use @State, @Observable, or a ViewModel
• Extract subviews for clarity
• Use .task for async loading

View identity matters:

ForEach(users, id: \.id) { user in
    UserRow(user: user)
}

Avoid unstable IDs like UUID() generated inside body, because they make SwiftUI think every item is new.

A strong answer is:

“SwiftUI views are structs because they are cheap descriptions of UI, not persistent UI objects. Persistent state belongs in state properties, models, or ViewModels, and body should stay lightweight.”

Modern SwiftUI navigation uses NavigationStack.

Basic value-based navigation:

NavigationStack {
    List(items) { item in
        NavigationLink(value: item) {
            Text(item.title)
        }
    }
    .navigationDestination(for: Item.self) { item in
        DetailView(item: item)
    }
}

For programmatic navigation, use a path.

@State private var path: [Route] = []

var body: some View {
    NavigationStack(path: $path) {
        HomeView()
            .navigationDestination(for: Route.self) { route in
                switch route {
                case .profile(let id):
                    ProfileView(id: id)
                case .settings:
                    SettingsView()
                }
            }
    }
}

Route enum:

enum Route: Hashable {
    case profile(User.ID)
    case settings
}

This gives you:

• Programmatic push
• Programmatic pop
• Testable route state
• Deep link mapping
• Clear navigation destinations

Common patterns:

UIKit equivalent is UINavigationController with push/pop.

For mixed apps, you may use SwiftUI inside a UIKit navigation controller or embed UIKit screens from SwiftUI where needed.

A strong answer is:

“I use NavigationStack with value-based routes and navigationDestination. For larger apps, I model routes with an enum and keep navigation path in a router so push, pop, and deep links are testable.”

SwiftUI performance issues often come from unstable identity, excessive observation, heavy body work, or too much work on the main actor.

Bad identity example:

ForEach(items, id: \.self) { item in
    Row(item: item)
}

This can be okay for simple stable values, but for models, prefer stable IDs.

ForEach(items, id: \.id) { item in
    Row(item: item)
}

Bad body example:

var body: some View {
    List(viewModel.sortAndFilter(items)) { item in
        Row(item: item)
    }
}

Better:

• Store sorted/filtered data in model state
• Use a computed value only if it is cheap
• Recalculate when inputs change, not every render
• Use pagination for large data sets

Useful tools:

• Instruments
• SwiftUI performance/hitches profiling
• Time Profiler
• Memory Graph
• OSLog/signposts for expensive flows

Senior-level point: performance is often about state design. If one global object changes and many views observe it, SwiftUI may update more UI than necessary.

A strong answer is:

“I keep SwiftUI views lightweight, use stable identity, avoid expensive body work, split observable state, and profile with Instruments instead of guessing.”

GCD and Swift structured concurrency both handle async work, but they have different programming models.

GCD example:

DispatchQueue.global().async {
    let data = loadData()

    DispatchQueue.main.async {
        self.updateUI(data)
    }
}

Modern async/await:

func loadFeed() async throws -> [Post] {
    let (data, _) = try await URLSession.shared.data(from: url)
    return try JSONDecoder().decode([Post].self, from: data)
}

Calling from UI:

Task {
    do {
        posts = try await service.loadFeed()
    } catch {
        errorMessage = error.localizedDescription
    }
}

Still know GCD because many older apps and SDKs use:

• DispatchQueue.main.async
• Completion handlers
• Operation queues
• Legacy callback APIs

Modern answer should include:

• Use async/await for new code
• Use actors for shared mutable state
• Use @MainActor for UI state
• Use continuations to bridge callback APIs
• Use GCD when working with legacy code or low-level queue control

A strong answer is:

“I prefer async/await for new Swift code because it gives clearer control flow, error handling, and cancellation. I still understand GCD because older iOS code and some APIs use queues and callbacks.”

@MainActor is a global actor used to isolate code that must run on the main actor, which is where UI updates should happen.

@MainActor
final class FeedViewModel: ObservableObject {
    @Published var posts: [Post] = []
    @Published var isLoading = false

    func load() async {
        isLoading = true
        defer { isLoading = false }

        do {
            posts = try await service.fetchPosts()
        } catch {
            posts = []
        }
    }
}

Why it matters:

• UI state should be updated on the main actor
• Prevents accidental background UI updates
• Replaces scattered DispatchQueue.main.async
• Makes thread expectations visible in the type system
• Helps with Swift concurrency safety

You can mark:

• A class
• A method
• A property
• A closure
• A ViewModel that owns UI state

Example method-only annotation:

@MainActor
func apply(_ posts: [Post]) {
    self.posts = posts
}

Common mistake:

Task.detached {
    self.posts = posts // unsafe for UI state
}

Better:

Task {
    let posts = try await service.fetchPosts()
    await MainActor.run {
        self.posts = posts
    }
}

If the whole ViewModel is @MainActor, you usually do not need scattered MainActor.run calls for its properties.

Senior nuance: do not put heavy CPU work on the main actor. Do background work outside, then return to the main actor only to update UI state.

A strong answer is:

“@MainActor isolates UI-related code to the main actor. I use it for ViewModels and UI state so updates are safe and explicit, while keeping heavy work off the main actor.”

An actor is a reference type that protects its mutable state from data races.

Only one task at a time can access actor-isolated mutable state.

actor ImageCache {
    private var storage: [URL: Data] = [:]

    func data(for url: URL) -> Data? {
        storage[url]
    }

    func insert(_ data: Data, for url: URL) {
        storage[url] = data
    }
}

Using the actor:

let cache = ImageCache()

await cache.insert(data, for: url)
let cached = await cache.data(for: url)

Why actors matter:

• Safer shared mutable state
• Compiler-enforced isolation
• Less manual locking
• Better fit with async/await
• Helpful for caches, managers, and background state

Actor vs class with lock:

Important nuance: actors are reentrant. When an actor method hits an await, other work may run on that actor before the original method resumes.

actor BankAccount {
    var balance = 100

    func withdraw(_ amount: Int) async -> Bool {
        guard balance >= amount else { return false }
        await logWithdrawal(amount)
        balance -= amount
        return true
    }
}

The await can allow interleaving. For critical state, update state before suspension or re-check after suspension.

A strong answer is:

“An actor is a reference type that serializes access to its isolated state. I use actors for shared mutable state instead of manually locking, but I remember that actor methods can be reentrant across await points.”

Sendable marks values that are safe to pass across concurrency boundaries, such as tasks and actors.

A type is sendable when it can be safely used from concurrent code without causing data races.

Examples usually safe:

• Immutable value types
• Structs whose stored properties are also Sendable
• Enums with sendable associated values
• Actors
• Carefully designed final classes

Example:

struct User: Sendable {
    let id: UUID
    let name: String
}

Classes need more care because they can hold shared mutable state.

final class Counter: @unchecked Sendable {
    private let lock = NSLock()
    private var value = 0
}

@unchecked Sendable means you promise the compiler that the type is safe. Use it sparingly because the compiler will not fully verify your claim.

Why Swift 6 matters:

Swift 6 language mode makes concurrency checking stricter. Code that only produced warnings in earlier modes may become errors when unsafe sharing crosses actor/task boundaries.

Common migration fixes:

• Add @MainActor to UI-facing types
• Make DTOs and value models Sendable
• Avoid capturing mutable non-sendable state in concurrent closures
• Replace shared mutable classes with actors
• Use nonisolated carefully for safe actor members
• Bridge legacy callbacks with continuations
• Enable strict checking per module instead of fixing everything at once

Common interview scenario:

“We turned on stricter concurrency checks and many warnings appeared around ViewModels, delegates, and shared services. I fixed UI state with @MainActor, converted simple models to Sendable, and moved shared mutable caches behind actors.”

A strong answer is:

“Sendable tells Swift a value can safely cross concurrency boundaries. Swift 6 matters because stricter concurrency checking forces unsafe shared mutable state to be fixed instead of silently becoming a data race.”

Swift gives different tools for different async needs.

Task example:

Task {
    await viewModel.load()
}

async let example for a fixed number of parallel calls:

async let users = fetchUsers()
async let posts = fetchPosts()

let feed = try await Feed(users: users, posts: posts)

Task group for dynamic parallel work:

let images = await withTaskGroup(of: UIImage?.self) { group in
    for url in urls {
        group.addTask {
            await loadImage(url)
        }
    }

    var result: [UIImage] = []

    for await image in group {
        if let image {
            result.append(image)
        }
    }

    return result
}

Structured concurrency means child tasks are tied to the parent scope. This helps with:

• Cancellation
• Error propagation
• Avoiding orphan tasks
• Reasoning about task lifetime

Important caution:

Task.detached does not inherit the same actor context or priority in the same way. Avoid it for normal UI work unless you know why you need it.

Screen-level example:

• Start load in .task or Task
• If the screen disappears, task can be cancelled
• Check cancellation in long-running work
• Do not update UI after cancellation

A strong answer is:

“I use Task to start async work, async let for a fixed number of parallel operations, and task groups for dynamic parallel work. I prefer structured concurrency because child task lifetime and cancellation are easier to reason about.”

Checked continuations bridge callback-based APIs into async/await.

Legacy callback API:

func fetchLegacy(completion: @escaping (Result<Data, Error>) -> Void) {
    // older SDK callback
}

Async wrapper:

func fetchLegacyAsync() async throws -> Data {
    try await withCheckedThrowingContinuation { continuation in
        fetchLegacy { result in
            continuation.resume(with: result)
        }
    }
}

Use:

Why “checked” matters:

• Helps detect double resume bugs
• Helps detect paths where continuation is never resumed
• Safer for migrations from callback code

Common mistakes:

// Bug: continuation may resume twice
completionA = {
    continuation.resume(returning: data)
}

completionB = {
    continuation.resume(returning: otherData)
}

A continuation must be resumed exactly once.

Also handle cancellation if the underlying API supports it. For example, if you wrap a network task, store the task and cancel it when the Swift task is cancelled.

Good use cases:

• Legacy SDK callbacks
• Delegate/callback APIs
• Old URLSession completion handlers
• One-shot async operations

Bad use cases:

• Multi-event streams
• Repeated delegate events
• Notifications over time

For streams of many values, consider AsyncStream or AsyncThrowingStream instead of a single continuation.

A strong answer is:

“Checked continuations let me wrap a one-shot callback API in async/await. I must resume the continuation exactly once, use the throwing version for errors, and consider cancellation when the underlying API supports it.”

Modern iOS networking usually uses URLSession with async/await.

For a simple GET request:

struct APIClient {
    func get<T: Decodable>(_ type: T.Type, from url: URL) async throws -> T {
        let (data, response) = try await URLSession.shared.data(from: url)

        guard let http = response as? HTTPURLResponse else {
            throw APIError.invalidResponse
        }

        guard (200...299).contains(http.statusCode) else {
            throw APIError.badStatus(http.statusCode)
        }

        return try JSONDecoder().decode(T.self, from: data)
    }
}

For real apps, prefer URLRequest when you need headers, method, body, cache policy, or timeout.

var request = URLRequest(url: url)
request.httpMethod = "GET"
request.timeoutInterval = 30
request.setValue("Bearer \(token)", forHTTPHeaderField: "Authorization")

let (data, response) = try await URLSession.shared.data(for: request)

A production-ready answer should discuss:

Avoid blindly retrying unsafe requests such as payment or order creation unless the backend supports idempotency keys.

Example error enum:

enum APIError: Error {
    case invalidResponse
    case badStatus(Int)
    case decoding(Error)
}

Senior-level answer: keep networking out of ViewControllers. Put it behind an API client/repository protocol so ViewModels can be tested with fakes.

A strong answer is:

“I use URLSession with async/await, validate the HTTP response, decode into DTOs, and expose typed errors. In production, I also handle timeouts, cancellation, auth headers, retry policy, caching, and testability through an injected API client.”

Choose persistence based on data size, structure, security, and deployment target.

Use UserDefaults for small non-sensitive values:

UserDefaults.standard.set(true, forKey: "hasSeenOnboarding")

Do not store secrets in UserDefaults.

Use Keychain for:

• Access tokens
• Refresh tokens
• Passwords
• Private credentials
• Sensitive account identifiers

Core Data is still important because many existing enterprise apps use it. It is mature, powerful, and supports complex persistence needs.

SwiftData is newer and more Swift-friendly:

@Model
final class Article {
    var title: String
    var isBookmarked: Bool

    init(title: String, isBookmarked: Bool = false) {
        self.title = title
        self.isBookmarked = isBookmarked
    }
}

SwiftData works nicely with SwiftUI, but deployment target matters. If your app supports older iOS versions, Core Data may still be the practical choice.

Offline-first interview answer:

• Local database is the source of truth
• UI reads from local store
• Sync service updates local store
• Network failure should not break reading
• Conflicts need a clear policy
• Migrations must be planned before schema changes

Senior topics:

• Lightweight/heavyweight migrations
• Conflict resolution
• Batch deletes
• Background contexts
• Sync status fields
• DTO-to-persistent-model mapping
• Core Data NSFetchedResultsController
• SwiftData @Query

A strong answer is:

“I use UserDefaults only for small non-sensitive preferences, Keychain for secrets, Core Data for mature complex persistence or older iOS support, and SwiftData for modern SwiftUI-friendly persistence when the deployment target allows it.”

iOS security interview answers should show defense in depth, not one magic API.

App Transport Security (ATS) helps prevent insecure network connections. Avoid broad exceptions like allowing all HTTP traffic.

Bad pattern:

<key>NSAllowsArbitraryLoads</key>
<true/>

If an exception is needed, make it narrow and justify it.

Keychain is for sensitive data:

• Access token
• Refresh token
• Password
• Private credential
• API secret issued to the user/device

Do not store secrets in:

• UserDefaults
• Plain plist
• Local JSON file
• Hardcoded constants

LocalAuthentication is commonly used for Face ID / Touch ID / passcode prompts. It proves user presence, but it does not replace backend authorization or secure token handling.

Example interview distinction:

“Face ID can unlock access to a token stored securely, but the server still decides whether the request is authorized.”

Privacy topics to mention in modern interviews:

• Ask only for permissions you need
• Explain permission purpose clearly
• Keep privacy manifest accurate
• Be careful with third-party SDKs
• Do not collect tracking data without proper consent
• Avoid using required-reason APIs without declaring valid reasons

A strong answer is:

“I rely on ATS for secure transport, Keychain for secrets, LocalAuthentication for user presence, and backend authorization for real access control. I also keep privacy manifests and permission usage aligned with what the app actually does.”

Interviewers expect you to write testable iOS code, not only know XCTest syntax.

Common test layers:

Simple decoding test:

func testDecodeUser() throws {
    let json = #"{"id":"1","name":"Ada"}"#.data(using: .utf8)!

    let user = try JSONDecoder().decode(User.self, from: json)

    XCTAssertEqual(user.name, "Ada")
}

Async XCTest example:

func testFetchUsers() async throws {
    let repository = MockUserRepository()

    let users = try await repository.fetchUsers()

    XCTAssertEqual(users.count, 1)
}

Good testing practices:

• Inject dependencies through protocols
• Do not hit real network in unit tests
• Use fake repositories for ViewModels
• Use custom URLProtocol or mock API client for networking
• Test loading, success, empty, and failure states
• Keep UI tests fewer and focused because they are slower
• Avoid testing implementation details

Example ViewModel test idea:

func testLoadShowsUsers() async {
    let viewModel = UserListViewModel(repository: MockUserRepository())

    await viewModel.load()

    XCTAssertEqual(viewModel.state, .loaded([User(id: "1", name: "Ada")]))
}

Modern note: Apple also has the newer Swift Testing framework, but XCTest is still widely used in existing iOS projects and interviews.

A strong answer is:

“I unit test ViewModels and pure logic with injected dependencies, test async code using async XCTest methods, avoid real network in unit tests, and reserve UI tests for the most important flows.”

Code signing proves the app comes from a trusted developer and has the entitlements it claims.

Interviewers ask because it shows whether you have shipped real apps, not only run code on the Simulator.

Important terms:

Provisioning profiles matter because they define what the signed app is allowed to do.

Examples of capabilities:

• Push notifications
• App Groups
• Keychain sharing
• Associated domains
• iCloud/CloudKit
• Background modes

Common problems:

• Wrong bundle ID
• Expired certificate
• Missing device in development profile
• Capability enabled in code but not in profile
• App Group mismatch
• Push notification entitlement missing
• CI machine missing signing credentials

CI/CD signing topics:

• Xcode automatic signing
• Xcode Cloud
• fastlane match
• Secure certificate/profile storage
• Separate development, staging, and production bundle IDs
• TestFlight distribution

Good interview answer: code signing is not only paperwork. It affects whether push, Keychain sharing, associated domains, App Groups, and app distribution work.

A strong answer is:

“Code signing proves app identity and controls entitlements. Provisioning profiles connect the bundle ID, certificate, devices, and capabilities. Interviewers ask because signing issues appear in real device testing, CI, TestFlight, and App Store releases.”

An offline-first reading list should treat local storage as the source of truth.

High-level design:

1. Store articles locally using Core Data or SwiftData
2. Render UI from the local store
3. Sync with server on launch, foreground, and background refresh
4. Queue local changes when offline
5. Retry sync when network returns
6. Resolve conflicts with a clear policy
7. Cache images separately
8. Show sync/offline state to the user

Suggested model fields:

Article {
    id
    title
    body
    updatedAt
    isBookmarked
    syncStatus
    serverVersion
}

UI behavior:

• User can read saved articles offline
• Bookmark action updates local DB immediately
• UI shows optimistic update
• Sync service uploads pending changes later
• Offline banner appears when network is unavailable
• Failed sync does not lose user actions

Sync policy:

Use BGAppRefreshTask for periodic refresh, but do not promise exact timing. iOS gives limited background execution based on system conditions.

Testing plan:

• Airplane mode
• Slow/flaky network
• App kill and relaunch
• Conflict simulation
• Partial sync failure
• Large article list
• Background refresh behavior

Senior-level point: offline-first is mostly a data consistency problem, not only a local database problem.

A strong answer is:

“I would make the local database the source of truth, update it optimistically, sync deltas with the server, queue offline changes, handle conflicts explicitly, and test airplane mode, flaky network, and app relaunch scenarios.”

Poor scrolling with remote images usually comes from doing too much work on the main thread or not handling cell reuse correctly.

Diagnosis path:

1. Confirm cells are reused correctly
2. Reset image state in prepareForReuse
3. Cancel old image requests when a cell is reused
4. Avoid decoding huge images on the main thread
5. Downsample images to cell size
6. Add memory cache
7. Add disk cache if images repeat
8. Use prefetching for upcoming rows
9. Verify with Instruments

Cell reuse fix:

override func prepareForReuse() {
    super.prepareForReuse()
    thumbnailView.image = placeholderImage
    imageTask?.cancel()
    imageTask = nil
}

Async loading safety:

cell.configure(title: item.title, image: placeholderImage)

imageLoader.load(url: item.imageURL) { [weak tableView] image in
    guard let currentCell = tableView?.cellForRow(at: indexPath) as? ItemCell else {
        return
    }

    currentCell.thumbnailView.image = image
}

In production, also verify that the cell still represents the same item. Index paths can change when the table updates.

Performance fixes:

SwiftUI note: AsyncImage is convenient, but production apps often need a custom image loader for caching, cancellation, placeholders, retries, and downsampling.

Measure with:

• Time Profiler
• Allocations
• Memory Graph
• Network instrument
• Core Animation hitches

A strong answer is:

“I would check reuse first, reset and cancel work in prepareForReuse, downsample images off the main thread, add cache layers, use prefetching, and verify smooth scrolling with Instruments.”

A large iOS app should be modularized around features, shared foundations, and team boundaries.

Common module layout:

App
Features/
  FeedFeature
  ProfileFeature
  SettingsFeature
Core/
  Networking
  Persistence
  Analytics
  DesignSystem
  Utilities

Common tools:

• Swift Package Manager
• Xcode projects/workspaces
• Tuist or similar project generation tools
• Internal frameworks/packages

Good module types:

Benefits:

• Faster focused builds
• Clear ownership
• Better testability
• Safer refactoring
• Reduced merge conflicts
• Reusable features/components
• Cleaner dependency direction

Boundary rules:

• Feature modules should not depend on each other directly
• Shared modules should stay generic
• UI modules should not know backend details
• Public APIs should be intentionally small
• App module wires dependencies together
• Avoid circular dependencies

Example dependency direction:

App
 → Feature
   → DesignSystem
   → Domain
   → Networking protocol

Avoid premature micro-modules. Too many tiny modules increase build complexity and developer friction.

Split when:

• Multiple teams own different areas
• Build time is too slow
• Feature boundaries are stable
• Code ownership is unclear
• Reuse is real, not imagined
• App also ships SDK/internal packages

Senior-level topics:

• Public API stability
• Deprecation policy
• Dependency inversion
• CI build caching
• Binary vs source packages
• Feature flags
• Release cadence
• Test ownership per module

A strong answer is:

“I modularize by feature and shared capability, enforce dependency direction, keep public APIs small, and avoid premature micro-modules. The goal is faster builds, clearer ownership, and safer team scaling.”

Accessibility should be designed into the screen, not added at the end.

Important areas:

UIKit example:

button.accessibilityLabel = "Add article"
button.accessibilityHint = "Adds this article to your reading list"
button.accessibilityTraits = [.button]

SwiftUI example:

Image(systemName: "bookmark")
    .accessibilityLabel("Bookmark article")

Dynamic Type:

• Use system text styles where possible
• Avoid fixed-height labels
• Test the largest accessibility text sizes
• Let layouts wrap or stack vertically
• Avoid clipped text

VoiceOver:

• Ensure custom controls have meaningful labels
• Group related elements when it improves navigation
• Keep reading order logical
• Do not expose decorative images
• Announce important dynamic updates when needed

Common mistakes:

• Clickable image with no label
• Custom button built from View but no trait
• Text clipped at large sizes
• Error message shown visually but not accessible
• Color-only validation state
• Modal opens without focus management

Senior answer: accessibility improves quality for everyone and is often required in enterprise, government, healthcare, finance, and public-facing apps.

A strong answer is:

“I support VoiceOver, Dynamic Type, contrast, touch targets, and Reduce Motion from the start. I test with real accessibility settings and make custom controls expose the right labels, hints, traits, and focus behavior.”

Use the final week to revise practical explanations and scenarios.

Swift fundamentals:

• Struct vs class
• Value vs reference semantics
• Optionals, guard let, and force unwrap risk
• Enums with associated values
• Protocol-oriented programming
• Generics, some, and any
• Codable pitfalls
• Copy-on-write

Memory and architecture:

• ARC and retain cycles
• weak vs unowned
• Closure capture lists
• MVC vs MVVM
• Delegate pattern
• NotificationCenter trade-offs
• Dependency injection
• Coordinator pattern

UIKit and SwiftUI:

• View controller lifecycle
• UITableView reuse and diffable data source
• Auto Layout basics
• Storyboard vs programmatic UI
• SwiftUI vs UIKit
• SwiftUI state wrappers
• Why SwiftUI views are structs
• NavigationStack
• SwiftUI performance pitfalls

Concurrency:

• GCD vs async/await
• @MainActor
• Actors
• Sendable
• Task, async let, and task groups
• Checked continuations
• Cancellation

Networking, persistence, release:

• URLSession request flow
• HTTP status and decoding errors
• Core Data vs SwiftData vs UserDefaults
• Keychain and ATS
• XCTest and async tests
• Code signing and provisioning profiles
• App Store/TestFlight release basics
• Privacy manifests and permissions

Scenario drills:

• Build offline-first reading list
• Fix slow table scrolling with remote images
• Debug retain cycle after screen dismiss
• Design modular app architecture
• Add token-based API client
• Implement SwiftUI navigation router
• Explain migration from UIKit to SwiftUI
• Explain Swift 6 concurrency migration
• Improve app accessibility
• Tell a production bug story using STAR

Behavioral story ideas:

• App Store release issue
• Crash or memory leak fix
• Slow screen performance improvement
• SwiftUI migration
• UIKit legacy maintenance
• API contract change
• Accessibility improvement
• CI/code signing failure
• Deadline trade-off with measurable result

Good final close:

“I can build new SwiftUI features, maintain UIKit code, debug memory and performance issues, explain Swift concurrency safely, and connect architecture decisions to reliability, testability, and user experience.”