Як публікувати застосунки в Microsoft Store, Apple App Store та Google Play Store в 2024 році

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт, мене звати Марія. Якщо останнім часом вам було цікаво, як виглядає публікація застосунків в Microsoft Store, Apple App Store, Google Play Store — то вам сюди. Зокрема, як в 2024 році з точки зору девелоперів виглядає реєстрація або відновлення на цих платформах, налаштування акаунту та продукту, і як той продукт — в нашому випадку застосунок — потім опублікувати.

Перш ніж почати, розкажу трохи про себе, і про те, яким саме досвідом публікації застосунків ділитимусь. Отже, є стартап з двох людей — власне, мене і мого колеги Антона. Ми обоє розробники з основним профілем в Embedded, працюємо в доволі звичайному українському аутстаффі GlobalLogic. І у вільний від основної роботи час займаємось side project — стартапом, який розробляє кілька застосунків. В основному під Desktop та Mobile, але не тільки.

Разом ми набрались доволі широкого досвіду розробки крос-платформних застосунків під Desktop та Mobile. Як в контексті основної роботи, так і в контексті цього стартапу. Fun fact: з Антоном навіть є стареньке інтерв’ю тут на DOU. А ось посилання на сторінку самого стартапу із продуктами.

Отже, цього року ми задумались, що було б дуже непогано нарешті як слід опублікувати свої продукти на популярних платформах — Microsoft Store, Apple App Store, Google Play Store. Цей текст буде про в основному мій досвід публікації + спільний досвід розробки застосунків під відповідні платформи від Microsoft, Apple та Google.

Тож якщо ви девелопер і теж задумуєтесь над публікацією на цих платформах — сподіваюсь, вам буде цікаво.

Застосунки, які будемо публікувати

Трохи про загальний контекст. Отже, як вже згадувалось, є наш стартап з двох розробників. Він існує вже доволі довгий час, і зосереджений в основному на розробці застосунків. Деякі з них раніше вже публікувалися на Apple App Store, Google Play Store та 3rd-party e-commerce платформі. Були як успішні публікації, так і не дуже — не доведені до фінального продакшену. Але оскільки останній досвід активної публікації саме своїх застосунків був більш ніж п’ять років тому, а ситуація за цей час сильно змінилася, цьогоріч ми вирішили спробувати ще раз.

Отже, задумка на 2024 рік була така:

• Дізнатись, що ми зможемо опублікувати в Microsoft Store, Apple App Store, Google Play Store. І якщо зможемо, то скільки часу і зусиль займе публікація та підтримка.
• Дізнатись, чи можливо монетизувати ці застосунки на платформах так, щоб вивести потім кошти на українські рахунки. Тобто використати це як джерело доходу.

Із таких міркувань спочатку були думки в якості пілотного проєкту публікувати якийсь умовний «Hello World» застосунок. Просто щоб протестувати, під які платформи зможемо щось опублікувати в наявних умовах. Доволі швидко, правда, з’ясувалось, що усі три платформи не публікують «Hello World». З резонних міркувань, що це буде спамом.

Тож ми змінили тактику, і вибрали один доволі старий застосунок. Він існує більш ніж 10 років, переважно під Windows + macOS, в ніші Audio. Раніше був опублікований на Apple App Store та на 3rd-party e-commerce платформі. Але активних оновлень не отримував вже років п’ять. І якщо чесно, то так — це застосунок у напівзакинутому стані. Який потребує не те щоб публікації, а допрацювання. І навіть зараз все ще перебуває в процесі активної розробки.

На цьому моменті довелось ще раз змінити тактику, бо застосунок потребує доробки та існує далеко не під усі цікаві нам платформи. А якийсь пілотний продукт для тесту публікації все ж був потрібен. Тож ми вирішили ризикнути і написати новий застосунок на основі старого (Win, Qt) і ду-у-уже старого коду (WinAPI). Але вже з врахуванням того, що це потрібно буде якнайпростіше портувати, а потім публікувати на цікавих нам платформах.

В результаті вийшов доволі цікавий досвід, майже експериментальний. Ми самі до кінця не вірили, але вийшло:
— написати крос-платформний застосунок з Core-частиною на C++ (усе це в одному .cpp-файлі);
— винести усю інтеграцію з таргет-платформою/ОС в явному вигляді в окремі source file;
— реалізувати цю саму інтеграцію, користуючись Native API відповідної платформи;
— використати дефолтові (вони ж Hello World) проєкти для білдів і конфігурації.

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

Якщо резюмувати, в результаті публікувати будемо два застосунки:

Наявний крос-платформний застосунок під десктопи:

• Платформи: Windows, OS X.
  
• Історія: застосунок існує понад 10 років.
• Попередні публікації: раніше був опублікований на Apple App Store та 3rd-party e-commerce платформі.
• Напрям: Audio.
• Стек технологій: C++, Qt.

Новий крос-платформний застосунок:

• Платформи: Desktop (Windows 10/11, OS X), Android (телефони, планшети, Chrome OS), WearOS, iOS, Apple WatchOS.
• Історія: новий застосунок, розроблений у 2024 році.
• Попередні публікації: немає.
• Напрям: Audio.
• Стек технологій: C++ для основної частини, Java (Android + Android Wear специфічна частина), obj-c (iOS, OS X, Apple Watch) — специфічна частина.

Ми обоє працюємо над проєктом у вільний від основної роботи час. А також працюємо як український ФОП — тож більшість юридично банківських нотаток буде в цьому контексті.

Microsoft Store

Так історично склалося, що цього року першою платформою, на якій я спробувала щось опублікувати, став Microsoft Store. Попереднього досвіду з Microsoft Store в нас не було. Але ми все ж таки вирішили спробувати.

Весь процес публікації можна розбити на чотири великі етапи — реєстрація або відновлення акаунту, сетап продукту, upload/тестування/сертифікація, та безпосередньо реліз в Microsoft Store.

Реєстрація або відновлення девелоперського акаунту в Microsoft Partner Center

Отже, крок перший — це реєстрація або відновлення девелоперського акаунту в Microsoft Partner Center.

Microsoft пропонує два типи акаунтів — Individual або Company. Відповідно це акаунти для індивідуальних розробників або компаній. Якщо дуже спростити, то різниця у тому, чи це ваш основний вид діяльності та дохід. А також у вартості реєстрації, наборі фіч, які пропонуватиме портал, та в тому, як з вами юридично буде взаємодіяти Microsoft.

Для України станом на весну 2024 року вартість реєстрації Individual-акаунту становить 156 гривень, і 800 гривень для Company. Детальніше тут.

Протягом усього процесу реєстрації Microsoft Partner Center доволі чутливий до того, скільки і яких акаунтів зараз залогінено в браузері, особливо якщо є два і більше Microsoft accounts. Тому рекомендую пройти усю реєстрацію, наприклад, в Incognito-режимі.

Існуючого девелоперського акаунту в Microsoft Partner Center не було, тому довелося створювали новий. Деталі про створення нових акаунтів можна почитати тут.

Отже, при створені потрібно:

• обрати тип — Individual or Company;
• обрати відповідні Партнерські Програми, до яких бажаєте доєднатися (для публікації в Microsoft Store застосунків під Desktop обраємо Windows and Xbox program);
• сплатити одноразовий внесок;
• верифікувати contact email через OTP-verification code.

Якщо все пройшло вірно — новий девелоперський акаунт успішно створено. Далі потрібно його налаштовувати. Сетап можна розбити на розділи з даними про розробників, податки і банківські рахунки, та сетап усіх необхідних Партнерських Програм (Partner Programs).

Дані про розробника заповнюємо в розділі Organization profile в Account Setting. Зокрема у розділі Legal info заповнюємо офіційну юридичну інформацію про вас як про розробника. Там же вписана ваша контактна інформація (Contact info).

Партнерські Програми. Варто перевірити ще раз, що ваш аканут доєднаний (enrolled) в усі необхідні Партнерські Програми (до прикладу, Windows and Xbox app developer program). Це можна зробити в розділі «Programs» в основних Account Setting. Додати нову Партнерську Програму можна в розділі «+ Myaccess» на головному дашборді.

Дані про банківські рахунки і податкові декларації можна заповнити в розділі «Payment and Tax profile»:

• Payout Profile. Тут все доволі прямолінійно — заповнити інформацію про банківський рахунок для виплат. Для прикладу, в нас це був рахунок українськго ФОП в USD, реквізити IBAN.
• Tax Profile. Для когось, можливо, неочікувано, але Microsoft виступає вашим податковим контрагентом в країні своєї юрисдикції (Сполучених Штатах). А тому, щоб сплачувати за вас податки і подавати документи в IRS — потрібно заповнити форму IRS W-8BEN Certificate of Foreign Status of Beneficial Owner for United States Tax Withholding and Reporting (Individuals). Тому тут же в розділі Tax profile потрібно заповнити і подати цю саму форму W-8BEN. В нашому випадку при заповненні форми вибирали наступне:
  non US resident, UKRAINE resident,
  permanent residence address (Не можна вибирати P.O. box або «is-address-care» згідно інструкцій)
  without US Tax Identifier Number (TIN), Foreign TIN
  include Tax Withholding treaty, choose 10%
• Не юридична порада. Між Україною та Сполученими Штатами укладений договір про уникнення подвійного оподаткування. Оскільки дохід, який буде отриманий від продажів Microsoft Store, можe бути оподаткований в Сполучений Штатах (як країна, резидентом якої є компанія, що виплачуватиме дохід) — в договорі про уникнення подвійного оподаткування є пункт про ліміт на нього в країні, де цей дохід умовно виник. Наскільки вдалось зрозуміти, дохід із Microsoft Store виплачується згідно ARTICLE 12 Royalties, а тому наш Tax Withholding Rate — це 10%.
  Договір українською з сайту мінфіну
  Договір англійською з сайту IRS
• І не забути прив’язати Payout profile до Tax profile.

Сетап продукту в Microsoft Partner Center

Технічно можна починати створювати новий продукт в Partner Center, як тільки ви створите ваш девелоперський акаунт і доєднаєтесь (enroll) до якоїсь із Партнерських Програм. Ну тобто не обов’язково заповнювати усі банківські й податкові деталі із попереднього розділу, щоб почати створювати новий продукт. Але щоб ваш новостворений продукт можна було подати на рев’ю для публікації в продакшн, треба виконати пункти із попереднього розділу. Особливо, якщо у вас не безплатний застосунок.

Отже, створити новий продукт можна в розділі Main dashboard -> Apps and Games -> New Product. Microsoft пропонує на вибір для Win32 застосунків два типи продуктів — ’MSIX’ або ’MSI or EXE’. Тут варто уважно обирати, тому що після того, як продукт вже створено, тип вже не змінити. Принаймні власноруч без сапорту.

Якщо дуже коротко:

Детальніше про типи та їх відмінності тут. Ми обрали варіант Packaged (MSIX) як більш простий за наших умов.

Наступний крок — створити і заповнити App Submission. Це така собі форма подання застосунку на публікацію.

Процедура містить:

• Резервування імені продукту.
• Заповнення секції Pricing and availability — за яку ціну і в яких буде доступним ваш застосунок.
• Заповнення секції Properties. Обрати категорію для вашого застосунку та вказати різноманітну інформацію про сапорт.
• Можливо, доведеться зробити і розмістити Privacy policy. В основному це стосується застосунків, які збирають хоч якісь персональні дані. А потім, відповідно, вказати його в полі Privacy policy URL.
• Тут же вказати System requirements, як-то необхідні хардварні фічі, необхідні або рекомендовані для вашого застосунку.
• Заповнення секції Age ratings — пройти опитувальник, який видасть в кінці рекомендований рейтинг.
• Для варіанту Packaged (MSIX) — секція Packages (.msix, .msixbundle, .msixupload, .appx, .appxbundle, .appxupload, .xap), асоційованих із цим продуктом і з цим App Submission.
• Заповнення секції Store listing — дані для сторінки вашого продукту в самому Microsoft Store.
• Додати список мов, які підтримує застосунок, і додаткові мови для Store listing.
• Для кожної із мов Store listing потрібно підготувати лого для застосунку (9:16 Poster art 720×1080 1440×2160, 1:1 Box art 1080×1080 2160×2160, 1:1 App tile icon 300×300), скріншоти для Desktop, Mobile, Xbox, Holographic/ Опціонально — Відео Trailer, Windows 10 and Xbox image, Xbox images, Holographic image, Windows 8.x and/or Windows Phone 8.x images. Та заповнити секцію Submission Options — обрати, чи публікувати одразу після того, як пройде сертифікація, чи за визначеним графіком.

Документація на тему App Submission тут.

Upload, Тестування і таке інше

Upload. Як вже згадувалось, залежно від типу продукту (App Record), який було вибрано в App Submission, аплоад — це:

• #1 варіант Unpackaged (Win32) — викласти підписаний .EXE або .MSI інсталер на ваш сайт та вказати https-посилання на нього.
• #2 варіант Packaged (MSIX) — аплодити пакет (.msix, .msixbundle, .msixupload, .appx, .appxbundle, .appxupload, .xap). Або безпосередньо в розділі Packages App Submission, або вибрати один із пакетів, які вже є в Package flights.

Детальніше про опції дистрибуції Win32 застосунків тут.

Package flights. Для тестування застосунків, а точніше для дистрибуції обмеженому колу тестувальників, Microsoft пропонує використовувати Package flights. Для тестувальників Package flights виглядає майже як звичайний реліз застосунку в Microsoft Store. Для девелоперів це теж як майже повноцінний реліз App Submission. До прикладу, для Package flights теж застосовується процедура Сертифікації, але з пом’якшеними вимогами.

Якщо будете створювати MSIX package із існуючого .EXE or MSI за допомогою «MSIX Packaging Tool», то:

• Заповнюйте «Publisher Name» як «CN=<id>», де <id> має співпадати з ID в девелоперському акаунті.
  
• «Publisher Display Name» теж має співпадати із девелоперським акаунтом.
• «Package Name» треба вказати як «<Publisher Display Name>.<Product Name>», і теж має співпадати із девелоперським акаунтом.
• «Package Display Name» має співпадати з Reserved Product Name.

Сертифікація та Release в продакшн

Після того, як App Submission вже заповнений і готовий до публікації, ви вже натиснули кнопочку Submit to the Store — починається процес сертифікації (або просто рев’ю).

• Перший етап це статус Validation — по суті це набір автоматичних тестів і всіляких перевірок.
• Другий етап — статус In certification — це вже рев’ю, яке робить (начебто) людина, перевіряючи ваш застосунок на відповідність внутрішнім гайдам Microsoft.

Додам кілька нотаток із поширеними проблемами на цьому етапі:

• назва застосунку (App Title in the title bar) має співпадати принаймні з одним із зарезервованих імен продукту;
• інстальовані компоненти, які видно юзеру, теж мають мати ім’я, що співпадає принаймні з одним із зарезервованих імен продукту;
• секція «About» має містити інформацію, що співпадає із зазначеною в девелоперському акаунті;
• є публічна версія Microsoft Store Policy, а є внутрішня версія цієї ж Microsoft Store Policy. Так от саме на внутрішню буде посилатися репорт після Сертифікації.

До прикладу ось такий текст в репорті з посиланням на внутрішню версію:

> Technical requirement policies Notes to publisher 
> 10.1.4.6 App Quality — Misleading Content 
> Information within the product or metadata does not accurately represent the product. Products need to have unique functionality and value in the Store. For more information see Microsoft Store Policy 10.1 at 
> [<a href="http://go.microsoft.com/fwlink/?LinkId=620446">go.microsoft.com/fwlink/?LinkId=620446</a>](<a href="http://go.microsoft.com/fwlink/?LinkId=620446).">go.microsoft.com/fwlink/?LinkId=620446)</a>

Рішення — писати в сапорт на пошту [email protected].

Як тільки Сертифікація пройдена — продукт можна публікувати в Microsoft Store. Ну або він опублікується автоматично, якщо вибрати потрібну опцію в App Submission. Якщо ви дійшли до цього моменту — вітаємо, ваш застосунок офіційно опубліковано!

Post Release нотатки — випуск нових версій, виплати і таке інше

Випуск нової версії це по суті той самий процес заповнення App Submission. Єдина відмінність — дані зберігаються з попереднього App Submission. Детальний огляд можна знайти тут

Про виплати

Окрім одноразового внеску за реєстрацію в девелоперській програмі,який згадувався в перших розділах, існує ше комісія, якщо Microsoft виступає у ролі payment processor. Для варіанту Packaged (MSIX) комісія складає 15% за застосунку і 12% за ігри. Для варіанту Unpackaged (Win32) цієї комісії немає.

Щодо виплат на ваш рахунок. На всі виплати встановлений графік (щомісячно) і мінімальний ліміт (50$). Сама транзакція із виплати займає 7-10 робочих днів. Залежно від банку з вас можуть спитати договір, згідно з яким ці виплати здійснюються (стосується українських банків і рахунків ФОП). Можна надіслати репорт про виплати з Microsoft Partner Center.

Додаткові тули для моніторингу застосунку в продакшені, реклами, маркетингу

Для моніторингу застосунку Microsoft пропонує кілька інструментів. Окремо є статистика завантажень, переглядів сторінки в Microsoft Store і покупок, якщо застосунок платний. Також є Health Report — статистика по крешам, зависанням та іншим помилкам. Як девелопери, в цей розділ ми, мабуть, заглядаємо найчастіше.

Окрім цього, є ще кілька тулів для реклами і маркетингу — як-то рекламні кампанії, промокоди, розпродажі й таке інше. Але маркетинг застосунків — це вже окрема тема. З простіших тулів, які стосуються публікації — документація, як дістати URL на ваш опублікований застосунок в Microsoft Store. Там можна створити бадж, тобто кнопку «Download from Microsoft Store» (із все тим же URL на застосунок).

Скільки на це пішло часу

Якщо підсумувати, не рахуючи часу на девелопмент самих застосунків, від початку публікації і до фінального релізу в Microsoft Store першого продукту пішло два-три тижні. Вся робота велась у вільний час поза основною роботою, включно із створенням акаунту, читанням документів про оподаткування, кількома ітераціями аплоаду і Сертифікації. Тож результат доволі пристойний.

Apple App Store

Як згадувалось раніше, в нас вже є досвід публікації на цій платформі. Один із двох застосунків був опублікований під macOS, але останні кілька років активно не оновлювався. Тож як мінімум будемо публікувати оновлення для нього. На додачу, тепер в планах було також опублікувати наш другий застосунок. Тож на цій платформі буде і повний раунд створення і публікації.

Реєстрація/Відновлення девелоперського акаунту в App Store Connect

Оскільки раніше публікувались на цій платформі, девелоперський аканут уже був. Але через те, що останні кілька років активних оновлень ми не робили — впевненості, що акаунт залишився активним або залишився взагалі, в нас не було. Виявилось, що після кількох років неактивності Apple деактивує акаунт, але не видаляє, тож його можна відновити. Все, що довелось зробити:

• Заплатити fee за девелоперський акаунт.
• Прийняти оновлений Developer Agreement.

З 2024 року щоб публікувати нові застосунки або оновлення в App Store на території Європейського Союзу, потрібно підтвердити статус трейдера (заповнити додаткові дані в спеціальній формі в App Store Connect) згідно Digital Services Act.

Банківська, податкова, compliance та інша інформація

• Agreements.
• Paid Apps Agreement («Угода про платні застосунки»).
• Free Apps Agreement («Угода про безкоштовні застосунки»).
• Bank Accounts.
• Ваші банківські акаунти для виплат.
• Tax Forms.
• Форма U.S. Form W-8BEN, така ж, як і в Microsoft Partner Center.
• Compliance.
• Уже згадана форма для Digital Services Act.

Створення нового застосунку в App Store Connect

Спершу потрібно створити відповідний App Record. Зазвичай це один App Record на один застосунок. Цілком притомний гайд із створення нового застосунку є на сайті Apple.

Якщо коротко, App Record містить:

1. Платформи Apple, які підтримуватиме застосунок:
macOS, iOS (Apple WatchOS only застосунки включені в iOS-платформу), tvOS, visionOS.
2. Розділ «General» із загальною інформацією про застосунок і девелопера (контактні дані й так далі).
3. Розділ «Trust & Safety» із уже знайомою Privacy Policy та рештою інформації про те, які персональні дані збирає (або ні) ваш продукт.
4. Розділ «Growth & Marketing» із налаштуванням розпродажів, промокодів і подібного.
5. Розділ «Monetization» із налаштуваннями цін і доступності на ринках.

Для кожної із платформ, яку підтримує застосунок (їх можна додати або оновити і після створення App Record), є окрема секція із списоком App Submission під цю платформу. Це умовний набір даних про версію застосунку, яку ви збираєтесь публікувати в App Store, як-то:

• версія застосунку, вона ж використовується для ідентифікації самих App Submission одне від одного;
• дані для сторінки продукту в App Store — опис продукту, скріншоти, банери, лого і таке інше;
• вибраний Build застосунку із тих, що залиті на App Store Connect;
• додаткова мета-інформація, як-то список entitlements для macOS.

Повний список різний під різні платформи, змінюється з часом. Тож тут варто користуватись документацією самих Apple. Але для прикладу, для macos App треба підготувати:

• Прев’ю і скріншоти.
• Рекламний, він же промо-текст.
• Опис застосунку.
• Ключові слова.
• URL для сапорту, маркетинговий URL (рекламний).
• Версія.
• Текст Copyright.
• Вибраний Build (з залитих в App Store Connect).
• Іконка для застосунку.
• Дані sign-in account, тобто логін і пароль акаунту, з яким можна залогінитись у ваш застосунок.
• Контактна інформація розробника.
• Sandbox Information, вона ж macOS Entitlements.
• Графік релізу (на заплановану дату чи одразу після проходженню рев’ю).

Додаткові нотатки

• При створенні App Record уважно обирайте Bundle ID. Продивитись і відредагувати все це можна в розділі Certificates, Identifiers & Profiles.
• Уважно заповнюйте і перевіряйте мета-дані в App Record для платформ, які цього потребують. Наприклад, macOS Entitlements. Це знадобиться пізніше в процесі рев’ю вашого застосунку.

Apple WatchOS. Станом на 2024 рік існує два варіанти WatchOS застосунку — standalone, тобто такі, які можуть працювати безвідносно iPhone. І bundled, що інсталюються в парі із застосунком iOS. Обидва варіанти пропонується додавати в App Submission під iOS.

Тож ситуація стає трохи заплутаною. Розібратись вдалось не одразу, але на момент девелопменту (середина 2024) ситуація була наступна:

• Apple Watch є не самостійним девайсом, а запейреним із iPhone.
• Варіант standalone-застосунку WatchOS за планом — це коли він може функціонувати повністю незалежно від iOS-застосунку, включно із випадками, коли iOS-застосунок взагалі не встановлено. Але навіть в цьому варіанті контент застосунку Watch вбудовується всередину iOS-застосунку для деплою, аплоаду в App Store Connect та App Submission.
• Варіант bundled — це коли застосунок WatchOS є Companion App до iOS-застосунку. Тобто деплой і робота iOS та частини WatchOS пов’язані. При цьому для частини WatchOS в Xcode-проєкті (Xcode 15) є галочка «Supports Running Without iOS App Installation».
• Для standalone і bundled існують окремі темплейти проєктів, тож там просто заплутатися.
• Якщо публічний реліз вийшов як standalone WatchOS застосунок — ревертнутись в bundled вже не можна, принаймні згідно того, що пише сапорт. Тож обирати схему варто уважно.

Залежно від вибраного варіанту (standalone чи bundled) буде трохи відрізнятися і сам процес деплою на девайс, навіть під час девелопменту. Стосується це і симуляторів Apple Watch, і реальних Apple WatchOS девайсів.

Upload та тестування

Upload. Отже, один з основних етапів в App Submission — це обрати Build. Для цього Build потрібно залити, власне, в App Store Connect. Це можна зробити одним із способів, описаних в Upload Builds. Ми просто користувались Xcode.

Додатково є опція користуватися Test Flight та Xcode Cloud. Test Flight — це тул для дистрибуції та тестування. Як всередині компаній, так і ззовні. Відповідно Xcode Cloud — для CI\CD workflow.

Технічно, щоб створити і подати на рев’ю App Submission, використання ні Test Flight, ні Xcode Cloud не є обов’язковим. Хоча використання як мінімум Test Flight вважається best practice.

Тож мінімально необхідний і достатній крок — це залити Build в App Store Connect, тобто в процесі аплоада:

• обрати скоуп саме «App Store Connect»;
• Build буде проходити процедуру дуже базової валідації, тож має її пройти.

Коли аплоад успішно завершився, ваш Build з’явиться в дашборді App Store Connect від кількох хвилин до кількох годин.

Рев’ю та Release в продакшн

Рев’ю. Коли App Submission вже повністю заповнений, і є як мінімум один Build — App Submission можна подавати на рев’ю (кнопкою «Add for Review»). Процедура може тривати кілька робочих днів.

На що звертають увагу під час рев’ю:

• базовий функціонал;
• чи запускається на відповідній платформі;
• чи відповідає базовий функціонал заявленій категорії;
• для iOS та Apple WatchOS — скріншоти і прев’ю мають відповідати дійсності, і мають бути надані для всіх форм факторів девайсів, що підтримуються;
• відповідність мета-даних в App Submission із тими, що в застосунку;
• назва застосунку в App Submission має строго відповідати тій, яка відображатиметься у користувача;
• якщо є ’About’, то інформація там теж має відповідати зазначеній в App Submission;
• якщо задекларований збір даних користувача — у вас можуть спитати, навіщо застосунку ці дані;
• якщо застосунок декларує, скажімо, доступ до девайсів (до прикладу macOS Entitlements) — у вас можуть запитати, навіщо йому такий доступ.

Як тільки рев’ю успішно завершено — продукт буде опубліковано згідно графіку обраного в App Submission.

Для кожної платформи треба створити окремий App Submission. Тож якщо ваш застосунок підтримує macOS, iOS (опціонально з WatchOS) та tvOS — це буде три окремих App Submission і три окремих релізи.

Post Release нотатки — випуск нових версій, виплати

Випуск нових версій — це все те ж створення відповідного App Submission. І подальше заповнення даних, що змінилися в App Submission, аплоад відповідного Build і фінальна подача на рев’ю.

Post Release аналітика/ App Store Connect пропонує розділ Analytics із даними про завантаження і продажі, деякими метриками і бенчмарками. App Store також пропонує тули для маркетингу. Ними можна створити баджі «Download on the App Store» із лінком на ваш застосунок. Або QR-код, теж з лінком на ваш застосунок. А також деякі рекламні матеріали для соціальних мереж.

Монетизація/ Виплати робляться наприкінці кожного місяця на рахунок, вказаний у вашому акаунті. Детальніше читайте тут.

Продивитися репорт про виплати можна в розділі «Payments and Financial reports» в App Store Connect. Залежно від банку, для остаточного зарахування коштів банк може запросити документ про походження коштів (контракт). Можна сформувати репорт про виплати від Apple в тому ж розділі ’Payments and Financial reports’.

Про строки. Якщо підсумувати, то випуск оновлення для нової версії для існуючого крос-платформного застосунку під десктопи зайняв приблизно один-півтора тижні. Це без урахування часу на девелопмент. Та за умови, що робота все ще ведеться в час поза основною роботою, й що новий аканут створювати не довелось.

На перший реліз нового продукту пішло трохи більше — три-чотири тижні. Переважно через довге тестування версії під Apple WatchOS.

Google Play Store

Деякий досвід із публікацією в Play Store в нас вже був — попередня спроба релізу під Android більше п’яти років тому. Тоді, на жаль, не вистачило часу та досвіду довести продукт до широкого релізу. Тому відклали до кращих часів. Однак, залишився девелоперський акаунт в Google Play Console, принаймні ми так думали.

До того моменту досвіду розробки під Android стало значно більше, тож цього разу під час створення нашого відносно нового другого застосунку ми замахнулися і на Android також.

Реєстрація або відновлення девелоперського акаунту

Чесно кажучи, ми розраховували, що девелоперський акаунт залишився хоча б в деактивованому стані. І що його можна буде відновити так само, як і Apple-акаунт. Навіть якщо для цього доведеться писати в сапорт. Але ні. Він дійсно висів деякий час деактивований, але потім Google вирішив його просто закрити і видалити. Разом із усіма нашими продуктами в ньому...

Тікети в сапорт не допомогли. Як виявилось пізніше, це не поодинока ситуація. І в цілому рекомендації сходяться на тому, що необхідно просто завести новий акаунт, що ми і зробили.

Створення або відновлення девелоперського акаунту

Щоб створити новий акаунт користувались стандартним гайдом.

Процедура в цілому схожа на Microsoft та Apple:

• Підписатись на девелоперський акаунт в Google Play Store.
• Прийняти Google Play Developer Distribution Agreement.
• Сплатити одноразовий внесок.
• Обрати тип акаунту.
• Google пропонує два типи акаунтів — Personal або Organization. Знову ж таки персональний і «для компаній».
• Для Personal акаунтів з листопада 2023 діють додаткові вимоги для того щоб публікувати щось в Google Play Store.

1. Потрібно підтвердити, що девелопер має доступ до реального Android-девайсу.
2. Перед публікацію в продакшн потрібно провести раунд тестування із як мінімум 20 тестерами (окремі акаунти які мають підписатися на тестування). Але про цей пункт поговоримо детальніше в наступних розділах.
3. Пройти верифікацію девелопера або компанії відповідно до того який тип акаунту вибрали в попередньому пункті.

В нашому випадку обрали Personal акаунт, так як по суті Android в нас займалася в основному тільки 1 людина. Отже надалі будемо налаштовувати саме цей тип акаунту.

Налаштування девелоперського акаунту

Десь із 2022 Google посилив вимоги до створення нових акаунтів, зокрема Personal. Тож тепер, щоб верифікувати девелоперський акаунт, потрібно крім стандартних імені та email заповнити наступне:

• Повне ім’я (офіційне) та адреса.
• Контактний email (який треба буде верифікувати).
• Контактний номер телефону (який теж треба буде верифікувати).
• Official government identity document, тобто офіційний документ, що засвідчує особу (Паспорт Громадянина України підійде).
• А також окремо підтвердити наявність реального Android-девайсу, детальніше тут і тут
.

Якщо плануєте щось продавати в Google Play Store, додатково до девелоперського акаунту треба ще створити Google merchant account:

• Створити Payments Profile.
• Додати Payment method, тобто, наприклад, рахунок для виплат.
• Додати податкову інформацію.
• Якщо вказуєте Україну як країну-резидент, потрібно подати підтвердження, тощо що ви є податковим резидент України. Його можна отримати, написавши заяву в вашу Податкову, детальніше тут.
• Також необхідно подати форму U.S. Form W-8BEN . Так само, як і в випадку з Microsoft та Apple, Google виступає вашим податковим контрагентом. Форму можна подати тут же, заповнивши усі дані (ті самі, що і в розділі про Microsoft Store).
• Додатково (опціонально, наскільки вдалось зрозуміти) можна подати Tax Form для Ірландії та Тайваню.
• Підв’язати ваш Payments Profile до вашого девелоперського акаунту.

Сетап продукту в Google Play Console

Тут все відносно стандартно. Створити новий продукт можна в головному дашборді. На вибір пропонують «Застосунок» або «Гру», безплатний або платний (можна пізніше змінити в налаштуваннях).

Далі все ще відносно стандартне заповнення даних про застосунок у форматі декларування:

• Set privacy policy — така ж privacy policy, як і у випадку з Microsoft і Apple.
• App access — чи обмежений деякий функціонал за логіном, місцезнаходженням і так далі.
• Ads — чи використовує застосунок Advertising ID.
• Content rating — потрібно пройти опитувальник, щоб отримати рейтинг контенту.
• Target audience — цільова аудиторія застосунку (діти, підлітки, дорослі), теж опитувальник.
• News apps — чи є застосунок новинним (так чи ні).
• Data safety — чи збирає застосунок дані користувача, і які саме.
• Government apps — чи є застосунок державним (так чи ні).
• Financial features — чи пропонує застосунок якісь фінансові послуги/фічі.
• Health — чи пропонує застосунок якийсь функціонал, пов’язаний із здоров’ям.

Наступний розділ — Store Listing. Тут треба підготувати наступне:

• Назва застосунку, короткий опис, детальний опис.
• Графіка.
• App icon (PNG або JPEG, до 1 MB, 512 px by 512 px) — основна іконка застосунку.
• Feature graphic (PNG або JPEG, до 15 MB, and 1,024 px by 500 px) — основний постер для застосунку. Очікується що постер буде відображати основні фічі застосунку.
• Відео (опціонально) — відео залите на YouTube, публічне.
• Скріншоти для телефонів — 2-8 штук, PNG або JPEG, до 8 MB кожен, співвідношення сторін 16:9 або 9:16 , кожна сторона між 320 px і 3840 px.
• Скріншоти для планшетів.
• 7-дюймові планшети — до 8 штук, PNG або JPEG, до 8 MB кожен, співвідношення сторін 16:9 або 9:16, кожна сторона між 320 px і 3840 px.
• 10-дюймові планшети — до 8 штук, PNG або JPEG, до 8 MB кожен, співвідношення сторін 16:9 або 9:16, кожна сторона між 1080 px або 7680 px.
• Скріншоти для Chromebook — 4-8 штук, PNG або JPEG, до 8 MB кожен, співвідношення сторін 16:9 або 9:16 , кожна сторона між 1080 px і 7680 px.

Наступний розділ — Pricing для платних застосунків. Потрібно:

• Створити, якщо ще не встигли, акаунт продавця (merchant account).
• Налаштувати або просто платний застосунок, або підписку.
• Встановити ціни/ціни (можна кастомізувати для окремих регіонів).
• Вказати регіони, в яких буде доступний застосунок.
• Підв’язати ваш merchant account.

Upload та тестування

Upload. Починаючи з 2021 року, усі нові застосунки необхідно аплодити як Android App Bundles. Вони ж в народі «бандли» (.aab).

Щоб залити бандл в Google Play Console, його треба підписати.. Також можна налаштувати, яким ключем буде підписаний застосунок вже в релізі. Для переважної більшості це буде Play App Signing.

Тестування. Google Play Console в контексті публікації застосунків оперує в термінах релізів і testing tracks:

• Internal Testing — умовно, реліз для внутрішнього тестування.
• Closed Testing — реліз для обмеженого кола тестувальників.
• Open Testing — реліз відкритої бети.
• Production — власне, основний публічний реліз.

Internal Testing трек доступний, як тільки продукт створений. Тобто щоб почати користуватись Internal Testing треком, не потрібно повністю налаштовувати застосунок. Типовий сценарій для Internal Testing трек — це тестування всередині вашої команди/компанії в процесі розробки.

Closed Testing трек це вже про більш широке коло тестувальників, включно з тими, що за межами вашої організації. Він стає доступними вже після закінчення всіх налаштувань продукту із попереднього розділу. А для персональних акаунтів, створених після листопада 2023, діють додаткові умови — для активації доступу в продакшн застосунок має обов’язково пройти раунд Closed Testing з не менш ніж 20 унікальними тестувальниками, протягом не менш ніж 14 днів.

Групу тестувальників для Closed Testing можна додати або напряму, вказавши email, або створити відповідну Google Group. Детальніше читайте тут.

Ці нові вимоги стосувались і мене, бо довелось створити геть новий акаунт. Тож можу поділитись деяким досвідом. Згідно Google, нові вимоги ввели для покращення якості застосунків в Google Play Store. З натяком на те, що обов’язковість раундів тестування якось поліпшить якість.

На ділі ці вимоги виглядають просто як підвищення порогу входу для Інді девелоперів (до яких входимо і ми). Особливо соло-девелоперів з обмеженими ресурсами. До того ж, обов’язковість раундів Closed Testing не підвищує якість застосунків в Play Store, а навіть навпаки знижує. Зусилля, які могли бути витрачені на девелопмент і справжнє покращення якості, тепер будуть витрачені на дотримання нових вимог. В той же час тим же скамерам ці вимоги відносно нескладно обійти.

Як набрати групу для Closed Testing

Якщо ви соло-девелопер і у вас під боком немає 20 готових тестувальників із Android-девайсами — то ось кілька варіантів, як набрати групу для Closed Testing:

Попросити 20 членів родини, друзів або знайомих долучитися до тестування. Для цього у них має бути Android-девайс і активний Google-аканут, підв’язаний до цього девайсу. Щоб почати тестування, треба дати активну згоду (opt-in). Тож приготуйтесь писати досить докладну інструкцію, як саме долучитись до тестування, адже не всі ваші друзі та родичі будуть технічно підкованими. Також доведеться трохи попрацювати тех сапортом для цієї групи. Бо навіть якщо інструкції було достатньо, і всі з групи змогли долучитися, під час самого раунду тестування в 14 днів будуть виникати питання щодо безпосередньо застосунку.

Знайти 20 Android девайсів + 20 Google акаунтів. З першого погляду може здатись, що це занадто. Але наш досвід показує — якщо ви займаєтесь розробкою під Android професійно, то цілком вірогідно, що застосунок буде підтримувати 3-4 версії Android, від 3-4 виробників, 2 форм-фактори кожен (телефон і планшет). А це вже 24 девайси загалом. На практиці це далеко не найбільша кількість варіантів підтримки, яку можна зустріти в розділі Supported Devices навіть середніх застосунок. Тож варіант просто докупити девайсів (навіть вживаних) вартий уваги. Потрібно буде створити/дістати 20 Google акаунтів під ці девайси.

Знайти 20 тестувальників в соц мережах. Для прикладу, існує сабреддіт AndroidClosedTesting, створений якраз для пошуку бажаючих протестувати застосунки один одного.

Нам в кінці кінців довелось скористалися так чи інакше усіма 3 варіантами. Більшість групи сформували наші власні девайси. Але ми також додали друзів, родичів і незнайомців з Реддіт для урізноманітнення вибірки. І так, мені довелось десь місяць попрацювати для них тех сапортом. І ще трохи тестувальником для незнайомців з Реддіт.

По результатах вийшло, що найбільшу кількість і найбільш суттєві проблеми ми виявили, просто проганяючи автотести на власних девайсах. Друзі і родичі знайшли ще кілька багів (у деяких з них виявились доволі рідкісні девайси). Ну і найменшу кількість фідбеку отримали з реддіт (що було очікувано).

Якщо ви працюєте в компанії, або ж у вас вже є готова база користувачів, то більшість з описаного вас не стосується. Але сподіваємось, соло-девелоперам було корисно.

Open Testing
Тут процес вже більш прямолінійний. Це усім добре відома звичайнісінька відкрита Бета. Щоб почати, потрібно попередньо в дашборді отримати доступ в продакшн. Для персональних аканутів, створених після листопада 2023 року необхідно, щоб згаданий вище раунд Closed Testing йшов не менше 14 днів. Додатково потрібно буде:

• заповнити форму в дашборді про результати Closed Testing раунду.
• пройти внутрішнє рев’ю Google. Звертатимуть увагу на такі речі, як результати pre-lunch report. А також на вміст і відповідність гайдлайнам Store Listing. До прикладу, наявність і відповідність усіх скріншотів.

Internal App Sharing
Крім згаданого вище Internal Testing треку, існує ще варіант Internal App Sharing. Це коротший спосіб залити Build і поділитися ним із тестувальниками через link.

WearOS
Окремо варто згадати, як в testing tracks виглядає реліз застосунків для годинників. WearOS винесений як окремий форм фактор кожного із різновидів testing track. Тобто є окремий Internal Testing трек для Phone/Tablet/Chromebook, окремий для Android TV, для WearOS, для Android Auto.

В нашому випадку продукт підтримує телефони, планшети, Chromebook та WearOS. Тож в нас було по 2 треки для кожної стадії. Девелопмент під WearOS це взагалі трохи окрема історія ніж звичний девелопмент під Android телефони/планшети. Включно з дебагом і процесом релізу.

Release в Production

Для Google Play Console остаточний реліз в Production це просто створення релізу вже в Production треку. За умови що усі попередні пункти вже виконано, тобто
— Як мінімум один реліз в Closed Testing завершено.
— Production Access вже надано (тобто Store Listing пройшов рев’ю).
— Опціонально, уся банківська і податкова інформація вже введена (для того щоб монетизація працювала одразу).

Якщо усі умови виконано, то далі потрібно просто:

1. створити реліз в Production треку;
2. заповнити усі Release Notes;
3. дочекатись поки цей реліз пройде рев’ю.

Типово, рев’ю займає 2-3 робочих дні. І за умови що все ОК, то реліз автоматично з’явиться в Google Play Store.

Post Release нотатки

Випуск нових версій виглядає загалом так само, як і випуск першої — тобто вам доступні все ті ж Internal Testing, Closed Testing, Open Testing і Production треки. Також можна редагувати Store Listing. Для публікації нових версій в Production технічно не обов’язково створювати релізи у всіх треках або ж редагувати Store Listing. Хоча, хорошою практикою вважається таки створити релізи у всіх цих треках. А також проранити якомога більше автотестів в Firebase.

Показники застосунку після релізу. В дашборді можна подивитись деякі із показників вже на девайсах користувачів. Як-то статистика встановлень і продажів, Crash & ANR (тобто креші), фрейм рейт, розподіл девайсів для кожного релізу тощо.

Монетизація. Ми в основному мали справу із звичайними платними застосунками, без підписок. В Payment Profile можна налаштувати графік виплат і мінімальний платіж. В нас вказаний звичайний банківський переказ (займає кілька бізнес-днів). В нашому випадку для зарахування коштів на рахунок банк попросив надати договір, згідно якого вони надходять. Нам пощастило, і банк прийняв репорт про виплати із дашборду.

Якщо підсумувати, то перший реліз в Google Play Store одного застосунку зайняв майже два місяці. Доволі довгою виявилась переписка з податковою про отримання довідки про податкове резидентство — кілька тижнів. Але, мабуть, найдовшим етапом були раунди Closed Testing — в нас пішло трохи більше місяця, щоб знайти та налаштувати усі Android-девайси. Знайти та умовити друзів і родичів, написати їм усім інструкції. А також писати в сабреддіт і тестувати продукти одне одного.

Наостанок

Резюмуючи під кінець — на випуск одного релізу або одного оновлення в App Store на усіх трьох платформах пішло приблизно три місяці однієї людини у вільний від основної роботи час. Найбільше часу зайняв реліз в Google Play Store. Публікація нового продукту в Microsoft Store і Apple App Store в такому ж режимі зайняла приблизно порівну — кілька тижнів.

Чи рекомендувати Microsoft Store, Apple App Store і Google Play Store інді та соло-девелоперам в 2024 році? Сильно залежить від ваших умов і досвіду. Якщо порівнювати зі схожим досвідом, але років п’ять тому, то реліз одного застосунку однозначно ускладнився. І за об’ємом ресурсів, і за об’ємом зусиль. Чи це все ще можливо для соло-девелоперів? Так.

Посилання на застосунки, про які йшлося в цій статті

Microsoft Store

• Наявний крос-платформний застосунок під десктопи
• Новий крос-платформний застосунок

Apple App Store

• Наявний крос-платформний застосунок під десктопи
• Новий крос-платформний застосунок

Google Play Store

• Новий крос-платформний застосунок