Самое ироничное, что вся эта боль не из-за «кривых разработчиков», а из-за исторического бага экосистем. Android тащит за собой Java, Apple — сертификаты и reverse DNS, Linux — CLI-культуру. Даже PWA, которые вроде бы обещают «одну точку входа», в итоге просто переносят эту сложность на уровень браузера и окружения, а не убирают её. И никакой Flutter/React Native это принципиально не лечит — только маскирует.
Хороший и очень точный разбор, особенно про установку и изоляцию стораджа — это обычно всплывает уже после продакшена.
Из практики по iOS могу добавить ещё один момент к теме установки.
Помимо отсутствия install prompt, сильно влияет то, что разные браузеры на iOS и Android ведут себя по-разному даже в рамках PWA. В частности, часть мобильных браузеров (тот же Opera на Android, некоторые webview) не отдают beforeinstallprompt вообще, даже когда формально все критерии выполнены.
В таких случаях единственный рабочий вариант — детект окружения на клиенте и показ браузер-специфичной инструкции, а не универсального «Add to Home Screen». Это не решает ограничений iOS как платформы, но снижает фрустрацию пользователя, потому что он видит ровно тот сценарий, который применим к его браузеру.
К сожалению, это ещё один пример того, что PWA в 2026 — это не «написал один раз», а набор условных веток под каждую комбинацию OS + browser.
По описанию приложение выглядит интересно, вокруг него вполне могут появиться пользователи.
В случае если захотите выложить его куда-то — можем чуть помочь с видимостью в сети. Мы поддерживаем стор веб-приложений (wapps.store). Все бесплатное, рекламы нет. (для рф еще тестируется на предмет блокировок)
А можно чуть подробнее про pwa-стор под гемблу? Это был прод с реальными пользователями или скорее эксперимент? Есть ли прототип или что-то, на что можно посмотреть в открытом доступе?
В целом согласен — PWA действительно не конкурируют с нативом в массовых категориях вроде соцсетей, маркетплейсов, такси или сложных игр.
И, честно говоря, идея PWA-магазина как прямой альтернативы App Store / Google Play действительно выглядит сомнительно.
Но речь, скорее, не о замене нативных экосистем, а о другом слое: — нишевые и региональные сервисы, — внутренние и B2B-приложения, — сервисы, которым важен быстрый запуск и кроссплатформенность, — случаи, где натив либо экономически нецелесообразен, либо недоступен для части аудитории.
Финансовая модель и масштаб — да, это ключевой риск, и здесь я скорее согласен со скепсисом, чем спорю с ним.
И всё же сектор, в котором PWA действительно удобны, существует. Вопрос лишь в том, возможен ли для этого сектора удобный и понятный «маркет».
Как мне кажется, сегодня PWA уже достаточно развились, чтобы закрывать гораздо больше сценариев, чем «банки и казино». Их ключевое преимущество — они дешёвые и быстрые в разработке, при этом вполне функциональные.
Часто пользователь и не будет специально «искать PWA». Он приходит потому, что ему порекомендовали конкретный сервис. Хороший пример — школьные дневники. Тот же «Дневник Kiasuo»: PWA-решение, которое удобно для родителей и школ, не требует сложной установки и при этом решает реальную задачу.
Похожая ситуация с региональными и нишевыми сервисами. Некоторые проекты (маркетплейсы, локальные сервисы, аптеки и т.д.) либо не имеют приложений в App Store / Google Play, либо доступны только через APK в RuStore. Для владельцев iPhone это сразу создаёт барьер — и здесь PWA снова становится рабочей альтернативой.
Кажется будто проблема не в самих PWA, а в том, что им сейчас сложно быть заметными и понятными для пользователя. Именно этот разрыв — между зрелой технологией и отсутствием привычного слоя распространения — и видется мне самым "болезненным".
Согласен, с браузером — ему пользователь действительно доверяет как инструменту.
Но проблема обычно не в браузере, а в конкретном PWA. Доверия к нему часто нет, пока пользователь: • не понимает, что именно он устанавливает, • не видит истории, отзывов и обновлений, • не ощущает, что приложение «остаётся с ним», а не просто исчезнет после закрытия вкладки.
Магазин в этом контексте — не замена браузеру и не ещё один способ установки. Скорее попытка создать привычную ментальную модель:
— «у меня есть библиотека», — «я могу вернуться», — «я понимаю, кто разработчик», — «я понимаю, что будет дальше с этим приложением».
То есть вопрос не в технологии установки, а в восприятии и доверии после неё.
Мне откликнулась не столько техническая часть (кэш, SW, предзагрузка), сколько сама формулировка про «доверие через внимание».
По опыту работы с PWA и продуктами, которые пользователи сравнивают с нативными приложениями, действительно выясняется, что ощущение “приложения”, а не “сайта” складывается из десятков мелочей, а не из одного Lighthouse-скора.
Предиктивная навигация, аккуратная работа с кэшем, визуальные микросигналы, отсутствие резких перезагрузок — всё это пользователь не формулирует словами, но очень хорошо чувствует.
При этом согласен, что без чёткого технического фундамента такие вещи легко превращаются в «магические термины». Баланс между инженерной строгостью и UX-целостностью — самый сложный момент.
В любом случае, редкий пример статьи, где PWA рассматривается не как “манифест + service worker”, а как архитектурный слой продукта.
Отличный разбор, спасибо, что так подробно расписали реальный продакшн-флоу.
Особенно понравился подход с Plan Navigator и сжатым контекстом вместо прокидывания всего плана — очень здраво с точки зрения токенов и latency.
Вопрос по PWA-части: сталкивались ли с какими-то edge cases при установке на iOS (особенно с повторной установкой или обновлением SW), или всё прошло относительно гладко?
Супер вопрос. У нас похожая история: есть большой SPA + PWA, и мы рассматриваем Capacitor только ради скорости выхода в сторы. Но главный вопрос не в “современности”, а в поддержке: насколько реально будет поддерживать и обновлять нативные части (iOS/Android) в долгосрочной перспективе, если команда — веб? Если есть опыт — поделитесь, пожалуйста. И ещё: насколько сильно растёт стоимость поддержки по мере роста приложения?
Самое ироничное, что вся эта боль не из-за «кривых разработчиков», а из-за исторического бага экосистем.
Android тащит за собой Java, Apple — сертификаты и reverse DNS, Linux — CLI-культуру.
Даже PWA, которые вроде бы обещают «одну точку входа», в итоге просто переносят эту сложность на уровень браузера и окружения, а не убирают её.
И никакой Flutter/React Native это принципиально не лечит — только маскирует.
Хороший и очень точный разбор, особенно про установку и изоляцию стораджа — это обычно всплывает уже после продакшена.
Из практики по iOS могу добавить ещё один момент к теме установки.
Помимо отсутствия install prompt, сильно влияет то, что разные браузеры на iOS и Android ведут себя по-разному даже в рамках PWA. В частности, часть мобильных браузеров (тот же Opera на Android, некоторые webview) не отдают beforeinstallprompt вообще, даже когда формально все критерии выполнены.
В таких случаях единственный рабочий вариант — детект окружения на клиенте и показ браузер-специфичной инструкции, а не универсального «Add to Home Screen». Это не решает ограничений iOS как платформы, но снижает фрустрацию пользователя, потому что он видит ровно тот сценарий, который применим к его браузеру.
К сожалению, это ещё один пример того, что PWA в 2026 — это не «написал один раз», а набор условных веток под каждую комбинацию OS + browser.
По описанию приложение выглядит интересно, вокруг него вполне могут появиться пользователи.
В случае если захотите выложить его куда-то — можем чуть помочь с видимостью в сети. Мы поддерживаем стор веб-приложений (wapps.store). Все бесплатное, рекламы нет.
(для рф еще тестируется на предмет блокировок)
Интересный кейс, спасибо.
А можно чуть подробнее про pwa-стор под гемблу?
Это был прод с реальными пользователями или скорее эксперимент?
Есть ли прототип или что-то, на что можно посмотреть в открытом доступе?
В целом согласен — PWA действительно не конкурируют с нативом в массовых категориях вроде соцсетей, маркетплейсов, такси или сложных игр.
И, честно говоря, идея PWA-магазина как прямой альтернативы App Store / Google Play действительно выглядит сомнительно.
Но речь, скорее, не о замене нативных экосистем, а о другом слое:
— нишевые и региональные сервисы,
— внутренние и B2B-приложения,
— сервисы, которым важен быстрый запуск и кроссплатформенность,
— случаи, где натив либо экономически нецелесообразен, либо недоступен для части аудитории.
Финансовая модель и масштаб — да, это ключевой риск, и здесь я скорее согласен со скепсисом, чем спорю с ним.
И всё же сектор, в котором PWA действительно удобны, существует.
Вопрос лишь в том, возможен ли для этого сектора удобный и понятный «маркет».
Как мне кажется, сегодня PWA уже достаточно развились, чтобы закрывать гораздо больше сценариев, чем «банки и казино».
Их ключевое преимущество — они дешёвые и быстрые в разработке, при этом вполне функциональные.
Часто пользователь и не будет специально «искать PWA». Он приходит потому, что ему порекомендовали конкретный сервис.
Хороший пример — школьные дневники. Тот же «Дневник Kiasuo»: PWA-решение, которое удобно для родителей и школ, не требует сложной установки и при этом решает реальную задачу.
Похожая ситуация с региональными и нишевыми сервисами.
Некоторые проекты (маркетплейсы, локальные сервисы, аптеки и т.д.) либо не имеют приложений в App Store / Google Play, либо доступны только через APK в RuStore. Для владельцев iPhone это сразу создаёт барьер — и здесь PWA снова становится рабочей альтернативой.
Кажется будто проблема не в самих PWA, а в том, что им сейчас сложно быть заметными и понятными для пользователя.
Именно этот разрыв — между зрелой технологией и отсутствием привычного слоя распространения — и видется мне самым "болезненным".
Согласен, с браузером — ему пользователь действительно доверяет как инструменту.
Но проблема обычно не в браузере, а в конкретном PWA. Доверия к нему часто нет, пока пользователь:
• не понимает, что именно он устанавливает,
• не видит истории, отзывов и обновлений,
• не ощущает, что приложение «остаётся с ним», а не просто исчезнет после закрытия вкладки.
Магазин в этом контексте — не замена браузеру и не ещё один способ установки.
Скорее попытка создать привычную ментальную модель:
— «у меня есть библиотека»,
— «я могу вернуться»,
— «я понимаю, кто разработчик»,
— «я понимаю, что будет дальше с этим приложением».
То есть вопрос не в технологии установки, а в восприятии и доверии после неё.
Интересная статья, спасибо.
Мне откликнулась не столько техническая часть (кэш, SW, предзагрузка), сколько сама формулировка про «доверие через внимание».
По опыту работы с PWA и продуктами, которые пользователи сравнивают с нативными приложениями, действительно выясняется, что ощущение “приложения”, а не “сайта” складывается из десятков мелочей, а не из одного Lighthouse-скора.
Предиктивная навигация, аккуратная работа с кэшем, визуальные микросигналы, отсутствие резких перезагрузок — всё это пользователь не формулирует словами, но очень хорошо чувствует.
При этом согласен, что без чёткого технического фундамента такие вещи легко превращаются в «магические термины». Баланс между инженерной строгостью и UX-целостностью — самый сложный момент.
В любом случае, редкий пример статьи, где PWA рассматривается не как “манифест + service worker”, а как архитектурный слой продукта.
Отличный разбор, спасибо, что так подробно расписали реальный продакшн-флоу.
Особенно понравился подход с Plan Navigator и сжатым контекстом вместо прокидывания всего плана — очень здраво с точки зрения токенов и latency.
Вопрос по PWA-части: сталкивались ли с какими-то edge cases при установке на iOS (особенно с повторной установкой или обновлением SW), или всё прошло относительно гладко?
Супер вопрос.
У нас похожая история: есть большой SPA + PWA, и мы рассматриваем Capacitor только ради скорости выхода в сторы.
Но главный вопрос не в “современности”, а в поддержке:
насколько реально будет поддерживать и обновлять нативные части (iOS/Android) в долгосрочной перспективе, если команда — веб?
Если есть опыт — поделитесь, пожалуйста.
И ещё: насколько сильно растёт стоимость поддержки по мере роста приложения?