Какой у вас опыт работы с архитектурой VIPER на iOS?

А, VIPER, говоришь? Ну, это как если бы обычный экран разобрали на запчасти и каждую деталь засунули в отдельный файл, блядь. Прям хирургическая операция, ёпта.

Смотри, суть в том, что он раскидывает всю эту кашу по пяти разным мискам, чтобы не было, как обычно, одного файла на тысячу строк, где и сетевые запросы, и обновление лейблов, и переходы на другие экраны — пиздец, а не класс.

Вот эти пять зверей:

1. View (Вьюшка). Это просто твоя верстка, кнопки, таблицы. Её задача — показывать, что скажут, и стучаться в презентер, когда пользователь тыкнул куда-то. Сама она нихуя не решает, тупая, как пробка.
2. Interactor (Интерактор, или "Мозг с данными"). Вот этот чувак — работяга. Он лезет в сеть, ковыряется в базе, хуячит сложную логику. Ничего не знает про интерфейс, только про бизнес-правила. Сухой, как сухарь.
3. Presenter (Презентер, или "Переводчик"). А это главный посредник, хитрая жопа. Интерактор ему скармливает сырые данные (Entity), а он их жуёт, переваривает и готовит красивые строки и модели для Вьюхи. "Получи, мол, показывай". И наоборот — от Вьюхи получает события и командует Интерактору: "Иди работай, чёрт!"
4. Entity (Сущность). Ну, это просто тупые структуры данных. id, title, date. Без логики, одни голые поля. Как мешки с картошкой.
5. Router (Роутер, или "Проводник"). Его задача — таскать пользователя между экранами. "Нажал кнопку — пошёл нахуй отсюда, вот тебе следующий модуль". Вся навигация через него.

Как это, блядь, работает в коде (смотри, не усни):

// Presenter - тут начинается цирк
final class ArticlePresenter {
    weak var view: ArticleViewInput? // Ссылка на вьюху
    private let interactor: ArticleInteractorInput // Ссылка на мозг
    private let router: ArticleRouterInput // Ссылка на проводника

    func viewDidLoad() {
        // Вьюха загрузилась? Отлично, командуем мозгу: "Работай!"
        interactor.fetchArticle()
    }
}

// Interactor - тут реальная работа
final class ArticleInteractor {
    func fetchArticle() {
        // Тут сетевой запрос, работа с БД, пиздец какой-то
        // Получили сырые данные...
        let entity = ArticleEntity(id: 1, title: "...")
        // И плюёмся ими в презентер: "На, разбирайся!"
        presenter.didFetchArticle(entity)
    }
}

Плюсы, блядь, очевидны:

• Всё по полочкам. Один файл — одна обязанность. Не будет такого, что ты ищешь, где сраный алерт показывается, а он затерялся между парсингом JSON и анимацией.
• Тестировать — одно удовольствие. Хочешь проверить логику? Тестируй интерактор, подсунув ему фейковый сетевой слой. Хочешь проверить, что показывается? Тестируй презентер с моковой вьюхой. Всё изолированно, красота.
• Для больших проектов и команд — овердохуища. Один пишет вьюхи, другой — бизнес-логику, третий — навигацию. Не мешают друг другу.

Но минусы, сука, тоже в глаза колются:

• Бойлерплейта — хуева туча. Для экрана с одной кнопкой нужно создать штук 5-6 файлов: вью, презентер, интерактор, роутер, куча протоколов... Пока всё опишешь, уже и задача не актуальна.
• Для мелких проектов — это как из пушки по воробьям. Оверкилл полный. Тратишь 80% времени на архитектуру, а не на фичу.

Лично я его применял в здоровенных банковских приложениях, где над одним модулем могло человек пять работать. Там он реально спасал от хаоса. Но если делаешь пет-проект или стартап — забей, нахуй. Там MVVM или даже классический MVC с умной головой чаще всего выигрывают по скорости. VIPER — это инструмент для взрослых, сложных игрушек, а не для песочницы.