Як працює offline-режим в мобільних додатках

1) Що таке offline-режим і навіщо він потрібен

Offline-режим - це здатність програми працювати без мережі (або при нестабільному інтернеті), а потім синхронізуватися, коли зв'язок з'являється. Він:

знижує відмови і підвищує утримання;
прискорює перший екран (дані вже локально);
дозволяє виконувати критичні дії (чернетки, перегляд контенту, частина операцій) «в полі».

2) Шари офлайн-архітектури (в будь-якому стеку)

1. Локальне сховище даних

Мобільні нативні: SQLite/Room (Android), Core Data/SQLite (iOS), Realm, Key-Value (SharedPreferences/UserDefaults).

Веб/PWA: IndexedDB (поверх - Dexie/LocalForage), Cache Storage для статики.

2. Кеш статики (App Shell)

Іконки, шрифти, CSS/JS, базові шаблони екранів.

3. Черга операцій (Outbox)

Запити «на запис» (створити/змінити/видалити) складаються в чергу і йдуть на сервер при появі мережі.

4. Шар синхронізації

Політики мерджа, версії, дедуплікація, ретраї, бекофф.

5. Сигнали стану мережі

NetInfo/Reachability/API браузера для перемикання UI між online/offline/limbo.

3) Як це виглядає на iOS/Android

Кеш і БД: структура даних дзеркалить основні API-відповіді (нормалізуйте сутності).

Офлайн-чернетки: форми і дії пишуться в локальну БД з прапорами'pending/sent/failed'.

Синхронізація: фонова задача періодично читає outbox і відправляє партії (batch), позначаючи статус.

Безпека: секрети/токени - в Keychain (iOS )/Android Keystore. Дані з PII/платежами шифруються (наприклад, AES-256 GCM) ключем із захищеного контейнера.

Обмеження ОС: фонові завдання залежать від режимів енергозбереження; плануйте ідемпотентність запитів і відновлення після вбивства процесу.

4) Як це працює в PWA (веб)

Service Worker (SW) - проксі між мережею і додатком:

Precache (App Shell): інтерфейс доступний моментально.
Runtime cache: дані/медіа за стратегіями нижче.
Background Sync/Periodic Sync (де доступно): відправка черги, оновлення кешу без участі користувача.
IndexedDB для даних і Cache Storage для статики.
Обмеження: квоти зберігання, жорсткий контроль фонових завдань (особливо iOS Safari).

5) Стратегії кешування (що і коли застосовувати)

Cache First - для незмінної статики (іконки, шрифти, версії JS).

Stale-While-Revalidate (SWR) - для списків/каталогів: миттєво з кеша, фоном підтягнути свіжі дані.

Network First - для особистих даних, коли мережа є; бекап - з кешу при офлайні.

Cache Only/Network Only - рідкісні приватні випадки (діагностика, приватні ресурси).

Комбінуйте: статика - CF/SWR; динаміка - SWR/NF; записи - через чергу.

6) Черга змін та ідемпотентність

Outbox-модель: кожна дія (POST/PUT/PATCH/DELETE) серіалізується в запис черги з тимчасовим ID, тілом, версією і дедлайном.

Відправка пакетами (batch) з експоненціальним backoff при помилках мережі/сервера.

Ідемпотентні ключі в заголовках/ендпоінтах - повторна відправка не створить дублів.

Транзакції БД: запис у чергу та оновлення локального стану повинні бути атомарними.

7) Вирішення конфліктів (server vs client)

Підходи:

Last Write Wins (LWW) - просто, але ризик втрати правок.
Версіонування/ETag - сервер відхиляє застарілі версії → клієнт робить merge/пересбереження.
Операційні трансформації/CRDT - для спільного редагування складних сутностей.
Правила по полях - які поля «істина» на сервері, які - у клієнта (наприклад, локальні мітки/прапори).

UX:

Показуйте бейдж «не синхронізовано», кнопку «оновити», і дифф при конфлікті (щоб вибрати версію).

8) Робота з медіа та важкими ресурсами

Дедуплікація і хеші (content-addressable) - не вантажте однакове.

Плейсхолдери/мініатюри офлайн, повна версія - після мережі.

Черга завантажень з паузою при поганій мережі/акумуляторі.

Політика TTL для кешу медіа - не збирайте гігабайти.

9) UX-патерни, щоб офлайн був «людяним»

ТОП-правило: ніколи не показуйте «порожнечу». App Shell + skeleton + остання валідна версія контенту.

Чіткі статуси: Online/Offline/Синхронізація .../Потрібна дія.

Undo/Retry: скасування останньої офлайн-дії; автоматичний і ручний повтор.

Локальні чернетки: видимі списки «Очікує відправки».

Тихі помилки: агресивно не турбуйте - досить ненав'язливих індикаторів + журнал.

10) Безпека і приватність в офлайні

Шифруйте чутливі дані «на диску»; ключі - в Keystore/Keychain.

Мінімізуйте збір/зберігання PII офлайн; задайте ретеншн і авто-очищення.

Ніколи не кешуйте секрети/повні PAN/CVV; токени платіжних провайдерів - тільки за правилами PCI.

Захистіть SW/клієнт від XSS (CSP, SRI), інакше атакуючий зможе вкрасти офлайн-дані при наступному онлайні.

11) Обмеження платформ

iOS: суворі ліміти фонових завдань в браузері; Web Push/periodic sync - з нюансами; Keychain - надійно для секретів.

Android: гнучкіші фонові сервіси (WorkManager), але OEM-оптимізації можуть «вбивати» завдання - розмічайте як «важливі».

PWA: квоти IndexedDB/Cache Storage, очищення системою без попереджень при нестачі місця.

12) Тестування офлайну

Мережеві профілі (Airplane, 2G/3G, packet loss, high RTT).

Kill/restore процесу під час синку.

Chaos-тести: половина батча падає 429/503/timeout.

Конфлікти: паралельні правки з двох пристроїв.

Квоти сховища: заповнити диск, перевірити поведінку кеша.

13) Метрики і спостережуваність

Time To First Offline View (TTFOV): швидкість появи App Shell.

Offline coverage: частка екранів/операцій, доступних без мережі.

Outbox health: довжина черги, середній час до синка, частка помилок.

Коефіцієнт конфліктів і частка ручних мерджів.

Квота/використання сховища, частота очищень ОС.

User impact: сесії, розпочаті без мережі → конверсія після синку.

14) Швидкий план впровадження (90 днів)

1. Визначити скоп офлайну: які екрани читаються з кеша, які операції можна відкласти.

2. Вибрати БД і схему: нормалізовані таблиці, індекси, версії.

3. Включити App Shell: PWA SW/кеш статик/іконки/шрифти.

4. Зібрати Outbox: черга, ідемпотентність, бекофф, батчі.

5. Стратегії кешу: SWR для списків, Network First для персональних даних.

6. UX статусів + журнал синя, retry/undo.

7. Безпека: шифрування на диску, CSP/SRI, мінімізація PII.

8. Тести під погану мережу, хаос-тести і метрики.

15) Часті помилки і як їх уникнути

«Офлайн» тільки для статики. → Потрібні чернетки і outbox, інакше цінність мала.

→ Дублі операцій при ретраях. Введіть ідемпотентні ключі.

Приховані конфлікти → Користувач втрачає правки. Показуйте дифф/решалку.

Без TTL і очищення кеша. → Додаток розпухає, ОС чистить примусово.

Синк блокує UI. → Синхронізація завжди в фоні, UI - чуйний.

Зберігання секретів у відкритому вигляді. → Використовуйте Keychain/Keystore і шифрування.

16) FAQ

Чи можна зробити «повний» офлайн для всього?

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

Що швидше: SWR або Network First?

SWR дає миттєву відповідь з кешу і тихе оновлення - кращий UX для списків. Network First потрібен там, де важлива свіжість (профіль, баланс).

Як зберігати великі медіа?

Кешуйте мініатюри і недовгий TTL, оригінали - за запитом, з очищенням LRU.

Чи потрібно шифрувати все?

Шифруйте PII/секрети і чутливі записи. Решта - щодо політики ризику і квот.

Офлайн погіршить SEO/PWA?

Ні, при правильному SW і SSR навпаки поліпшить швидкість і повторні візити.

Офлайн-режим - це не «галочка», а системна архітектура: локальна БД + кеш статики + черга змін + надійний синк і продуманий UX статусів. Додайте безпеку (шифрування, Keychain/Keystore), ідемпотентність і метрики, протестуйте погану мережу - і ваш додаток залишиться корисним навіть без інтернету, а при його появі безшовно наздожене сервер, не втрачаючи дані і довіру користувача.