Чеклист мобільного застосунку для стартапів: 34 пункти від MVP до схвалення в App Store (2026)

Чеклист мобільного застосунку для стартапів: 34 пункти від MVP до схвалення в App Store (2026)

Настанова Apple з розгляду в App Store за номером 5.1.1(v) зірвала більше дат запуску стартапів, ніж будь-який баг, який ми колись відправляли в реліз. Одна відсутня кнопка видалення облікового запису, подана ввечері напередодні демо-дня, зсуває весь графік на тиждень. Цей чеклист мобільного застосунку для стартапів існує саме тому, що цієї помилки цілком можна уникнути, проте майже ніхто не записує номер настанови, яка її спричиняє.

Ключові висновки:

• Apple відхиляє застосунки без потоку видалення облікового запису та без посилання на політику конфіденційності: настанови 5.1.1 і 1.5 називають це прямо.
• Google Play вимагає два шляхи видалення облікового запису: у застосунку та публічний веб-шлях, а примусові заходи настають після завершення відстрочки 31 травня 2024 року.
• Чеклисти подання для iOS та Android різні; якщо поводитися з ними як з одним спільним списком, це причина номер один зривів релізу в останній момент.

До того, як писати код

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

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

Власні настанови Apple кажуть про вимогу до політики конфіденційності без обиняків: настанова 5.1.1(i) вимагає, щоб застосунки «мали посилання на свою політику конфіденційності» в метаданих App Store Connect, а в багатьох випадках і в самому застосунку. Це не порада. Якщо посилання немає, подання заблоковане.

• Визначте обсяг MVP одним реченням
• Переконайтеся, що вам потрібна політика конфіденційності (майже завжди потрібна)
• Підготуйте URL-адресу підтримки (настанова Apple 1.5 вимагає її)
• Перевірте застосовність GDPR/KVKK, якщо у вас є користувачі з ЄС або Туреччини
• Оберіть нативний чи кросплатформний стек

Тиждень розробки MVP

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

Найчастіше ми вирізаємо з обсягу v1 усе, що не є тією єдиною річчю, яку перевіряємо. Push-сповіщення, вхід через соцмережі, екран налаштувань із шістьма перемикачами, усе це може почекати. Засновники опираються, і це зрозуміло; здається, ніби ви відправляєте в реліз щось незакінчене. Воно й є незакінченим. У цьому й сенс.

Як сказав один засновник, який відправив у реліз кілька застосунків, у чеклисті на dev.to, пропуск механізму зворотного зв'язку на ранньому етапі це помилка, про яку він «шкодував щоразу». Вбудуйте його зараз, а не після першого відгуку. Якщо хочете прискорити саму розмову про обсяг, використання AI для швидкого визначення обсягу варто переглянути до початку розробки.

• Підключіть аналітику до першої збірки TestFlight або внутрішньої збірки
• Налаштуйте звітування про збої (Sentry або Firebase Crashlytics)
• Вбудуйте у застосунок механізм зворотного зв'язку
• Виріжте будь-яку функцію, яка не є ключовою для тієї єдиної речі, що перевіряється
• Напишіть перший рядок версії (див. версіонування нижче)

Тиждень до подання

Це етап, який усі чеклисти конкурентів повністю пропускають, і саме тут стаються найлегше попереджувані затримки. Семантичне версіонування застосунків дотримується схеми MAJOR.MINOR.BUILD (1.0.0, далі 1.0.1 для патчу, 1.1.0 для нової функції). Оберіть схему зараз, бо непослідовні номери версій плутають і крамниці застосунків, і вашу власну команду.

Поетапне розгортання спершу випускає оновлення на невеликий відсоток користувачів (часто 1%, потім 10%, потім 50%), перш ніж дійти до всіх. Лише один із трьох переглянутих нами чеклистів конкурентів згадує про це, та й то побіжно. Якщо крізь тести просочиться збій, поетапне розгортання обмежує радіус ураження, замість того щоб одразу вразити 100% користувачів.

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

• Переконайтеся, що номер версії дотримується послідовної схеми
• Ще раз протестуйте критичний шлях наскрізь
• Підготуйте відсоток поетапного розгортання, якщо крамниця його підтримує
• Перед поданням переконайтеся, що показник роботи без збоїв прийнятний
• Зробіть скріншоти та підготуйте всі матеріали сторінки в крамниці

День подання: iOS проти Android

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

У наших власних поданнях дві речі, які найчастіше підводять засновників-початківців, це вимога видалення облікового запису та недоступна URL-адреса підтримки. Обидві виправляються одним рядком, якщо помітити їх до подання. І обидві спричиняють автоматичне відхилення, якщо ні.

Настанови Apple з розгляду в App Store конкретні: настанова 5.1.1(v) вимагає, щоб застосунки зі створенням облікового запису також пропонували видалення облікового запису всередині застосунку, настанова 1.6 стосується розкриття Data Security, а настанова 1.5 вимагає робочої URL-адреси підтримки. На Android політика розробників Google Play вимагає і шлях видалення в застосунку, і публічну URL-адресу для запитів на видалення облікового запису. Google оголосив цю вимогу в квітні 2023 року, встановив кінцевий термін 7 грудня 2023 року для питань про видалення даних у формі Data safety і дозволив відстрочку до 31 травня 2024 року, після якої невідповідні застосунки чекають примусові заходи. Це не застаріле правило, яке скасували для малих застосунків; воно досі діє.

Два потоки подання відрізняються і механічно, а не лише на папері. На iOS ви вивантажуєте збірку через Xcode або Transporter, App Store Connect її обробляє (це триває від кількох хвилин до понад години), а далі ви або скеровуєте її в TestFlight для внутрішніх і зовнішніх тестувальників, або подаєте безпосередньо на розгляд App Review. TestFlight це не обов'язкова формальність: саме так Apple очікує від вас виявлення багів, за які рецензент інакше вас би відхилив. На Android Google Play Console працює не з одним поданням, а з треками, рухаючись від внутрішнього тестування до закритого чи відкритого тестування, а потім у продакшн, кожен зі своєю аудиторією та власним кроком просування. Поетапне розгортання з'являється лише тоді, коли ви оновлюєте наявний реліз у продакшні. Як каже власна документація Google про релізи, «якщо ви випускаєте свій перший реліз, ви не побачите опції вибору відсотка розгортання», тож не плануйте свій найперший запуск навколо відсоткового нарощування, воно з'явиться пізніше.

Документи, а не код, ось що насправді блокує більшість перших подань. Apple вимагає маніфест приватності для визначеного переліку поширених сторонніх SDK (рекламні мережі, аналітика, інструменти звітування про збої), і її власні настанови кажуть без обиняків, хто несе відповідальність: «коли ви використовуєте у своєму застосунку стороннє SDK, ви відповідаєте за весь код, який SDK включає у ваш застосунок, і маєте знати його практики збору та використання даних», згідно зі сторінкою вимог Apple до сторонніх SDK. Пропустіть маніфест для SDK з переліку, і ваша збірка не пройде App Store Connect. Еквівалентний документальний бар'єр Google Play це форма Data safety, і вона обов'язкова для кожного застосунку на кожному треку, окрім збірок лише для внутрішнього тестування: «усі розробники, які мають застосунок, опублікований у Google Play, повинні заповнити форму Data safety, включно із застосунками на треках закритого, відкритого тестування чи продакшну», згідно з документацією Google Play про Data safety. Помиліться, і Google прямо каже, що «може вжити відповідних заходів, включно з примусовими», щойно виявиться невідповідність між заявленою та фактичною поведінкою застосунку.

Є третій вид провалу, який не має стосунку до тексту політик: рецензент буквально не може протестувати ваш застосунок. Настанова Apple 2.1 каже про це прямо: «додайте дані демо-облікового запису (і увімкніть свій бекенд-сервіс!), якщо ваш застосунок має вхід». Немає робочих демо-облікових даних, немає живого бекенду під час вікна розгляду, немає доступної URL-адреси підтримки, і вас відхилять попри те, наскільки відповідний вимогам у вас потік видалення облікового запису. Якщо будь-яка частина вашого застосунку сидить за пейволом або входом, напишіть нотатки для рецензента з точним поясненням, як туди дістатися. Це двохвилинний крок, який засновники-початківці постійно пропускають.

Ще один бар'єр лише для Android належить до тієї ж розмови: цільовий рівень API. Власна документація розробника Android стверджує, що «нові застосунки та оновлення застосунків мають цілитися на» поточний необхідний рівень API Android, «щоб бути поданими в Google Play», і що «застарілі застосунки недоступні новим користувачам пристроїв із новішими версіями Android». Це не має жодного стосунку до видалення облікового запису чи Data Safety, але блокує подання так само наглухо, і це та вимога, яка змінюється щороку, тож перевірте поточний номер до того, як збирати свій реліз.

Жоден із чеклистів у топі видачі за цим точним запитом не цитує жодного номера настанов App Store. Ми цитуємо, бо вгадування відповідності вимогам це спосіб, у який релізи затримуються на тиждень за раз. Якщо ви вибудовуєте ширшу позицію поводження з даними, ваш чеклист поводження з даними перед релізом покриває бік безпеки, який ми тут не дублюємо.

Чеклист подання для iOS:

• URL-адресу політики конфіденційності опубліковано й вона доступна
• Шлях видалення облікового запису в застосунку відправлено в реліз (настанова 5.1.1(v))
• URL-адресу підтримки опубліковано (настанова 1.5)
• Розкриття Data Security заповнено (настанова 1.6)
• Збірку TestFlight схвалено перед публічним поданням

Чеклист подання для Android:

• Форму Data Safety заповнено в Play Console
• Шлях видалення облікового запису в застосунку відправлено в реліз
• Публічну URL-адресу для запитів на видалення облікового запису опубліковано (вимога Google Play)
• Відсоток поетапного розгортання встановлено
• Цільовий рівень API відповідає поточній вимозі Play

День релізу

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

Перші 24 години слідкуйте за панеллю App Store Connect або Play Console щогодини, а не щодня. Якщо ваш показник роботи без збоїв падає, ви хочете дізнатися протягом години, а не наступного ранку, коли ще сотня користувачів натрапила на той самий баг. Тримайте напоготові збірку для відкату. Та сама дисципліна «зміцни-стабілізуй-розгорни», яку ми застосовуємо для AI-функцій, тут працює так само безпосередньо.

• Перші 24 години відстежуйте показник роботи без збоїв щогодини
• Підготуйте канал підтримки з людиною напоготові
• Переконайтеся, що поетапне розгортання розширюється за планом
• Тримайте напоготові збірку для відкату на випадок критичного багу

Перший тиждень у релізі

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

«Сам реліз важить менше, ніж ви думаєте. Важить те, що ви робите в наступні тижні», як написав один засновник у власному чеклисті після релізу. Це чесна версія першого тижня: латайте швидко, відповідайте особисто й насправді перевірте, що ваш потік видалення даних працює, перш ніж реальний користувач протестує його замість вас. Якщо тепер вас цікавить, скільки все це коштує розробляти й утримувати, бюджетування підтримки та оновлень після релізу це супутня стаття. Ця стаття покриває готовність; та покриває рахунок.

• Перший тиждень розглядайте звіти про збої щодня
• Відповідайте особисто на перші 10 відгуків у крамниці
• Сортуйте та латайте будь-який критичний баг протягом 48 годин
• Переконайтеся, що ваш процес запитів на видалення даних справді працює наскрізь
• Задайте ритм звіряння аналітики з вашим початковим припущенням MVP

Як до цього підходить Techsy

Ми поводимося з передподальним розглядом однаково для кожної клієнтської збірки: перш ніж дати поданню зелене світло, ми питаємо, чи працює критичний шлях на реальному пристрої, чи тримається показник роботи без збоїв і чи справді функціонує кожен обов'язковий за настановами потік (видалення облікового запису, політика конфіденційності, URL-адреса підтримки), а не просто існує в макеті. Це короткий список, але саме він визначає, чи пройде застосунок розгляд із першої спроби.

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

Часті запитання

Що таке MVP і чому він важливий для чеклиста запуску?

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

Чому застосунки відхиляють в App Store?

Найпоширеніші причини, яких можна уникнути, це відсутнє посилання на політику конфіденційності (настанова 5.1.1(i)), немає видалення облікового запису в застосунку (настанова 5.1.1(v)) і недоступна URL-адреса підтримки (настанова 1.5). Жодна з них не потребує інженерних зусиль для виправлення, це пункти чеклиста, а не баги.

Що буде, якщо не додати опцію видалення облікового запису в мій застосунок?

На iOS настанова 5.1.1(v) робить це автоматичною причиною відхилення, якщо ваш застосунок підтримує створення облікового запису. На Android Google Play вимагає і шлях видалення в застосунку, і публічний веб-шлях, а невідповідні застосунки чекають примусові заходи після кінцевого терміну відстрочки 31 травня 2024 року; якщо пропустити це, подання заблоковане на обох платформах.

Чи потрібна стартапам політика конфіденційності для мобільного застосунку?

Так, майже завжди. Apple вимагає політику конфіденційності з посиланням за настановою 5.1.1(i), а Google Play вимагає її всередині форми Data Safety. Якщо ви збираєте будь-які дані користувачів, хоча б email для реєстрації, вона потрібна вам до подання.

У чому різниця між поданням в App Store та в Google Play?

Розгляд Apple керується настановами з іменованими пунктами (5.1.1, 1.5, 1.6) та живим рецензентом; Google Play спирається на форму Data Safety та автоматичні перевірки. Вимога видалення облікового запису схожа за духом, але відрізняється механікою; див. порівняльну таблицю вище.

Скільки насправді триває розгляд у крамницях застосунків?

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

Що таке поетапне розгортання і чи варто його використовувати?

Поетапне розгортання спершу випускає оновлення на невеликий відсоток користувачів, а потім поступово розширюється, замість того щоб іти одразу на 100%. Використовуйте його, коли крамниця його підтримує; воно обмежує кількість користувачів, які натраплять на баг, перш ніж ви зможете зупинитися й виправити його.

Чи потрібна URL-адреса підтримки, щоб подати мій застосунок?

Так. Настанова Apple 1.5 вимагає робочої URL-адреси підтримки як частини подання, і Google Play також очікує контакт підтримки. Мертве посилання або скринька, яку ніхто не перевіряє, це проста, попереджувана причина відхилення.

Що відстежувати в перший тиждень мого застосунку в релізі?

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

Чи стосуються GDPR або KVKK застосунку малого стартапу?

Якщо у вас є користувачі в ЄС, GDPR застосовується незалежно від розміру вашої компанії. Якщо у вас є користувачі в Туреччині, KVKK застосовується так само. Жоден із законів не має винятку для малих стартапів, тож перевірте застосовність під час визначення обсягу, а не після того, як у вас з'являться реальні дані користувачів для захисту.

Про автора

Мерт Батур — співзасновник Techsy.io, де команда відправляє в продакшн AI-агентів, системи автоматизації та голосові/SDR-конвеєри для B2B-клієнтів. Він пише про стек інструментів для LLM, який команда Techsy реально використовує в продакшні. Профіль у LinkedIn.

Висновки

Чеклист мобільного застосунку для стартапів заслуговує на своє місце, лише якщо він достатньо конкретний, щоб діяти за ним сьогодні: визначте свій MVP одним реченням, підключіть аналітику до розробки, перегляньте свою схему версіонування за тиждень до подання та розділіть чеклисти для iOS і Android, замість того щоб поводитися з ними як з одним списком. Саме пункти видалення облікового запису та політики конфіденційності дають більшість попереджуваних відхилень, які ми бачимо.

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