Настройка архитектуры MVP для iOS: шаблон и практика

Настройка архитектуры MVP для iOS-приложения

Представьте: кодовая база UIKit-приложения разрослась до 20+ экранов, каждый ViewController тащит 500+ строк, а тесты отсутствуют или требуют запуска симулятора. Вы пробовали MVVM, но связка Combine с @Published не вписалась — проект слишком стар, или команда пришла из Android с её MVP-культурой. Наша команда имеет опыт настройки MVP на 15+ проектах и гарантирует работоспособность шаблона с первого коммита. В этой статье разберём ключевые протоколы, изоляцию UIKit и тестирование без симулятора.

Wikipedia: Model-View-Presenter — это архитектурный паттерн, в котором Presenter выступает посредником между View и Model. На iOS это особенно полезно для крупных проектов, где MVVM с Combine требует переписывания кода под реактивный стек.

Почему MVP подходит для UIKit-проектов?

Если ваш проект — не простой список с деталями, а сложный многоэкранный UIKit, MVP даёт чёткое разделение: Presenter не видит UIKit, ViewController тоньше, тесты пишутся без симулятора. В отличие от MVVM, где ViewModel подписывается на Combine, MVP использует простые протоколы и слабые ссылки. Это снижает порог входа и не требует переписывания кода под реактивный стек. Такой подход является элементом чистой архитектуры iOS, поскольку зависимости направлены от внешних слоёв к ядру.

Что такое MVP на iOS и в чём отличие от MVVM?

По определению Model-View-Presenter — это архитектурный паттерн, в котором Presenter выступает посредником между View и Model. В MVVM ViewController подписывается на @Published-свойства ViewModel через Combine. В MVP Presenter не знает о UIKit: он общается с протоколом View, который реализует ViewController. Нет биндингов, нет реактивности — полная контролируемость потока данных.

// View protocol — интерфейс для Presenter
protocol ProfileView: AnyObject {
    func showUser(_ user: User)
    func showLoading(_ isLoading: Bool)
    func showError(_ message: String)
}

// Presenter — чистый Swift, ноль 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 — тонкий, только UI
final class ProfileViewController: UIViewController, ProfileView {
    private var presenter: ProfilePresenter!

    override func viewDidLoad() {
        super.viewDidLoad()
        presenter.viewDidLoad()
    }

    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 или Alert
    }
}

Ключевой момент: weak var view: ProfileView? — слабая ссылка обязательна, иначе retain cycle. Presenter держит View, View держит Presenter — один из них должен быть weak.

Как тестировать Presenter без симулятора?

Главное преимущество MVP — Presenter тестируется без симулятора. Вот пример с моком:

final class MockProfileView: ProfileView {
    var didShowUser = false
    var isLoading = false

    func showUser(_ user: User) { didShowUser = true }
    func showLoading(_ isOn: Bool) { isLoading = isOn }
    func showError(_ message: String) { /* ignore */ }
}

func testViewDidLoad_success() async {
    let mockView = MockProfileView()
    let mockRepository = MockUserRepository(result: .success(User.fixture))
    let sut = ProfilePresenter(userRepository: mockRepository)
    sut.view = mockView

    sut.viewDidLoad()
    // Небольшая пауза для async Task
    try await Task.sleep(nanoseconds: 100_000_000)

    XCTAssertTrue(mockView.didShowUser)
    XCTAssertFalse(mockView.isLoading)
}

Тест занимает миллисекунды, не требует XCUITest. Покрытие кода такими тестами достигает 80%, а экономия средств на регрессе — до 40% бюджета. Сравните: типичная MVVM-ViewModel с Combine требует настройки XCTestExpectation или Sink — MVP здесь значительно проще и быстрее.

Что входит в настройку MVP?

При заказе настройки MVP вы получаете:

• Полные Swift-файлы модуля: Presenter, ViewController, Router.
• Unit-тесты Presenter (5–10 кейсов на модуль, покрытие 80%).
• Интеграционные инструкции для добавления новых экранов.
• Обучение команды (1–2 созвона с демонстрацией).

Работа занимает 2–3 дня для нового проекта. Свяжитесь с нами для оценки объёма миграции существующих экранов. Получите консультацию по внедрению MVP в ваш проект.

Навигация в MVP: что такое Router / Wireframe?

Presenter не должен управлять навигацией напрямую — это нарушает Single Responsibility. Классическое решение: Router (или Wireframe в оригинальном MVP терминах):

protocol ProfileRouter: AnyObject {
    func navigateToEditProfile(user: User)
    func navigateToSettings()
}

Конкретный ProfileRouterImpl работает с UINavigationController — UIKit-зависимость изолирована. Presenter получает Router через DI и вызывает router.navigateToEditProfile(user:) — без знания о том, что происходит под капотом.

Как мигрировать MVC на MVP?

Миграция существующего MVC-экрана на MVP — задача на 4–8 часов на экран. Создайте протокол View, выделите логику в Presenter, добавьте Router. Перенесите зависимость от Model в Presenter. Реализуйте View в ViewController. Тестируйте Presenter. Такой пошаговый план применим для любого экрана, а итоговая архитектура становится модульной и тестируемой.

Пошаговая настройка MVP для нового проекта

1. Определите модули. Каждый экран — отдельный модуль с протоколами View, Presenter, Router.
2. Напишите протоколы. View — только методы отображения; Presenter — методы жизненного цикла и обработки событий; Router — навигационные методы.
3. Реализуйте Presenter. Вся логика, работа с сервером/БД. Никакого UIKit.
4. Реализуйте View (ViewController). Пробрасывайте вызовы к Presenter.
5. Реализуйте Router. Создайте класс, который использует UINavigationController для переходов.
6. Настройте DI. Используйте фабрику модулей или Swinject для компоновки зависимостей.
7. Напишите тесты. Покройте каждый метод Presenter (5–10 кейсов на модуль).

Сравнение MVP и MVVM

Какие типичные ошибки допускают при внедрении MVP?

• Забыть weak на view — retain cycle, утечка памяти. Всегда используйте weak var view: ViewProtocol?.
• Смешивать логику навигации в Presenter — выделите Router.
• Не тестировать Presenter — теряете главное преимущество MVP. Покрывайте моками.
• Переусложнять протоколы — один метод на экран вместо дробления. Держите количество методов View в разумных пределах (5–7).

Закажите настройку MVP для вашего проекта — получите готовый шаблон за 2–3 дня. Мы гарантируем, что ваш проект получит структуру, удобную для тестирования, а команда — рабочий процесс без лишнего оверхеда. Свяжитесь с нами для консультации.

Архитектура мобильных приложений

Приложение собрано в одном ViewController на 2000 строк. Сетевые вызовы, бизнес-логика, обновление UI — всё в одном месте. Добавить новую фичу без регрессии сложно, написать тест невозможно. Это не «плохой код» — это отсутствие архитектуры. И это встречается чаще, чем можно ожидать, даже в production-приложениях с миллионом пользователей.

Мы проектируем архитектуру под ключ: от выбора паттерна до полной структуры проекта с тестами и документацией. За 7–10 дней получаете чистый модульный код, готовый к масштабированию.

Архитектурные паттерны в мобайле решают одну задачу: отделить UI от логики так, чтобы каждая часть была тестируемой и заменяемой.

MVVM: базовый паттерн

Model-View-ViewModel — стандарт для iOS (SwiftUI + Combine/async, UIKit + Combine) и Android (Jetpack ViewModel + StateFlow + Compose). ViewModel содержит состояние UI и бизнес-логику. View только отображает состояние и передаёт намерения пользователя в ViewModel. Model — данные и их источник.

Ключевое правило: ViewModel не знает об UIKit или Android View-классах. Нет импортов UIKit, нет Context-зависимостей (кроме Application context через Hilt). Это гарантирует тестируемость: ViewModel тестируется как чистый Kotlin/Swift-код без Android Instrumented Test.

MVVM закрывает 70% потребностей. Остальные 30% — где нужна строгая изоляция фич, масштабирование команды, сложный flow управления состоянием.

Clean Architecture: когда MVVM недостаточно

Добавляет слои поверх MVVM:

Domain-слой — бизнес-логика, независимая от платформы. UseCase (или Interactor) содержит одно бизнес-правило: GetUserOrdersUseCase, PlaceOrderUseCase. Зависит только от интерфейсов (protocol/interface), не от конкретных реализаций.

Data-слой — реализация репозиториев. OrderRepositoryImpl реализует OrderRepository из domain. Знает про Retrofit, Room, UserDefaults. ViewModel не знает, откуда данные — из сети или кеша.

Presentation-слой — ViewModel + View. Знает о Domain, не знает о Data.

Dependency rule: зависимости направлены только внутрь. Domain не зависит ни от чего. Data и Presentation зависят от Domain.

Presentation → Domain ← Data

Это даёт возможность подменять реализацию: тест использует in-memory репозиторий вместо сетевого, интерфейс остаётся тем же.

Практическая оговорка: Clean Architecture добавляет файлы и слои. Для небольшого приложения это overhead. Оправдан от ~15 фич и при команде 3+ разработчиков.

BLoC для Flutter: предсказуемый поток состояний

BLoC (Business Logic Component) — стандартный паттерн в Flutter-сообществе. Библиотека flutter_bloc реализует его через два типа: Bloc (Event → State) и Cubit (State без Events, только методы).

Bloc обрабатывает Event и эмитирует новый State через on<EventType> хендлеры. Состояние иммутабельно — новый объект на каждое изменение. BlocBuilder перерисовывает только ту часть дерева, где изменился state.

// Event
abstract class CartEvent {}
class AddItemToCart extends CartEvent {
  final String productId;
  AddItemToCart(this.productId);
}

// State
abstract class CartState {}
class CartLoaded extends CartState {
  final List<CartItem> items;
  CartLoaded(this.items);
}

// Bloc
class CartBloc extends Bloc<CartEvent, CartState> {
  CartBloc(this._cartRepository) : super(CartLoaded([])) {
    on<AddItemToCart>(_onAddItem);
  }

  Future<void> _onAddItem(AddItemToCart event, Emitter<CartState> emit) async {
    final current = state as CartLoaded;
    final updated = await _cartRepository.addItem(event.productId);
    emit(CartLoaded(updated));
  }
}

Преимущество BLoC — тестируемость. blocTest из bloc_test пакета позволяет проверить: при таком-то Event, с таким-то начальным State, BLoC должен эмитировать такой-то State. Без UI, без моков для Flutter-фреймворка.

VIPER: для крупных iOS-проектов

VIPER (View, Interactor, Presenter, Entity, Router) — наиболее строгое разделение обязанностей для iOS. Каждый компонент имеет протокол и конкретную реализацию.

• View — только UI, делегирует всё Presenter
• Interactor — бизнес-логика, работа с сетью и данными
• Presenter — посредник между View и Interactor, форматирует данные для View
• Entity — модели данных (чистые структуры)
• Router — навигация между модулями

Каждый модуль (экран или фича) — отдельный VIPER-модуль. Это исключает coupling между фичами и позволяет большим командам работать параллельно без конфликтов.

Цена: много файлов, много протоколов. Шаблонный код генерируется через Sourcery или кастомные Xcode-шаблоны. VIPER оправдан для приложений с 10+ разработчиками и 50+ экранами.

TCA (The Composable Architecture)

TCA от Point-Free — более современная альтернатива VIPER для iOS/macOS. Основные концепции: State (иммутабельное состояние фичи), Action (все возможные события), Reducer (State + Action → новый State + Effect), Store (хранит State, обрабатывает Actions).

Scope позволяет composable строить большие фичи из маленьких: родительский Reducer делегирует часть State дочернему. Каждая фича тестируется изолированно через TestStore с точным контролем над Effects.

TCA имеет крутую кривую обучения, но даёт предсказуемость, которую сложно получить другим способом: каждое изменение состояния — явный Action с конкретным источником.

Какой паттерн выбрать под вашу задачу?

Оценим проект за 1 день — подберём архитектуру с учётом размера команды, платформы и планов роста.

Универсального ответа нет. Архитектуру выбирают под размер команды, требования к тестируемости и горизонт поддержки приложения.

Что входит в нашу работу

• Аудит текущей архитектуры (если приложение уже существует) — выявим узкие места и регрессионные зоны.
• Проектирование модульной структуры с чёткими границами слоёв и правилами зависимостей.
• Создание каркаса проекта (Scaffold) с внедрением DI, организации папок и настройки линтеров.
• Написание юнит-тестов для слоя домена и ViewModel — минимум 80% покрытия ключевых use case.
• Подготовка документации — архитектурные диаграммы, README с правилами модификации кода, инструкция для онбординга новых разработчиков.
• Передача рабочего репозитория с CI-пайплайном (GitHub Actions / Bitrise), настроенным запуском тестов и статическим анализом.

Всё это входит в стоимость проектирования. Дополнительно — поддержка на этапе внедрения: консультации команды, code review первых pull request.

Что происходит без архитектуры

Типичный сценарий через 18 месяцев без архитектуры: 40% времени разработки уходит на дебаг регрессий. Новый разработчик разбирается в коде неделю перед тем, как сделать первый PR. Тесты не пишутся, «потому что сложно мокировать». Добавление новой фичи требует понимания половины кодовой базы.

Выбор архитектуры на старте — это инвестиция с возвратом через 3–6 месяцев. По нашим данным, правильно спроектированная архитектура с MVVM + Clean даёт в 3 раза меньше регрессий по сравнению с монолитным ViewController. А затраты на её внедрение окупаются за 2–3 спринта.

Согласно рекомендациям Apple по проектированию приложений, разделение ответственности — ключевой фактор устойчивости кода (https://developer.apple.com/library/archive/featuredarticles/ViewControllerPGforiPhoneOS/ImplementingaViewController.html).

Почему стоит доверить архитектуру профессионалам?

Неправильный выбор паттерна на старте ведёт к переписыванию половины кода через год. Мы видели десятки проектов, где попытка сэкономить на архитектуре оборачивалась многомесячным рефакторингом. У нас за плечами 10+ лет коммерческой разработки, опыт работы с приложениями от 1 до 50 разработчиков. Мы помогаем избежать типовых ошибок:

• Overengineering для простого MVP (назначаем MVVM, а не VIPER).
• Отсутствие dependency injection — подключаем Hilt/Koin/Dagger уже на старте.
• Игнорирование тестируемости — закладываем протоколы/интерфейсы с первого коммита.

Оценим ваш проект бесплатно — пришлите описание текущего приложения или идеи, и мы подберём оптимальную архитектуру за 1 день. Пишите в Telegram или на почту — в ответ вы получите архитектурную схему, план внедрения и смету.

Дополнительная таблица: сравнение затрат на внедрение

Время указано для команды из 2–3 разработчиков. С нашим шаблоном (generator) стартовый каркас готов за 1 день вне зависимости от выбранного паттерна.