Який Apple Developer акаунт потрібен для VPN-застосунку та як правильно підготувати його до публікації

Для VPN-проєкту важливо заздалегідь вирішити чотири завдання: оформити акаунт на організацію, реалізувати VPN через підтримувані Apple API, підготувати політику конфіденційності та продумати поступовий вихід продукту в App Store.

Який тип Apple Developer акаунта потрібен для VPN-застосунку

Для публікації застосунку з VPN-функціональністю необхідно використовувати Company Apple Developer Account, тобто акаунт організації.

У правилах App Store Review Guidelines зазначено, що VPN-застосунки можуть пропонувати лише розробники, зареєстровані як організація. Individual Apple Developer Account, оформлений на фізичну особу, для такого проєкту не підходить.

На практиці розробники, які надсилають VPN-застосунок з Individual-акаунта, часто отримують відхилення з прямою вимогою перенести застосунок на акаунт компанії. У такому разі виправлення інтерфейсу, опису або серверної частини не вирішить проблему: спочатку знадобиться відповідний тип членства в Apple Developer Program.

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

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

Чим акаунт організації відрізняється від Individual

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

Чому Apple висуває окремі вимоги до VPN

VPN-застосунок може перенаправляти інтернет-трафік через віддалену інфраструктуру, тому користувач і Apple мають розуміти, яка компанія відповідає за сервіс та обробку даних.

Company-акаунт дозволяє визначити відповідальну юридичну сторону, але не гарантує схвалення. Організація повинна керувати застосунком, контролювати інфраструктуру та надавати достовірні відомості в App Store Connect.

NEVPNManager і технічна реалізація VPN

VPN-функціональність має бути побудована з використанням офіційних інструментів Apple із сімейства Network Extension.

У вимогах Apple окремо згадується NEVPNManager. Це системний API, який дозволяє створювати VPN-конфігурації та керувати ними на iOS і macOS. Через нього застосунок взаємодіє із системними налаштуваннями, а користувач отримує стандартний запит на додавання VPN-конфігурації.

Залежно від архітектури проєкт також може використовувати NETunnelProviderManager і Packet Tunnel Provider — це актуально, коли застосунок реалізує власний тунель або нестандартний протокол.

Перед надсиланням збірки необхідно перевірити:

• чи правильно налаштовані Network Extension capabilities;
• чи додані необхідні entitlements;
• чи коректно підписані основний застосунок і розширення;
• чи працює підключення на реальному пристрої;
• чи доступні сервери під час перевірки;
• чи може рев'юер протестувати всі заявлені функції.

Працюючий VPN-тунель не гарантує схвалення: App Review також оцінює якість продукту, прозорість його призначення та відповідність заявленим функціям.

Чому готовий VPN-застосунок не завжди варто публікувати одразу

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

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

Ризик підвищують такі ознаки:

• стандартний головний екран з однією кнопкою підключення;
• типовий список країн і серверів;
• однакова структура підписки та paywall;
• шаблонні скриншоти й опис;
• відсутність функцій, окрім увімкнення та вимкнення VPN;
• дизайн, схожий на інші застосунки з того самого вихідного коду;
• кілька однотипних проєктів, пов'язаних з одним розробником.

Саме тому ми не рекомендуємо в усіх випадках починати публікацію одразу з повністю готового VPN-продукту. Обережніша стратегія — спочатку випустити якісний застосунок суміжної тематики, а потім поступово розвивати його через оновлення та додавати VPN-функціональність як логічне продовження продукту.

Що означає поступовий запуск VPN-застосунку

Поступовий запуск — це не завантаження прихованого VPN під виглядом іншого застосунку. Йдеться про нормальний розвиток продукту за версіями.

Перша версія повинна мати власну цінність і реально виконувати заявлені функції. Це може бути застосунок, пов'язаний із безпекою підключення, захистом у публічних Wi‑Fi-мережах, аналізом мережі, перевіркою з'єднання або керуванням мережевими налаштуваннями.

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

Такий підхід допомагає сформувати ширшу продуктову ідею, перевірити стабільність інтерфейсу та серверної частини, а також показати послідовний розвиток застосунку. VPN стає частиною корисного набору функцій, а не єдиною кнопкою.

Головна мета стратегії — створити зріліший і самостійніший продукт, а не обійти App Review.

Як може виглядати поступовий розвиток застосунку

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

Перша версія: застосунок суміжної тематики

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

• перевіряє безпеку поточної Wi‑Fi-мережі;
• показує основну інформацію про підключення;
• попереджає про роботу в незашифрованій мережі;
• допомагає керувати довіреними мережами;
• містить рекомендації щодо захисту з'єднання;
• виконує діагностику доступності інтернету.

Перша версія не повинна бути порожньою оболонкою, створеною лише заради появи картки в App Store. Користувач має отримувати повноцінну користь і без VPN.

Наступні оновлення: розвиток основної концепції

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

Додавання VPN-функціональності

Коли VPN-модуль готовий, його можна додати через повноцінне оновлення. До цього моменту застосунок уже має використовувати Company Apple Developer Account і відповідати всім вимогам Apple до VPN.

В оновленні необхідно чесно зазначити:

• що в застосунку з'явилася VPN-функція;
• як вона працює;
• які дані обробляються;
• які дозволи запитуються;
• як рев'юер може протестувати підключення;
• чи потрібна підписка або тестовий акаунт.

Також необхідно оновити опис, скриншоти, App Privacy, політику конфіденційності та Notes for Review.

Повний перехід до VPN-продукту

Надалі VPN може стати основною функцією, якщо перехід виглядає природно, а застосунок зберігає цілісну концепцію. Наприклад, утиліта для захисту публічних мереж може поступово перетворитися на комплексний сервіс із VPN, автоматичним підключенням і контролем довірених Wi‑Fi-мереж.

Чого не можна робити під час поступового запуску

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

• залишати готовий VPN-модуль прихованим під час перевірки;
• активувати його віддалено одразу після схвалення;
• надавати рев'юеру урізану версію застосунку;
• приховувати VPN-функції за недоступним екраном;
• описувати оновлення як незначне, якщо призначення продукту суттєво змінилося;
• залишати старі скриншоти та політику конфіденційності після додавання VPN;
• додавати функції, які App Review не може протестувати.

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

Як підготувати політику конфіденційності

Політика конфіденційності VPN-застосунку має точно відповідати архітектурі сервісу, а не бути формальним документом для App Store Connect.

Користувачеві необхідно зрозуміло пояснити:

• чи збираються IP-адреси;
• чи ведуться журнали підключень;
• чи фіксуються час і тривалість сесій;
• які діагностичні дані передаються;
• чи використовуються аналітичні та рекламні SDK;
• де розташовані сервери та системи зберігання;
• як довго зберігаються дані;
• як подати запит на видалення інформації;
• чи передаються відомості інфраструктурним підрядникам.

До початку використання VPN або придбання підписки всередині застосунку має з'являтися зрозуміле повідомлення про дані. Якщо сервіс заявляє no logs, це має підтверджуватися налаштуваннями серверів, аналітики та сторонніх SDK.

Що підготувати перед App Review

Перед надсиланням версії з VPN-функціональністю варто перевірити:

• акаунт оформлений на організацію;
• юридичні дані компанії актуальні;
• використовується офіційна архітектура Network Extension;
• VPN-сервери доступні та стабільно працюють;
• рев'юеру наданий повний тестовий доступ;
• у Notes for Review описаний увесь сценарій підключення;
• VPN-функція відкрито зазначена в метаданих;
• скриншоти відповідають поточній версії;
• політика конфіденційності оновлена;
• розділ App Privacy заповнений коректно;
• правила підписки та пробного періоду показані прозоро;
• застосунок має власну цінність і не виглядає копією шаблону;
• перевірені обмеження в країнах поширення.

Якщо застосунок починався як суміжна утиліта, під час додавання VPN необхідно повторно перевірити всю картку та привести її у відповідність до нової версії.

Поширені причини відхилення VPN-застосунків

1. Використовується Individual Apple Developer Account. Для VPN потрібен акаунт організації.
2. Застосунок виглядає надто типовим. Він майже не відрізняється від десятків наявних VPN.
3. VPN реалізований через невідповідну технологію. Не використовуються передбачені Apple інструменти.
4. Функції не розкриті рев'юеру. Частина застосунку прихована або недоступна для перевірки.
5. Політика конфіденційності не відповідає продукту. Заяви розходяться з фактичним збором даних.
6. Не працює тестовий сценарій. Рев'юер не може підключитися до сервера або перевірити підписку.
7. Призначення застосунку різко змінене. VPN доданий без оновлення метаданих і зрозумілого пояснення.
8. Не дотримані місцеві вимоги. Застосунок поширюється в регіоні без необхідних дозволів.

У відповіді на відхилення краще перелічити конкретні виправлення: перенесення на Company-акаунт, оновлення розкриття даних, тестового доступу, Network Extension або унікальних функцій.

Висновок

Для публікації VPN-застосунку необхідний Company Apple Developer Account, оформлений на підтверджену юридичну особу. Individual-акаунт для цієї категорії не підходить.

Однак правильний тип акаунта вирішує лише одне питання. Застосунок також повинен використовувати підтримувані Apple API, прозоро працювати з даними, відповідати законодавству обраних країн і мати самостійну продуктову цінність.

Через велику кількість однотипних VPN-сервісів ми рекомендуємо розглядати поступовий запуск: спочатку опублікувати повноцінний застосунок суміжної тематики, потім послідовно розвивати його та через оновлення додавати VPN-функціональність. При цьому кожну зміну необхідно відкрито показувати користувачам і App Review.

Такий підхід не гарантує схвалення, але допомагає сформувати зріліший продукт, уникнути враження чергового шаблонного VPN-клону та заздалегідь підготувати застосунок до суворих вимог Apple.