Магазины: App Store, Google Play, RuStore и первая отправка

Сама отправка занимает минуту, но это последняя минута долгой подготовки. Сборку некуда положить, пока в магазине нет карточки приложения, а карточку не завести без аккаунта разработчика. Команде из терминала нужен ещё и ключ, с которым магазин пустит её от вашего имени.

Ключ Google eas-cli просит при первой отправке — «A Google Service Account JSON key is required to upload your app to Google Play Store» — и может хранить его на серверах EAS, рядом с keystore из статьи «EAS Build». Тогда в репозитории ключа нет, а отправлять можно с любой машины.

Разработчику из России стоит заранее сверить с этой таблицей и деньги. Google с 26 декабря 2024 года не проводит платежи через Play Billing, если счёт для выплат в России. В справке при этом прямо сказано, что новые бесплатные приложения публиковать и обновлять можно. С 1 апреля 2026 года российские операторы отключили оплату покупок в App Store со счёта мобильного телефона, а это был самый ходовой в России способ платить. RuStore платит в рублях, но монетизацию через свои платёжные инструменты с 1 февраля 2026 года оставил только ИП и юрлицам. «Подход» бесплатный, и ни одно из этих ограничений его не касается. Платные функции потребовали бы отдельного разговора.

Карточку приложения в Google Play заводят руками. eas submit кладёт сборки в готовую карточку, но создать её не может.

Как отправлять, описывает секция submit в eas.json, и у автора она занимает одну строку: "submit": { "production": {} }. Пустой профиль — не ошибка: всё, чего в нём нет, допишет схема @expo/eas-json. Отправка последней сборки для Android:

$ eas submit --platform android --latest

Сводка перед отправкой — это разрешённый профиль отправки. Ни трек internal, ни статус COMPLETED в eas.json автора не написаны: их дописала схема. Строка Rollout: undefined — не опечатка статьи. eas-cli 22.2.0 кладёт поле в сводку, даже когда значения нет, и так его и печатает. «All done!» значит одно: Google Play принял файл. Кто и когда увидит сборку, решает трек — о треках секция «Что происходит после отправки».

Без флагов команда спрашивает, что отправлять: сборку с EAS, ссылку, файл или ID сборки. С --latest она берёт последнюю сборку платформы — но «последнюю» среди каких? В submit/utils/builds.js запрос к серверу несёт фильтр distribution: Store и четыре статуса: new, in queue, in progress и finished. Профиль отправки, если --profile не указан, ищется по имени профиля, которым собрана сборка. В подложке — разрешение профиля сборки и выбор файла из статьи «EAS Build» и eas.json автора, теперь вместе с секцией submit. Прогноз: что уйдёт в магазин по каждой из трёх команд и с какими настройками?

type Platform = "android" | "ios";
interface BuildProfile {
  distribution?: "store" | "internal";
  buildType?: "apk" | "app-bundle";
  simulator?: boolean;
}
interface SubmitProfile {
  track?: string;
  releaseStatus?: string;
  changesNotSentForReview?: boolean;
  language?: string;
}
type SubmitSection = { extends?: string } & Partial<Record<Platform, SubmitProfile>>;
interface Build {
  id: string;
  platform: Platform;
  profile: string;
  status: "new" | "in-queue" | "in-progress" | "finished" | "errored";
}
// из подложки — разрешение профиля сборки, файл сборки и eas.json автора из статьи «EAS Build»
declare function resolveBuildProfile(easJson: object, platform: Platform, name?: string): BuildProfile;
declare function androidArtifact(profile: BuildProfile): string;
declare function iosArtifact(profile: BuildProfile): string;
declare const easJson: { submit: Record<string, SubmitSection> };

// @expo/eas-json 22 · submit/schema.js: что схема дописывает к пустому профилю отправки
const submitDefaults: Record<Platform, SubmitProfile> = {
  android: { track: "internal", releaseStatus: "completed", changesNotSentForReview: false },
  ios: { language: "en-US" },
};

// submit/resolver.js: берётся только секция платформы, и сливается она в один уровень
function resolveSubmitProfile(platform: Platform, name = "production"): SubmitProfile {
  const section = (profileName: string): SubmitProfile | undefined => {
    const entry = easJson.submit[profileName];
    if (!entry) throw new Error("Missing submit profile in eas.json: " + profileName);
    return entry.extends ? { ...section(entry.extends), ...entry[platform] } : entry[platform];
  };
  return { ...submitDefaults[platform], ...section(name) };
}

// eas-cli 22 · submit/utils/builds.js: фильтр, с которым --latest спрашивает сервер
function latest(builds: Build[], platform: Platform): Build | undefined {
  const alive = ["new", "in-queue", "in-progress", "finished"];
  return builds
    .filter((b) => b.platform === platform && alive.includes(b.status))
    .filter((b) => resolveBuildProfile(easJson, platform, b.profile).distribution === "store")
    .at(-1);
}

// submit/commons.js: без --profile профиль отправки ищется по имени профиля сборки
function submit(build: Build | undefined): void {
  if (!build) return;
  const profile = resolveBuildProfile(easJson, build.platform, build.profile);
  const file = build.platform === "android" ? androidArtifact(profile) : iosArtifact(profile);
  console.log(build.id + " · " + build.profile + " · " + build.status + " · " + file);
  try {
    console.log(resolveSubmitProfile(build.platform, build.profile));
  } catch {
    console.log(`Selected build uses "${build.profile}" build profile but a submit profile with the same name is missing in eas.json. Using default ("production") profile`);
    console.log(resolveSubmitProfile(build.platform));
  }
}

// сборки проекта на серверах EAS, от старых к новым
const builds: Build[] = [
  { id: "a1", platform: "android", profile: "production", status: "finished" },
  { id: "i1", platform: "ios", profile: "production", status: "finished" },
  { id: "a2", platform: "android", profile: "preview", status: "finished" },
  { id: "a3", platform: "android", profile: "production", status: "errored" },
  { id: "i2", platform: "ios", profile: "preview-device", status: "finished" },
  { id: "i3", platform: "ios", profile: "production", status: "in-progress" },
];
submit(latest(builds, "android")); // eas submit -p android --latest
submit(latest(builds, "ios")); // eas submit -p ios --latest
submit(builds.find((b) => b.id === "a2")); // eas submit -p android --id a2

Для Android выбрана a1, хотя после неё были ещё две сборки. preview собирается с distribution: "internal" и под фильтр «для магазина» не подходит, а упавшая a3 отсеялась по статусу. Поэтому --latest не отправит в Google Play тестовый .apk, даже если он самый свежий. Для iOS выбрана i3, которая ещё собирается: недостроенная сборка фильтр проходит. Отправка встанет ждать её со строкой «Submitting your app to Apple App Store Connect: waiting for the associated build to complete». Если последняя сборка для магазина — не та, что вы хотели отправить, --latest об этом не спросит.

Третья команда называет сборку по ID. Фильтра здесь нет, профиля отправки preview тоже нет, и eas-cli одной строкой перешёл на production. В Google Play поехал бы .apk, а новые приложения Google Play с августа 2021 года принимает только в формате App Bundle. У iOS схема дописывает один язык. Он нужен, когда eas-cli сам заводит запись приложения в App Store Connect. ascAppId, Apple ID и ключ API он либо спросит, либо найдёт на серверах EAS.

Слияние у профилей отправки ещё проще, чем у профилей сборки: extends раскрывается, но от каждого профиля берётся только секция нужной платформы, и сливается она в один уровень. Как собрать на этом профиль постепенного выката — первая задача к статье.

Первая отправка в Google Play по умолчанию уходит на внутренний тест, а не в продакшн. Так решает схема eas.json, а не вы.

Требования бывают двух видов. Одни проверяет автомат при загрузке, и отправка падает сразу. Другие смотрят люди на проверке, и отказ приходит через день. Вот главные для «Подхода»:

Отдельно проверяют карточку. Иконку для Google Play, 512 на 512, обещала прошлая статья.

Иконку карточки Google Play скругляет сам, и радиус его маски уже менялся. Спецификация 2019 года обещала скругление в 20% стороны, нынешняя — 30%, то есть 153,6 пикселя из 512. У автора в icon-512.png тёмный квадрат скруглён радиусом 112 и лежит на белом, это мы выяснили в прошлой статье. В подложке он нарисован тем же SVG, что и там, а рядом — квадрат в край, как просит спецификация. Маску карточки изображает View с overflow: "hidden", как маску лаунчера в статье «Иконка, сплэш, имя, версия», а белые пиксели под маской считает функция подложки через холст страницы. Прогноз: у какой иконки под какой маской останутся белые углы?

declare const cardIcons: { author: string; fullBleed: string };
// из подложки: сколько чисто белых пикселей видно под маской — холст есть у страницы, у примера его нет
declare function whiteUnderMask(uri: string, radiusShare: number): Promise<number>;
const { View, Image, StyleSheet } = ReactNative;

interface CardIconProps {
  uri: string;
  percent: number;
}

const SIZE = 128;
// радиус маски карточки в процентах стороны: по спецификации 2019 года и по нынешней
const masks = [20, 30];

// маску Google Play изображает View: overflow прячет всё, что за скруглением
function CardIcon({ uri, percent }: CardIconProps) {
  return (
    <View style={[styles.mask, { borderRadius: (SIZE * percent) / 100 }]}>
      <Image source={{ uri }} style={styles.icon} />
    </View>
  );
}

const styles = StyleSheet.create({
  // серый фон вместо витрины магазина: на белой странице белые углы не разглядеть
  row: { flexDirection: "row", gap: 12, padding: 12, backgroundColor: "#e5e5e5" },
  mask: { width: SIZE, height: SIZE, overflow: "hidden" },
  icon: { width: SIZE, height: SIZE },
});

mount(
  <View>
    {Object.entries(cardIcons).map(([name, uri]) => (
      <View key={name} style={styles.row}>
        {masks.map((percent) => <CardIcon key={percent} uri={uri} percent={percent} />)}
      </View>
    ))}
  </View>,
);

async function report() {
  for (const [name, uri] of Object.entries(cardIcons)) {
    for (const percent of masks) {
      const white = await whiteUnderMask(uri, percent / 100);
      console.log(name + " · маска " + percent + "%: " + (white > 0 ? "белые углы видны" : "белого нет"));
    }
  }
}
report();

Под нынешней маской белого нет: её скругление больше, чем 112 из 512, и Google срезает углы глубже, чем их скруглил автор. Под маской 2019 года по углам проступила бы белая кайма. Она тонкая: на диагонали угла скругление 112 отступает от края на 46,4 пикселя из 512, а маска 20% — на 42,4, так что белого остаётся полоска около четырёх пикселей. На экране примера иконка вчетверо меньше, кайма там уже пикселя и видна разве что светлым ободком на углу — поймал её счёт пикселей, а не глаз. Выходит, иконка автора проходит по совпадению: стоит Google снова уменьшить радиус, и кайма вернётся. Квадрат в край переживает любую маску, поэтому его и просят спецификации Google и Apple. Прозрачные углы тоже не выход: сквозь них на карточке проступит фон самого магазина.

Анкеты, демо-аккаунт и удаление аккаунта готовят до отправки на проверку: автомат их не ловит, отказ придёт от проверяющего.

В Google Play «All done!» значит, что на треке создан выпуск. Треков четыре вида: внутренний тест (internal) до 100 тестировщиков из списка, закрытый (alpha и свои закрытые треки), открытый (beta) и production. Первая отправка с профилем автора ляжет во внутренний тест. Expo пишет, что такой первый выпуск eas submit создаёт сам. Если же Google ответит «Only releases with status draft may be created on draft app», приложение ещё числится черновиком. Тогда API примет выпуск только с releaseStatus: "draft", а довести его придётся кнопкой в консоли.

До продакшна у нового личного аккаунта есть обязательная остановка. Если личный аккаунт в Play Console создан после 13 ноября 2023 года, приложение должно пройти закрытый тест: не меньше 12 тестировщиков, подписанных без перерыва хотя бы 14 дней. Только потом в консоли подают заявку на доступ к продакшну и отвечают на вопросы о тесте. Для «Подхода» это две недели, которые стоит заложить в план до даты релиза. Дальше выпуск в production уходит на проверку, а выкатить его можно постепенно: releaseStatus: "inProgress" с долей rollout. Долю поднимают в консоли, а halted останавливает выкат.

У App Store путь другой. eas submit кладёт .ipa в App Store Connect, и больше ничего:

$ eas submit --platform ios --latest

Сборка сначала обрабатывается, об этом говорит сам eas-cli. Потом она появляется в TestFlight. Внутренние тестировщики из вашей команды получают её сразу, а внешним первую сборку показывают только после проверки бета-версии. На проверку в App Store eas submit не отправляет. Это делают в App Store Connect: создают версию, выбирают сборку, заполняют карточку и анкеты и отправляют заявку. После одобрения версию выпускают вручную, автоматически или не раньше заданной даты. Обновления, но не первую версию, можно выкатывать постепенно — семь дней, на 1, 2, 5, 10, 20, 50 и 100% пользователей с автоматическими обновлениями. Паузы в сумме — до 30 дней.

У RuStore шаги видны прямо в API: черновик версии, загрузка файлов, отправка на модерацию. Что будет после одобрения, решает publishType черновика: INSTANTLY (по умолчанию) — выпустить сразу, MANUAL — ждать вашей кнопки, DELAYED — выпустить в publishDateTime. Постепенный выкат задаёт partialValue: 5, 10, 25, 50, 75 или 100 процентов.

У eas submit два магазина, и RuStore среди них нет. Вместо этого у RuStore есть Public API: получить токен, создать черновик версии, загрузить файл, отправить на модерацию. Ниже набросок по документации API. Ключей RuStore у нас нет, поэтому скрипт не запускался:

// scripts/rustore-publish.mjs — отправка в RuStore через Public API: своего пути в EAS у RuStore нет
import { createPrivateKey, sign } from "node:crypto";
import { openAsBlob } from "node:fs";

const API = "https://public-api.rustore.ru/public";
const PACKAGE = "com.podhod.app";

// токен: подпись SHA512withRSA над идентификатором ключа и временем; живёт 900 секунд
async function getToken() {
  const keyId = process.env.RUSTORE_KEY_ID;
  const timestamp = new Date().toISOString();
  // закрытый ключ API из консоли RuStore, приведённый к PEM
  const key = createPrivateKey(process.env.RUSTORE_PRIVATE_KEY_PEM);
  const signature = sign("sha512", Buffer.from(keyId + timestamp), key).toString("base64");
  const res = await fetch(`${API}/auth/`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ keyId, timestamp, signature }),
  });
  return (await res.json()).body.jwe;
}

// ответы API обёрнуты одинаково: { code, message, body, timestamp }
async function call(token, path, init = {}) {
  const res = await fetch(`${API}/v1/application/${PACKAGE}${path}`, {
    ...init,
    headers: { "Public-Token": token, ...init.headers },
  });
  const json = await res.json();
  if (json.code !== "OK") throw new Error(json.message);
  return json.body;
}

const token = await getToken();
// черновик у приложения один: второй такой запрос вернёт ошибку
const versionId = await call(token, "/version", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    developerContacts: { email: "…" },
    whatsNew: "…",
    publishType: "MANUAL", // после модерации выпустить кнопкой, а не сразу
  }),
});
const form = new FormData();
// какой именно APK класть сюда — ниже, в разборе подписи
form.append("file", await openAsBlob("./podhod-universal.apk"), "podhod-universal.apk");
await call(token, `/version/${versionId}/apk?isMainApk=true`, { method: "POST", body: form });
await call(token, `/version/${versionId}/commit`, { method: "POST" });

Токен живёт 900 секунд и передаётся в заголовке Public-Token. Черновик у приложения может быть только один. Главный APK помечается isMainApk=true: без такого файла версию на модерацию не отправить. Для .aab есть свой адрес, /aab. Но RuStore сам нарезает из набора APK и подписывает их ключом подписи приложения, а этот ключ нужно заранее загрузить в консоль. RuStore ключей не генерирует и не хранит их за вас.

Какой APK положить в form? Кажется, что подойдёт APK, подписанный тем же keystore из EAS, — собранный профилем с buildType: "apk" или вынутый из .aab. Здесь и ловушка. С Play App Signing Google Play подписывает APK для телефонов своим ключом подписи приложения. Keystore, который создал EAS, для Google — лишь ключ загрузки: им подписан отправленный .aab. RuStore же отдаёт APK с той подписью, с которой его загрузили. Android ставит обновление поверх установленного приложения, только если сертификат совпадает. Два телефона, на обоих «Подход» из Google Play. Прогноз: что увидят Анна и Борис?

interface Apk {
  versionCode: number;
  signer: string;
}
interface Phone {
  owner: string;
  installed: Apk;
  diary: string[];
}

// keystore, которым EAS подписал сборку, и ключ, которым Google Play подписывает APK для телефонов
const EAS_KEY = "keystore EAS";
const GOOGLE_KEY = "ключ подписи Google Play";

// Google Play принимает .aab с подписью ключа загрузки, а на телефон отдаёт APK со своей подписью
function fromGooglePlay(versionCode: number): Apk {
  return { versionCode, signer: GOOGLE_KEY };
}

// Android ставит обновление поверх, только если сертификат тот же, а номер больше
function offer(phone: Phone, store: string, apk: Apk): void {
  const where = phone.owner + " · " + store + " " + apk.versionCode + ": ";
  if (apk.signer !== phone.installed.signer) return console.log(where + "INSTALL_FAILED_UPDATE_INCOMPATIBLE");
  if (apk.versionCode <= phone.installed.versionCode) return console.log(where + "обновления нет");
  phone.installed = apk;
  console.log(where + "обновлено, записей в дневнике " + phone.diary.length);
}

// то, что RuStore предлагает при чужой подписи: удалить приложение и поставить заново
function reinstall(phone: Phone, store: string, apk: Apk): void {
  phone.installed = apk;
  phone.diary = [];
  console.log(phone.owner + " · " + store + " " + apk.versionCode + ": переустановлено, записей в дневнике " + phone.diary.length);
}

const anna: Phone = { owner: "Анна", installed: fromGooglePlay(2), diary: ["жим", "присед", "тяга"] };
const boris: Phone = { owner: "Борис", installed: fromGooglePlay(2), diary: ["жим", "присед"] };

// RuStore отдаёт APK как загружен: здесь — APK с подписью keystore EAS и versionCode 3
const easApk: Apk = { versionCode: 3, signer: EAS_KEY };
offer(anna, "RuStore", easApk);
reinstall(anna, "RuStore", easApk);
offer(anna, "Google Play", fromGooglePlay(4));

// в RuStore вместо своей сборки — подписанный универсальный APK из Play Console
const playApk: Apk = { versionCode: 3, signer: GOOGLE_KEY };
offer(boris, "RuStore", playApk);
offer(boris, "Google Play", fromGooglePlay(4));

У Анны Android отказал с INSTALL_FAILED_UPDATE_INCOMPATIBLE, и RuStore в таком случае предлагает удалить приложение и поставить заново. Для обычного приложения это просто повторный вход. Для «Подхода» — потеря: главная копия дневника и неотправленный журнал из главы 6 лежат в файле базы, а удаление приложения стирает его. Синхронизированное вернётся с сервера после входа, неотправленное — нет. Хуже того, ловушка работает в обе стороны: теперь у Анны подпись EAS, и следующее обновление из Google Play не встанет тоже.

Борис получил в RuStore APK с подписью Google, и оба магазина обновляют его по очереди. Такой файл выдаёт сама Play Console: в разделе Test and release → Latest releases and bundles выбрать набор, открыть вкладку Downloads и скачать строку «Signed, universal APK» — один APK, подписанный тем же ключом, что и приложение в Google Play. Справка Google прямо предлагает раздавать его в других магазинах и на сайтах, чтобы приложение везде было подписано одним ключом. Второй путь, из той же справки, — при создании приложения передать Google копию своего ключа подписи и подписывать им сборки для всех магазинов. Если ключ сгенерировал Google, .aab в RuStore отправить не выйдет: ключа подписи у вас нет. Остаётся универсальный APK.

Вопрос подписи решают до первой публикации во втором магазине. У тех, кто уже поставил приложение с другой подписью, обновление поверх не встанет — только переустановка.

Подпись и номер сборки — два замка, которыми Android стережёт уже установленное приложение: обновление встаёт поверх, только если сертификат тот же, а номер больше. Магазин при этом — не единственный путь нового кода на телефон. Следующая глава — об обновлениях по воздуху и о третьем замке, runtimeVersion. Этот замок решает, какому из установленных бинарников можно прислать новый бандл по воздуху, без новой сборки и без очереди на проверку.