iOS senior interviews place heavy emphasis on architecture and design patterns. Beyond Swift syntax, interviewers evaluate the ability to design maintainable, testable, and scalable applications.

This guide covers the most frequent questions on MVVM, VIPER, Clean Architecture, and essential patterns, with detailed answers and interview-ready code examples.

What Interviewers Really Evaluate

In senior interviews, the technical answer matters less than the reasoning. Always explain why an architecture fits a given context, not just how to implement it.

Understanding iOS Architectures: An Overview

Before diving into specific questions, understanding the iOS architectural landscape is essential. Each pattern solves different problems and suits different contexts.

MVC: Apple's Historical Pattern

MVC (Model-View-Controller) remains Apple's default pattern but suffers from the "Massive View Controllers" problem in complex applications.

UserViewController.swiftswift

// Typical MVC example showing its limitations
class UserViewController: UIViewController {
    // The ViewController accumulates too many responsibilities
    private var users: [User] = []

    override func viewDidLoad() {
        super.viewDidLoad()
        // View logic
        setupUI()
        // Business logic
        fetchUsers()
        // Navigation logic
        setupNavigationBar()
    }

    private func fetchUsers() {
        // Networking in the VC: anti-pattern
        URLSession.shared.dataTask(with: URL(string: "api/users")!) { data, _, _ in
            // JSON parsing here too...
        }.resume()
    }
}

This pattern becomes problematic when ViewControllers exceed 500 lines, making unit testing nearly impossible.

Question 1: Explain MVVM and Its Swift Implementation

MVVM (Model-View-ViewModel) separates presentation logic into a ViewModel, facilitating testing and reducing ViewController size.

Key Interview Point

MVVM shines with SwiftUI thanks to @Observable and native data binding. With UIKit, a binding mechanism (Combine, closures) is required.

MVVM Implementation with Combine

UserViewModel.swiftswift

// ViewModel separated from any UIKit dependency
import Combine

@MainActor
final class UserViewModel: ObservableObject {
    // Published states for binding
    @Published private(set) var users: [User] = []
    @Published private(set) var isLoading = false
    @Published private(set) var errorMessage: String?

    // Injected dependency for testability
    private let userRepository: UserRepositoryProtocol
    private var cancellables = Set<AnyCancellable>()

    init(userRepository: UserRepositoryProtocol = UserRepository()) {
        self.userRepository = userRepository
    }

    func loadUsers() {
        isLoading = true
        errorMessage = nil

        userRepository.fetchUsers()
            .receive(on: DispatchQueue.main)
            .sink { [weak self] completion in
                self?.isLoading = false
                if case .failure(let error) = completion {
                    self?.errorMessage = error.localizedDescription
                }
            } receiveValue: { [weak self] users in
                self?.users = users
            }
            .store(in: &cancellables)
    }
}

The View with Combine Binding

UserListView.swiftswift

// SwiftUI View consuming the ViewModel
import SwiftUI

struct UserListView: View {
    // StateObject for lifecycle management
    @StateObject private var viewModel = UserViewModel()

    var body: some View {
        Group {
            if viewModel.isLoading {
                ProgressView("Loading...")
            } else if let error = viewModel.errorMessage {
                ErrorView(message: error, retry: viewModel.loadUsers)
            } else {
                List(viewModel.users) { user in
                    UserRowView(user: user)
                }
            }
        }
        .onAppear { viewModel.loadUsers() }
    }
}

The ViewModel knows neither UIKit nor SwiftUI, making it entirely unit testable.

Question 2: When Should You Choose VIPER Over MVVM?

VIPER (View-Interactor-Presenter-Entity-Router) suits complex applications requiring strict separation of concerns and advanced navigation.

Complete VIPER Structure

UserListProtocols.swiftswift

// Contract definitions between VIPER components
protocol UserListViewProtocol: AnyObject {
    var presenter: UserListPresenterProtocol? { get set }
    func showUsers(_ users: [UserViewModel])
    func showError(_ message: String)
    func showLoading()
}

protocol UserListPresenterProtocol: AnyObject {
    var view: UserListViewProtocol? { get set }
    var interactor: UserListInteractorInputProtocol? { get set }
    var router: UserListRouterProtocol? { get set }
    func viewDidLoad()
    func didSelectUser(_ user: UserViewModel)
}

protocol UserListInteractorInputProtocol: AnyObject {
    var presenter: UserListInteractorOutputProtocol? { get set }
    func fetchUsers()
}

protocol UserListInteractorOutputProtocol: AnyObject {
    func didFetchUsers(_ users: [User])
    func didFailWithError(_ error: Error)
}

protocol UserListRouterProtocol: AnyObject {
    func navigateToUserDetail(with userId: String)
}

The Presenter Orchestrates Logic

UserListPresenter.swiftswift

// The Presenter bridges View and Interactor
final class UserListPresenter: UserListPresenterProtocol {
    weak var view: UserListViewProtocol?
    var interactor: UserListInteractorInputProtocol?
    var router: UserListRouterProtocol?

    func viewDidLoad() {
        view?.showLoading()
        interactor?.fetchUsers()
    }

    func didSelectUser(_ user: UserViewModel) {
        router?.navigateToUserDetail(with: user.id)
    }
}

// Extension for Interactor callbacks
extension UserListPresenter: UserListInteractorOutputProtocol {
    func didFetchUsers(_ users: [User]) {
        // Model -> ViewModel transformation
        let viewModels = users.map { UserViewModel(from: $0) }
        view?.showUsers(viewModels)
    }

    func didFailWithError(_ error: Error) {
        view?.showError(error.localizedDescription)
    }
}

Interview Warning

VIPER introduces significant boilerplate. Justify its use by team size (multiple devs on one module) or business domain complexity.

Question 3: How Do You Implement Clean Architecture on iOS?

Clean Architecture organizes code in concentric circles, with business rules at the center, independent of frameworks.

Layer Structure

Domain/Entities/User.swiftswift

// Pure business entity, no framework dependencies
struct User: Identifiable, Equatable {
    let id: String
    let email: String
    let fullName: String
    let subscriptionLevel: SubscriptionLevel

    enum SubscriptionLevel: String {
        case free, premium, enterprise
    }
}

// Domain/UseCases/GetUsersUseCase.swift
// Use Case encapsulating a business rule
protocol GetUsersUseCaseProtocol {
    func execute() async throws -> [User]
}

final class GetUsersUseCase: GetUsersUseCaseProtocol {
    // Dependency on abstraction, not implementation
    private let repository: UserRepositoryProtocol

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

    func execute() async throws -> [User] {
        let users = try await repository.fetchAll()
        // Business rule: sort by subscription level
        return users.sorted { $0.subscriptionLevel.rawValue > $1.subscriptionLevel.rawValue }
    }
}

The Data Layer with Repository Pattern

Data/Repositories/UserRepository.swiftswift

// Concrete repository implementation
final class UserRepository: UserRepositoryProtocol {
    private let remoteDataSource: UserRemoteDataSourceProtocol
    private let localDataSource: UserLocalDataSourceProtocol

    init(
        remoteDataSource: UserRemoteDataSourceProtocol = UserRemoteDataSource(),
        localDataSource: UserLocalDataSourceProtocol = UserLocalDataSource()
    ) {
        self.remoteDataSource = remoteDataSource
        self.localDataSource = localDataSource
    }

    func fetchAll() async throws -> [User] {
        do {
            // Cache-first strategy with fallback
            let remoteUsers = try await remoteDataSource.fetchUsers()
            await localDataSource.save(remoteUsers)
            return remoteUsers
        } catch {
            // Fallback to local cache
            return try await localDataSource.fetchUsers()
        }
    }
}

This organization enables testing each layer independently and changing implementations (e.g., migrating from CoreData to SwiftData) without touching the domain.

Ready to ace your iOS interviews?

Practice with our interactive simulators, flashcards, and technical tests.

Explore iOS

Question 4: Which Design Patterns Do You Use Daily?

Interviewers expect practical pattern mastery, not theoretical recitation. Here are the most frequent in iOS.

Dependency Injection with Property Wrappers

DependencyInjection/Container.swiftswift

// Simple and effective injection container
final class DIContainer {
    static let shared = DIContainer()

    private var factories: [String: () -> Any] = [:]

    func register<T>(_ type: T.Type, factory: @escaping () -> T) {
        let key = String(describing: type)
        factories[key] = factory
    }

    func resolve<T>(_ type: T.Type) -> T {
        let key = String(describing: type)
        guard let factory = factories[key], let instance = factory() as? T else {
            fatalError("No registration for \(key)")
        }
        return instance
    }
}

// Property Wrapper for elegant injection
@propertyWrapper
struct Injected<T> {
    private var value: T

    init() {
        self.value = DIContainer.shared.resolve(T.self)
    }

    var wrappedValue: T {
        get { value }
        mutating set { value = newValue }
    }
}

// Usage in a ViewModel
final class PaymentViewModel {
    @Injected private var paymentService: PaymentServiceProtocol
    @Injected private var analyticsService: AnalyticsServiceProtocol

    func processPayment(_ amount: Decimal) async throws {
        analyticsService.track(.paymentInitiated(amount: amount))
        try await paymentService.charge(amount)
    }
}

Coordinators/AppCoordinator.swiftswift

// Coordinator managing navigation flow
protocol Coordinator: AnyObject {
    var childCoordinators: [Coordinator] { get set }
    var navigationController: UINavigationController { get }
    func start()
}

final class AppCoordinator: Coordinator {
    var childCoordinators: [Coordinator] = []
    let navigationController: UINavigationController

    private let window: UIWindow

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

    func start() {
        window.rootViewController = navigationController
        window.makeKeyAndVisible()

        // Flow decision based on state
        if AuthManager.shared.isAuthenticated {
            showMainFlow()
        } else {
            showAuthFlow()
        }
    }

    private func showAuthFlow() {
        let authCoordinator = AuthCoordinator(navigationController: navigationController)
        authCoordinator.delegate = self
        childCoordinators.append(authCoordinator)
        authCoordinator.start()
    }

    private func showMainFlow() {
        let mainCoordinator = MainCoordinator(navigationController: navigationController)
        childCoordinators.append(mainCoordinator)
        mainCoordinator.start()
    }
}

This pattern moves navigation logic out of ViewControllers, making them lighter and more reusable.

Question 5: How Do You Handle Inter-Module Communication?

Inter-module communication is crucial in large applications. Several approaches exist depending on desired coupling.

Protocol-Based Communication

Modules/Shared/ModuleProtocols.swiftswift

// Public contracts exposed by each module
protocol PaymentModuleProtocol {
    func startPaymentFlow(for productId: String, completion: @escaping (Result<Receipt, PaymentError>) -> Void)
}

protocol UserModuleProtocol {
    func getCurrentUser() -> User?
    func updateProfile(_ profile: ProfileUpdate) async throws
}

// Modules/Payment/PaymentModule.swift
// Internal module implementation
final class PaymentModule: PaymentModuleProtocol {
    static let shared: PaymentModuleProtocol = PaymentModule()

    private let paymentService: PaymentService

    private init() {
        self.paymentService = PaymentService()
    }

    func startPaymentFlow(for productId: String, completion: @escaping (Result<Receipt, PaymentError>) -> Void) {
        // Module-internal logic
        paymentService.process(productId: productId, completion: completion)
    }
}

Event-Driven Communication with Combine

EventBus/AppEventBus.swiftswift

// Decoupled event bus for async communication
enum AppEvent {
    case userDidLogin(User)
    case userDidLogout
    case purchaseCompleted(Receipt)
    case subscriptionChanged(SubscriptionLevel)
}

final class AppEventBus {
    static let shared = AppEventBus()

    // Private Subject, public Publisher
    private let eventSubject = PassthroughSubject<AppEvent, Never>()
    var events: AnyPublisher<AppEvent, Never> {
        eventSubject.eraseToAnyPublisher()
    }

    func send(_ event: AppEvent) {
        eventSubject.send(event)
    }
}

// Listening in any module
final class AnalyticsModule {
    private var cancellables = Set<AnyCancellable>()

    init() {
        AppEventBus.shared.events
            .sink { [weak self] event in
                self?.handleEvent(event)
            }
            .store(in: &cancellables)
    }

    private func handleEvent(_ event: AppEvent) {
        switch event {
        case .purchaseCompleted(let receipt):
            trackPurchase(receipt)
        case .userDidLogin(let user):
            identifyUser(user)
        default:
            break
        }
    }
}

Interview Tip

Mention that choosing between tight coupling (protocols) and loose coupling (events) depends on context: events suit global notifications, protocols suit direct interactions.

Question 6: How Do You Structure Tests in a Modular Architecture?

Testability is a major criterion for senior positions. Good architecture facilitates testing at all levels.

Unit Testing the ViewModel

Tests/UserViewModelTests.swiftswift

// Unit tests with injected mocks
import XCTest
@testable import MyApp

final class UserViewModelTests: XCTestCase {
    private var sut: UserViewModel!
    private var mockRepository: MockUserRepository!

    override func setUp() {
        super.setUp()
        mockRepository = MockUserRepository()
        sut = UserViewModel(userRepository: mockRepository)
    }

    override func tearDown() {
        sut = nil
        mockRepository = nil
        super.tearDown()
    }

    func test_loadUsers_success_updatesUsersArray() async {
        // Given
        let expectedUsers = [User.mock(), User.mock()]
        mockRepository.stubbedUsers = expectedUsers

        // When
        await sut.loadUsers()

        // Then
        XCTAssertEqual(sut.users.count, 2)
        XCTAssertFalse(sut.isLoading)
        XCTAssertNil(sut.errorMessage)
    }

    func test_loadUsers_failure_setsErrorMessage() async {
        // Given
        mockRepository.stubbedError = NetworkError.noConnection

        // When
        await sut.loadUsers()

        // Then
        XCTAssertTrue(sut.users.isEmpty)
        XCTAssertNotNil(sut.errorMessage)
    }
}

// Mocks/MockUserRepository.swift
final class MockUserRepository: UserRepositoryProtocol {
    var stubbedUsers: [User] = []
    var stubbedError: Error?
    var fetchUsersCalled = false

    func fetchUsers() -> AnyPublisher<[User], Error> {
        fetchUsersCalled = true

        if let error = stubbedError {
            return Fail(error: error).eraseToAnyPublisher()
        }
        return Just(stubbedUsers)
            .setFailureType(to: Error.self)
            .eraseToAnyPublisher()
    }
}

Integration Testing the Use Case

Tests/GetUsersUseCaseTests.swiftswift

// Integration test verifying business logic
final class GetUsersUseCaseTests: XCTestCase {
    func test_execute_sortsUsersBySubscriptionLevel() async throws {
        // Given
        let freeUser = User(id: "1", email: "free@test.com", fullName: "Free", subscriptionLevel: .free)
        let premiumUser = User(id: "2", email: "premium@test.com", fullName: "Premium", subscriptionLevel: .premium)

        let mockRepo = MockUserRepository()
        mockRepo.stubbedUsers = [freeUser, premiumUser]

        let sut = GetUsersUseCase(repository: mockRepo)

        // When
        let result = try await sut.execute()

        // Then - Premium should be first
        XCTAssertEqual(result.first?.subscriptionLevel, .premium)
        XCTAssertEqual(result.last?.subscriptionLevel, .free)
    }
}

Question 7: How Do You Handle Complex UI States?

State management is critical for senior applications. A structured approach prevents bugs and simplifies debugging.

State Machine with Enum

ViewModels/CheckoutViewModel.swiftswift

// State machine for payment flow
enum CheckoutState: Equatable {
    case idle
    case loadingCart
    case cartLoaded(CartSummary)
    case processingPayment
    case paymentSucceeded(Receipt)
    case paymentFailed(PaymentError)

    var isLoading: Bool {
        switch self {
        case .loadingCart, .processingPayment: return true
        default: return false
        }
    }
}

@MainActor
final class CheckoutViewModel: ObservableObject {
    @Published private(set) var state: CheckoutState = .idle

    private let cartService: CartServiceProtocol
    private let paymentService: PaymentServiceProtocol

    init(cartService: CartServiceProtocol, paymentService: PaymentServiceProtocol) {
        self.cartService = cartService
        self.paymentService = paymentService
    }

    func loadCart() async {
        state = .loadingCart

        do {
            let summary = try await cartService.getSummary()
            state = .cartLoaded(summary)
        } catch {
            state = .paymentFailed(.cartLoadFailed)
        }
    }

    func confirmPayment() async {
        guard case .cartLoaded(let summary) = state else { return }

        state = .processingPayment

        do {
            let receipt = try await paymentService.charge(summary.total)
            state = .paymentSucceeded(receipt)
        } catch let error as PaymentError {
            state = .paymentFailed(error)
        } catch {
            state = .paymentFailed(.unknown)
        }
    }
}

This approach makes inconsistent states impossible (e.g., isLoading = true with an error displayed).

Start practicing!

Test your knowledge with our interview simulators and technical tests.

Create my free account

Conclusion

iOS senior interviews evaluate the ability to choose and justify an architecture suited to context. Key takeaways:

iOS Senior Architecture Checklist:

✅ MVVM for medium-sized apps with SwiftUI or UIKit + Combine ✅ VIPER for large teams and complex business domains ✅ Clean Architecture for framework independence ✅ Systematic Dependency Injection for testability ✅ Coordinator Pattern to decouple navigation ✅ State Machines for complex flows ✅ Tests at every level: unit, integration, UI

In interviews, demonstrate:

Understanding of trade-offs (simple MVVM vs structured VIPER)
Practical experience with real project examples
Ability to adapt architecture to context (team size, complexity)
Mastery of testing as an architectural quality criterion

Start practicing!

Test your knowledge with our interview simulators and technical tests.

Create my free account

iOS Senior Interview 2026: Architecture and Design Patterns Questions

Understanding iOS Architectures: An Overview

MVC: Apple's Historical Pattern

Question 1: Explain MVVM and Its Swift Implementation

MVVM Implementation with Combine

The View with Combine Binding

Question 2: When Should You Choose VIPER Over MVVM?

Complete VIPER Structure

The Presenter Orchestrates Logic

Question 3: How Do You Implement Clean Architecture on iOS?

Layer Structure

The Data Layer with Repository Pattern

Ready to ace your iOS interviews?

Question 4: Which Design Patterns Do You Use Daily?

Dependency Injection with Property Wrappers

Coordinator Pattern for Navigation

Question 5: How Do You Handle Inter-Module Communication?

Protocol-Based Communication

Event-Driven Communication with Combine

Question 6: How Do You Structure Tests in a Modular Architecture?

Unit Testing the ViewModel

Integration Testing the Use Case

Question 7: How Do You Handle Complex UI States?

State Machine with Enum

Start practicing!

Conclusion

Start practicing!

Related articles

StoreKit 2 Interview: Subscription Management and Receipt Validation

Swift Testing Framework Interview 2026: #expect and #require Macros vs XCTest

iOS Push Notifications Interview in 2026: APNs, Tokens and Troubleshooting