Скільки часу займає розробка застосунку для iOS та Android?

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

Чому ніхто не може назвати строк одразу?

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

Команда, яка називає дату на першому дзвінку, вгадує. Корисна оцінка з’являється, коли застосунок розбили на сценарії (флоу) й оцінили кожен окремо, а для цього потрібен огляд вашої специфікації, дизайну чи наявного застосунку, а не анкета.

З яких етапів складається розробка застосунку?

Чотири етапи, і після кожного у вас має лишатися щось, на що можна подивитися.

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

Що робить розробку довшою?

Шість речей впливають на строки найбільше.

1. Кількість окремих сценаріїв. Реєстрація, онбординг, головна дія, оплата, налаштування, сповіщення — кожен сценарій має власні екрани, стани й помилки. Кількість екранів важить менше, ніж кількість різних шляхів, якими може пройти користувач. 2. Потрібний бекенд. Застосунок, що працює з наявним API, — це переважно клієнтська робота. Застосунок, якому потрібні власний сервер, база даних, адмінка й облікові записи користувачів, — це два проєкти. 3. Інтеграції. Оплати й підписки, карти й геолокація, пристрої Bluetooth Low Energy, дані про здоров’я, відео. Кожна має свій SDK, правила платформи й тестування на реальних пристроях — BLE як слід не протестуєш на симуляторі. 4. Готовність дизайну. Готові макети для кожного стану — порожнього, завантаження, помилки — дають змогу почати розробку одразу. Дизайн, який ще обговорюють, перетворює розробників на дизайнерів, і всім стає повільніше. 5. Швидкість рішень. Кожне відкрите питання («що буде, якщо оплата не пройде?») блокує частину роботи, доки хтось не відповість. Команда, яка чекає відповіді днями, днями й втрачає. 6. Перевірка в сторах. Часто коротка, але не під вашим контролем, а відхилення означає виправлення й повторне подання.

Скільки триває перевірка в App Store і Google Play?

Зазвичай недовго, але її треба закладати в план. Apple пише, що App Review зазвичай перевіряє щонайменше половину всіх подань менш ніж за 24 години і 90% — менш ніж за 48, і попереджає, що неповне подання може затриматися (Apple Developer: App Review, дані станом на 27 жовтня 2026).

Google типового строку не публікує. У довідці сказано, що для деяких акаунтів розробника і деяких застосунків перевірка може тривати до семи днів, а у виняткових випадках і довше (Play Console Help: Publish your app, станом на 27 жовтня 2026).

На Android є пастка серйозніша. Особисті акаунти розробника, створені після 13 листопада 2023 року, мають провести закрите тестування щонайменше з 12 тестувальниками, які безперервно беруть у ньому участь не менше 14 днів, і лише потім можуть попросити доступ до продакшну (Play Console Help: вимоги до тестування для нових особистих акаунтів, станом на 27 жовтня 2026). Якщо зареєструвати новий особистий акаунт за тиждень до запуску, лише це вже відсуне дату.

На iOS налаштування акаунта теж може забрати час: організації для вступу в Apple Developer Program потрібен номер D-U-N-S (Apple Developer: реєстрація). Заводьте обидва акаунти на початку проєкту, а не наприкінці.

Через що застосунки найчастіше відхиляють і як уникнути другого кола: чек-лист відхилень App Store.

Чи вдвічі довше робити застосунок для iOS та Android?

Ні — з однією кодовою базою на Flutter більшість роботи робиться один раз. Документація Flutter описує його як інструмент, створений, щоб дозволити повторне використання коду між операційними системами, зокрема iOS і Android (Flutter architectural overview). Екрани, бізнес-логіку, керування станом і роботу з API пишуть один раз, і вони працюють на обох платформах.

Дещо все одно робиться для кожної платформи окремо:

• дозволи, налаштування пуш-сповіщень і підпис для кожного стору;
• платформний код там, де його потребує інтеграція (той самий огляд зазначає, що застосунки можуть напряму звертатися до сервісів платформи);
• два лістинги й дві перевірки;
• тестування і на iPhone, і на Android-телефонах, бо вони все одно поводяться по-різному.

Отже, з двома нативними застосунками більшість функцій пишуть двічі; з одним застосунком на Flutter — пишуть один раз і перевіряють двічі. Детальніше про те, як порівнюються варіанти: Flutter, нативна розробка чи React Native.

Як чесно скоротити строки?

Будувати спершу менше й прибрати очікування, а не просити команду поквапитися.

1. Почніть з найменшої корисної версії. Оберіть одне завдання, яке застосунок має виконувати добре, і випустіть саме його. Те, що часто називають MVP, має бути найменшою версією, якою реальні користувачі захочуть користуватися, а не демо. Решта прийде в оновленнях. 2. Підготуйте дизайн. Хоча б для ключових сценаріїв, зі станами порожнього екрана, завантаження й помилки. 3. Відповідайте протягом дня. Призначте одну людину, яка ухвалює рішення, і домовтеся, що на питання відповідають того ж або наступного робочого дня. 4. Заведіть акаунти заздалегідь. Apple Developer Program, Google Play Console, закрите тестування, якщо його вимагає ваш акаунт у Play, домен і пошта, від яких залежить застосунок. 5. Встановлюйте кожен тестовий білд. Проблема, знайдена на другому тижні, дешевша за проблему, знайдену наприкінці. 6. Фіксуйте обсяг поточного модуля. Нові ідеї йдуть у наступний модуль із власною ціною, а не в той, що вже в роботі.

Що не працює: додавати розробників у проєкт, який запізнюється, пропускати тестування на пристроях або подавати неготовий білд, щоб «подивитися, що скаже перевірка».

Які червоні прапорці в оцінці строків?

Строк — це обіцянка щодо роботи, яку ніхто ще не бачив, якщо команда не визначила обсяг робіт. Звертайте увагу на таке:

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

Як ми оцінюємо й розробляємо застосунок

DriveCode розробляє застосунки для iOS та Android, Flutter-first. Ми не називаємо строк, доки не побачили вашу специфікацію, дизайн чи наявний застосунок. Спершу ми їх переглядаємо, потім ділимо роботу на модулі з фіксованою ціною кожного, погодженою ще до того, як написано перший рядок коду. Код живе у вашому репозиторії з першого коміту, а регулярні тестові білди з TestFlight і Google Play ви встановлюєте самі — і бачите прогрес, не чекаючи звіту про статус. Якщо обсяг змінюється, зміна отримує окрему оцінку. Проєкти — від $10K. Як це працює детальніше: розробка нового застосунку для iOS та Android на Flutter.

Уже маєте застосунок, який треба доробити, а не новий? Почніть зі статті виправити, рефакторити чи переписати.

Що часто питають

Чи можна зробити застосунок за кілька тижнів? Деякі — так, якщо обсяг вузький, дизайн готовий, а бекенд уже існує. Чи вийде так із вашим, покаже визначення обсягу робіт, а не перший дзвінок.

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

Скільки триває перевірка в App Store? Станом на жовтень 2026 Apple пише, що зазвичай перевіряє щонайменше половину подань за 24 години і 90% — за 48 годин. Google Play попереджає, що для деяких акаунтів і застосунків перевірка може тривати до семи днів, а у виняткових випадках довше; новим особистим акаунтам у Play спершу потрібне 14-денне закрите тестування.

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

Чи можна бачити прогрес до завершення застосунку? Так, і варто. Просіть тестові білди, щойно запрацює перша функція. Станом на жовтень 2026 у TestFlight можна додати до 100 внутрішніх тестувальників із вашої команди (Apple: TestFlight), а внутрішнє тестування в Google Play приймає до 100 тестувальників (Play Console Help: налаштування тестування).