Особенности «сборки» мобильных приложений
«Разбираемся в вопросе сборки приложений на разные площадки»
🕒 Время прочтения: 4 минуты
В сегодняшней статье мы решили по шагам пройтись в таком вопросе как сборки проектов для магазинов AppStore и Play Market.
Хотим показать наглядно нашим клиентам, что это за работы и сколько времени нужно потратить на сборку вашего приложения…
1️⃣ СБОРКА В «APP STORE»
Каждый человек, так или иначе связанный с разработкой приложений для устройств Apple, уже успел оценить спорное удобство инфраструктуры. Сложности встречаются повсюду: начиная с меню профиля разработчика и заканчивая инструментами отладки и сборки.
Статей об «азах» предостаточно в сети, поэтому постараемся выделить главное. Вот что нужно для успешной сборки приложения:
- аккаунт разработчика;
- устройство на базе macOS, выступающее в роли билд-сервера;
- сгенерированный сертификат разработчика, который будет далее использоваться для подписи приложения;
- созданное приложение с уникальным ID (следует отметить важность Bundle Identifier, потому что применение wildcard ID делает невозможным использование многих функций приложения, например: Associated Domains, Push Notifications, Apple Sign In и прочих);
- профиль подписи приложения.
Сертификат разработчика следует сгенерировать через Keychain на любом устройстве на базе macOS. Очень важным является тип сертификата. В зависимости от среды приложения (Dev, QA, Staging, Production) он будет различаться (Development или Distribution), так же как и тип профиля подписи приложения.
- Development — предназначен для подписи приложения команды разработчиков, используется Development-сертификат (имя вида iPhone Developer: XXXXX);
- Ad Hoc — предназначен для подписи тестового приложения и внутренней проверки QA-отделом, используется Distribution-сертификат разработчика (имя вида iPhone Distribution: XXXXX);
- App Store — релизный билд для внешнего тестирования через TestFlight и выгрузки в App Store, используется Distribution-сертификат разработчика.
При генерации профилей Development и Ad Hoc также указывается список устройств, на которые можно установить билд, что позволяет дополнительно разграничить доступ для пользователей. В профиле App Store нет списка устройств, так как разграничением доступа при закрытом бета-тестировании занимается TestFlight, о котором будет рассказано позже.
Для наглядности можно представить профиль разработчика в виде таблички ниже. Так проще понять, какие параметры для сборки нам нужны и откуда их брать.
Чтобы было проще разделять сборки по проекту и среде, используем имена профилей вида
${ProjectName}_${Instance}
, то есть имя проекта + инстанс (зависит от среды приложения: Dev, QA, GD, Staging, Live и так далее).
При импорте на билд-сервер профиль меняет название на уникальный ID и перемещается в папку
/Users/$Username/Library/MobileDevice/Provisioning Profiles
$Username
соответствует имени учетной записи пользователя билд-сервера).
Существует два способа сборки файла *.ipa — устаревший (PackageApplication) и современный (через создание XcAchive и экспорт). Первый способ считается устаревшим, так как с версии 8.3 модуль упаковки app-файла убран из дистрибутива Xcode. Для его использования надо скопировать модуль из старого Xcode (версии 8.2 и более ранних) в папку:
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/
chmod +x /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/*
Далее нужно собрать *.app-файл приложения:
xcodebuild \\ -workspace $ProjectDir/$ProjectName.xcworkspace \\ -scheme $SchemeName \\ -sdk iphoneos \\ build \\ -configuration Release \\ -derivedDataPath build \\ CODE_SIGN_IDENTITY=”$DevAccName”\\ PROVISIONING_PROFILE=”$ProfileId” DEPLOYMENT_POSTPROCESSING=YES \\ SKIP_INSTALL=YES \\ ENABLE_BITCODE=NO
-workspace — путь к файлу проекта. -scheme — используемая схема, указанная в проекте. -derivedDataPath — путь выгрузки собранного приложения (*.app). CODE_SIGN_IDENTITY — имя аккаунта разработчика, которое можно проверить в Keychain (iPhone Developer: XXXX XXXXXXX, без TeamID в скобках).
PROVISIONING_PROFILE — ID профиля для подписи приложения, который можно получить командой:
cd "/Users/$Username/Library/MobileDevice/Provisioning Profiles/" && find *.mobileprovision -type f | xargs grep -li ">${ProjectName}_${Instance}<" | sed -e 's/.mobileprovision//'
Если в приложении используется дополнительный профиль (например, для Push Notifications), то вместо PROVISIONING_PROFILE, указываем:
APP_PROFILE=”$AppProfile” \\ EXTENSION_PROFILE=”$ExtProfile” \\
Далее полученный файл *.app следует упаковать в *.ipa. Для этого можно использовать команду вида:
/usr/bin/xcrun --sdk iphoneos PackageApplication \\ -v $(find "$ProjectDir/build/Build/Products/Release-iphoneos" -name "*.app") \\ -o "$ProjectDir/$ProjectName_$Instance.ipa"
Однако данный способ считается устаревшим с точки зрения Apple. Актуальным является получение *.ipa путем экспорта из архива приложения.
Для начала нужно собрать архив командой:
xcodebuild \\ -workspace $ProjectDir/$ProjectName.xcworkspace \\ -scheme $SchemeName \\ -sdk iphoneos \\ -configuration Release \\ archive \\ -archivePath $ProjectDir/build/$ProjectName.xcarchive \\ CODE_SIGN_IDENTITY=”$DevAccName” \\ PROVISIONING_PROFILE=”$ProfileId” ENABLE_BITCODE=NO \\ SYNCHRONOUS_SYMBOL_PROCESSING=FALSE
Отличия заключаются в методе сборки и опции SYNCHRONOUS_SYMBOL_PROCESSING , которая отключает выгрузку символов во время сборки.
Далее нам надо сгенерировать файл с настройками экспорта:
ExportSettings="$ProjectDir/exportOptions.plist" cat << EOF > $ExportSettings <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict> <key>compileBitcode</key> <false/> <key>uploadBitcode</key> <false/> <key>uploadSymbols</key> <false/> <key>method</key> <string>$Method</string> <key>provisioningProfiles</key> <dict> <key>$BundleID</key> <string>$ProfileId</string> </dict> <key>signingCertificate</key> <string>$DevAccName</string> <key>signingStyle</key> <string>manual</string> <key>stripSwiftSymbols</key> <true/> <key>teamID</key> <string>$TeamID</string> <key>thinning</key> <string><none></string> </dict> </plist> EOF
$Method — метод доставки, соответствует типу профиля подписи приложения, то есть для Development значение будет development, для Ad Hoc — ad-hoc, а для App Store — app-store. $BundleID — ID приложения, который указан в настройках приложения. Проверить можно командой: defaults read $ProjectDir/Info CFBundleIdentifier $DevAccName и $ProfileId — настройки имени разработчика и ID профиля подписи, которые использовались ранее и должны совпадать со значениями в настройках экспорта. $TeamID — десятизначный ID в скобках после имени разработчика, пример: iPhone Developer: …… (XXXXXXXXXX); можно проверить в Keychain.
Далее с помощью команды экспорта получаем необходимый файл *.ipa:
xcodebuild \\ -exportArchive \\ -archivePath $ProjectDir/build/$ProjectName.xcarchive \\ -exportPath $ProjectDir \\ -exportOptionsPlist $ExportSettings
Теперь собранный файл нужно доставить конечному пользователю, то есть установить на конкретное устройство.
Для распространения билдов Development и Ad Hoc существует множество сервисов вроде HockeyApp, AppBlade и прочих, однако в рамках данной статьи речь пойдет об автономном сервере для раздачи приложений.
Установка приложения для iOS проходит в 2 этапа:
- Получение манифеста установки приложения через Items Service.
- Установка файла *.ipa согласно информации, указанной в манифесте, через HTTPS.
Таким образом, нам для начала надо сгенерировать манифест установки (тип файла *.plist) командой:
cat << EOF > $manifest <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict> <key>items</key> <array> <dict> <key>assets</key> <array> <dict> <key>kind</key> <string>software-package</string> <key>url</key> <string>$ipaUrl</string> </dict> </array> <key>metadata</key> <dict> <key>bundle-identifier</key> <string>$BundleID</string> <key>bundle-version</key> <string>$AppVersion</string> <key>kind</key> <string>software</string> <key>title</key> <string>$ProjectName_$Instance</string> <key>subtitle</key> <string>$Instance</string> </dict> </dict> </array> </dict> </plist> EOF
Как видим, манифест содержит практически все параметры, участвующие в сборке приложения.
Версию приложения ($AppVersion) можно проверить командой:
defaults read $ProjectDir/Info CFBundleVersion
Параметр $ipaUrl содержит прямую ссылку на скачивание файла *.ipa. С седьмой версии iOS приложение должно быть установлено через HTTPS. В восьмой версии немного изменился формат манифеста: были удалены блоки с настройками иконок приложения вида
<images> <image>...</image> </images>
Таким образом, для установки приложения достаточно простой html-страницы со ссылкой вида:
itms-services://?action=download-manifest&url=https://$ServerUrl/$ProjectName/$Instance/iOS/$AppVersion/manifest.plist
Теперь речь пойдет о предрелизном тестировании приложения с помощью TestFlight.
Обязательными условиями для загрузки являются тип профиля подписи App Store и наличие сгенерированных API-ключей.
Есть несколько способов загрузки приложения:
- через Xcode (Organizer),
- через altool,
- через Application Loader для старых версий Xcode (теперь Transporter).
Для автоматической загрузки используется altool, в котором тоже есть два способа авторизации:
Более предпочтительной является загрузка приложения с помощью API Key.
Для получения API Key переходим по ссылке и генерируем ключ. Кроме самого ключа в формате *.p8, нам понадобятся два параметра: IssuerID и KeyID.
Далее скачанный ключ импортируем на билд-сервер:
mkdir -p ~/.appstoreconnect/private_keys
mv ~/Downloads/AuthKey_${KeyID}.p8 ~/.appstoreconnect/private_keys/
Перед загрузкой приложения в TestFlight нужно выполнить валидацию приложения, делаем это командой:
xcrun altool \\ --validate-app \\ -t ios \\ -f $(find "$ProjectDir" -name "*.ipa") \\ --apiKey “$KeyID” \\ --apiIssuer “$IssuerID”
, где apiKey и apiIssuer имеют значения полей со страницы генерации API-ключа.
Далее при успешной валидации выполняем загрузку приложения командой --upload-app c теми же параметрами.
Приложение будет проверено Apple в течение одного-двух дней и после станет доступным внешним тестировщикам: им пришлют на почту ссылки для установки.
Другим способом загрузки приложения через altool является использование App-Specific Password.
Для получения App-Specific Password нужно перейти по ссылке и сгенерировать его в разделе Security.
Далее следует создать в Keychain запись билд-сервера с этим паролем. С 11 версии Xcode это можно сделать командой:
xcrun altool --store-password-in-keychain-item "Altool" -u "$DeveloperName" -p $AppPswd
$DeveloperName — имя аккаунта iOS-разработчика, используемое для логина в сервисы Apple. $AppPswd — сгенерированный App-Specific Password.
Далее получаем значение параметра asc-provider и проверяем успешность импорта пароля командой:
xcrun altool --list-providers -u "$DeveloperName" -p "@keychain:Altool"
Provider listing: - Long Name - - Short Name - XXXXXXX XXXXXXXXX
Как видим, искомое значение Short Name (asc-provider) совпадает с параметром $TeamID, который мы использовали при сборке приложения.
Для валидации и загрузки приложения в TestFlight применяем команду:
xcrun altool \\ --(validate|upload)-app \\ -f $(find "$ProjectDir" -name "*.ipa") \\ -u "$DeveloperName" \\ -p "@keychain:Altool" \\
В качестве значение параметра -p можно взять значение $AppPswd в незашифрованном (явном) виде.
Однако, как уже было сказано, с точки зрения работоспособности для авторизации altool лучше выбрать API Key, так как в разных версиях Xcode встречаются те или иные проблемы («не видит» Keychain, ошибки авторизации при выгрузке и прочее).
На этом, собственно, все со сборкой для AppStore. Едем дальше 👇🏻
2️⃣ СБОРКА В «PLAY MARKET»
2.1. Создаём аккаунт разработчика в Google Play Console Кто этим занимается: менеджер или клиент.
В инструкции по публикации приложений в App Store мы рассказывали, что для релиза приложения от юридического лица вам нужно получить для своей компании уникальный D- U-N-S number. С ним имя разработчика вашего приложения будет выглядеть как ООО «Ваша Компания».
В Google Play Console нет необходимости проверять подлинность юридического лица: если вы хотите опубликовать приложение от имени компании, вы просто регистрируете аккаунт от имени компании. Таким образом, на создание аккаунта разработчика в Google у вас уйдёт не больше одного дня.
a) Создаём аккаунт Google на имя вашей компании.
b) Открываем Google Play Console, регистрируем аккаунт разработчика, принимаем условия.
c) Оплачиваем аккаунт при помощи банковской карты — $25.
d) Заполняем данные о разработчике и завершаем регистрацию.
Что может пойти не так на этапе регистрации
Если по каким-то причинам оплата в Google Play не проходит, а дедлайны горят, вы можете опубликовать приложение с аккаунта студии мобильной разработки — с вероятностью 99,9% он у неё есть. Уже после релиза менеджеры переведут приложение на ваш аккаунт, чтобы все права и маркетинговое имя оставались за вами.
Мы не можем опубликовать приложение, не согласившись с требованиями Google. Вот основные вещи, за которые владелец приложения берёт ответственность на себя:
- Вы полностью отвечаете за ваш продукт и поставляемый в нём контент.
- Вы обязуетесь отвечать на вопросы пользователей в течение трёх рабочих дней и на «срочные вопросы, согласно определению Google» в течение 24 часов.
- Обязуетесь сохранять конфиденциальность и безопасность пользовательских данных.
- Вы не пытаетесь обманывать, причинять какой-либо вред или вводить в заблуждение пользователя и компанию Google.
- Вы не распространяете запрещённый контент. Все Продукты, распространяемые через Google Play, должны соответствовать Правилам программы для разработчиков.
- Вы разрешаете Google возвращать покупателю полную стоимость Продукта или транзакции внутри приложения от вашего имени, если покупатель запрашивает возврат средств в любой момент после покупки. Удаление продукта не освобождает вас от ответственности перед какими-либо выплатами.
Чтобы некоторые пункты не стали для вас сюрпризом, ознакомьтесь с действующим пользовательским соглашением Google Play.
2.2 Указываем информацию о приложении Кто этим занимается: менеджер или клиент.
После регистрации в Google Play Console мы попадаем на вкладку All apps (Все приложения), нажимаем кнопку Create app (Создать приложение) и начинаем заполнять информацию о приложении.
Чтобы поменять язык консоли на русский, откройте страницу своегогугл-аккаунта. Зайдите в раздел Data & Personalisation в меню слева. В поисковой строке наберите language, нажмите Enter. На открывшейся странице нажмите на стрелочку в поле «Русский» и обновите Google Play Console.
Сначала консоль просит указать имя, язык, тип (приложение/игра) и способ распространения (платно/бесплатно) приложения, а потом перенаправляет нас на пошаговую настройку в разделе Dashboard (Панель управления).
Если ваше приложение платное, то перед тем, как продолжить заполнение анкеты, вам предстоит настроить платёжный профиль.
Обновлённая консоль предлагает нам список задач, которые нужно выполнить для завершения настройки. Каждая задача — гиперссылка: нажимаем на любую из них и попадаем на нужную вкладку.
2.3 Предоставляем сведения о контенте
- Настройка доступа (App access) — указываем, требуется ли отдельным пользователям специальный доступ к нашему приложению (например, жителям Австралии). Если требуется, мы должны добавить инструкции, на основании которых этот доступ будет им предоставлен.
- Встроенная реклама (Ads) — если ваше приложение содержит рекламу, то в сторе рядом с его иконкой появится соответствующий значок.
- Возрастной рейтинг (Content rating) приложение получит после того, как мы ответим на вопросы о его содержании. Google проверяет ответ на соответствие действительности, поэтому будет лучше, если вы заполните анкету честно.
По результатам опроса система сама присвоит приложению нужный рейтинг.
- Целевая аудитория (Target audience) — по правилам Google, мы обязаны описать целевую аудиторию приложения. Это сделано, чтобы уберечь разные группы пользователей от потенциально неприемлемого контента.
Решённые задачи автоматически вычёркиваются из списка.
2.4 Указываем данные для распространения приложения
- Категория и контактные данные (Select an app category and provide contact details) — на этой странице мы выбираем тип приложения, тематическую категорию и добавляем теги, которые лучше всего описывают содержание или основные функции приложения, а также заполняем данные для связи с разработчиком.
- Настройка страницы приложения (Set up your Store Listing) — загрузка маркетинговых материалов — это последний шаг первичной настройки страницы приложения в Google Play. Подробнее об этом — в следующей главе.
2.5 Загружаем маркетинговые материалы Кто этим занимается: менеджер проекта, дизайнер, разработчик и/или клиент.
Перед релизом дизайнер и менеджер проекта готовят маркетинговые материалы для карточки приложения в Google Play. Они должны соответствовать задачам проекта и требованиям Google.
Для срочных релизов и проверки MVP можно сделать маркетинговые материалы, соответствующие только требованиям стора. В остальных случаях подготовка маркетинговых материалов — креативный процесс. Мы создаём уникальные изображения и тексты, которые демонстрируют, какую пользу приложение приносит людям, и привлекают новых пользователей.
Главное правило текста — лаконичность. У нас не так много места, чтобы описать все плюсы приложения, поэтому важно сосредоточиться на том, что может привлекать его целевую аудиторию.
- Маркетинговое название приложения не должно содержать информацию о цене, категории и эмодзи, длина — до 50 символов.
- Краткое описание пользователи видят в карточке приложения в Google Play до того, как нажать «далее» — 80 символов.
- Полное описание характеризует возможности и преимущества приложения, оно должно быть конкретным и умещаться в 4000 символов. Писать сильные тексты нам помогает гайд Елены Абросимовой.
Если приложение распространяется для нескольких стран, то для кажой желательно предоставить локализации — описание, переведённое на разные языки. Сделать это стоит по двум причинам: 1) локализации — это забота о пользователе; 2) локализации увеличивают загрузки.
Задача графических материалов — произвести впечатление на аудиторию и рассказать о функциях приложения с помощью картинки. С одной стороны, изображения должны быть информативными, а с другой — удерживать внимание пользователя, который всё время отвлекается на что-то.
Какие изображения нужны для публикации приложения в Google Play:
- Значок с высоким разрешением — иконка вашего приложения для страницы Google Play. Это отдельный элемент, который может отличаться от собственной иконки приложения (той, которую пользователь видит на смартфоне) в незначительных деталях. Но внося изменения, следите за тем, чтобы иконка не утрачивала идентичность с брендом.
Требования: формат JPEG или 32-битный PNG (непрозрачный, без альфа-канала), разрешение — 512×512 пикселей, объём до 1 МБ.
- Картинка для описания — обложка приложения, которую Google Play будет использовать в разных местах стора. Не размещайте текст и ключевые элементы по краям картинки: 15% от каждого края может отсечься при масштабировании.
Требования: формат JPEG или 24-битный PNG (непрозрачный, без альфа-канала), разрешение — 1024×500 пикселей, объём до 1 МБ.
- Скриншоты отражают внешний вид и функции приложения. На странице можно разместить от 2-х до 8-ми скриншотов для каждого поддерживаемого типа устройств (телефон, 7-ми и 10-дюймовые планшеты, Android TV и Wear OS by Google).
Требования: формат JPEG или 24-битный PNG (непрозрачный, без альфа-канала), разрешение от 320 до 3840 пикселей, соотношение сторон 16: 9 (для пейзажных снимков экрана), объём до 8 МБ.
Как много скриншотов загружать — вопрос открытый. С одной стороны, нам нужно наглядно показать функциональные особенности приложения. С другой — сформировать у пользователя стремление загрузить приложение и посмотреть, что же там есть ещё, чего не было на скриншотах.
- Баннер для телевизора — если приложение запускается на Android TV, ему требуется картинка, которая будет использована для отображения приложения на экране телевизора.
Требования: формат JPEG-файл или 24-битный PNG-файл (без альфа-канала), разрешение — 1280×720 пикселей.
- Видео — если у приложения есть проморолик, мы добавляем на него ссылку с YouTube. Это необязательный элемент, но Google рекомендует использовать его, потому что видео даёт пользователю более полную информацию о приложении. Обратите внимание, что перед добавлением ссылки с ролика нужно снять монетизацию.
Сделать страницу приложения заметнее для пользователей помогут рекомендации Google Play.
Маркетинговая информация о приложении загружается в разделе Развитие (Grown) > Страница приложения (Store Presence) > Основная страница приложения в Google Play (Main store listing). Попасть на неё можно как через навигационную панель слева, так и через уже знакомый нам список задач.
2.6 Загружаем сборку в Google Play Console
Кто этим занимается: разработчик и менеджер проектов или клиент.
Каждая сборка приложения должна быть защищена сертификатом цифровой подписи. Эта подпись нужна Google Play, чтобы идентифицировать разработчика — в дальнейшем только обладатель этого сертификата сможет обновлять и изменять приложение.
После компиляции (сборки) приложения в среде разработки (к примеру, Android Studio, Unity или Unreal) на руках у разработчиков остаётся файл формата APK или App Bundle. App Bundle — это современный форматAndroid-приложений. Он обязателен с 2022 года.
«App Bundle даёт пользователю возможность установить приложение меньшего размера. У Android пять базовых разрешений экрана. Это значит, что во время разработки мы складываем в пять папок один и тот же набор картинок, которые нарезаны под разные размеры. Также мы поступаем и с ресурсами для разных языков. Когда пользователь скачивает приложение в формате App Bundle, Play Market сам определяет разрешение его экрана, язык и другие параметры и скачивает только необходимые ресурсы, в то время как файл APK скачивается полностью».
Разработчики подписывают файл приложения и передают его менеджеру проекта.
Менеджер должен убедиться, что приложение подписано и ключ вместе с сопровождающими его паролями не забыт, не утерян или не попал в чужие руки. Потеря файла или паролей обернётся для приложения трагедией: пользователям придётся удалять текущую версию и скачивать из Google Play новую, а мы потеряем статистику, скачивания, аудиторию и многое другое, ради чего столько времени трудились. Не надо так.
После этого мы своими руками выкладываем сборку в Google Play Console в разделе Рабочая версия (Production).
Для завершения этого этапа нам потребуется:
- Задать номер версии — зачастую он автоматически подтягивается из сборки, но при необходимости его можно поменять.
- Указать, какие изменения мы внесли в новую версию (для обновлений) — этот текст будет доступен в сторе в разделе «Что нового».
В описании обновлений избегайте общих фраз. Пользователь приходит за обновлениями, чтобы получить исправленную версию, в которой нет ошибок, мешающих работать с приложением. Описание должно сообщить человеку, что изменилось.
2.7 Оформляем политику конфиденциальности
Кто этим занимается: менеджер или клиент.
Чтобы рассказать пользователям, как будут обрабатываться их данные, мы добавляем ссылку на политику конфиденциальности (privacy policy). Сделать это можно в меню слева в разделе Правила (Policy) -> Контент приложения (App Content).
Если у клиента нет готовой политики конфиденциальности, он может воспользоваться документом студии разработки на время, пока будет готовить свой. Составить документ можно с помощью англо-и русскоязычных конструкторов. Ещё можно «подглядеть» политику конфиденциальности у похожего проекта, но советовать этого мы, конечно, не будем.
2.8 Настраиваем продаваемый контент
Кто этим занимается: менеджер проекта или клиент.
Прежде чем настраивать продаваемый контент, нам нужно зарегистрировать аккаунт продавца, или платёжный профиль. Для этого мы возвращаемся к разделу Все приложения (All Apps) переходим в Настройки (Setting) выбираем пункт Аккаунт разработчика (Developer Account) и открываем вкладку Настройки оплаты (Payments Settings).
Или просто нажимаем синюю кнопку «Создать платёжный профиль» (Set up a merchant account), когда консоль предлагает сделать это.
Play Console перенаправляет нас в платёжный центр, чтобы мы настроили свой платёжный профиль. Мы указываем юридическое название компании клиента, контактные данные лица, с которым Google может связаться при необходимости, и местонахождение компании.
Мы можем связать Play Console с аккаунтом продавца только один раз. Если мы захотим отменить связь или внести изменения, то придётся зарегистрировать новую учетную запись разработчика, оплатить ещё один регистрационный сбор и перенести все существующие приложения.
После регистрации аккаунта мы настраиваем покупки в разделе Монетизация (Monetise) на вкладке Товары (Products).
Подписка — это покупка какого-то товара или услуги в приложении, за которую пользователь платит каждый оговоренный период. Например, подписка на прослушивание музыки в приложении-плеере.
Если в приложении есть платные подписки, мы должны настроить сведения о товаре:
- Название — что, до 55 символов.
- Описание — что делает, до 80 символов.
- Преимущества — функции, которые подписка открывает для пользователя, можно указать до четырёх преимуществ.
- Цена — указание цены за подписку в местной валюте.
Чтобы сделать подписку доступной для продажи, нужно изменить её статус в разделе Статус (Status) на «Активно».
Все условия подписки должны быть прописаны чётко и явно. Google заблокирует приложение, если в вашей подписке есть следующие нарушения:
- Ежемесячные подписки, в условиях которых не указано, что они будут продляться автоматически каждый месяц со списанием средств со счёта.
- Годовые подписки, где ярко выделена только их месячная стоимость, например написано: «Подписаться за $5», а ниже кнопки «Подписка на месяц», «Подписка на год». В этом случае не очень понятно, сколько пользователь отдаст за месяц, а сколько за год.
- Неполная локализация условий и стоимости подписки.
- Предложения, в которых неясно указано, что пользователь может получить доступ к контенту без подписки.
- Неточное указание наименования товара: для подписки с автоматическим списанием средств дана формулировка «Бесплатная пробная версия».
Убедитесь, что подписки оформлены верно и честно. Подробнее о правилах можно прочитать здесь.
В разделе «Монетизация» также можно изменить способ распространения приложения. Для этого мы открываем вкладку «Цена приложения» (App Pricing) и нажимаем кнопку «Сделать приложение платным».
2.10 Контент для продажи ( In-app products)
Контент для продажи — это покупки в приложении, которые пользователи оплачивают один раз, например виртуальные товары (предметы в играх) или разделы приложения.
У каждого товара должен быть свой уникальный идентификатор, который позволит отличить ваш продукт от продукта другого продавца. Откройте вкладку контент для продажи и добавьте следующие данные к каждому товару:
- Название — что, до 55 символов.
- Описание — что делает, до 80 символов.
- Цена — указание цены в местной валюте.
Чтобы узнать больше о том, как управлять продаваемым контентом в приложении, прочитайте все правила и рекомендации Google.
После этого можно отправлять сборку на релиз.
Не бойтесь что-то пропустить. Если вы о чём-то забудете, Google Play Console обязательно подскажет, какую информацию на странице вы ещё не заполнили, перед тем, как пустить ваше приложение на проверку.
2.11 Отправляем сборку в Google Play
Ревью может длиться до трёх дней. Но в период пандемии приложения проверяют дольше: в первую очередь ревью проходят медицинские приложения, связанные с ковидом. Поэтому сейчас и в обозримом будущем на проверку приложения в Google Play стоит закладывать от трёх до пяти дней.
Перед публикацией вам необходимо убедиться, что приложение соответствует правилам Google. Чтобы избежать нарушений, вы можете:
- Проверить, правильно ли занесены метаданные — полное и краткое описание не должно содержать ненужных деталей и отзывов пользователей.
- Использовать только те изображения, на которые у вас авторские права, — скриншоты и видео для продвижения должны быть уникальным продуктом.
- Обновить контактные данные, чтобы представители Google могли связаться с вами.
- Если вы не уверены в том, что корректно ответили на вопросы анкеты возрастных ограничений, вернись к опросу и пройдите его заново.
- Если в приложении есть реклама, убедитесь, что она не содержит контента для взрослых, пропаганды насилия и психотропных веществ.
Google Play лояльнее, чем App Store. Здесь никто не скажет, что приложение «не даёт людям достаточный пользовательский экспириенс» — даже если в нём будет всего одна кнопка, его опубликуют.
Но это совсем не значит, что можно расслабиться и забыть о правилах. Google Play отклонит сборку, если найдёт в ней серьёзные ошибки:
- Несоответствие приложение правилам Google Play — приложение нарушает соглашение о распространении программных продуктов.
- Несоответствие приложения его описанию — в информации на странице приложения есть ложные данные или данные, которые некорректно описывают работу приложения.
- Неприемлемый контент — пропаганда насилия порнография, употребление психотропных веществ, угрозы, издевательства, дискриминация, продажа оружия и контент, связанный с терроризмом.
- Размещаемая реклама — приложение вынуждает пользователя нажимать на рекламный баннер, который блокирует основной экран; рекламное объявление имитирует системное уведомление или не может быть прервано по желанию пользователя.
- Неадекватная работа с sensitive data — приложение пытается получить безосновательный доступ к конфиденциальным пользовательским данным (например, к sms или к управлению функциями телефона).
- Нарушение прав на интеллектуальную собственность — если Google посчитает, что ваше приложение использует чужие товарные знаки, нарушает авторские права и копирует чей-то контент, то компания может отказать вам в публикации приложения.