Тестування In-App Purchases на iOS: гайд для QA з реального досвіду

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт! Мене звати Лада, я QA Team Lead в Universe Group — команді, яка перетворює ідеї на продукти, якими користуються мільйони людей по всьому світу. Я відповідаю за якість застосунків нашого бізнесу Guru Apps: від Cleaner Guru і Scan Guru до AI-асистентів та редакторів фото. А ще вдома зі мною тестує все, що рухається (і не рухається теж) мій пухнастий помічник котик Лакі.

Моя суперсила — мобільне тестування та побудова ефективної автоматизації перевірки iOS-застосунків. У цій статті я розповім про in-app purchases:

• які вони бувають;
• що таке StoreKit і його новіша версія StoreKit 2;
• і найголовніше — як їх правильно тестувати.

Цей матеріал стане в пригоді всім, хто працює з iOS-застосунками, має або планує додати in-app purchases, і хоче краще розуміти, як усе це влаштовано під капотом.

Що таке in-app purchases і які вони бувають

Куди ж без основ! Давайте коротко пройдемося по тому, що таке in-app purchases і які вони бувають.

In-app purchases (IAP) — це те, що ви можете придбати в мобільному застосунку, і це може бути додатковий преміальний контент, внутрішня валюта застосунку або підписка, яка буде розблоковувати вам якісь можливості.

Якщо керуватися документацією Apple, вони виділяють такі типи IAP:

1. Consumable — продукт, який використовується один раз, після чого його запас вичерпується і його потрібно купувати знову. Приклад: корм для риби в застосунку для риболовлі.

2. Non-Consumable — продукт, який купується один раз і не закінчується, і не зменшується в міру використання. Приклад: перегонова траса для ігрового застосунку.

3. Auto-Renewable Subscription — продукт, який дозволяє користувачам купувати динамічний контент на певний період. Цей тип підписки поновлюється автоматично, якщо користувач не скасує її. Приклад: щомісячна підписка на застосунок, що пропонує стрімінгові послуги.

4. Non-Renewing Subscription — продукт, який дозволяє користувачам придбати послугу з обмеженим терміном дії. Вміст цієї покупки в застосунку може бути статичним. Цей тип підписки не поновлюється автоматично. Приклад: річна підписка на каталог архівних статей.

Як же працює функціонал підписок в застосунках

Ще з перших версій App Store розробники могли додавати покупки в застосунки за допомогою StoreKit — фреймворку від Apple для роботи з IAP.

Флоу роботи StoreKit:

• Користувач відкриває paywall / магазин у застосунку.
• App створює SKProductsRequest із product identifiers.
• StoreKit зв’язується з App Store.
• Повертає SKProducts.
• App показує UI з цінами / назвами товарів.
• Користувач натискає «Купити».
• App створює SKPayment і додає до SKPaymentQueue.
• App Store обробляє покупку (оплата, підтвердження).
• App отримує оновлення транзакції через SKPaymentTransactionObserver.
• App перевіряє транзакцію (успішна / скасована / помилка).
• App розблокує контент або надає доступ.
• App має завершити транзакцію call `SKPaymentQueue.default().finishTransaction(...)`.

Проте цей інструмент був складним: вимагав багато ручної роботи, делегатів, обробки транзакцій та зовнішньої валідації.

У відповідь на ці виклики Apple представила StoreKit2 — оновлений, сучасний API, який значно спрощує інтеграцію підписок і покупок. Він з’явився у 2021 році разом з iOS 15, і був побудований на основі Swift, async/await, Swift Concurrency, з акцентом на безпеку, зручність і меншу залежність від власного бекенду.

Флоу роботи StoreKit2:

• Користувач відкриває paywall / магазин у застосунку.
• App запитує пропозиції (Products) через Product.products(for:).
• StoreKit2 зв’язується з App Store і повертає доступні продукти.
• App відображає UI для покупки (ціни, назви, кнопки).
• Користувач натискає «Купити».
• App викликає product.purchase().
• Відкривається системне вікно покупки.
• App Store обробляє покупку (оплата, підтвердження).
• StoreKit2 повертає результат (успішно / помилка / скасування).
• App перевіряє покупку через Transaction.latest(for:) або підписується на Transaction.updates.
• App розблокує контент, або надає доступ.

StoreKit 2 — це не просто оновлення, а повноцінна переписана з нуля версія StoreKit, яка враховує потреби сучасної розробки на iOS.

Ось основні відмінності, які помітні одразу:

Простіший код. StoreKit 2 працює на базі Swift Concurrency (async/await), що дозволяє писати коротший, чистіший і зрозуміліший код без зайвих «танців з бубном».

Менше мороки. У StoreKit 1 треба було багато всього робити вручну: створювати черги, слідкувати за статусом покупок, підтверджувати їх. У StoreKit 2 більшість цього відбувається автоматично.

Легше перевірити покупку. У StoreKit 2 можна швидко дізнатися, чи покупка дійсна, прямо в застосунку — без складної перевірки або обов’язкового звернення до сервера.

Підписки «з коробки». StoreKit 2 краще працює з підписками. Наприклад, можна легко дізнатися, коли вона закінчується, чи ввімкнено автооплату, і так далі.

Замість спостерігачів — зручні оновлення. Не треба більше писати код, який «слухає» всі зміни вручну. У StoreKit 2 є простий спосіб підписатися на оновлення транзакцій.

Безпечніше. Apple зробила нову версію більш захищеною від підробок і помилок. Це особливо важливо, якщо ви працюєте з реальними грошима.

Зручніше тестувати. Зʼявився StoreKit Transaction Manager, який значно спрощує тестування.

Примітка: якщо не знаєте, який StoreKit використовує ваш застосунок — спитайте у розробника або гляньте по коду:

SKPaymentQueue → StoreKit 1,

Transaction, Product, Product.SubscriptionInfo → StoreKit 2.

Тестування через Sandbox-акаунти

Тепер, коли ми розібрались з тим, які покупки бувають і як вони працюють в застосунку, можемо перейти безпосередньо до тестування.

Одним з основних способів перевірки роботи In-App Purchases є використання Sandbox-акаунтів — спеціальних тестових Apple ID, які дозволяють здійснювати фіктивні покупки без реального списання коштів.

Важливо: ці акаунти не мають доступу до App Store чи iCloud, і ними не можна користуватися як звичайним Apple ID.

Як створити Sandbox-акаунт? Знаходячись в AppStore Connect акаунті свого застосунку, у розділі «Users and Access» → «Sandbox Testers» натисніть «+». Заповніть всі поля форми. Як імейл можна використовувати лайфхак з [email protected] або одноразові тимчасові імейл-адреси. Натисніть «Invite». Sandbox-акаунт має бути підтверджений через пошту.

Як використовувати на пристрої? На фізичному iPhone відкрийте: Settings → App Store → Sandbox Account. Увійдіть з новоствореним акаунтом. Запустіть застосунок, у якому реалізовані IAP. Здійсніть покупку і з’явиться тестове вікно підтвердження оплати.

Порада: щоб уникнути кешування і збоїв, завжди розлогінюйтеся перед зміною sandbox-акаунта. Наявному користувачу можна відредагувати країну, Subscription Renewal Rate та параметр Interrupt Purchases for This Tester. Subscription Renewal Rate у sandbox усі події пришвидшені, наприклад: підписка на 1 місяць триває ~5 хвилин.

Що можна і не можна протестувати через Sandbox:

Можна:

• Одноразові покупки та підписки.
• Оновлення, скасування й відновлення підписок.
• Відновлення покупок на іншому пристрої.
• Тестування Family Sharing.
• Тестування edge-case сценаріїв (наприклад, скасування через кілька хвилин).

Не можна:

• Тестування складних edge-case сценаріїв (фейл і так далі).
• Введення промокодів, подарункових карт.
• Надійне тестування server-to-server notifications.
• Використання StoreKit 2 Transaction Manager.

Тестування через Sandbox-акаунти — це найнаближеніший до реальності спосіб перевірки роботи внутрішніх покупок.

Він дозволяє побачити справжню взаємодію з App Store, протестувати різні сценарії підписок, відновлення й помилок, а також переконатись, що інтеграція працює коректно на фізичних пристроях.

Тестування через StoreKit Configuration Files

StoreKit Configuration (.storekit) — це спеціальний файл у Xcode, який дозволяє створити віртуальний магазин з тестовими продуктами.

Як налаштувати? У Xcode натисніть File → New → File from Template → StoreKit Configuration File → Next. Для того, щоб всі наявні підписки підтягнулись до вашого StoreKit Configuration File, треба натиснути галочку Sync this file with an app in App Store Connect. Після цього автоматично підтягнеться Name, Team та App. Переходимо до наступного кроку після натискання Next. Треба обрати основний таргет застосунку і натиснути Create.

У вас відкрився StoreKit Configuration File зі всіма підписками, одноразовими покупками, які є в App Store Connect. Далі треба зробити так, щоб Run Action користувався цим файлом і дозволяв робити симуляції покупок. Перейдіть до Scheme → Edit Scheme → Run → Options. У полі StoreKit Configuration оберіть створений файл. Запускайте застосунок — усі покупки будуть іти через віртуальний StoreKit.

Важливо: в .storekit-файл підтягуються всі підписки, починаючи зі статусу Ready to Submit. Новостворені підписки в статусі Missing Metadata не відображаються.

Як працюють симуляції (success, failure, refunds). StoreKit Transaction Manager. У .storekit-файлі можна симулювати різні сценарії поведінки користувача або App Store — без реального акаунта чи підключення до мережі. Це зручно для швидкого тестування edge-кейсів.

Що можна налаштувати:

• Storefront (наприклад, Україна, США).
• Localization — тексти покупки різними мовами.
• Subscription Renewal Rate — пришвидшене автоподовження (наприклад, 1 хв = 1 місяць).
• Ask to Buy — імітація запиту на дозвіл.
• Grace Period, Billing Retry, Interrupted Purchases.
• StoreKit Failures — наприклад, purchase declined або store unavailable.
• Confirmation Dialogs — можна вимикати/вмикати системні pop-ups.

Для допомоги тестування підписок з використанням .storekit-файлу існує інструмент StoreKit Transaction Manager.

При запущеному застосунку на панелі можна вибрати Transaction Manager (дивіться скриншот).

Це окреме вікно у Xcode, де можна переглядати всі транзакції, які відбулися через .storekit, вручну створювати refund, завершувати транзакції зі статусом success /failure/cancelled. Працювати з Ask to Buy функціоналом.

Через Transaction Manager можна також тестувати Purchase Intent.

Purchase Intent — це процес, коли користувач виявляє бажання здійснити покупку в застосунку (запит на покупку) «ззовні застосунку», наприклад, одразу в AppStore за допомогою функціонала win-back offers. Він може бути у вигляді натискання кнопки «Buy/Subscribe» або ініціалізації покупки через інтерфейс застосунку.

За допомогою StoreKit Transaction Manager в Xcode можна імітувати цей процес і перевірити, як застосунок реагує на різні сценарії покупки.

Важливо: Transaction Manager працює тільки для StoreKit 2 і з конфіг-файлом. Не показує транзакції з sandbox.

Також .storekit-файл можна використовувати в XCUITest. Для цього потрібно буде імпортувати StoreKitTest у XCUITest. Далі треба провести налаштування тесту зі .storekit-файлом.

Приклад використання:

Що можна протестувати за допомогою .storekit-файлу:

Можна:

• Повна симуляція всіх типів покупок.
• Повна симуляція edge-case сценаріїв (фейл, кенсел, рестор, рефанд і так далі).
• Встановлення статусу підписки вручну (активна / завершена).
• UI-флоу покупки.
• Підключення до StoreKit 2 Transaction Manager.

Не можна:

• Перевірка інтеграції з реальним App Store.
• Симуляція покупки з різних акаунтів.

StoreKit Configuration — ідеальний інструмент для локального тестування та UI-автотестів. Він швидкий, зручний і не вимагає доступу до реального облікового запису чи App Store. Проте щоб перевірити інтеграцію «по-справжньому», все одно варто запускати фінальні тести через sandbox-акаунти.

Порівняння Sandbox vs StoreKit Configuration

Sandbox можна використовувати:

• Для тестування реальних транзакцій. Якщо вам потрібно перевірити процес покупки з реальним обробленням платежу, покупкою через App Store та оновленням користувача (наприклад, для тестування підписок).
• Тестування у реальних умовах. Якщо ви хочете перевірити, як застосунок буде працювати з реальними користувачами та реальними транзакціями в умовах реального App Store.

StoreKit Configuration можна використовувати:

• Для швидкого налаштування тестових сценаріїв. Якщо ваша мета — швидко тестувати різні сценарії покупок, такі як успішні або невдалі транзакції, без необхідності здійснювати реальні платежі, StoreKit Configuration — ідеальний варіант.
• Для автоматизованих тестів. StoreKit Configuration є чудовим інструментом для інтеграції в XCUITest та інших автоматизованих тестах, де ви хочете імітувати покупки без реальної взаємодії з App Store.
• Тестування поведінки застосунку при помилках. Ідеально підходить для тестування відмов та помилок (наприклад, стани, коли недостатньо коштів, повернення коштів), оскільки можна легко імітувати ці ситуації за допомогою конфігураційних файлів.

Наостанок — що обираю особисто я

Як людина, яка постійно працює з підписками у мобільних застосунках, можу з упевненістю сказати: StoreKit 2 — це справжній прорив. Але якщо говорити про те, що мені найбільше полегшило життя — це, без сумнівів, StoreKit Configuration + StoreKit Transaction Manager.

Можливість тестувати покупки без постійного введення паролів Sandbox-акаунта — це просто мрія. А ще й підтримка автотестів! Для QA це не просто зручно, а це любов з першого тапу :)