MVP Architecture Setup for iOS App
MVP on iOS went out of fashion with SwiftUI and MVVM+Combine arrival, but on UIKit projects with large codebase it remains justified. Especially where team came from Android (where MVP was standard until Jetpack) or where MVP structure historically settled, no reason to break it for trend.
How MVP differs from MVVM on UIKit
In MVVM ViewController subscribes to @Published properties of ViewModel via Combine. In MVP — Presenter doesn't know UIKit: works with View protocol, and ViewController implements protocol and updates UI itself. No bindings, no reactivity — but complete data flow control.
// View protocol — interface for Presenter
protocol ProfileView: AnyObject {
func showUser(_ user: User)
func showLoading(_ isLoading: Bool)
func showError(_ message: String)
}
// Presenter — clean Swift, zero UIKit
final class ProfilePresenter {
weak var view: ProfileView?
private let userRepository: UserRepository
init(userRepository: UserRepository) {
self.userRepository = userRepository
}
func viewDidLoad() {
view?.showLoading(true)
Task {
do {
let user = try await userRepository.fetchCurrentUser()
await MainActor.run {
view?.showLoading(false)
view?.showUser(user)
}
} catch {
await MainActor.run {
view?.showLoading(false)
view?.showError(error.localizedDescription)
}
}
}
}
}
// ViewController — thin, UI only
final class ProfileViewController: UIViewController, ProfileView {
private var presenter: ProfilePresenter!
func showUser(_ user: User) {
nameLabel.text = user.name
avatarImageView.load(url: user.avatarURL)
}
func showLoading(_ isLoading: Bool) {
isLoading ? activityIndicator.startAnimating() : activityIndicator.stopAnimating()
}
func showError(_ message: String) {
// Toast or Alert
}
}
Key point: weak var view: ProfileView? — weak reference mandatory, otherwise retain cycle. Presenter holds View, View holds Presenter — one must be weak.
Presenter testing
Main MVP advantage — Presenter tested without simulator:
func testViewDidLoad_success() async {
let mockView = MockProfileView()
let mockRepository = MockUserRepository(result: .success(User.fixture))
let sut = ProfilePresenter(userRepository: mockRepository)
sut.view = mockView
sut.viewDidLoad()
// Small pause for async Task
try await Task.sleep(nanoseconds: 100_000_000)
XCTAssertTrue(mockView.didShowUser)
XCTAssertFalse(mockView.isLoading)
}
MockProfileView implements ProfileView with call flags. Test takes milliseconds, needs no XCUITest.
Navigation in MVP: Router / Wireframe
Presenter shouldn't manage navigation directly — violates Single Responsibility. Classical solution: Router (or Wireframe in original MVP terms):
protocol ProfileRouter: AnyObject {
func navigateToEditProfile(user: User)
func navigateToSettings()
}
Concrete ProfileRouterImpl works with UINavigationController — UIKit dependency isolated. Presenter gets Router via DI and calls router.navigateToEditProfile(user:) — without knowing what happens under hood.
When MVP better than MVVM
MVP convenient when team actively writes unit tests for screen logic and doesn't want add Combine as dependency. Also — with large UIKit screen count with UITableView / UICollectionView: Presenter conveniently handles delegate events, View just forwards calls.
On SwiftUI projects MVP feels unnatural — no UIViewController, pattern doesn't fit naturally.
What we set up
Design base View, Presenter, Router protocols → create module factory (each screen — ProfileModule.build() returns UIViewController) → set up DI → create example module with tests → optionally migrate existing MVC screens.
Work takes 2–3 days for new project.