Ограничения PWA в Safari
Ограничения PWA в Safari — то, с чем неизбежно сталкивается любая команда, льющая на iOS, и часть этих ограничений нельзя обойти техническим трюком, только сценарием. WebKit исторически реализует PWA-возможности медленнее и уже, чем Chrome на Android, и это данность, а не временный баг. Разберём, что конкретно не работает и как строить воронку с учётом этого.
Нет автоматического баннера установки
В отличие от Chrome, Safari не поддерживает событие beforeinstallprompt — системного баннера «установить приложение» с кнопкой в один тап на iOS просто нет. Пользователь должен вручную открыть меню «Поделиться» и выбрать «На экран Домой», и если крео или преленд не объясняют этот шаг явно, установка на iOS проседает не из-за оффера, а из-за интерфейса. Здесь помогает пошаговая инструкция прямо в преленде: экран с колесом фортуны или квизом (преленды APEX) можно использовать не только как игровой элемент, но и как повод задержать внимание пользователя ровно на этом шаге.
Пуши работают только с iOS 16.4 и только после установки
Веб-пуши на iOS доступны начиная с iOS 16.4, и только для PWA, которое уже добавлено на главный экран — обычная открытая вкладка Safari пуши не получает вообще. На практике это означает: часть аудитории на старых версиях iOS пушей не увидит никогда, и закладывать 100% покрытие пушем для iOS-трафика нельзя. Сегментация базы по факту установки и версии ОС (это умеет пуш-движок APEX) позволяет не тратить рассылки на тех, кто их физически не получит.
Хранилище и данные не гарантированно постоянны
Safari применяет собственную политику ограничения хранилища для веб-контента, и локальные данные малоактивной PWA могут очищаться, если пользователь долго не открывал её. Это отличается от нативного приложения, где данные живут, пока приложение не удалено вручную. Сценарии, которые критично зависят от постоянного локального состояния (долгая сессия, кэш без переавторизации), на iOS нужно проектировать с запасом на возможный сброс.
Часть API недоступна или работает иначе
Некоторые возможности, привычные по нативным приложениям или Android Chrome — бейджи на иконке, фоновая синхронизация, отдельные API камеры и микрофона — на iOS Safari либо отсутствуют, либо работают с оговорками и меняются от версии к версии. Строить воронку, которая жёстко зависит от одинакового поведения такого API и на iOS, и на Android, — риск: на iOS часть функциональности может просто не сработать. Закладывайте деградацию функциональности на iOS как норму, а не как исключение.
Как строить сценарий с учётом всего этого
Разделяйте креатив и преленд для iOS и Android хотя бы на уровне инструкции по установке — на iOS явно показывайте шаг «Поделиться → На экран Домой», на Android можно рассчитывать на системный баннер. Тестируйте эти два сценария раздельно через сплит-тест sticky по визитору, а не общей цифрой — иначе слабый iOS-сценарий просто размывается на фоне сильного Android. Для iOS-аудитории закладывайте push как бонус, а не как основной канал удержания, и продумайте, что удерживает пользователя в первой сессии без пуша вообще.
Частые вопросы
- Работают ли пуш-уведомления в PWA на iPhone?
- Да, но только начиная с iOS 16.4 и только для PWA, уже добавленного на главный экран — обычная вкладка Safari пуши не получает.
- Почему на iPhone не показывается баннер «установить приложение»?
- WebKit не реализует событие beforeinstallprompt, поэтому установка возможна только вручную через меню «Поделиться» → «На экран Домой», и это нужно явно объяснять пользователю.
- Может ли Safari сама удалить данные PWA?
- Да, при длительном отсутствии визитов Safari может очистить локальное хранилище малоактивной PWA, поэтому не стоит проектировать сценарии, которые жёстко зависят от постоянного локального состояния.
- Нужен ли отдельный сценарий под iOS?
- Да, как минимум отдельная инструкция по установке и реалистичные ожидания по пушам — стоит протестировать iOS и Android раздельно через сплит-тест, а не смотреть на общую цифру.
Клоака, антибот, пуши, сплит-тесты и свои домены — в одном сервисе.
Начать бесплатно