Перевірка відповідності ігор вимогам платформ (Compliance)
Відхилення Submission від Sony, Microsoft або Apple — це не просто затримка релізу. Це порушення маркетингової кампанії, втрачені рекламні бюджети та перегляд дат партнерських домовленостей. Більшість відхилень відбуваються не через серйозні технічні порушення, а через деталі, які команда не перевірила, тому що «так завжди працювало».
Що дійсно перевіряють платформи
У кожної платформи свої технічні вимоги (TRC для PlayStation, TCR для Xbox, App Review Guidelines для Apple), і вони оновлюються. Те, що працювало рік тому, сьогодні може бути підставою для відхилення.
PlayStation (TRC). Найчастіші причини відхилення: неправильна обробка системних подій — suspend/resume, вихід з гри через PS Button, втрата геймпада. TRC вимагає, щоб при втраті контролера гра повинна паузувати геймплей (не просто показати повідомлення). Багато команд реалізують лише UI-повідомлення, забуваючи встановити Time.timeScale = 0 або відправити відповідне NetworkEvent в мультиплеєрі. Також критично: розблокування трофеїв має вирватися тільки при реальному досягненні, а не тестовим викликом, який випадково залишився в білді.
Xbox (TCR). Розблокування achievement без реального триггера — автоматичне відхилення. Крім цього: xinput-сумісність, правильна робота Quick Resume (гра повинна коректно відновлюватися зі suspended-стану без перезапуску сесії), дотримання Xbox Accessibility Guidelines. Останнє часто ігнорують як «необов'язкове», але Microsoft все активніше перевіряє базові accessibility-вимоги.
iOS App Store. Список причин відхилення широкий, але технічні улюбленці: використання private API (легко перехопити, якщо використовувати сторонні плагіни без аудиту), неправильна обробка App Background Modes, проблеми з in-app purchase flow (Apple вимагає строго визначений UX для IAP, відхилення від Human Interface Guidelines в цій частині — майже гарантоване відхилення), і — особливо актуально для ігор — некорректні privacy manifests починаючи з iOS 17.
Google Play. З 2024 року Google активно перевіряє Target API Level (повинен бути актуальним), коректність Data Safety section (якщо гра збирає дані — це повинно бути точно задекларовано, невідповідність між кодом та декларацією веде до suspension), та compliance з Families Policy для ігор з рейтингом для дітей.
Процес compliance-аудиту
Робота починається з читання актуальних вимог для конкретної платформи та версії SDK. Не дворічної давнини документації — актуальної, на дату подачі. Sony, Microsoft та Apple оновлюють вимоги регулярно, і підписка на developer newsletters — обов'язкова практика.
Далі формуємо compliance checklist під кожну платформу. Це не універсальний список — він складається під конкретну гру: жанр, монетизація, онлайн-режими, вікова рейтинг, цільові регіони (GDPR для EU, COPPA для США).
Тестування охоплює:
- Всі системні сценарії (suspend, resume, sign-out, controller disconnect, low battery)
- IAP flow від початку до кінця, включаючи restore purchases та обробку помилок
- Network interruption scenarios (втрата з'єднання в момент транзакції)
- Age rating відповідність (контент у грі vs заявлений рейтинг)
- Privacy та permissions (запитуються тільки необхідні, з правильними рядками обґрунтування)
- Локалізація системних повідомлень (на всіх підтримуваних мовах платформи)
Після тестування — pre-submission report з переліком виявлених невідповідностей, пріоритизованих за ймовірністю відхилення.
На одному мобільному проекті за тиждень до релізу ми виявили, що Game Center integration викликала GKAchievement.reportAchievements двічі при певному сценарії прохождення рівня — один раз з gameplay-логіки, другий раз з analytics-события. Apple відстежує duplicate achievement calls та при певній частоті флагує як спробу накрутки. Виправили через дедуплікацію на рівні AchievementManager з кешем вже відправлених achievements у PlayerPrefs.
Підготовка до submission
Compliance-тестування — фінальний крок, але краще розпочати його паралельно з основною розробкою. Базові речі (обробка системних подій, IAP flow) можна верифікувати на ранніх білдах.
Фінальний submission checklist включає: перевірку всіх метаданих (скриншоти, опис, вікова рейтинг у кожному регіоні), верифікацію сертифікатів та provisioning profiles, тест на чистому встановленні без попередніх даних.
| Платформа | Орієнтовні терміни аудиту |
|---|---|
| iOS або Android (одна платформа) | 1–2 тижні |
| iOS + Android | 2–3 тижні |
| Console (PlayStation або Xbox) | 2–4 тижні |
| Multi-platform (PC + Mobile + Console) | 4–8 тижнів |
Вартість розраховується після аналізу платформ, монетизаційної моделі та обсягу функціоналу.