Публикуване на приложение в App Store и Google Play: практически списък

За да публикувате приложение, ви трябват акаунт за разработчици в Apple и акаунт в Google, и двата на ваше име или на името на фирмата ви. След това качвате подписана версия, попълвате страницата в магазина и формулярите за поверителност, тествате с реални потребители чрез TestFlight и тестовите канали на Google Play и изпращате приложението за преглед. Повечето откази идват от сривове, непълна информация, отговори за поверителност, които не съвпадат с приложението, или липса на достъп за проверяващия, а всичко това може да се провери предварително. След одобрение пускайте обновленията постепенно, за да стигне евентуална грешна версия до възможно най-малко хора.

#Акаунти и ключове за подписване на ваше име

Акаунти за разработчици

Apple публикува приложения чрез Apple Developer Program и App Store Connect, а Google чрез Google Play Console. И при двете можете да се регистрирате като физическо лице или като организация. Ако приложението е на фирма, регистрирайте фирмата: в магазина като разработчик се показва титулярят на акаунта, а прехвърлянето на приложение към друг акаунт по-късно изисква допълнителна работа. Apple изисква от организациите D-U-N-S номер, а Google иска данни за потвърждаване на самоличността, затова започнете отрано.

• Поканете разработчиците или агенцията като потребители с ограничени роли. Не им давайте входа на титуляря.
• Поддържайте актуални данните за плащания и данъци, споразуменията и контактите. И двата магазина могат да спрат публикуването, ако ново споразумение не е прието.

Същото правило важи за всичко около приложението: хранилището с кода, хостинга на сървърната част и домейна. В статията кой трябва да притежава кода и акаунтите обясняваме какво да проверите преди подписване и при предаване на проекта.

Ключове за подписване

Всяка версия се подписва, за да могат магазинът и телефонът да потвърдят, че идва от вас.

• При iOS се използват сертификати и provisioning профили, свързани с акаунта ви в Apple. При нужда се издават наново от акаунта.
• При Android се използва keystore. С Play App Signing Google пази ключа, с който приложението се подписва за устройствата на потребителите, а вие подписвате качваните версии с отделен ключ за качване. Ако загубите ключа за качване, титулярят на акаунта може да поиска от Google да го смени. Ако сами управлявате ключа за подписване на приложението и го загубите, повече не можете да публикувате обновления на това приложение.

Съхранявайте keystore файловете и паролите в мениджър на пароли или хранилище за тайни, което е под контрола на фирмата, и запишете къде се намират. Никога не ги оставяйте само на лаптопа на един разработчик.

#Страница в магазина и екранни снимки

Страницата в магазина е това, което потребителите четат преди да инсталират, а проверяващите я сравняват с приложението.

• Име, подзаглавие или кратко описание и пълно описание, което казва на ясен език какво прави приложението.
• Екранни снимки за изискваните размери устройства, направени от истинското приложение. И двата магазина публикуват актуалните изисквания; проверявайте ги при всяко издание, вместо да използвате стари изображения.
• Икона, категория, ключови думи (App Store) и рекламно изображение (Google Play).
• Възрастова класификация, попълнена чрез въпросника на всеки магазин.
• Адрес за поддръжка и адрес на политика за поверителност, които се отварят и описват точно това приложение.

#Декларации за поверителност и формулярът Data safety

И двата магазина питат какви данни събира приложението и с каква цел. В App Store отговорите се показват като информация за поверителността на приложението, а в Google Play се попълват във формуляра Data safety. Отговаряте за цялото приложение, включително за външния код: аналитика, отчети за сривове, реклама, вход чрез външни доставчици и библиотеки за плащане се броят.

1. Опишете всеки вид данни, които приложението или библиотеките в него събират: контакти, местоположение, идентификатори, данни за използване, логове от сривове и данни за плащане.
2. За всеки вид отбележете дали е свързан с потребителя, дали се използва за проследяване и дали се споделя с трети страни.
3. Уверете се, че политиката за поверителност казва същото като формулярите в магазините.
4. Ако потребителите могат да си създадат профил в приложението, дайте им начин да го изтрият. И двата магазина го изискват.
5. В iOS поискайте разрешение чрез App Tracking Transparency, преди да проследявате потребителите в приложения и сайтове на други компании, и напишете ясен текст за всяко искане на разрешение (камера, местоположение, контакти).

Обновявайте отговорите всеки път, когато добавите библиотека или функция, която събира нови данни.

#Тестване с реални потребители преди пускане

TestFlight е услугата на Apple за бета тестове. Вътрешните тестери са членове на екипа ви в App Store Connect и могат да инсталират версията веднага след обработката ѝ. Външните тестери се канят по имейл или с публична връзка, а първата версия за външно тестване минава кратък бета преглед.

Google Play има вътрешен, затворен и отворен тестов канал. Вътрешният бързо стига до малък списък хора. Затвореният стига до групите, които поканите. Отвореният позволява на всеки да се включи от страницата в магазина. Google изисква някои по-нови лични акаунти за разработчици да проведат затворен тест с минимален брой тестери за определен период, преди да получат достъп до публикуване. Проверете актуалното правило при създаването на акаунта и го включете в плана.

Използвайте тестовете, за да проверите нещата, до които проверяващите и потребителите стигат първи: регистрация и вход, плащания или абонаменти, push известия, искания на разрешения и поведението при бавна или липсваща връзка.

#Чести причини за отказ и как да ги избегнете

Правилата на магазините се променят и са публикувани в App Review Guidelines на Apple и в Developer Program Policies на Google Play. Причините по-долу се срещат често и всяка може да се провери преди изпращане.

• Сривове и прекъснати сценарии. Проверяващият отваря приложението на истинско устройство. Ако то се срине, блокира или покаже грешка още на първия екран, ще бъде отхвърлено.
• Липса на достъп за проверяващия. Ако е нужен вход, дайте работещ демо профил и инструкции в бележките за прегледа.
• Временно или непълно съдържание. Lorem ipsum, празни екрани, мъртви връзки и секции „очаквайте скоро“ показват, че приложението не е завършено.
• Твърде малко функционалност. Приложение, което само обвива уебсайт и не използва нищо от устройството, често бива отказано.
• Плащания за дигитално съдържание. Продажбата на дигитални стоки и абонаменти в приложението обикновено трябва да минава през системата за плащания на магазина. Физическите стоки и услуги се плащат чрез ваш доставчик на плащания. Прочетете актуалните правила за вашия случай, преди да изграждате плащането.
• Разминавания в поверителността. Недекларирани данни, липсваща политика за поверителност или неясни искания на разрешения.
• Подвеждащи данни. Снимки, описания или имена, които не отговарят на приложението или използват чужди марки без разрешение.

При отказ прочетете внимателно съобщението, поправете конкретния проблем и отговорете в App Store Connect или в Play Console. И двата магазина имат процедура за обжалване, ако смятате, че проверяващият е сгрешил.

#Постепенно пускане и редовни обновления

След одобрението изберете как версията да стигне до потребителите. Google Play поддържа поетапно пускане: публикувате за процент от потребителите, следите сривовете и отзивите и след това увеличавате дела или спирате. В App Store поетапното пускане разпределя автоматичното обновление в рамките на няколко дни и можете да го паузирате при проблем.

Публикуването не е еднократно събитие. Магазините периодично вдигат минималните изисквания за нови версии на операционните системи и SDK, а приложение без обновления може да бъде скрито от нови потребители. Планирайте редовни версии за поддръжка и пазете API-то зад приложението съвместимо с по-старите версии, които още са на телефоните на хората. Ако все още избирате технология, сравнението React Native или Flutter показва как изборът влияе на поддръжката.

#Как може да помогне PN Scripts

PN Scripts разработва мобилни приложения за iOS и Android на React Native, Flutter, Swift и Kotlin, заедно с API-то зад тях, и се грижи за публикуването им в магазините. Акаунтите за разработчици, ключовете за подписване и кодът са на ваше име от първия ден. Как протича един проект, ще видите на страницата за разработка на мобилни приложения.