25 Swift interview questions

Listen for: A strong answer shows a structured debugging path: reproduce, isolate inputs, inspect logs, use breakpoints, read stack traces, and verify the fix with a test or manual scenario. They should mention Xcode tools such as the debugger, View Debugger, Instruments, or Console rather than only guessing or rewriting code.

Red flag: They cannot explain how they confirmed the cause or whether the fix worked.

Listen for: Look for practical reasoning around value semantics, mutation, copying, identity, reference sharing, and thread safety. A good junior should know structs are common for models and view state, while classes fit shared mutable objects, delegates, Objective-C interop, and identity-heavy APIs. They should avoid treating one as always superior.

Red flag: They answer with memorized definitions but cannot connect the choice to bugs or maintainability.

Listen for: Listen for a simple state model, not scattered booleans. Good answers mention an enum or typed view state, async/await in a view model or observable model, main-actor UI updates, cancellation when the view disappears, retry behavior, and user-friendly errors. They should keep networking separate from view layout.

Red flag: They put all networking directly in the View body and rely on print statements for errors.

Listen for: A strong answer treats force unwrap as rare and justified only when an invariant is guaranteed and failure should surface during development. They should use guard for required preconditions, optional binding for conditional paths, and throwing or result-based APIs when callers can recover. Listen for clarity around user input and remote data.

Red flag: They say force unwrap is fine if the app has not crashed in testing.

Listen for: Good signals include separating rendering from business logic, extracting smaller views only when it improves clarity, using focused state, avoiding duplicated modifiers, and moving side effects out of body. They should understand property wrappers such as @State, @Binding, @Observable, and @Environment at a practical level.

Red flag: They think every large view should be split by line count without considering state ownership.

Listen for: Listen for tests around normal cases, rounding, nil or missing fields, locale or currency behavior, and invalid server values. Strong juniors separate formatting logic from UI so it can be unit tested, name tests clearly, and avoid depending on live APIs. Snapshot tests may be useful but should not be the only coverage.

Red flag: They only test the happy path by tapping through the app manually.

Listen for: A strong answer discusses task cancellation, view identity, task(id:), MainActor isolation, and preventing older responses from overwriting newer state. They should inspect lifecycle events and logs, reproduce with slow network conditions, and consider moving ownership to a model with explicit cancellation rather than relying on timing.

Red flag: They add arbitrary delays or dispatch back to the main queue without understanding task lifetimes.

Listen for: Look for clear boundaries: endpoint modeling, URLSession configuration, authentication, retries, decoding strategy, error taxonomy, cancellation, and test injection. Good candidates avoid over-engineering but know where abstractions help. They should discuss observability, redaction of sensitive data, and how to support async/await cleanly without hiding useful HTTP details.

Red flag: They propose a single global client with string URLs everywhere and no test strategy.

Listen for: Strong answers identify publisher semantics first: backpressure, debouncing, sharing, cancellation, scheduler behavior, and error handling. They may use AsyncSequence bridges where appropriate, keep Combine for UI/event streams when it fits, and migrate incrementally behind protocols. They should add tests around ordering and cancellation before refactoring.

Red flag: They claim async/await always replaces Combine with a simple mechanical rewrite.

Listen for: Listen for Instruments, signposts, cold versus warm launch, dyld and static initialization, main-thread work, dependency setup, disk I/O, remote config, and synchronous keychain or database access. Good candidates propose moving noncritical work after first render while keeping correctness, and they verify improvement with repeatable measurements.

Red flag: They immediately blame SwiftUI or the backend without profiling.

Listen for: A strong mid-level answer covers Swift Package Manager modules, feature boundaries, shared design system or core utilities, dependency direction, and avoiding a large catch-all module. They should consider build times, preview/test targets, access control, and ownership. They should also know that too many modules create coordination overhead.

Red flag: They suggest either one giant app target or a module for every file with no trade-off discussion.

Listen for: Good answers clarify freshness, conflict behavior, data sensitivity, storage size, authentication changes, offline actions, sync triggers, and user messaging. They should compare URLCache, file storage, SQLite/Core Data/SwiftData, and keychain where relevant. Listen for awareness that cache invalidation and migration are product decisions as much as technical ones.

Red flag: They choose a persistence framework before understanding the data and consistency requirements.

Listen for: Look for review focus beyond style: state ownership, actor isolation, dependency injection, error handling, accessibility labels, localization, test coverage, and whether abstractions match current needs. A good answer balances correctness with delivery, asks clarifying questions, and explains when they would request changes versus leave suggestions.

Red flag: They mainly comment on formatting and personal preferences.

Listen for: A strong answer starts with inventory and compiler settings, then migrates module by module. Listen for Sendable audits, actor boundaries, @MainActor usage, nonisolated APIs, third-party dependencies, and temporary escape hatches with clear ownership. They should prioritize risky shared mutable state and preserve release flow with tests and CI gates.

Red flag: They suggest adding @MainActor or @unchecked Sendable broadly until the warnings disappear.

Listen for: Look for context-driven judgment: team familiarity, testability, navigation complexity, state sharing, app size, and onboarding cost. Strong seniors do not sell one architecture universally. They should explain how they keep business logic out of views, prevent dependency sprawl, and evolve architecture through real seams instead of rewrites.

Red flag: They insist their preferred architecture is always correct regardless of product or team constraints.

Listen for: Listen for crash symbolication, device/OS segmentation, release version comparison, logs and breadcrumbs, feature flags, rollback or hotfix criteria, and communicating risk. Strong answers include reproducing with realistic data, adding regression tests when possible, and improving observability or guardrails so similar issues are caught earlier.

Red flag: They focus only on fixing the code locally and ignore rollout, communication, and recurrence.

Listen for: A good answer separates authentication tokens, local unlock, and server trust. Listen for keychain access control, Secure Enclave where appropriate, LocalAuthentication, token refresh, logout behavior, device passcode changes, jailbreak/root risk, logging redaction, and not storing secrets in UserDefaults or source. They should involve backend constraints early.

Red flag: They describe Face ID as if it authenticates the user to the server by itself.

Listen for: Strong answers cover public surface area, semantic versioning, binary compatibility when relevant, dependency minimization, test fixtures, documentation comments, examples, and clear ownership. They should discuss async APIs, error types, cancellation, access control, and how to avoid leaking app-specific assumptions into the package.

Red flag: They expose implementation types publicly because it is faster for the first consumer.

Listen for: Look for concrete practices: pairing, focused review comments, shared examples, lightweight design notes, and follow-up refactors tied to product work. Strong seniors distinguish must-fix correctness issues from improvements, explain trade-offs, and create reusable patterns. They should avoid becoming the bottleneck for every Swift decision.

Red flag: They either rewrite others’ code themselves or approve everything to avoid conflict.

Listen for: Listen for background URLSession constraints, app lifecycle states, notification authorization, universal links, idempotent routing, authentication gates, and state restoration. Strong answers plan for delivery out of order: upload completes before UI exists, link arrives while logged out, or notification opens stale content. They include testing on real devices.

Red flag: They assume foreground flows and simulator testing cover the feature.

Listen for: Strong candidates clarify conflict rules, data ownership, attachment size, retry policy, and user expectations before choosing storage. They should discuss SwiftData/Core Data or SQLite, background transfers, a sync queue, stable local IDs, merge status in UI, and tests for interrupted uploads. Security and migration should be part of the design.

Red flag: They describe a cache but no durable queue, conflict handling, or user-visible sync state.

Listen for: Look for module boundaries with Swift Package Manager, dependency direction, app shell ownership, shared UI components, routing contracts, and CI implications. Strong answers weigh build time, preview reliability, access control, and governance for shared code. They should avoid centralizing all decisions in a core module.

Red flag: They create a massive shared framework that every feature imports and modifies.

Listen for: A strong design mentions cell/view reuse, prefetch windows, cancellation, memory pressure handling, downsampling images, video session limits, caching layers, and measuring with Instruments. They should coordinate SwiftUI or UIKit rendering with async loading and avoid doing decoding or layout-heavy work on the main thread.

Red flag: They rely on loading full-resolution assets directly in each row as it appears.

Listen for: Strong answers are incremental: identify seams, bridge with Objective-C interoperability, add Swift packages, wrap UIKit where needed, and replace screens based on value and risk. They should discuss testing, navigation integration, design parity, concurrency adoption, and avoiding a stalled big-bang rewrite. Release safety matters as much as code modernization.

Red flag: They propose rewriting the whole app first and pausing product work until it is done.

Listen for: Look for API stability, minimal dependencies, clear async APIs, cancellation, error taxonomy, theming boundaries, accessibility, logging redaction, and secure handling of tokens or PII. Strong candidates discuss Swift Package Manager distribution, sample apps, integration tests, versioning, and not assuming the host app’s architecture or lifecycle.

Red flag: They design the SDK as if it controls the entire app environment.