Політика конфіденційності застосунку: гайд для iOS

Чому Apple вимагає політику конфіденційності

Щойно ти створюєш сторінку застосунку в App Store Connect, Apple просить URL політики конфіденційності і URL підтримки, яка справді працює. Це не декоративна формальність: правила App Review вимагають, щоб вона була в кожного застосунку, незалежно від того, чи є в ньому обліковий запис користувача. Без доступної сторінки твою заявку заблокують ще до того, як її подивиться рев'юер.

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

Що насправді має бути в твоїй політиці конфіденційності

Текст має описувати те, що твій застосунок справді збирає, а не загальний список, скопійований звідкись. У більшості випадків потрібні чотири елементи:

Дані, які збираються. Обліковий запис, email, контент, створений у застосунку, технічні дані на кшталт рекламного ідентифікатора, якщо ти його використовуєш. Якщо нічого особливого не збираєш, так само чітко про це напиши.

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

Залучені треті сторони. Якщо ти користуєшся провайдером автентифікації, платежів, аналітики чи ШІ, назви його. Наприклад, застосунок, який надсилає фото зовнішньому ШІ-сервісу, має прямо про це сказати і, найчастіше, попросити дозвіл перед відправкою.

Як видалити свої дані. Apple вимагає, щоб застосунок з обліковим записом давав змогу видалити цей обліковий запис просто в застосунку, а не лише через email. Шлях до цього має бути доступним, а не захованим у якомусь неймовірному підменю.

Різниця між політикою і деклараціями конфіденційності

У головах новачків часто змішуються дві різні речі. Політика конфіденційності це текст на вебсторінці, доступний за посиланням. Декларації конфіденційності це форма, яку заповнюють безпосередньо в App Store Connect, у розділі "App Privacy": вона перелічує за категоріями зібрані дані та їхнє використання, а потім показується на публічній сторінці застосунку.

Обидві мають розповідати одну й ту саму історію. Декларація "дані не збираються", коли твій застосунок використовує SDK аналітики, що збирає ідентифікатор, це саме та розбіжність, яку може помітити рев'юер або пізніший аудит. Заповнюй цю форму, реально перевіряючи, що робить твій код і що зазначено в твоєму privacy manifest, а не ставлячи галочку, яка здається найпростішою.

А як щодо GDPR?

Якщо твій застосунок орієнтований на користувачів у Європі, GDPR (у Франції RGPD) діє додатково до вимог Apple. CNIL публікує посібник для розробників мобільних застосунків, де розписано принципи: збирати лише необхідне, чітко інформувати, давати доступ до даних і можливість їх видалити. Вимоги Apple і GDPR значною мірою перетинаються, але відповідність Apple не означає автоматично відповідність GDPR, якщо твій застосунок обробляє персональні дані в широкому сенсі.

Якщо застосунок простий, без облікового запису і без збору персональних даних понад те, чим iOS керує нативно, політика може бути короткою: прямо так і напиши, замість копіювати довгий текст не по темі.

Реальний приклад: відмови за правилом 5.1.1

За свій досвід публікацій я отримав відмову від Apple через онлайн-політику конфіденційності, яка вже не була актуальною, і через кнопку функції, показану до очікуваного запиту дозволу на камеру. Обидва випадки стосуються правила 5.1.1 про збір і зберігання даних. Гайд відмова Apple за правилом 2.1 розбирає ще одну поширену причину, цього разу пов'язану з тим, що тестувальник реально може зробити в застосунку.

Спільний урок обох випадків: рев'юер порівнює те, що обіцяє твоя політика, те, що застосунок робить насправді, і те, що ти задекларував у формі. Розбіжності між цими трьома речами достатньо, щоб заблокувати заявку, навіть якщо решта в порядку.

Як написати свою, нічого не вигадуючи

Для першого застосунку відштовхуйся від реального списку сервісів, якими користуєшся: автентифікація, база даних, платежі, аналітика, ШІ. Для кожного запиши, що він отримує від застосунку і навіщо. Цей список стає каркасом твоєї політики: тобі не потрібен юридичний текст на десять сторінок для застосунку з простим обліковим записом і підпискою.

Якщо твій застосунок зроблено на Expo, гайд про API-ключі в Expo-застосунку пояснює, де розміщувати виклики сторонніх сервісів. Це також допоможе точно знати, які дані проходять через які сервіси, коли писатимеш політику.

Коли текст і декларації конфіденційності готові, вони додаються до решти заявки перед відправкою в Apple: сторінка застосунку, скриншоти, нотатки для тестувальника. Сторінка опублікувати застосунок в App Store описує всі ці кроки в тому порядку, в якому їх вимагає App Store Connect.

Що далі: заявка, перевірена перед відправкою

Я не можу гарантувати, що Apple прийме твій застосунок з першого разу, чесно цього не може ніхто. Але можу допомогти уникнути відмов, яких можна уникнути, зокрема через політику конфіденційності. Щоб перевірити заявку перед відправкою, Apple Review Kit містить мій чекліст і skills для Claude Code, які переглядають твій проєкт, paywall і сторінку застосунку.

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

Поширені запитання

Що таке політика конфіденційності для iOS-застосунку?

Це текст на вебсторінці, доступний за посиланням, який описує, що твій застосунок справді збирає. Його URL ти вказуєш Apple в App Store Connect одразу під час створення сторінки застосунку. Це не загальний список, скопійований звідкись: він має відповідати реальній поведінці застосунку.

Чи обов'язкова політика конфіденційності для публікації iOS-застосунку?

Так, правила Apple вимагають політику конфіденційності для кожного застосунку, незалежно від того, чи є в ньому обліковий запис. Без доступної сторінки твою заявку заблокують ще до перевірки рев'юером. Якщо застосунок простий, політика може бути короткою. Чітко напиши, що ти збираєш, або що нічого особливого не збираєш, замість копіювати довгий текст не по темі.

Що писати в політиці конфіденційності застосунку?

У більшості випадків потрібні чотири елементи: дані, які збираються, причина кожного збору, залучені треті сторони і спосіб видалити свої дані. Щодо даних, подумай про обліковий запис, email, створений контент і рекламний ідентифікатор, якщо ти його використовуєш. Застосунок, який надсилає фото зовнішньому ШІ-сервісу, має прямо про це сказати.

Яка різниця між політикою конфіденційності і деклараціями конфіденційності (App Privacy)?

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

Чи треба дотримуватися GDPR додатково до правил Apple?

Так, якщо твій застосунок орієнтований на користувачів у Європі: GDPR діє додатково до вимог Apple. Вони значною мірою перетинаються, але відповідності Apple не достатньо автоматично, якщо застосунок обробляє персональні дані в широкому сенсі. CNIL публікує посібник для розробників мобільних застосунків: збирати лише необхідне, чітко інформувати, давати доступ до даних і можливість їх видалити.

Чи може Apple відхилити застосунок через політику конфіденційності?

Так, відсутня політика або така, що не відповідає реальній поведінці застосунку, це причина відмови, якої можна уникнути. Рев'юер порівнює те, що обіцяє твоя політика, що робить застосунок і що ти задекларував у формі. Розбіжності між цими трьома речами достатньо, щоб заблокувати заявку. Я сам отримав відмову через онлайн-політику, яка вже не була актуальною.