Работали ли с сетями

Что проверяют

Сеть в мобильном приложении это не про умение сходить по URL, а про поведение в плохих условиях: обрыв, таймаут, переключение на сотовую связь, уход экрана во время запроса. Интервьюер хочет понять, строили ли вы сетевой слой целиком или дёргали готовый клиент из вьюконтроллера.

Как отвечать

Расскажите про архитектуру слоя, а не про одну функцию.

• Основа: URLSession с async/await, try await session.data(for: request), декодирование через Codable. Alamofire уместен, но надо объяснить, что именно он у вас закрывал.
• Описание запросов: отдельный тип эндпоинта с путём, методом и телом, чтобы строки URL не расползались по экранам.
• Ошибки: три разных случая, транспортная ошибка URLError, код ответа 4xx и 5xx с телом ошибки от бэкенда, и ошибка декодирования. Пользователю они показываются по-разному.
• Конфигурация: таймауты в URLSessionConfiguration, waitsForConnectivity, фоновая сессия для больших загрузок, кэш через URLCache и заголовки валидации.
• Отмена и гонки: задача отменяется при закрытии экрана, иначе поздний ответ перезапишет свежие данные.
• Авторизация: обновление токена делается одним запросом на все параллельные, с повтором исходных после успеха.
• Тесты: подменённый URLProtocol отдаёт заготовленные ответы, включая ошибки и задержки.

Где спотыкаются

Обновляют интерфейс не с главного потока. В колбэчном URLSession завершение приходит на своей очереди, и без возврата на главный актор UI ведёт себя непредсказуемо.

Считают запрос успешным по отсутствию ошибки. Ответ с кодом 500 приходит без error, тело не парсится, и приложение показывает пустой экран вместо внятного сообщения.

Третье: повторяют запросы вслепую. Ретрай без разбора кода ошибки и без учёта идемпотентности создаёт дубли заказов, а мгновенные повторы подряд добивают уже перегруженный сервер.