Що отримує замовник після розробки мобільного додатку: повний чекліст

Питання, що отримує замовник після розробки мобільного додатку, не зводиться до встановленої на смартфоні програми або посилань на App Store і Google Play. Бізнес має отримати контроль над усією системою: вихідним кодом, репозиторіями, серверною інфраструктурою, обліковими записами, інтеграціями, дизайном і документацією.

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

Що означає повна передача мобільного додатку

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

Практичний підхід WebUI Studio — розглядати мобільний продукт як сукупність взаємопов’язаних активів. Застосунок, backend, база даних, домен, хмара, аналітика та кабінети магазинів мають бути внесені до єдиного переліку передачі із зазначенням власника, ролей, оплати та способу відновлення доступу.

Вихідний код і Git-репозиторій

Замовнику потрібна актуальна версія вихідного коду мобільного додатку: окремі iOS та Android проєкти або код кросплатформного рішення. Передавати лише інсталяційний APK, AAB чи готову iOS-збірку недостатньо — з таких файлів неможливо нормально продовжити розробку.

Яким має бути доступ до Git

Оптимально, коли репозиторій створений у корпоративній організації замовника. Якщо його створив підрядник, бізнесу потрібно надати роль власника або адміністратора та, за потреби, перенести репозиторій. Варто перевірити не лише основну гілку, а й історію змін, теги релізів, підмодулі, Git LFS, конфігурацію автоматичних збірок і пов’язані репозиторії.

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

Чи достатньо просто отримати вихідний код

Ні. Код без конфігурації середовищ, backend, ключів підписання, схеми бази даних і доступів до хмарних сервісів може бути непридатним для випуску оновлень. Репозиторій показує, як продукт написаний, але не обов’язково пояснює, як він працює у production.

Разом із кодом потрібні перелік environment variables без секретних значень, інструкції build і deploy, версії інструментів, параметри тестового та бойового середовищ, правила міграції бази даних і процедура відкату релізу. Секрети не слід зберігати у відкритому файлі в Git.

Backend, API та інфраструктура

Якщо застосунок має серверну частину, передача source code додатку охоплює і backend. Замовнику потрібні код сервера, документація API, схема даних, міграції, опис фонових завдань, черг, файлових сховищ і зовнішніх інтеграцій.

Окремо перевіряють контроль над реєстратором домену, DNS, VPS, AWS, Google Cloud чи іншою хмарою, базою даних, CDN, резервними копіями та системою моніторингу. Корпоративний акаунт із власним білінгом і відновленням доступу безпечніший за особистий профіль програміста. Перед видаленням доступів підрядника слід переконатися, що нові ролі працюють і не зупинять production.

Як передавати паролі та ключі

API keys, паролі, access tokens, приватні ключі та резервні коди не можна додавати до звичайної документації, листа чи чату. Їх передають через корпоративний менеджер паролів, систему керування секретами або інший погоджений захищений канал. Після приймання критичні секрети доцільно змінити, а старі доступи — відкликати з урахуванням плану підтримки.

Кому мають належати акаунти App Store та Google Play

Для бізнес-продукту рекомендована модель — компанія-замовник контролює облікові записи розробника, платіжні дані, відновлення доступу та найвищі адміністративні ролі. Підрядник отримує лише ті дозволи, які потрібні для збірки, тестування й публікації.

Apple Developer та App Store Connect

Акаунт Apple Developer і доступ до App Store Connect бажано оформлювати на організацію замовника, якщо її форма та умови Apple це дозволяють. Представник бізнесу має контролювати роль Account Holder, корпоративну адресу, двофакторну автентифікацію, угоди й оплату. Команді розробки можна надати відповідні робочі ролі без передачі головного пароля.

Під час приймання також перевіряють ідентифікатори застосунку, сертифікати, профілі, налаштування push-повідомлень, Sign in with Apple, тестові групи та картку застосунку. Якщо продукт уже розміщений в акаунті підрядника, можливість перенесення залежить від актуальних правил Apple, стану застосунку та використаних функцій. Перед діями потрібно перевірити вимоги й скласти план міграції.

Google Play Console

Google Play Console також має контролювати компанія-замовник: профіль розробника, адміністраторів, платіжні налаштування та способи відновлення. Необхідно перевірити package name, сторінку застосунку, тестові треки, політики, звіти, Play App Signing і доступ до ключа завантаження. Передавання опублікованого продукту між акаунтами може бути можливим, але залежить від поточних вимог Google та пов’язаних сервісів.

Firebase, аналітика та сторонні інтеграції

Проєкт Firebase може обслуговувати авторизацію, Firestore, Cloud Messaging, Analytics, Crashlytics, Remote Config або інші критичні функції. Замовник повинен мати достатню адміністративну роль у самому проєкті та пов’язаному хмарному білінгу. Назва проєкту в документації без реального доступу не вирішує проблему.

Так само перевіряють GA4, AppsFlyer, Adjust, Meta SDK та інші системи аналітики. Ресурси, аудиторії, експорти даних і зв’язки з рекламними кабінетами мають залишатися під контролем бізнесу.

До реєстру інтеграцій варто включити платіжні системи, SMS та email-сервіси, карти, CRM, телефонію, соціальну авторизацію, підтримку користувачів і сторонні API. Для кожного сервісу фіксують власника акаунта, тариф, спосіб оплати, квоти, production і test середовища, контакт підтримки та наслідки відключення.

Документація, дизайн і матеріали для магазинів

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

• архітектуру та перелік використаних технологій;
• структуру репозиторіїв і правила роботи з гілками;
• інструкцію локального запуску та встановлення залежностей;
• процеси build, test, deploy і публікації нових версій;
• перелік environment variables без паролів і токенів;
• опис серверів, баз даних, резервного копіювання та моніторингу;
• список сторонніх сервісів, інтеграцій і відповідальних осіб.

Якщо дизайн входив до робіт, замовнику передають Figma-проєкт із належними правами, компоненти дизайн-системи, іконки, логотипи, splash screen, шрифти та графіку для сторінок App Store і Google Play. Для придбаних шрифтів, фото, ілюстрацій або бібліотек потрібно окремо перевірити ліцензії: сам файл не завжди означає право на подальше використання.

Права на код і результати робіт

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

Сам факт оплати або отримання Git-доступу не варто автоматично прирівнювати до юридично оформленого переходу всіх прав. Конкретний обсяг залежить від договору та законодавства застосовної юрисдикції, тому спірні формулювання доцільно перевірити з профільним юристом. Технічне приймання й оформлення прав — пов’язані, але різні завдання.

Що не варто приймати як нормальну ситуацію

• актуальний код є тільки на комп’ютері одного розробника;
• замовник бачить Git, але не може керувати учасниками чи зробити резервну копію;
• App Store Connect або Google Play Console контролює лише підрядник;
• сервер, домен чи Firebase оформлені на особистий акаунт фахівця;
• немає повного списку платних сервісів та інтеграцій;
• секрети записані в репозиторії або незахищеному документі;
• ніхто, крім попередньої команди, не може зібрати й опублікувати реліз.

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

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

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

Що перевірити перед фінальною оплатою за розробку

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

Також потрібно звірити регулярні витрати: хостинг, базу даних, сховища, аналітику, SMS, email, карти, сертифікати та акаунти розробника. Замовник має розуміти, які платежі є критичними, з якої картки вони списуються і що станеться після перевищення лімітів.

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

Передачу потрібно планувати до початку робіт

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

Правильна передача проєкту не означає недовіру до команди. Це базова умова безперервності бізнесу: компанія зберігає активи під власним контролем, а розробники можуть підтримувати продукт без залежності від особистих акаунтів і неформальних домовленостей.