Мультиаккаунтинг для издателей приложений: App Store и Google Play
Как студии и агентства ведут несколько консолей разработчика в App Store Connect и Google Play без путаницы и риска связанных блокировок.
Студия с пятью мобильными играми, агентство, которое публикует приложения под брендом клиента, инди-разработчик с отдельным юрлицом на каждый проект — у всех одна и та же бытовая проблема: несколько консолей разработчика, несколько Apple ID и Google-аккаунтов, и один браузер на компьютере, в котором всё это постоянно путается. Разберём, как с этим работать так, чтобы не ловить блокировки за «ассоциированные аккаунты» и не терять доступ, когда разработчик увольняется посреди релиза.
Откуда берутся несколько аккаунтов разработчика
Причины у этого почти всегда легитимные, не про обход правил:
- Агентство ведёт приложения нескольких клиентов. У каждого клиента свой Apple Developer Program ($99 в год) и свой Google Play Console (разовый взнос $25). Агентство не владелец аккаунта — оно получает доступ как сотрудник или через роль в консоли.
- Белый лейбл. Одна студия делает десятки похожих приложений (конструкторы, шаблонные игры) под разными юрлицами заказчиков — у каждого юрлица обязан быть собственный аккаунт разработчика, это требование Apple напрямую.
- Мульти-бренд внутри одной компании. Разные продуктовые линейки публикуются под разными именами разработчика, иногда намеренно, чтобы в App Store они не выглядели как один конвейер.
- Региональные витрины. App Store поддерживает более 175 витрин, и часть команд держит тестовые аккаунты (sandbox tester) под конкретные локали, чтобы проверить цены, формулировки, локализованные скриншоты до публикации.
Ничего из этого не нарушает правила платформ — пока каждый аккаунт действительно принадлежит своему юрлицу или используется по назначению (тестирование, работа по доверенности клиента).
Что реально запрещают Apple и Google
Здесь стоит быть точным, потому что путаница в этом месте дороже всего обходится.
Apple. Один Apple Developer Program — на одно юрлицо или физлицо. Создавать второй аккаунт для того же бизнеса, чтобы обойти отклонение приложения или бан, прямо запрещено — Apple называет это «circumventing review» и банит разом все связанные аккаунты, если находит пересечения: один и тот же банковский счёт, одно устройство, с которого логинились в оба аккаунта, одна и та же команда разработки без раскрытия связи. При этом иметь легитимно разные аккаунты для разных клиентов или брендов — нормально, это стандартная практика агентств, подтверждённая самой программой Apple для агентств (App Store Connect позволяет добавлять агентство как «Developer» или «Admin» в чужой аккаунт по приглашению).
Google Play. Политика аналогичная: несколько developer-аккаунтов разрешены, если они представляют разные реальные бизнесы или проекты. А вот создание дублей после удаления приложения, накрутка через несколько аккаунтов одного разработчика или сокрытие связи между аккаунтами при нарушении политики — основание для termination сразу всех связанных консолей.
Вывод простой: право на несколько аккаунтов есть, но платформы активно ищут технические совпадения между ними — именно потому, что через такие совпадения чаще всего и ловят реальные схемы обхода банов. Поэтому разделение по браузерам, сетям и устройствам — это не маскировка, а гигиена: вы показываете платформе ровно то, чем на самом деле являетесь — отдельными легитимными аккаунтами, а не одним человеком, который прячет связь между ними.
Где чаще всего всё путается на практике
Три типичные ситуации у студий и агентств:
- Один браузер на все консоли. Разработчик держит открытыми пять вкладок App Store Connect под разными Apple ID. Автозаполнение подставляет не тот email, куки от одного аккаунта утекают в сессию другого, а при входе через общий Chrome-профиль Apple иногда видит связку устройство+сеть у аккаунтов, которые формально принадлежат разным клиентам.
- Передача доступа при смене исполнителя. Фрилансер, который вёл публикацию приложения клиента, уходит — а у него остался пароль, сохранённые куки и ключ 2FA в его личном браузере. Переустановить всё на нового человека без простоя релиза получается не всегда гладко.
- Тестирование витрин. QA-инженер логинится под sandbox tester-аккаунтом для немецкой витрины, потом в том же окне — под американским, язык интерфейса и геолокация не совпадают с тем, что должен видеть этот тестовый аккаунт, и часть локализационных багов остаётся незамеченной именно из-за этого.
Как устроить работу с несколькими консолями разработчика
Один профиль браузера — один аккаунт разработчика
Самое простое и самое эффективное решение — завести отдельный изолированный профиль браузера на каждый Apple Developer Program и каждый Google Play Console, с которыми работает команда. В профиле фиксируется набор параметров: ОС, версия браузера, экран, часовой пояс и язык — всё подтягивается из IP выходного прокси, а не копируется с рабочей машины сотрудника. Это убирает самую частую причину случайных пересечений: один и тот же «отпечаток» браузера на разных клиентских аккаунтах.
Для студий с десятками приложений и десятком клиентских консолей это выглядит как список профилей с понятными названиями («Клиент А — App Store Connect», «Клиент А — Google Play», «Бренд Б — sandbox DE»), сгруппированных по проекту. Про то, как не утонуть в этом списке, когда профилей становится действительно много, разбирали отдельно в материале про организацию профильных пулов.
Прокси для региональных витрин и тестовых аккаунтов
Если команда проверяет локализацию магазина для конкретной страны, аккаунт-тестировщик должен физически заходить с IP этой страны — иначе геолокация, часовой пояс и язык интерфейса, которые видит Apple или Google, не совпадут с заявленной витриной, и часть проверок потеряет смысл. Прокси-менеджер с привязкой прокси к профилю и проверкой exit-IP решает это напрямую: один прокси — одна витрина, без ручного переключения VPN перед каждым тестом.
Для агентств, которые ведут не тестовые, а боевые консоли нескольких клиентов, прокси выполняет вторую функцию — технически разводит клиентов по разным сетям, чтобы у Apple и Google не возникало повода связать несвязанные бизнесы в один кластер. Какой тип прокси выбрать под такую задачу — резидентный, мобильный или дата-центровый — подробно разобрано в статье про типы прокси для мультиаккаунтинга.
Хранение 2FA и доступ без передачи пароля
У App Store Connect и Google Play Console двухфакторная аутентификация обязательна не формально, а по сути — без неё аккаунт разработчика просто не пройдёт верификацию. Проблема в том, что ключ 2FA обычно живёт в телефоне конкретного человека, и при смене исполнителя его приходится перевыпускать с нуля, иногда теряя доступ на день-два.
Хранилище 2FA-ключей привязано к профилю, а не к личному устройству сотрудника: ключ переезжает вместе с профилем, если проект передаётся другому человеку в команде, и не исчезает вместе с увольняющимся разработчиком. Подробнее о том, как устроено шифрование и восстановление доступа, — в материале про безопасность профилей.
Роли и передача профиля между сотрудниками
В агентстве с несколькими клиентскими консолями не у всех должен быть доступ ко всем аккаунтам. Командные роли с лимитами на профили и права по умолчанию решают это так: разработчик видит только профили своих проектов, аккаунт-менеджер — только клиентскую переписку и аналитику, а владелец аккаунта GetAntik контролирует весь пул.
- lev открыл Airdrop zkSync 07
- artem закрыл FB · US · BM-14
- maya смотрит браузер artem
- lev передал TikTok Shop 03
Когда проект переходит от одного фрилансера к другому — а в студиях с внешними подрядчиками это происходит регулярно, — профиль со всеми куками, историей и 2FA-ключом передаётся штатно, без пересборки с нуля и без риска, что у бывшего исполнителя остался рабочий доступ. Эта механика и типичные ошибки при передаче разобраны в статье про роли и передачу профилей в команде.
Таблица: какой сценарий — какая настройка
| Сценарий | Профиль | Прокси | 2FA | Роль в команде |
|---|---|---|---|---|
| Агентство ведёт App Store Connect пяти клиентов | отдельный профиль на клиента | свой прокси на клиента | ключ в хранилище профиля | доступ только у ответственного менеджера |
| Белый лейбл: 20 приложений под разными ООО | профиль на юрлицо, не на приложение | можно общий для одного юрлица | отдельный ключ на юрлицо | admin видит все, member — своё |
| Тест локализации витрины DE/US/JP | профиль на страну | прокси с exit-IP нужной страны | sandbox-тестер без боевого 2FA | QA-команда, временный доступ |
| Смена фрилансера на проекте | профиль остаётся, меняется исполнитель | без изменений | ключ не перевыпускается | handoff профиля новому члену команды |
Типичные ошибки
Логиниться в личный и рабочий Apple ID в одном окне браузера. Keychain и автозаполнение Safari/Chrome периодически путают сессии, и клиентский аккаунт получает отпечаток личного устройства разработчика вместе с его личными данными автозаполнения.
Один общий прокси или домашний IP на все клиентские консоли. Если пять разных юрлиц заходят в свои Developer Program с одного и того же IP в одно и то же время, это ровно та картина, которую Apple и Google ищут при проверке на обход блокировок — даже если каждый клиент абсолютно легален сам по себе.
Не разводить тестовые и боевые аккаунты. Sandbox tester для QA и реальный Apple ID разработчика — разные учётные записи по назначению, но часто оказываются в одном и том же браузерном профиле, и тестовые действия случайно засоряют продакшн-данные.
Хранить пароль и 2FA только у одного человека. Классика: единственный, кто может опубликовать обновление, в отпуске или уволился, а релиз горит. Решается заранее настроенным доступом с ролями, а не паролем в личном блокноте разработчика.
Привязывать к разным аккаунтам одну и ту же платёжную информацию без необходимости. Это уже не про браузер и фингерпринт, а про банковские реквизиты и способы вывода выплат — но именно по ним платформы чаще всего и связывают формально разные аккаунты. Изоляция профиля снимает техническую часть риска, но не заменяет честного ведения бухгалтерии по каждому юрлицу отдельно.
FAQ
Можно ли агентству иметь доступ к App Store Connect клиента без передачи пароля клиента? Да, это предусмотренный Apple механизм — клиент добавляет агентство как пользователя с ролью Developer или Admin в своём аккаунте. Отдельный изолированный профиль со своим входом удобен именно для такого случая: агентство не держит общий логин, а заходит под собственным приглашённым пользователем.
Снимает ли антидетект-браузер риск блокировки за «связанные аккаунты»? Он убирает техническую причину ложного срабатывания — совпадение отпечатка браузера, IP и сессии между разными легитимными аккаунтами. Если же аккаунты действительно одного и того же бизнеса используются для обхода отклонения или бана, никакая изоляция профиля не делает это разрешённым — Apple и Google проверяют не только браузер, но и платёжные данные, содержимое приложений, команду разработки.
Нужен ли отдельный прокси для каждого sandbox tester-аккаунта? Если задача — проверить именно локализованную витрину конкретной страны, да: часовой пояс, язык и геолокация в профиле должны соответствовать стране витрины, иначе часть локализационных проверок теряет смысл. Для внутренних функциональных тестов, не привязанных к региону, этого можно не делать.
Что происходит с 2FA-ключом и куками, если профиль передают другому сотруднику? Профиль переезжает к новому исполнителю целиком — вместе с ключом из хранилища, куками и историей входов, без необходимости перевыпускать двухфакторную аутентификацию с нуля на стороне Apple или Google.
С чего начать, если сейчас всё хранится в головах разработчиков и в одном общем Chrome? Сначала — инвентаризация: список всех Developer Program и Play Console аккаунтов, к какому юрлицу или клиенту каждый относится, кто сейчас имеет доступ. Дальше — по одному профилю на аккаунт, перенос 2FA в хранилище профиля и назначение ролей в команде. Для начала хватает тарифа на 20 профилей — для большинства студий с несколькими клиентами или брендами этого достаточно, расширить лимит можно позже на странице тарифов.