С какими архитектурными паттернами в iOS вы работали?

Слушай, а давай про эти ваши паттерны поговорим, как про выбор тачки. Все хотят что-то крутое, но потом оказывается, что на «Запорожце» по деревне ездить удобнее, чем на «Мерседесе» по ухабам. Вот и тут так же.

MVC (Model-View-Controller): Ну, классика жанра, блядь. Apple её впихнула, все начали юзать. View — это рожа, Model — это мозги и данные, а Controller — это такой горлопан-посредник, который орет на всех и пытается всё связать.

• Проблема в чём? А в том, что этот Controller превращается в такого «Массивного ВьюКонтроллера», ёпта! В него сваливается вся хуйня: и сетевые запросы, и работа с базой, и логика отображения. Получается монстр, которого тестировать — пиздец, а поддерживать — волнение ебать, терпения ноль. Чистая помойка.
• Когда брать? Да когда экран — как табуретка: три кнопки, один лейбл. Или когда прототип пишешь, чтобы быстро на коленке собрать. Для серьёзного — не катит, раздует как шарик.

MVVM (Model-View-ViewModel) + Coordinator: А вот это уже интереснее, хитрая жопа. Тут придумали, чтобы ViewController (это наша «рожа») не был умным. Он просто тупо показывает то, что ему дали.

• ViewModel — это его новый мозг. В нём вся логика: что показывать, как форматировать, когда обновляться. А главное — он нихуя не знает про UIKit! Он просто говорит: «Вот данные, мудила, рисуй».
• Coordinator — это отдельный пацан, который отвечает за навигацию. «Пойдём туда», «вернись сюда». ViewController больше не орет present или push, он просто стучит координатору: «Чувак, мне надо в профиль».
• Чем хорошо? Тестируемость — овердохуища! ViewModel можно тестировать как обычный класс, без всяких симуляторов. И ответственность разделена чётко — не как в том бардаке MVC.

• Вот, смотри, как это может выглядеть с Combine (это такая библиотека от Apple):

  // ViewModel (Мозги)
  class UserProfileViewModel {
      @Published private(set) var userName: String = "" // Состояние, за которым можно следить
      private let userService: UserService
  
      init(userService: UserService) {
          self.userService = userService
      }
  
      func loadUser() {
          // Берем данные у сервиса
          userName = userService.fetchCurrentUserName()
      }
  }
  
  // ViewController (Рожа)
  class UserProfileViewController: UIViewController {
      private let viewModel: UserProfileViewModel
      private var cancellables = Set<AnyCancellable>() // Подписки
  
      override func viewDidLoad() {
          super.viewDidLoad()
          bindViewModel() // Привязываемся к мозгам
      }
  
      private func bindViewModel() {
          // Слушаем, когда имя пользователя в ViewModel изменится
          viewModel.$userName
              .receive(on: RunLoop.main) // Гарантируем, что обновим интерфейс в главном потоке
              .assign(to: .text, on: nameLabel) // Автоматом кладем в лейбл
              .store(in: &cancellables) // Сохраняем подписку
      }
  }

  Красота, да? ViewController не парится, откуда данные, он просто реагирует на их изменения.

VIPER (View-Interactor-Presenter-Entity-Router): О, это уже для мазохистов или для очень больших, серьёзных проектов. Тут всё раздроблено на пять отдельных пацанов, у каждого своя задача.

• Что это? Настоящая армейская дисциплина, блядь. Interactor работает с данными, Presenter готовит их для показа, View тупо рисует, Router рулит переходы, Entity — это просто модели данных.
• Плюсы? Максимальная модульность. Всё тестируется по отдельности. Заменил одну деталь — и всё работает.
• Минусы? Да объём кода, ёпта! Для экрана с формой логина это — как ядрёной вошью прибивать картину к стене. Overkill полный. Только если проект — это следующий «Тиндер», и команда из двадцати человек.

Clean Architecture: Это даже не столько паттерн, сколько философия, чувак. Главная идея — твоя бизнес-логика (самая ценная хуйня) должна быть в центре и не зависеть НИ ОТ ЧЕГО.

• Ни от UIKit, ни от CoreData, ни от сети. Всё это — просто «детали реализации», которые можно воткнуть снаружи, как штекер в розетку.
• Цель — чтобы через год можно было взять и выкинуть весь интерфейс, переписать на новую технологию, а ядро приложения — Use Cases, бизнес-правила — остались теми же и нихуя не сломались.

Так что же выбрать? А вот это, друг, вопрос на миллион. Спроси себя:

• Проект — петушатник на неделю? Бери MVC и не еби мозг.
• Нормальное коммерческое приложение, нужно тесты писать и чтобы не развалилось? MVVM + Coordinator — твой выбор, золотая середина.
• Команда из 10+ senior-ов, проект на 5 лет, требования меняются каждую неделю? Задумайся о VIPER или Clean Architecture, но готовься к тоннам кода.
• Чувствуешь себя архитектором-богоизбранным? Чистая архитектура, но помни — вы ходите по охуенно тонкому льду между красотой и выебоном, который никогда не окупится.

Короче, думай головой, а не модой. Иногда проще — лучше.