Эта статья — не ревью чужого кода и не пересказ абстрактных паттернов. Это практическое описание того, как я подхожу к проектированию сетевого слоя, какие решения считаю удачными, какие — опасными, и почему. Основа текста — реальный подход к построению сети в production iOS-приложении: с явной EndpointPolicy, RequestContext, interceptor-pipeline, безопасным логированием, отдельной обработкой refresh flow, snapshot-first чтением и выделенным transport для долгих upload-сценариев.

Мой главный тезис простой: сетевой слой — это не “место, где отправляются запросы”, а инфраструктура приложения. URLRequest и URLSessionConfiguration в Foundation уже работают как объекты, которые несут не только URL, но и правила поведения запроса; Swift Concurrency даёт структурированную асинхронность и безопасную модель доступа к разделяемому состоянию через actors. На практике это значит, что retry, auth, timeout, cache, logging и metrics лучше проектировать как часть контракта, а не как случайный набор if внутри одного большого send(). 

Если сжать статью до одного абзаца, получится так: я начинаю не с URLSession, а с вопросов кто имеет право знать о transport, где живёт policy, кто отвечает за retry, как не утечь токенами в логах, где source of truth для UI и как выяснить, что именно сломалось в production. Всё остальное — код вокруг этих решений.