С какими проблемами можно столкнуться при подключении к удалённому серверу в iOS

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

Знаете ли вы, что мобильная сеть это не локальный стенд: она рвётся, переключается и молчит. Смотрят, работали ли вы с URLSession руками, помните ли про требования системы к транспорту и что делаете с ошибкой, кроме показа сообщения.

Как отвечать

Перечислите проблемы и сразу то, чем закрываете каждую:

• обрывы и смена сети. URLError.networkConnectionLost прилетает при переходе с Wi-Fi на сотовую, .notConnectedToInternet в туннеле. Разные коды требуют разного поведения: одно повторяется молча, другое показывается пользователю;
• таймауты. В URLSessionConfiguration их два: timeoutIntervalForRequest на паузу в передаче и timeoutIntervalForResource на всю операцию целиком. Значения по умолчанию для мобильного приложения великоваты;
• транспорт. Требования ATS не выпустят запрос по обычному HTTP или к серверу со слабым TLS, и стенд с самоподписанным сертификатом отваливается именно поэтому;
• пиннинг. Делается в делегате сессии и требует запасного ключа: истёкший пин ломает приложение сразу у всех, а обновиться можно только релизом;
• авторизация. Протухший токен прилетает на десяток параллельных запросов одновременно, обновлять его нужно одной задачей, остальные ждут её результата;
• фон. Обычная сессия умирает вместе с уходом приложения в фон, долгие загрузки живут в фоновой конфигурации сессии.

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

Проверяют работу только на офисном Wi-Fi. Network Link Conditioner, авиарежим и обрыв на середине загрузки находят больше дефектов, чем все остальные проверки вместе.

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

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