Чеклист релиза в App Store: privacy, StoreKit, review и launch operations

Короткий ответ

Production-запуск в App Store — не «загрузить binary и ждать review». Это согласованный релиз code signing, metadata в App Store Connect, privacy disclosures, accounts и entitlements, backend compatibility, StoreKit, reviewer access, staged rollout, analytics, support и incident response.

Минимальная профессиональная последовательность:

1. зафиксировать release contract и owners;
2. проверить clean install и полный account lifecycle на физических устройствах;
3. согласовать runtime behaviour, privacy manifests, App Privacy, permissions и policy;
4. протестировать purchases и subscription states в Xcode, Sandbox и TestFlight;
5. подготовить полную metadata и review instructions;
6. проверить backend, flags, observability, support, rollback и kill switches;
7. отправить build без непроверенных production changes;
8. наблюдать review, phased release, crashes, purchases, support и first-use outcomes.

Ни один checklist не гарантирует approval. Guidelines и platform behaviour меняются, а App Review может найти специфичную для приложения проблему. Checklist снижает preventable failures и создаёт evidence для быстрого ответа.

Определите release contract

До final build создайте release record:

Build должен позволять ответить «что именно находится на review?». Запишите source revision, Xcode/SDK versions, dependency lock, build configuration, entitlements, environment и generated assets.

Не меняйте незаметно production API или remote configuration после тестов и до review. Reviewer и users могут увидеть состояние, отличное от approved release. Если remote config необходим, version it и включите в release evidence.

Определите rollout boundary. Submission может содержать code, риск которого контролируется server capability, cohort, region или flag, но reviewed app должна оставаться complete и honest. App Review Guidelines требуют final version, working metadata/URLs и запрещают hidden behaviour, вводящее review в заблуждение.

Проверьте accounts, signing и capabilities

Многие launch failures связаны с account state, а не code.

Проверьте:

• Apple Developer Program membership и agreements;
• legal, banking и tax status для paid apps/IAP;
• bundle identifier и SKU;
• App ID capabilities;
• certificates и provisioning profiles;
• team roles;
• expiry и ownership distribution certificate;
• push notification keys;
• Sign in with Apple;
• associated domains и universal links;
• app groups, keychain groups, iCloud, HealthKit, VPN и entitlements;
• App Store Connect API keys и CI secrets;
• domain и support-email access.

Signing assets и store roles — operational credentials. Нужны organizational ownership, least privilege, recovery и offboarding. Release не должен зависеть от одного laptop или personal account.

Сравните archive entitlements с реально используемыми capabilities. Development build может работать из-за permissive profile, а distribution signing откроет mismatch.

Для extensions — widgets, share, network, watch, notification service — проверьте bundle ID, version, signing, privacy manifest, app groups и deployment. Успех main app не доказывает валидность embedded targets.

Протестируйте lifecycle на физических устройствах

Simulator не доказывает hardware, permissions, notifications, camera, location, Bluetooth, HealthKit, network extensions, background execution и StoreKit.

Device matrix должна включать:

• oldest supported OS на representative hardware;
• current production OS;
• latest доступную команде OS;
• small/large screen при различии layout;
• poor network, offline и восстановление;
• low storage/interruption при актуальности;
• locale, region, timezone, clock, dynamic type, dark mode;
• VoiceOver и keyboard/switch paths.

Проверьте установки:

1. clean install без previous keychain/account assumptions;
2. update с текущей App Store version;
3. reinstall при сохранённом keychain или server account;
4. restored/second device;
5. logged-out, expired-session, deleted-account и revoked-permission states.

First launch обязан переживать backend unavailability, configuration delay и permission denial. Запрашивайте permission в контексте после объяснения value. При отказе app должна оставаться понятной.

Полный account lifecycle:

• sign up и verification;
• sign in и Sign in with Apple edge cases;
• credential recovery;
• account linking и duplicate identity;
• session expiration/token refresh;
• logout на одном и нескольких devices;
• data export;
• account deletion и re-registration;
• subscription restore после account changes.

Evidence включает build, device, OS, account type, time, steps, expected/actual result и logs. «QA passed» невоспроизводимо.

Согласуйте privacy, permissions и disclosures

Один продукт описывают несколько представлений:

• runtime data flow;
• third-party SDK behaviour;
• permission purpose strings;
• privacy manifests;
• App Store Connect App Privacy;
• privacy policy и choices;
• consent/in-app controls;
• deletion и retention operations.

App Privacy Details требуют раскрывать collection самим app и third parties, связь data с identity и tracking. On-device data, не отправляемые на server, рассматриваются иначе. Не выводите label из SDK marketing: проверяйте traffic, storage, config и contracts.

Privacy manifest files описывают collected data, tracking domains и required-reason API. Каждому relevant executable/library нужны accurate declarations. Required-reason API guidance требует approved reasons, согласованных с functionality, и запрещает fingerprinting.

Создайте SDK register:

Удалите SDK, не оправдывающий privacy и operational cost. Отключение collection в вашем code может не выключать default behaviour — проверяйте configuration и traffic.

Согласуйте каждый permission string с видимой feature. «Нужен доступ для лучшего опыта» не объясняет purpose. Проверьте denied, restricted, one-time, limited-library, approximate-location и settings-changed states.

Public privacy policy должна быть доступной, актуальной и соответствовать app. Review может её проверить, но важнее, чтобы user понимал data use и мог использовать choices.

Тестируйте StoreKit как state machine

Purchases — asynchronous state transitions, а не success callback.

Определяйте entitlement по verified transactions и server state. Обработайте:

• products unavailable/config mismatch;
• cancellation;
• pending approval;
• success;
• interrupted transaction;
• restore;
• purchase на другом device;
• renewal;
• billing retry/grace period;
• expiration;
• refund/revocation;
• upgrade/downgrade/cross-grade;
• offer eligibility;
• account mismatch;
• delayed/duplicate server notification;
• offline launch с cached entitlement.

StoreKit testing guidance разделяет StoreKit Testing in Xcode, Sandbox и TestFlight. Xcode полезен для deterministic errors и automation, Sandbox — для App Store Connect products/server integration, TestFlight — для realistic beta. Одна environment не покрывает всё.

StoreKitTest позволяет автоматизировать renewal, Ask to Buy, failures и другие scenarios. Server notifications, reconciliation и idempotency тестируйте отдельно.

Product IDs должны совпадать в code, configuration, App Store Connect, backend, analytics и support. Никогда не выдавайте entitlement по button tap или unverified local flag.

Purchase UI показывает localized name, duration, price, renewal, trial/offer, restore path и policy links. Не hardcode price, если StoreKit даёт localized data.

Тестируйте clean account и accounts с history: eligibility и subscription group меняют UI на одном build.

Считайте App Store metadata правдой о продукте

Metadata формирует ожидания user и mental model reviewer.

Проверьте:

• name, subtitle, category, age rating, availability;
• description и promotional text;
• keywords без misleading claims;
• screenshots для device classes/locales;
• preview video;
• support, marketing и privacy URLs;
• copyright и legal entity;
• release notes;
• export compliance;
• content rights;
• advertising identifier;
• review contact/notes;
• demo credentials или approved demo mode;
• attachment для hardware/setup flows.

Screenshots должны показывать released experience. Уберите personal data, test banners, placeholders, outdated paywalls и features за выключенными flags. Localized metadata должен проверить человек, понимающий продукт: правильный перевод может обещать неправильный workflow.

Guidelines требуют accurate metadata и full review access. Для login дайте стабильные credentials, valid на весь review, preload data и объясните MFA/roles. Если feature зависит от location, hardware, subscription, enterprise config или backend sequence, дайте короткие воспроизводимые steps.

Review notes:

1. что изменилось;
2. где найти;
3. credentials и role;
4. prerequisites;
5. IAP items;
6. объяснение ambiguous policy area;
7. monitored support contact.

Используйте TestFlight как release environment

TestFlight не production, но и не просто кнопка distribution.

TestFlight guidance описывает internal/external groups, feedback, screenshots и crash context. Для external testing нужны beta information и иногда TestFlight App Review.

Создайте cohorts:

Дайте каждой group test charter. «Попробуйте app» создаёт low-signal feedback. Запросите реальную task и context, expected, actual, recovery.

Beta accounts не должны обходить production authorization так, чтобы скрыть release issue. Test data допустимы, permission model и backend contract должны быть representative.

Exit criteria:

• нет unresolved critical crashes/data loss;
• core journeys проходят device matrix;
• privacy/permissions reconciled;
• purchase matrix passes;
• backend/minimum-version behaviour passes;
• support и incident owners готовы;
• limitations documented и accepted.

Подготовьте backend и operations

Binary может быть на review часы или дни и оставаться установленным годы. Backend обязан поддерживать mixed client versions.

До submission:

• deploy backward-compatible APIs;
• verify migrations и rollback;
• определить minimum supported version;
• confirm remote config defaults;
• проверить feature/emergency kill switches;
• dashboards для activation, errors, latency, purchases, notifications и jobs;
• actionable alerts с owners;
• support macros и escalation;
• incident/release rollback paths;
• backups/restore evidence;
• expiry monitoring certificates, keys и agreements.

Rejected build не должен оставлять production half-migrated. Delayed phased release не должен ломать previous version. Expedited fix не должен требовать unsafe schema rollback.

Flags требуют lifecycle ownership: purpose, default, audience, dependency, removal date, emergency behaviour. Undocumented combinations создают второе нетестируемое application.

Analytics должны отвечать на release decisions без лишних personal data. Определите activation, critical task, failure, purchase, restore и support signals. Сохраняйте build/app version dimensions.

Отправляйте и выпускайте осознанно

Final archive check:

• correct version/build и distribution configuration;
• symbols и dSYMs;
• нет dev endpoints, test accounts, debug menus, sensitive verbose logs;
• valid signing/entitlements всех targets;
• privacy manifests present/valid;
• icons и launch assets;
• export/upload validation clean;
• archive сохранён или traceable.

После submission заморозьте material assumptions. Monitor App Store Connect и review contact. Отвечайте facts, steps и evidence. При rejection классифицируйте:

Не resubmit unchanged build с длинным спором. Измените evidence или используйте appeal, если policy действительно применена спорно.

Выберите manual, automatic или phased release по operational readiness. Phased release ограничивает distribution rate, но не все risks: backend changes и existing users уже создают exposure. Сохраняйте monitoring и возможность pause/disable.

Эксплуатируйте первые семь дней

Первый час

Проверьте store availability, version, product page, deep links, clean install, login, core task, purchases, remote config, backend health и dashboards.

Первый день

Изучите crash-free use, critical errors, onboarding abandonment, purchase/restore failures, support, reviews и неожиданные data/cost signals. Segment by version/OS.

Дни 2–3

Разберите реальные failures, а не averages. Проверьте notifications, background tasks, renewals и delayed integrations. Исправьте metadata/support, если users неправильно понимают release.

Дни 4–7

Решите expand, pause или complete rollout. Запишите incidents и превратите failures в regression tests. Уберите temporary access и flags.

Downloads не доказывают success. Измеряйте activation, critical task, entitlement correctness и high-severity failures относительно documented baseline без выдуманной causation.

Release checklist

Product и policy

• Scope, non-goals, owners и gates записаны.
• Behaviour совпадает с metadata, screenshots, review notes и policy.
• Policy-sensitive workflows имеют evidence и owner.

Build и device QA

• Archive, source revision, tools, dependencies и config записаны.
• Clean install, upgrade, reinstall, session expiry, deletion и recovery проходят.
• Physical device, accessibility, localization, offline и poor network проходят.
• Embedded targets имеют signing, entitlements, versions и manifests.

Privacy и security

• Runtime data flow, SDK register, permissions, manifests, App Privacy и policy совпадают.
• Secrets, logs, admin access, deletion и incident response проверены.

Purchases

• Product IDs и localized StoreKit data совпадают.
• Purchase, pending, cancel, restore, renewal, expiry, refund, revoke и offers проходят.
• Server notifications и reconciliation idempotent/observable.

Store и review

• Agreements, roles, metadata, URLs, screenshots, rating, compliance и IAP готовы.
• Stable credentials и reproducible notes готовы.
• TestFlight exit criteria выполнены.

Operations

• Backward-compatible backend, migrations, flags, dashboards, alerts, support и rollback готовы.
• First-hour, first-day и seven-day owners назначены.

Launch готов, когда команда может объяснить release, доказать critical journeys, обнаружить failure, защитить users и восстановиться. Approval обязателен; safe operation — outcome.