Это происходит каждый день: метро, лифт, самолёт, поле. Пользователь открывает приложение, а оно показывает спиннер, затем «Проверьте соединение» — и работа встала. 📡 Кажется, мелочь. Но для команды это потерянные сессии, злые отзывы в сторах и рост нагрузки на поддержку. Дальше — самое интересное: почему обычные ретраи и «попробуй ещё раз» ситуацию только ухудшают.

Развитие простое: сеть — не исключение, а норма. Мобильный клиент живёт там, где связь то появляется, то пропадает. Если архитектура рассчитана на «онлайн всегда», любая просадка превращается в баг. Команды лечат симптомы: увеличивают таймауты, добавляют повторные запросы, кэшируют экраны локально. Но без явной модели деградации это хаки, которые ломаются в самый неподходящий момент — при релизе или в пиковой нагрузке.

А теперь важная часть: offline-first — это не «режим оффлайн», а архитектурная модель. Мутации сначала попадают в локальную очередь (outbox), потом синхронизируются с сервером. Хранилище — MMKV или SQLite — становится источником правды, а не кэшем «на всякий случай». И главный подводный камень — конфликты: два устройства изменили одни и те же данные, а merge не готов заранее. Мало кто думает об этом на этапе проектирования — и потом переделывает всю сетевую прослойку.

Вывод: устойчивый клиент — это не набор костылей, а спроектированная цепочка: outbox, хранилище, дельты, метрики sync health, chaos-сценарии сети. Курс Offline-first и сеть разбирает её от NetInfo до обработки 401/429/timeout и merge-конфликтов. Первый модуль бесплатно. Подписывайся на канал, чтобы не пропустить следующее.