WOLF VPN — мобильный VPN-сервис. Приложение мы сделали целиком: от аналитики и дизайна до разработки и запуска. В этом кейсе рассказываем, из чего состоит такой продукт и как мы подходим к его созданию на каждом этапе.
VPN-приложение выглядит простым: одна большая кнопка «Подключиться». Но за этой кнопкой стоят системные разрешения, серверная инфраструктура, подписки и одна из самых строгих модераций в сторах. Разбор пригодится всем, кто планирует разработку мобильного приложения под ключ, особенно сервисного и подписочного.
Задача: VPN-сервис как мобильный продукт
Перед нами стояла задача сделать мобильное приложение VPN-сервиса целиком, без готового дизайна и чужого кода. Такой проект объединяет три разных мира: интерфейс для обычного человека, низкоуровневую работу с сетью на устройстве и серверную часть, через которую идёт трафик.
Пользователь VPN-приложения обычно не разбирается в протоколах и шифровании. Ему нужно, чтобы соединение было защищено, интернет не тормозил, а приложение не мешало. Поэтому мы позиционируем такой продукт как инструмент для защиты соединения и приватности, например в общественных сетях Wi-Fi, и под эту задачу строим весь интерфейс.
Отсюда главный принцип: вся сложность остаётся внутри, снаружи — одно понятное действие. Всё, что требует от пользователя технических решений, мы либо убираем, либо прячем в настройки.
Вся сложность VPN остаётся внутри приложения, снаружи — одно понятное действие.
Главный экран: подключение в одно касание
В VPN-приложении человек проводит на главном экране почти всё время. Он открывает приложение, чтобы включить или выключить защиту, и сразу закрывает его. Поэтому UX мобильного приложения такого типа проектируется от главного экрана, а не от меню.
На главном экране типичного VPN-сервиса нужно ответить на четыре вопроса пользователя:
- Защищён ли я сейчас? Статус соединения должен считываться за секунду: цвет, подпись, состояние кнопки.
- Как включить или выключить? Одна крупная кнопка, до которой легко дотянуться большим пальцем.
- Через какую локацию я подключён? Текущий сервер и быстрый переход к выбору другого.
- Всё ли работает нормально? Время сессии, скорость или другой понятный признак, что соединение живое.
Отдельно продумываем промежуточные состояния: «подключаемся», «переподключаемся», «нет сети», «сервер недоступен». Именно в них пользователь чаще всего нервничает и удаляет приложение. У каждого состояния должны быть свой вид и понятный текст, а не бесконечный спиннер.
Выбор локации и скорость
Список серверов — второй по важности экран. Обычно в нём есть вариант «самый быстрый сервер» по умолчанию, список стран или городов, поиск и избранное. Если серверов много, рядом с каждым полезно показывать загрузку или задержку, чтобы человек выбирал не наугад.
Показ скорости — тонкое место. Цифры должны быть честными и понятными, иначе они вызывают больше вопросов, чем ответов. Поэтому на этапе дизайна мы решаем, что именно измерять и как это подавать, вместе с командой, которая отвечает за серверную часть.
Онбординг и системные разрешения
Чтобы VPN заработал, операционная система должна разрешить приложению управлять сетевым соединением. На iOS пользователь видит системный запрос на добавление конфигурации VPN, на Android — диалог с разрешением на подключение. Текст этих окон задаёт система, и звучит он для неподготовленного человека тревожно.
Поэтому онбординг приложения мы строим вокруг этого момента. До системного окна пользователь должен понимать, что сейчас произойдёт, зачем это нужно и что приложение делает с его данными. Хороший онбординг короткий: два-три экрана, без рассказа обо всех функциях.
Есть и платформенные различия, которые влияют на дизайн и разработку:
| iOS | Android | |
|---|---|---|
| Системный механизм | Network Extension | VpnService |
| Первое подключение | Запрос на добавление VPN-конфигурации | Диалог с разрешением на подключение |
| Работа в фоне | Управляется системой через расширение | Постоянное уведомление о работающем VPN |
| Подписки | Встроенные покупки App Store | Google Play Billing |
Подписка и пробный период
Большинство VPN-сервисов зарабатывают на подписке, поэтому экран оплаты — такая же часть продукта, как кнопка подключения. Подписка в мобильном приложении проектируется вместе с основным сценарием: когда показать предложение, что доступно без оплаты, как работает пробный период и что видит человек, когда он закончился.
При проектировании подписки разбираем несколько вопросов:
- какие тарифы нужны: по сроку, по числу устройств, по набору локаций;
- будет ли пробный период и как пользователь узнает, когда начнётся списание;
- как восстановить покупку на новом телефоне и как отменить подписку;
- как приложение проверяет статус подписки на сервере, чтобы доступ был у тех, кто заплатил.
Для цифровых подписок внутри приложения сторы обычно требуют использовать свои системы оплаты, а условия зависят от платформы и страны. Поэтому схему оплаты мы согласуем с клиентом до дизайна экранов: от неё зависят тексты, сценарии и серверная логика.
Ещё один принцип: отмена подписки должна быть такой же понятной, как покупка. Сторы проверяют прозрачность условий, а пользователи, которых запутали, пишут плохие отзывы и оформляют возвраты.
Публикация в App Store и Google Play
VPN — одна из категорий, к которым сторы относятся строже всего: приложение получает доступ ко всему трафику пользователя. Публикация в App Store и Google Play для такого продукта требует подготовки, которую стоит начинать параллельно с разработкой.
Из общеизвестных требований, которые мы закладываем с начала проекта:
- В App Store VPN-приложения публикуются от аккаунта разработчика-организации, а не частного лица.
- В Google Play использование VpnService нужно задекларировать, и оно допустимо, когда VPN — основная функция приложения.
- Политика конфиденциальности должна прямо описывать, какие данные собираются и как используются.
- Анкеты о данных в карточке приложения должны совпадать с тем, что приложение делает на самом деле.
- Условия подписки, пробного периода и автопродления видны пользователю до оплаты.
Отдельно учитываем правовую сторону. В разных странах действуют свои правила для VPN-сервисов, в том числе в России. Как и где распространять продукт, решает клиент со своими юристами, а мы закладываем в приложение то, что для этого нужно: корректные тексты, прозрачную работу с данными и возможность гибко управлять доступными регионами.
Серверная часть и инфраструктура
Мобильное приложение VPN-сервиса — только видимая часть. За ним стоят серверы, через которые идёт трафик, и бэкенд, который управляет пользователями, подписками и списком локаций.
В общих словах серверная часть такого продукта решает несколько задач: учёт пользователей и устройств, проверка подписки, выдача конфигурации для подключения, список серверов с их состоянием, мониторинг доступности. Важно, чтобы набор локаций и параметры можно было менять без выпуска новой версии приложения: проверка обновления в сторах занимает время, а сервер может понадобиться заменить сегодня.
Для сервиса приватности есть ещё одно требование: собирать о пользователе только то, что необходимо для работы и оплаты. Это решение принимается на уровне архитектуры, а не текста в политике конфиденциальности.
Как мы вели проект: этапы работ
Проект мы вели по нашим стандартным этапам. Для VPN-приложения каждый из них имеет свою специфику:
- Аналитика, структура и смыслы. Разбираем рынок и конкурентов, сценарии пользователей, модель монетизации и требования сторов. На выходе — карта экранов и состояний, включая ошибки и промежуточные статусы.
- Визуальный код и дизайн. Предлагаем варианты в разных стилях и рисуем интерфейс с нуля. Особое внимание — главному экрану, онбордингу и экрану подписки.
- Разработка. Интерфейс, сетевая часть на системных механизмах каждой платформы, подписки, связь с серверной частью.
- Тестирование. Проверяем подключение на разных устройствах и версиях систем, в мобильной сети и на Wi-Fi, при смене сети и потере связи, а также покупку, восстановление и отмену подписки.
- Публикация и запуск. Готовим карточки приложения, политику конфиденциальности и анкеты о данных, проходим модерацию и отвечаем на замечания сторов.
Другие проекты, которые мы делали по этой же схеме, собраны на странице наших работ.
Аналитика и развитие после запуска
Подписочное приложение начинает по-настоящему работать только после публикации. Дальше команда смотрит, где пользователи теряются, и улучшает продукт по данным, а не по ощущениям.
Для VPN-приложения полезно следить за несколькими группами показателей:
- Воронка: установка, прохождение онбординга, выдача разрешения на VPN, первое подключение, оформление подписки или пробного периода.
- Качество соединения: доля успешных подключений, обрывы, время подключения по локациям.
- Стабильность: падения приложения по версиям систем и моделям устройств.
- Подписки: переход из пробного периода в платный, продления, отмены.
Аналитику в VPN-приложении собираем аккуратно: продукт обещает приватность, поэтому события описывают действия в интерфейсе, а не то, куда человек ходит в интернете. Метрики продукта не должны противоречить его обещанию.
Кроме того, приложение нужно обновлять под новые версии iOS и Android, следить за изменениями правил сторов и поддерживать серверную часть. Это постоянная работа, которую стоит планировать сразу вместе с первой версией.
Частые вопросы
Сколько длится разработка мобильного приложения под ключ?
Зависит от объёма первой версии, числа платформ и серверной части. Для VPN-приложения на срок сильнее всего влияют настройка инфраструктуры, подписки и модерация в сторах. Реальный срок даёт оценка после аналитики, когда понятен состав экранов и интеграций.
Можно ли сделать приложение сразу для iOS и Android?
Да. Интерфейс можно сделать общим или кроссплатформенным, но сетевую часть VPN на каждой платформе пишут через её системные механизмы: на iOS это Network Extension, на Android — VpnService. Поэтому тестировать соединение нужно отдельно на обеих системах и на разных устройствах.
Почему VPN-приложение дольше проходит модерацию?
Сторы относят VPN к чувствительным категориям: приложение получает доступ к трафику пользователя. Модераторы проверяют, кто его публикует, как описан сбор данных, что сказано в политике конфиденциальности и как устроены подписки. Чем аккуратнее это подготовлено, тем меньше отказов.
Что делать с приложением после публикации?
Следить за стабильностью соединения и падениями, смотреть воронку от установки до подписки, выпускать обновления под новые версии iOS и Android и обновлять серверы. Для подписочного продукта развитие после запуска — обычная работа, а не отдельный проект.
