Страница Notion открывается офлайн. Задача, ради которой она нужна, — уже нет: вложенную страницу забыли загрузить, нужная запись базы не попала в доступные строки. Формально режим работает. Для человека работа остановилась.

У Яндекс Карт граница другая. Скачанная карта позволяет построить маршрут без интернета, но пробки и дорожные события требуют связи. Если выездному специалисту на день назначены несколько объектов, ему нужны не просто «офлайн-карты», а адреса, задания, схемы оборудования и подходящие области карты. Прогноз дорожной обстановки при этом остаётся живой информацией; выдавать старый снимок за актуальный нельзя.

Можно скачать карту города и всё равно остановиться перед третьим заказом, если схема оборудования не попала на устройство. Готовность проверяется по всей задаче, а не по одному загруженному файлу.

Поэтому вопрос «делать ли offline-first?» слишком крупный. Полезнее спросить: **какую работу человек сможет закончить, когда связь исчезнет?** В Notion можно представить подготовку конкретного проекта: нужные страницы, задачи и файлы, а перед отключением — проверку, что вошло в локальную копию и что осталось недоступным. Это проектная гипотеза, не существующая функция сервиса. Её цена — хранение, обновления и изменение прав доступа. Obsidian решает другую задачу: заметки уже лежат в локальных файлах, зато синхронизация и резервная копия становятся отдельной ответственностью.

Есть действия, которые нельзя честно объявить завершёнными локально. В торговой точке касса Эвотор может напечатать чек при временном отсутствии интернета и отправить сведения оператору фискальных данных позже. Но это не означает, что любой платёж картой уже подтверждён: Т‑Банк требует дождаться отметки «Одобрено» от терминала. Подготовленная корзина, сформированный чек, передача его сведений и банковское подтверждение — разные события. В статье это примеры отдельных частей процесса, не проверенная связка устройств.

Даже продукт, зависящий от сервера, не должен превращать каждый жест в сетевой запрос. Figma сохраняет возможность править уже загруженную страницу после обрыва связи, хотя новые библиотечные компоненты и изменения коллег будут недоступны. Ценность совместного состояния не равна обязанности ждать сервер после каждого движения объекта.

Практическая проверка для своего продукта короткая: что пользователь считает завершённой работой; какие данные можно подготовить заранее; как быстро они устаревают; что произойдёт при позднем отказе; как восстановиться после потери устройства. Ответы могут отличаться между двумя экранами одного приложения. Архитектура должна следовать из этой разницы, а не из верности ярлыку `offline-first` или «всё онлайн».

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

Это анализ опубликованного поведения сервисов, не отчёт об испытании оборудования или Flutter-приложения. Полный разбор: ArkTelos Lab. Об экосистеме — ArkTelos. Каналы: Lab RU | Lab EN.