Реалізація Hard Paywall (без можливості пропуску) у мобільному застосунку
Hard paywall блокує доступ до контенту або функцій без оплати, без можливості пропустити. Це найбільш агресивна, але при правильному застосуванні найбільш конверсійна модель. Головна помилка при реалізації — порушити правила App Store або створити UX, при якому користувач почувається обманутим.
App Store правила для hard paywall
Apple детально розглядає hard paywall при ревю. Відклинення по 3.1.1 відбувається, якщо:
- Застосунок взагалі не працює без покупки, але в описанні немає явного упоминання що це платний продукт.
- Користувач не може ни на що натиснути без підписки (навіть на «Посмотреть тарифи» або «Войти»).
- Hard paywall показується немедленно при першому запуску без демонстрації хоч мінімальної цінності.
Допустимі схеми з hard paywall: онбординг показує ключові фічі → paywall. Або: trial період (3–7 днів безплатно) → hard paywall по закінченню. Застосунок у описанні явно зазначена як subscription-based.
Onboarding + Hard Paywall як воронка
Стандартна конверсійна схема:
- Onboarding (2–4 екрана) — демонстрація цінності через конкретні фічі, не абстрактні обіцянки.
- Personalization step — питання про ціль користувача (жанр для читалки, ціль тренування для фітнес-застосунку). Ответы не обов'язково впливають на алгоритм — важна psychological investment (користувач вложився, складніше йти).
- Hard Paywall — після того як користувач «настроїв» продукт під себе.
На клієнті: OnboardingCoordinator керує кроками, PaywallCoordinator — фінальний крок онбордингу. Після успішної покупки — перехід у головний екран без можливості повернутися на paywall.
Обов'язкові елементи hard paywall
Restore Purchases — обов'язковий. Користувач переустановив застосунок — повинен відновити підписку. AppStore.sync() (StoreKit 2) або BillingClient.queryPurchasesAsync() (Android) для відновлення. Без цього — відклинення App Store, злі відзиви.
SKPaymentQueue.canMakePayments() перевірка перед показом paywall — на деяких пристроях (корпоративні MDM профілі, Screen Time обмеження) IAP заблоковані. Якщо canMakePayments == false — показуємо пояснення, не крашим.
Terms of Service / Privacy Policy посилання — внизу екрана, мелким шрифтом, але доступні. Для subscription-застосунків: явно вказати суму, період та умову автопродління у CTA кнопці або рядом: «7 днів безплатно, потім $9.99/мес, відмова в будь-час».
Блокування навігації
Hard paywall не повинен обходитися через back gesture або фізичну кнопку назад. На iOS: UIViewController.isModalInPresentation = true запобігає swipe-to-dismiss для .pageSheet / .formSheet. Full-screen — back gesture недоступна за замовчуванням. На Android: override onBackPressed() / BackHandler (Compose) — або нічого не робимо, або показуємо confirmation «Упевнені? Без підписки застосунок недоступний».
В NavigationStack (SwiftUI) або NavHost (Compose) — paywall екран не має NavigationBarBackButton та не знаходиться в стандартному navigation stack, він presentирован модально поверх stack.
Introductory Offer
Hard paywall з trial конвертує краще без trial — це не значить що trial завжди потрібен. Для утилітарних застосунків (калькулятори, інструменти) hard paywall без trial працює. Для lifestyle/habit/health — trial необхідний, користувач повинен упевнитися в цінності.
StoreKit 2 product.subscription?.introductoryOffer — показуємо trial пропозицію тільки eligible користувачам. isEligibleForIntroOffer — async check, робимо при prefetch продуктів, кешуємо.
Аналітика
Ключові события для hard paywall: paywall_shown, paywall_purchase_started, paywall_purchase_success, paywall_purchase_failed, paywall_restore_tapped, paywall_restore_success. Основа для моніторингу health монетизації. Drop між purchase_started та purchase_success більше 20% — проблема з біллінгом, потрібно розслідувати.
Ориентири по срокам
Hard paywall з повним StoreKit 2 / Play Billing flow, restore, introductory offer, аналітикою событій та блокуванням навігації — 2–3 робочих дня. З кастомним онбордингом як воронкою — плюс 3–5 днів на онбординг-екрани.