😄 Combine vs Async/Await

В долгоживущих проектах часто возникают проблемы с инструментами и архитектурами. Они имеют свойство накапливаться и перемешиваться. Старый код где-то на completion handlers, где-то на Promises, в старых вьюмоделях используется RxSwift, в относительно новых используется Combine, совсем новый код пишется на Async/Await.

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

В какой-то момент мы решили отказаться от зависимости на RxSwift и начали использовать Combine, а замыкания и промисы потихоньку стали переводить на Async/Await. Кажется, здесь все однозначно и понятно. Но что же выбрать между Async/Await и Combine?

Чем они отличаются концептуально?

🔹Async/Await это языковая модель структурированной конкуренции, встроенная в Swift. Она позволяет писать асинхронный код в линейном, последовательном стиле, максимально близком к синхронному.

- Структурированная конкуренция.
- Последовательный, линейный код.
- Легко читать как синхронный.
- Отлично ложится на модель «запрос → ответ».

Не сахар над completion handlers, а другая модель мышления, ориентированная на понятный контроль потока выполнения.

🔸Combine это фреймворк для реактивного программирования. Работа происходит не с одиночными результатами, а с потоками значений во времени.

- Реактивная парадигма.
- Работа с потоками значений во времени.
- Композиция, chaining, операторы (map, flatMap, retry, combineLatest).
- Подходит, когда данные изменяются непрерывно.

Не просто асинхронность, а реактивная архитектура.

Как осуществляется обработка ошибок и отмена задач?

🔹В Async/Await ошибки пробрасываются через throw, отмена через Task, поведение более очевидное.

🔸В Combine ошибки это часть stream’а, отмена через Cancellable, логика рассредоточена по цепочке операторов.

Почему нетворкинг это особый случай?

Большинство сетевых операций по своей природе не реактивны:

- один HTTP-запрос;
- один ответ;
- декодирование данных;
- возврат результата или ошибки.

🔹Async/await в этом контексте короче, проще, легче тестируется, проще обрабатывает ошибки через try/catch. Для сетевого слоя это даёт async/await преимущество в предсказуемости и прозрачности логики.

🔸Для такого сценария Combine часто избыточен, добавляет ненужную сложность, ухудшает читаемость.

С другой стороны Combine будет правильным выбором, если есть:

- WebSocket;
- live-updates;
- continuous streams данных;
- сложные зависимости между несколькими источниками данных;
- когда UI напрямую подписывается на поток изменений.

То есть там, где данные живут во времени, а не приходят один раз.

Какие выводы можно сделать?

Плохая идея использовать Combine и Async/Await вперемешку в одном сетевом слое. Лучше выбрать одну модель асинхронности для нетворкинга, чаще всего это будет Async/Await. Сombine стоит использовать выше по стеку (например, во ViewModel), если он нужен для реактивного UI.

Combine и Async/Await не конкуренты, а инструменты для разных задач.

📎 Combine vs Async/Await: Choosing the Right Concurrency Model for Networking

#D #Swift #Concurrency #Async #Combine

👏