Публикация в App Store и Google Play

Приложение в сторе всегда принадлежит аккаунту разработчика, и имя владельца аккаунта видят пользователи как продавца. Поэтому первый вопрос релиза — не технический: на кого регистрировать аккаунт. У обеих платформ есть личные аккаунты и аккаунты организаций, и требования к ним разные.

D-U-N-S — девятизначный идентификатор организации в базе Dun & Bradstreet. По справке Google Play его можно получить бесплатно, но процесс занимает до 30 дней, а платные посредники для этого не нужны. Закладывайте этот срок в план, если у компании номера ещё нет.

У приложения три вида «имени», и путать их нельзя. Идентификатор — bundleIdentifier на iOS и package (applicationId) на Android — уникален в сторе и после публикации не меняется: новый идентификатор означает новое приложение. Версия для пользователей (1.2.0) видна в карточке. Номер сборки (build number на iOS, versionCode на Android) нужен только сторам и должен расти с каждой загрузкой.

По документации Expo, одна из частых причин отказа при загрузке — повторный номер сборки: разработчик забыл его увеличить. Поэтому Expo рекомендует хранить номера сборок на серверах EAS (appVersionSource: "remote") и увеличивать их автоматически, а версию для пользователя менять вручную при каждом релизе.

Подпись подтверждает, что обновление выпустил тот же разработчик. На Android используется схема из двух ключей: вы подписываете .aab upload-ключом, а Google по Play App Signing переподписывает APK ключом подписи приложения, который хранит у себя. Для новых приложений Play App Signing обязательна. Если upload-ключ потерян или скомпрометирован, его можно сбросить через Play Console. На iOS нужны сертификат распространения (distribution certificate, общий для всех приложений аккаунта) и профиль подготовки (provisioning profile) для каждого приложения; профили действуют 12 месяцев, но их истечение не влияет на уже опубликованное приложение.

EAS Build собирает подписанные .aab и .ipa в облаке Expo, EAS Submit загружает их в Google Play Console и App Store Connect. Оба работают с macOS, Linux и Windows, так что для выпуска iOS-версии из Expo-проекта Mac не обязателен. Начните с идентификаторов в конфигурации приложения.

{
  "expo": {
    "name": "Callback",
    "slug": "callback",
    "version": "1.0.0",
    "orientation": "portrait",
    "icon": "./assets/icon.png",
    "userInterfaceStyle": "light",
    "ios": {
      "bundleIdentifier": "kz.example.callback",
      "supportsTablet": false
    },
    "android": {
      "package": "kz.example.callback",
      "adaptiveIcon": {
        "backgroundColor": "#E6F4FE",
        "foregroundImage": "./assets/android-icon-foreground.png",
        "backgroundImage": "./assets/android-icon-background.png",
        "monochromeImage": "./assets/android-icon-monochrome.png"
      }
    }
  }
}

{
  "cli": {
    "version": ">= 18.0.0",
    "appVersionSource": "remote"
  },
  "build": {
    "preview": {
      "distribution": "internal",
      "android": {
        "buildType": "apk"
      }
    },
    "production": {
      "autoIncrement": true
    }
  },
  "submit": {
    "production": {
      "android": {
        "track": "internal",
        "releaseStatus": "draft"
      },
      "ios": {
        "ascAppId": "1234567890"
      }
    }
  }
}

• cli.appVersionSource: "remote" и autoIncrement: true — EAS сам увеличивает versionCode и build number при каждой продакшн-сборке.
• Профиль preview собирает APK для установки на устройства команды; в Google Play APK не загрузить — для стора нужен .aab, его и собирает профиль production по умолчанию.
• track: "internal" отправляет сборку во внутреннее тестирование, releaseStatus: "draft" создаёт черновик релиза без выкатки — завершаете его в Play Console.
• Для отправки в Google Play EAS нужен JSON-ключ сервисного аккаунта Google: его загружают в EAS через панель или eas credentials.

npm install --global eas-cli
eas login

# сборка для сторов: .aab для Google Play и .ipa для App Store
eas build --platform all --profile production

# отправка последней сборки по профилю submit.production
eas submit --platform android --latest
eas submit --platform ios --latest

# или сборка и отправка одной командой
eas build --platform all --profile production --auto-submit

$ npx expo config --type public --json
{
  "name": "Callback",
  "slug": "callback",
  "version": "1.0.0",
  "sdkVersion": "57.0.0",
  "platforms": ["ios", "android"],
  "ios": {
    "bundleIdentifier": "kz.example.callback",
    "supportsTablet": false
  },
  "android": {
    "package": "kz.example.callback",
    ...
  }
}

После eas submit iOS-сборка появляется в TestFlight после обработки, а в App Review её отправляют вручную в App Store Connect. В Google Play первая отправка создаёт релиз во внутреннем тестировании, но приложение остаётся черновиком, пока не заполнены карточка и разделы App content.

Во Flutter версия задаётся одной строкой в pubspec.yaml, а сборки — командами Flutter CLI. Android-сборку подписывают upload-ключом через android/key.properties, iOS собирают только на Mac с Xcode.

version: 1.0.0+1

# Android: App Bundle, подписанный upload-ключом из android/key.properties
flutter build appbundle
# результат: build/app/outputs/bundle/release/app.aab

# iOS (только macOS с Xcode): архив и .ipa для App Store Connect
flutter build ipa
# результат: build/ios/ipa/*.ipa — загрузка через Transporter или Xcode

Альтернативы EAS: локальная сборка (eas build --local), Android Studio и Xcode вручную, а для CI — инструменты вроде Codemagic и fastlane, которые упоминает документация Flutter. Механика везде одна: подписанный артефакт с новым номером сборки загружается в консоль стора.

Карточка — то, что видит пользователь до установки, и то, что первым проверяет ревьюер. Требования App Review прямо говорят: метаданные, включая описание, скриншоты и информацию о приватности, должны точно отражать основной опыт приложения, а скриншоты — показывать приложение в работе, а не только заставку или экран входа.

Политика конфиденциальности — это публичная страница на сайте, а не PDF в почте. Она описывает, какие данные собирает приложение, зачем, кому передаёт и как пользователь может их удалить. Ответы в App Privacy и Data safety должны совпадать с реальным поведением приложения и всех подключённых библиотек: аналитики, рекламы, SDK для push-уведомлений. За расхождения Google применяет санкции, а Apple требует держать ответы актуальными.

Apple сообщает, что в среднем более 40% нерешённых проблем на ревью связаны с правилом 2.1 App Completeness — завершённостью приложения. По данным той же страницы, App Review рассматривает не менее 50% заявок быстрее чем за 24 часа и 90% — быстрее чем за 48 часов; неполная заявка рассматривается дольше. Google Play сроков ревью в справке о подготовке к проверке не называет.

Если App Review отклонил сборку, в App Store Connect указано, какие правила нарушены, и можно переписываться с ревьюером, чтобы решить вопрос до повторной отправки. Если вы считаете, что приложение поняли неверно, есть апелляция в App Review Board — одна на каждую отклонённую заявку, с конкретными доводами. Для Google Play порядок тот же: исправьте приложение или декларации в Play Console и отправьте исправленную версию на повторную проверку.

Каждый новый бинарник проходит тот же путь: новый номер сборки, загрузка, ревью. Expo-проекты могут доставлять часть изменений по воздуху (OTA, over-the-air) через EAS Update: приложение с библиотекой expo-updates скачивает новый JavaScript-бандл и ресурсы при следующем запуске.

npx expo install expo-updates
eas update:configure
# после новой сборки с expo-updates:
eas update --channel production --message "Fix login button alignment"

Дальше — эксплуатация: следите за отчётами о падениях в консолях сторов, отвечайте на отзывы и планируйте обновления под регулярное повышение требований Google Play к целевому API Android. Если приложение использует push-уведомления, проверьте ключи APNs и настройки Firebase до релиза — об этом отдельный материал.