PWA или приложение из магазина

У приложения автора веб-версия живёт на подпути /app, и собирает её одна команда — в package.json она записана скриптом export:web. Мы её выполнили:

$ npx expo export --platform web --output-dir dist-web

В dist-web легли 42 файла. Вот они, с пометками, откуда что взялось:

dist-web/
  index.html  login.html  register.html  profile.html  forgot-password.html
  +not-found.html  _sitemap.html  (auth)/  (main)/  notes/
  _expo/static/js/web/entry-bbe441cf9b0b0e50a999c4ee749beebd.js
  assets/
  manifest.webmanifest   sw.js                      # из public/, байт в байт
  icon-192.png  icon-512.png  icon-maskable-512.png  apple-touch-icon.png
  icon.svg  favicon-32.png                           # тоже из public/
  favicon.ico                                        # единственная картинка, которую сделал экспорт

Это обычный статический сайт: по файлу на маршрут (в конфиге web.output: "static"), один бандл с хешем в имени и картинки. Никакого сервера ему не нужно — у автора его отдаёт Caddy из тома, в который образ сборки выкладывает готовую статику. Папка public/ при этом копируется целиком: в @expo/cli за это отвечает copyPublicFolderAsync, и мы сверили файлы побайтно — manifest.webmanifest и sw.js в экспорте ровно те же, что в public/. Страницы маршрутов и бандл экспорт, конечно, собрал сам, а вот из картинок сделал ровно одну — favicon.ico из поля web.favicon; его разобрала прошлая статья.

А теперь главное — чего в этой команде нет. Ни манифеста, ни service worker Expo не создаёт. Это легко принять на веру неправильно, поэтому проверим по установленному пакету, а рядом поставим контрольное слово, которое там точно есть:

$ find node_modules/@expo/cli -type f | wc -l
$ grep -rl serviceWorker node_modules/@expo/cli | wc -l
$ grep -rl workbox node_modules/@expo/cli | wc -l
$ grep -rl favicon node_modules/@expo/cli | wc -l     # контроль: это слово там есть

Восемьсот с лишним файлов, и ни одного упоминания service worker или workbox. Значит, PWA из веб-сборки Expo делаете вы: манифест, воркер и его регистрация — ваши файлы. У автора они лежат в public/ и потому доезжают до dist-web сами. Манифест целиком:

{
  "name": "Приложение",
  "short_name": "Приложение",
  "description": "Заметки: пишите свои, читайте опубликованные",
  "lang": "ru",
  "start_url": "/app/",
  "scope": "/app/",
  "id": "/app/",
  "display": "standalone",
  "orientation": "portrait",
  "background_color": "#ffffff",
  "theme_color": "#171717",
  "icons": [
    { "src": "/app/icon-192.png", "sizes": "192x192", "type": "image/png", "purpose": "any" },
    { "src": "/app/icon-512.png", "sizes": "512x512", "type": "image/png", "purpose": "any" },
    { "src": "/app/icon-maskable-512.png", "sizes": "512x512", "type": "image/png", "purpose": "maskable" }
  ]
}

Главные поля этого файла разобраны в статье части II «Манифест и установка на экран»; здесь важно одно: он написан руками и лежит рядом с иконками, которые прошлая статья готовила для телефона. Регистрация воркера тоже своя — строкой в шаблоне страницы:

// src/app/html/html.tsx: скрипт уезжает в <head> каждой страницы экспорта.
// Он написан строкой, а не модулем: должен отработать до гидратации, иначе
// первый заход не попадёт под контроль воркера.
if ("serviceWorker" in navigator) {
  window.addEventListener("load", function () {
    navigator.serviceWorker.register("/app/sw.js", { scope: "/app/" }).catch(function () {
      /* без воркера приложение просто работает как обычный сайт */
    });
  });
}

Мы нашли этот скрипт в собранном dist-web/index.html — он попадает в каждую страницу экспорта. Механизмы (жизненный цикл воркера, стратегии кеша, обновление) — глава части II; здесь нас интересует другое: если экран и логика те же, что на телефоне, то что из модулей «Подхода» переживает переезд в браузер?

Ответ даёт реестр модулей из статьи «Модуль — это запись в реестре»: он в подложке, и registerWebModule кладёт в него веб-реализацию, а requireOptionalNativeModule её оттуда достаёт. Настоящие пакеты Expo в предпросмотр не собираются вовсе — expo-modules-core тянет TurboModuleRegistry, которого у react-native-web нет, — поэтому веб-файлы модулей ниже переписаны по исходникам SDK 57, с теми же именами и теми же текстами. Соберём перепись трёх способностей «Подхода»: обновление по воздуху, токен синхронизации в SecureStore и звонок таймера отдыха. Прогноз перед запуском: какая из трёх работает в браузере, какая молча отвечает «нечего делать», а какая падает?

// из подложки — реестр модулей Expo из статьи «Модуль — это запись в реестре»
declare class NativeModule {}
declare function registerWebModule<T extends NativeModule>(Impl: new () => T, moduleName?: string): T;
declare function requireOptionalNativeModule<T>(name: string): T | null;

// expo-modules-core 57 · errors/UnavailabilityError.ts: текст сообщения дословно
class UnavailabilityError extends Error {
  constructor(moduleName: string, propertyName: string) {
    super(`The method or property ${moduleName}.${propertyName} is not available on web, are you sure you've linked all the native dependencies properly?`);
  }
}

// ExpoUpdates.web.ts из expo-updates 57: веб-реализация есть, сокращена до одного метода
class ExpoUpdates extends NativeModule {
  isEnabled = true;
  async checkForUpdateAsync(): Promise<{ isAvailable: boolean; reason: string }> {
    return { isAvailable: false, reason: "noUpdateAvailableOnServer" };
  }
}
registerWebModule(ExpoUpdates, "ExpoUpdates");

// ExpoSecureStore.web.ts — весь файл целиком
const ExpoSecureStore: Record<string, unknown> = {};

// NotificationScheduler.ts — файл без .native, тоже целиком
const NotificationScheduler: Record<string, unknown> = { addListener: () => {}, removeListeners: () => {} };

// scheduleNotificationAsync.ts проверяет метод, а не платформу
async function scheduleNotificationAsync(): Promise<string> {
  if (!NotificationScheduler.scheduleNotificationAsync) {
    throw new UnavailabilityError("Notifications", "scheduleNotificationAsync");
  }
  return "запланировано";
}

async function survey(): Promise<void> {
  const updates = requireOptionalNativeModule<ExpoUpdates>("ExpoUpdates");
  const check = await updates?.checkForUpdateAsync();
  console.log("обновление по воздуху: " + (check ? "isAvailable " + check.isAvailable : "модуля нет"));
  console.log("токен в SecureStore: " + Boolean(ExpoSecureStore.getValueWithKeyAsync));
  await scheduleNotificationAsync().catch((error: Error) => console.log("таймер отдыха: " + error.message));
}
survey();

Три разных способа не работать. expo-updates веб-реализацию имеет, и она честно отвечает isAvailable: false: обновлений по воздуху в вебе не бывает — там обновление это новый деплой, и reload() у той же заглушки сводится к window.location.reload. ExpoSecureStore.web.ts — пустой объект, и метода в нём не окажется в момент вызова, а не при сборке; так модуль и устроен, мы вскрывали его в главе 9. А у уведомлений в вебе нет планировщика: файл NotificationScheduler.ts без расширения .native состоит из двух заглушек, и scheduleNotificationAsync бросает UnavailabilityError с тем самым текстом про «linked all the native dependencies». Заметьте, что решение принимает не платформа, а наличие метода: if (!NotificationScheduler.scheduleNotificationAsync).

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

Веб-сборка Expo — статический сайт. PWA из него делаете вы: манифест, service worker и его регистрация — ваши файлы в public/.

«PWA умеет всё, кроме мелочей» и «PWA на айфоне не работает» — два одинаково бесполезных утверждения. Полезен список проверок, каждая из которых отвечает за одно решение. Спросим браузер прямо сейчас. Заглядывание в window и navigator идёт в подложке: у примера React Native их нет, и правильно — на телефоне их тоже нет. Каждая проверка обёрнута, потому что отказ безопасности — такой же ответ, как «нет».

Прогноз: сколько строк ответят «есть» и что окажется в строке про SharedArrayBuffer?

// из подложки — опрос браузера: ни window, ни navigator примеру React Native не положены
declare function webCheck(): Record<string, string>;
const { Platform } = ReactNative;

const check = webCheck();
console.log("Platform.OS: " + Platform.OS);
for (const [name, value] of Object.entries(check)) {
  console.log(name + ": " + value);
}
// веб-сборка expo-sqlite ждёт ответ рабочего потока через SharedArrayBuffer
console.log("та же база, что на телефоне: " + (check.SharedArrayBuffer === "undefined" ? "не откроется" : "откроется"));

Разберём по строкам — и сразу отделим то, что говорит о браузерах вообще, от того, что говорит только о нашей песочнице. Первая строка — как раз из второго рода: Platform.OS здесь всегда web, потому что примеры части выполняет react-native-web. На телефоне в ней стояло бы ios или android, и про канал доставки она не сообщает ничего — про него говорят следующие восемь.

Две строки про изоляцию стоят отдельного слова, потому что это единственная проверка, ответ на которую зависит от вас, а не от браузера пользователя. Заголовки Cross-Origin-Opener-Policy и Cross-Origin-Embedder-Policy шлёт ваш хостинг. У автора статику отдаёт Caddy, и он их не шлёт — там заданы только правила кеша:

# deploy/Caddyfile: веб-версия отдаётся статикой из тома
handle_path /app/* {
	root * /srv/mobile-web
	@hashed path /_expo/* /assets/*
	handle @hashed {
		header Cache-Control "public, max-age=31536000, immutable"
	}
	handle {
		header Cache-Control "no-cache"
		try_files {path} {path}.html {path}/index.html /index.html
	}
}

Пока этих заголовков нет, веб-версия «Подхода» останется без того самого файла базы, который мы открывали в статье «expo-sqlite: настоящая база в телефоне». Дневник в браузере придётся держать в другом хранилище — IndexedDB, — и место для него уже готово: это тот самый подменяемый по расширению journal-db.web.ts, который в песочнице лежал поверх ящика из главы 6. А включить изоляцию не всегда дёшево: COEP ломает загрузку чужих ресурсов, пока их сервер не пришлёт нужных заголовков, — у автора с чужого домена приходит счётчик Метрики.

Ответ «нет» у возможности, которая есть только в Chromium, — это не про ваш код. Это карта браузеров ваших пользователей.

Проверки превращаются в решение одним движением: у каждого требования приложения есть пометка «обязательно» или «хотелось бы». Обязательное требование, которого веб не умеет, закрывает вопрос. Остальное — цена, которую надо назвать вслух, а не обнаружить в отзывах.

Соберём требования «Подхода», какими они сложились за часть. Прогноз: какая строка окажется решающей и что напечатает второй вызов, где этого требования нет?

type Support = "есть" | "нет" | "с оговоркой";
interface Requirement {
  name: string;
  must: boolean;
  web: Support;
  note: string;
}

// требования «Подхода», собранные за часть: что приложение обязано уметь и что просто хотелось бы
const requirements: Requirement[] = [
  { name: "записать подход без сети", must: true, web: "есть", note: "локальная копия из главы 6 и service worker" },
  { name: "открываться с домашнего экрана", must: true, web: "с оговоркой", note: "на iPhone ставит сам пользователь через «Поделиться»" },
  { name: "звонок таймера отдыха при закрытом приложении", must: true, web: "нет", note: "планировщика уведомлений в вебе нет" },
  { name: "синхронизация, пока приложение закрыто", must: false, web: "нет", note: "фоновая синхронизация есть только в Chromium" },
  { name: "та же база SQLite, что на телефоне", must: false, web: "с оговоркой", note: "хостинг обязан слать COOP и COEP" },
  { name: "находиться поиском в магазине", must: false, web: "нет", note: "витрины у сайта нет" },
];

function decide(list: Requirement[]): string {
  const blocking = list.filter((r) => r.must && r.web === "нет");
  const price = list.filter((r) => r.must && r.web === "с оговоркой");
  if (blocking.length > 0) return "магазин обязателен — " + blocking.map((r) => r.name).join("; ");
  return "хватает веб-версии, но с оговорками: " + price.map((r) => r.note).join("; ");
}

for (const r of requirements) {
  console.log((r.must ? "обязательно" : "хотелось бы") + " · " + r.name + " — " + r.web);
}
console.log(decide(requirements));
// у второго тренера таймер звонит, пока он смотрит на телефон, и напоминание не нужно
console.log(decide(requirements.filter((r) => !r.name.startsWith("звонок таймера"))));

Решает одна строка. Таймер отдыха — сердце «Подхода»: между подходами человек кладёт телефон в карман, и звонок обязан прийти, когда приложение закрыто. В браузере планировщика нет вовсе, мы это только что видели запуском, а веб-push — не замена: он приходит с сервера, значит, требует сети в зале, где её нет. Всё остальное веб-версия умеет или умеет с оговоркой.

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

Тот же список удобно держать не в голове, а в виде таблицы канала. Слева — чего просит «Подход», справа — что за это придётся сделать в каждом канале.

Вопрос не «что лучше», а «есть ли в списке обязательного хоть одна строка, которой веб не умеет». Одной хватает.

Эти две способности в спорах называют первыми, и обе устроены сложнее, чем «есть или нет». Механизмы — в главе части II; здесь только то, что влияет на выбор канала.

Установка. В Chrome у неё свои критерии: HTTPS, манифест с нужными полями и вовлечённость — нажатие на странице и около тридцати секунд на ней. Только после этого браузер даёт то самое событие beforeinstallprompt, которым приложение показывает свою кнопку. Событие нестандартное: его нет ни в Firefox, ни в Safari. На iPhone и iPad ставят через «Поделиться» → «На экран Домой», и с iOS 26 так открывается как веб-приложение любой сайт, даже без манифеста. Firefox 143 умеет ставить сайты на панель задач, но только в Windows. Отсюда практическое: кнопку «Установить» показывают по событию, а всем остальным — короткую подсказку, и понять, что подсказка больше не нужна, помогает display-mode: standalone из наших проверок.

Заодно о ходовом заблуждении: start_url за пределами scope установку не ломает. По спецификации манифеста такой scope просто отбрасывается и берётся значение по умолчанию — от start_url; манифест остаётся годным, и Chrome его ставит. Иначе с start_url на чужом происхождении: спецификация отбрасывает и его, но к установке Chrome такой манифест уже не пустит. У автора оба поля — /app/, потому что веб-версия живёт на подпути.

Уведомления. Локального планировщика в вебе нет: мы видели UnavailabilityError запуском. Остаётся push, а это разговор трёх сторон — страница, служба доставки браузера и ваш сервер. Для «Подхода» существенны две оговорки. Первая: на iPhone и iPad push есть с iOS 16.4 и только у приложения, поставленного на экран; из вкладки Safari подписки нет вовсе. Declarative Web Push (iOS и iPadOS 18.4, Safari 18.5 на macOS) показывает уведомление даже без service worker, но на iPhone иконка на экране всё равно нужна. Вторая: push приходит с сервера, то есть требует сети — а «Подход» задумывался для зала, где её нет.

Любопытно, что expo-notifications в вебе всё же умеет одно — подписку. Её веб-файл требует двух полей конфига и сам регистрирует ваш воркер:

// expo-notifications 57 · getDevicePushTokenAsync.web.ts, сокращено
const vapidPublicKey = Constants.expoConfig?.notification?.vapidPublicKey;
if (!vapidPublicKey) {
  throw new CodedError('ERR_NOTIFICATIONS_PUSH_WEB_MISSING_CONFIG', 'You must provide `notification.vapidPublicKey` in `app.json` to use push notifications on web. …');
}
const serviceWorkerPath = Constants.expoConfig?.notification?.serviceWorkerPath;
if (!serviceWorkerPath) {
  throw new CodedError('ERR_NOTIFICATIONS_PUSH_MISSING_CONFIGURATION', 'You must specify `notification.serviceWorkerPath` in `app.json` to use push notifications on the web. …');
}
guardPermission();
const registration = await navigator.serviceWorker.register(serviceWorkerPath);
const pushSubscription = await registration.pushManager.subscribe({
  userVisibleOnly: true,
  applicationServerKey: _urlBase64ToUint8Array(vapidPublicKey),
});

То есть из Expo-кода веб-push достижим, но опирается он целиком на браузерный механизм: ключ VAPID, ваш service worker, ваш сервер рассылки. Ничего общего с scheduleNotificationAsync, которым «Подход» ставит звонок таймера, у него нет.

«Push в PWA есть» и «напоминание придёт» — разные утверждения. Напоминание без сети умеет только системный планировщик, а он живёт в сборке.

Выбор канала — не развилка «или-или». У автора приложение живёт в обоих: сборка для телефона и веб-версия на /app, собранные из одного кода. Для «Подхода» после главы 7 это даже естественно: телефон и браузер — два устройства одного дневника, а сервер синхронизации делает их копиями друг друга. Разница только в роли. На телефоне — главная копия и вся работа в зале; в браузере — второе устройство: посмотреть историю с рабочего компьютера, поправить название упражнения, свести объём за месяц.

Держать два канала сразу стоит внимания в трёх местах.

Обновления. В вебе обновление — это деплой, и доезжает оно сразу; в магазине — сборка, проверка и, если правка только в JS, бандл по воздуху с замком runtimeVersion (глава 11). Общее у них одно: и там и там старый код может задержаться. В вебе его держит service worker, в телефоне — установленная сборка, которую пользователь не обновил. Поэтому сервер синхронизации обязан понимать операции старой формы — это правило мы записали ещё в главе 7.

Данные. Хранилище браузера — не файл приложения: его выселяют. WebKit стирает данные сайта, записанные скриптом, после семи дней пользования Safari без визитов к вам; приложение, поставленное на экран Домой, из этого правила исключено. Для local-first вывод простой: неотправленный журнал в браузере — риск, которого на телефоне нет. Поэтому веб-версия «Подхода» синхронизируется при каждом заходе и не должна становиться единственным местом, где живут записи.

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

Итог для «Подхода»: основной канал — магазин, потому что таймер отдыха обязан звонить при закрытом приложении, а дневник должен лежать в файле, который никто не выселит. Веб-версия остаётся — как второе устройство и как вход для тех, кто пробует приложение и ещё ничего не ставил. Значит, дальше нас ждут три кабинета разработчика, ключи и первая отправка — и лучше знать заранее, что именно мы покупаем за 99 долларов в год.