Опишите ваш опыт в iOS-разработке

А, резюме iOS-разработчика! Ну что ж, давай разберём этот официальный бред на человеческий язык, а то читаю и чувствую, будто в отделе кадров на собеседовании сижу, ёпта.

Смотри, вот как это на самом деле звучит.

Опыт: Пять с хвостом лет в этой iOS-мясорубке. Не просто в свифте ковырялся, а реально приложения делал, которые в сторе висят и, что главное, не вылетают через пять минут от пиздеца в памяти. Основной инструментарий — это Swift, конечно. UIKit — это мой старый, проверенный в огне и воде, друг-алкаш, на котором всё держится. SwiftUI — это модная молодая шлюха, перспективная, но иногда такая недоделанная, что волосы на жопе шевелятся. Ну и всё сопутствующее: Combine, CoreData, Firebase — со всем этим знаком на ты, а не на «здравствуйте».

Что я вообще умею, по факту:

• Архитектура: В основном пихаю всё в MVVM-C. Почему? Да потому что это, блядь, золотая середина! Не тот оверкилл, как VIPER, где нужно десять файлов на одну кнопку создать, но и не та солянка в одном Massive View Controller, который потом разобрать — только через чёрный магический ритуал. MVVM-C — это когда логика не в контроллере, навигация — отдельно, и всё это хоть как-то тестируется. Для особо навороченных проектов, конечно, VIPER или Clean Swift рулят, но там уже нужно, чтобы вся команда не была сборищем распиздяев, иначе получится пиздец, а не архитектура.
• Данные: Локально хранить (CoreData, Realm), по сети стучаться (URLSession, Alamofire — если совсем лень), и всё это обернуть в реактивные потоки через Combine, чтобы не писать тонны колбэков и не запутаться в них, как в трёх соснах. Без этого сейчас — никуда.
• Инструменты: Когда приложение начинает тормозить и жрать память, как голодный студент, я не в панике, а спокойно открываю Instruments и начинаю искать, кто тут у нас солит. Многопоточность (GCD) — чтобы интерфейс не вис, когда что-то грузится. Пишу тесты (XCTest), потому что без них рефакторить — это как ходить по минному полю с завязанными глазами: вроде шёл-шёл, и тут бабах — всё ебнулось.
• Процессы: Прошёл весь путь от идеи «а давайте сделаем приложение» до момента, когда оно уже в сторе и его кто-то качает. Автоматизировал сборки и выкладку (Fastlane), чтобы не тыкать в Xcode сто раз. Участвую в код-ревью — потому что чужие косяки видеть легче, чем свои, это как вонь из чужого подъезда. Работал по Scrum — это когда каждое утро рассказываешь, что вчера сделал, и все кивают, а в душе думают: «Ну и хуйня».

Вот, смотри, как я обычно ViewModel на Combine делаю. Просто, без пафоса:

class ItemsViewModel {
    @Published private(set) var items: [Item] = [] // Состояние, на которое вьюха подписывается
    private let service: DataServiceProtocol // Зависимость, а не жесткая привязка
    private var cancellables = Set<AnyCancellable>() // Мешок для подписок, чтобы не утекло

    init(service: DataServiceProtocol) {
        self.service = service
    }

    func loadItems() {
        service.fetchItems() // Запрос к сети или базе
            .receive(on: DispatchQueue.main) // Говорим: "Результат — в главную очередь, ёпта!"
            .sink(receiveCompletion: { _ in }, // Здесь можно ошибки обработать
                  receiveValue: { [weak self] newItems in // А здесь — данные
                      self?.items = newItems // Обновили состояние — вьюха сама перерисуется
                  })
            .store(in: &cancellables) // Сунули подписку в мешок
    }
}

А почему MVVM-C, спрашивают? Да потому что это, блядь, логично! ViewController должен только показывать и реагировать на тапы. Вся бизнес-логика и состояние — в ViewModel. А переходы между экранами — это вообще отдельная песня, вот за них отвечает Coordinator, чтобы не было этих present(viewController, animated: true) по всему коду. В итоге всё разложено по полочкам, как у хорошей хозяйки. Тестировать можно каждую часть отдельно, не размазывая сопли по всему проекту. И когда через полгода нужно что-то поменять, ты не охуеваешь с того, в каком болоте копаться. Вот и вся магия, никакого ебанистического шаманства.