Когда в Combine нужно явно оборачивать UI-обновления в DispatchQueue.main.async?

В большинстве случаев — никогда. Combine предоставляет операторы для управления потоками, и явный DispatchQueue.main.async обычно избыточен или даже вреден.

Правильный подход: Используйте операторы receive(on:) и subscribe(on:) для управления доставкой событий на нужных очередях.

// ✅ ПРАВИЛЬНО: Используйте оператор receive(on:)
networkPublisher
    .map { ... } // Тяжелая обработка в фоновом потоке
    .receive(on: DispatchQueue.main) // Переключаемся на главный поток
    .sink { [weak self] data in
        self?.updateUI(with: data) // UI-обновление гарантированно на главном потоке
    }
    .store(in: &cancellables)

Когда DispatchQueue.main.async всё же может понадобиться:

1. При интеграции с callback-based API, которые не используют Combine.
2. Внутри обработчика sink, если вы выполняете побочный эффект, который должен быть на главном потоке, но издатель (Publisher) не гарантирует этого (например, PassthroughSubject, отправляемый из фонового потока).

// ⚠️ СЛУЧАЙ ДЛЯ ЯВНОГО ОБОРАЧИВАНИЯ: Callback-based API
legacyAPI.fetchData { result in
    DispatchQueue.main.async { // Явное переключение
        self.label.text = "Data received"
    }
}

Ключевой принцип: Операторы receive(on:)/subscribe(on:) — это декларативный и тестируемый способ управления потоками в реактивном пайплайне. Явный DispatchQueue.main.async — это императивное вмешательство, которое усложняет понимание потока данных.