Причини відмови в App Store та Google Play: топ-6 і як уникнути

Хто і як перевіряє застосунок перед публікацією

Уяви, що ти здаєш квартиру, а перед заселенням приходить прискіпливий інспектор. Жити в ній місяцями він не збирається. Пʼять хвилин - і він пройшовся по кімнатах, смикнув кожну ручку, перевірив, чи тече кран, зазирнув під раковину. Один тарган - і акт не підписаний.

Ревʼю Ревʼю (review) - перевірка застосунку людьми та автоматикою з боку магазину перед публікацією. Вирішують, пустити тебе в магазин чи повернути на доопрацювання. в App Store та Google Play працює точно так само. По той бік - жива людина з чеклистом, у якої пара хвилин на твою збірку. Вона не шукає, за що тебе похвалити. Вона шукає, до чого причепитися. І знаходить, як правило, одне й те саме: впало, недороблено, посилання бите, скриншот бреше, просить зайвого.

Чому одна відмова коштує тобі тижня

Кожен реджект - це втрачені дні. Відправив збірку. Відстояв чергу. Отримав сухе «rejected». Поліз читати формулювання правила. Полагодив. Відправив знову. І знову чекаєш. Один дурний недогляд - і ось він, тиждень простою на рівному місці.

• Зекономиш дні та нерви: полагодити заздалегідь у рази дешевше, ніж після відмови.
• Перестанеш сприймати реджект як особисту образу - це просто пункт чеклиста, який ти проґавив.
• Почнеш думати як ревʼюер ще на етапі розробки, а не згадувати про правила в останній день.
• Вайбкодинг обожнює плодити напівфабрикати: ШІ намалював красивий екран, а кнопка під ним - пустушка. Магазини це ловлять на раз.

Більшість відмов потрапляють у пʼять кошиків: неповна інформація, зламана функціональність, порушення приватності, проблеми дизайну та невідповідність правилам. Запамʼятай цю пʼятірку - і ти вже на крок попереду черги на реджект.

Топ-6 причин відмови в App Store та Google Play

Пройдемося по найчастіших граблях. По кожній - у чому суть і які ліки.

1. Краші та баги: застосунок падає на перевірці

Вирок номер один. Застосунок падає або явно глючить на будь-якому екрані, який відкрив ревʼюер - усе, розмову закінчено. Магазин не зобовʼязаний зʼясовувати, що в тебе «взагалі-то майже все працює». Впало на перевірці - значить відмова. Крапка.

Ліки: пройди весь сценарій руками перед відправкою - так, ніби бачиш застосунок уперше. Окремо ганяй перший запуск, вхід, порожні стани (коли даних ще немає) і поведінку на поганому звʼязку. Саме там зазвичай усе й сиплеться.

2. Недороблений функціонал і заглушки в релізі

Екрани з написом «Скоро буде», текст-риба Lorem Ipsum Lorem Ipsum (лорем іпсум) - стандартний текст-заглушка псевдолатиною, який вставляють замість справжнього контенту на етапі верстки. У готовому застосунку його бути не повинно. , кнопки в нікуди - один із найчастіших приводів завернути новачка. Магазину потрібен готовий продукт. Не демо з дірками, не «майже фінал» - готовий.

Ліки: правило просте до неподобства - кожна кнопка, до якої можна дотягнутися з першого екрана, має робити щось реальне. Фічі поки немає? Прибери кнопку, а не ліпи заглушку. Жодних «TODO», плейсхолдерів і «тимчасових» екранів у релізній збірці.

3. Неробочі посилання: битий URL коштує відмови

Бите посилання - начебто дрібниця, а коштує цілої відмови. Найчастіше спотикаються на посиланні на політику приватності: воно веде на порожню сторінку, на 404 чи взагалі відсутнє. Ревʼюер не може перевірити твої обіцянки про дані - значить, не пропустить.

Ліки: відкрий кожне посилання руками перед відправкою. У застосунку, у картці магазину, у підтримці. Усі мають відкриватися й вести туди, куди заявлено. Жодного «localhost» і чернеток, які ти забув підмінити.

4. Немає політики приватності (Guideline 5.1.1)

Майже будь-якому застосунку сьогодні потрібна політика приватності Політика приватності (privacy policy) - документ, який зрозуміло описує, які дані застосунок збирає, як і навіщо, і кому передає. Потрібен майже для всіх застосунків в обох магазинах. . Порушення правил про приватність (в Apple це розділ Guideline 5.1.1) - одна з найчастіших причин відмови, особливо в новачків.

Що вимагається:

5. Скриншоти, що вводять в оману, у картці

Скриншоти в картці - це вітрина. І показувати вона зобовʼязана рівно те, що всередині збірки, яку ти відправив. Красиві картинки з фічами «з майбутнього», чужий інтерфейс, екрани, яких у застосунку немає, - прямий шлях до відмови за обман.

Ліки: знімай скриншоти з поточної збірки, а не з макетів дизайнера. Жодного фотошопу зверху, жодних функцій, яких ще немає. Покажи рівно те, що людина побачить, завантаживши застосунок - ні кадром більше.

6. Запит зайвих дозволів застосунком

Дозволи Дозвіл (permission) - доступ, який застосунок просить у користувача: камера, мікрофон, геолокація, контакти, сповіщення. Кожен має бути виправданий тим, що застосунок робить. на кшталт геолокації у фоні, доступу до контактів, камери чи SMS магазини перевіряють особливо суворо. Просиш доступ, який ніяк не вʼяжеться з тим, що застосунок робить, - це червоний прапорець, і збірку завернуть.

Ліки: проси лише те, що реально використовуєш просто зараз, і до кожного дозволу дай зрозуміле пояснення - навіщо він. Сумніваєшся, чи потрібна фіча в цьому релізі? Прибирай - і дозвіл разом із нею.

Чеклист перед відправкою застосунку на ревʼю

Перед тим як тиснути «Відправити на ревʼю», пройди по списку - вголос. На кожен пункт чесне «так», без поблажок собі.

Пройшов увесь застосунок руками на свіжому встановленні без своїх даних - ніде не впало.
Перевірив порожні екрани, вхід і поведінку за поганого звʼязку - нічого не зламалося.
Кожна кнопка з першого екрана робить щось реальне. Заглушок, «Скоро буде» і тексту-риби немає.
Відкрив кожне посилання - у застосунку і в картці. Усі робочі, ведуть куди треба.
Політика приватності є, посилання живе у двох місцях, текст збігається з тим, що застосунок реально збирає.
Скриншоти зняті з поточної збірки, без фотошопу і фіч із майбутнього.
Пройшовся по списку дозволів - залишив лише потрібні, у кожного є зрозуміле пояснення навіщо.
Опис і мітки приватності в картці не обіцяють того, чого в застосунку немає.

Застосунок писав ШІ? Згодуй йому цей промпт - хай сам вишукає міни, які любить закладати. Тільки відповідь читай очима, а не вір на слово: ШІ вміє і вигадувати проблеми, і ховати справжні.

Перевір мій застосунок перед відправкою на ревʼю в App Store та Google Play. Знайди і перелічи все, за що його можуть відхилити:

Екрани або кнопки, які падають, нічого не роблять або ведуть у нікуди.
Заглушки: «Скоро буде», текст-риба, сірі квадрати замість картинок, позначки TODO.
Биті або тимчасові посилання (localhost, чернетки), особливо на політику приватності.
Дозволи, які запитуються, але реально не використовуються в коді.
По кожній знахідці скажи: де вона в коді і як її прибрати. Не вигадуй неіснуючих проблем - тільки те, що реально є.

Часті помилки, через які завертають збірку

• Тестувати лише на своєму пристрої. У тебе вже є дані та видані всі дозволи. Ревʼюер бачить чисте встановлення, де все інакше. Перевіряй з нуля.
• Залишати «тимчасові» заглушки. Кнопка-пустушка або екран «Скоро буде» - готовий привід для відмови. У реліз іде лише те, що працює.
• Не відкрити посилання руками. Особливо на політику приватності: одна 404 - і збірку повернуть. Клікни кожне перед відправкою.
• Малювати скриншоти у фотошопі. Вітрина зобовʼязана збігатися зі збіркою. Красиві фічі з майбутнього читаються як обман.
• Просити дозволи «про запас». Доступ, який не використовується, - червоний прапорець. Бери лише потрібне і пояснюй навіщо.
• Сприймати відмову як катастрофу. Реджект - це пункт чеклиста, який ти проґавив. Прочитав формулювання, полагодив, відправив знову - і поїхали далі.