Как создаётся приложение для App Store, Google Play и других Store: разработка, публикация и расчёты

Заказ на мобильное приложение часто формулируется очень просто:

Нужно разработать приложение и разместить его в Store.

Но фактически внутри этой фразы находятся сразу несколько разных процессов:

Проектирование продукта
        ↓
Разработка приложения
        ↓
Тестирование
        ↓
Подготовка релизной сборки
        ↓
Подача в Store
        ↓
Модерация магазина
        ↓
Возможные замечания
        ↓
Доработка
        ↓
Повторная подача
        ↓
Публикация

И здесь есть принципиально важная граница.

Разработчик создаёт приложение.

Store принимает решение о его публикации.

А в модели работы WebRuta публикацию приложения через аккаунт магазина выполняет сам заказчик.

Это позволяет сразу правильно разделить:

разработку продукта;
владение приложением;
аккаунт Store;
процесс модерации;
дополнительные работы по доведению до публикации.

Разберём весь процесс подробно.

Что означает «разработать приложение для Store»

Приложение для App Store, Google Play, RuStore или другого магазина — это не просто сайт, помещённый в файл.

В зависимости от проекта может разрабатываться:

полностью нативное приложение;
кроссплатформенное приложение;
веб-приложение в нативной оболочке;
PWA + мобильная оболочка;
клиент мобильного приложения к существующему backend.

Например web-first продукт может иметь общую основу:

Web application
      │
      ├── Browser
      ├── PWA
      │
      └── Native shell
             │
        ┌────┴────┐
        ▼         ▼
     Android     iOS

При этом для мобильных платформ всё равно появляются отдельные требования:

package/application ID;
версии;
иконки;
splash screen;
permissions;
подпись;
release build;
privacy settings;
platform configuration.

То есть подготовка Store-версии является отдельным этапом продукта.

Заказ начинается не с Store, а с ТЗ

До публикации ещё очень далеко.

Сначала нужно определить:

Что именно должно делать приложение?

Например:

регистрация;
авторизация;
личный кабинет;
уведомления;
работа с файлами;
платежи;
offline;
камера;
геолокация;
синхронизация;
push;

Далее фиксируются:

целевые платформы;
функционал;
дизайн;
интеграции;
backend;
права пользователей;
требования безопасности;
форматы данных;

И только после согласования объёма работ начинается разработка.

Почему ТЗ особенно важно для Store-приложения

Потому что нужно отделить два критерия.

Первый:

Приложение соответствует согласованному техническому заданию?

Второй:

Магазин приложений согласился его опубликовать?

Это разные вопросы.

Допустим по ТЗ приложение должно:

регистрировать пользователя;
создавать проекты;
работать с файлами;
отправлять push;
синхронизировать данные.

Разработчик реализовал всё перечисленное.

Тесты прошли.

Приложение работает на предусмотренных устройствах.

Но модерация Store предъявляет дополнительное требование к:

описанию продукта;
политике конфиденциальности;
модели аккаунтов;
способу оплаты;
контенту;
доступу ревьюера;
юридической информации.

Факт такого замечания сам по себе не означает, что разработанное приложение технически не соответствует ТЗ.

Это чрезвычайно важно определить ещё до начала проекта.

Кто должен владеть аккаунтом Store

В WebRuta используется принцип:

аккаунт магазина создаётся и принадлежит заказчику.

Не разработчику.

Почему?

Потому что опубликованное приложение является активом бизнеса заказчика.

Именно заказчик должен контролировать:

developer account;
приложение;
название;
страницу приложения;
статистику;
платежные данные;
договорные отношения со Store;
будущие обновления.

Это исключает зависимость от разработчика после завершения проекта.

Почему не стоит публиковать приложение из личного аккаунта подрядчика

Представим приложение принадлежит компании заказчика.

Но опубликовано из аккаунта разработчика.

Через два года заказчик хочет:

сменить подрядчика;
обновить приложение;
добавить другую команду;
изменить юридические данные.

И обнаруживает, что фактический контроль Store находится у третьей стороны.

Это плохая архитектура владения продуктом.

Поэтому правильнее:

Бизнес заказчика
      ↓
Developer account заказчика
      ↓
Приложение заказчика

Разработчик остаётся техническим исполнителем.

Это соответствует самой модели магазинов

Например Apple подача приложения в App Review выполняется через App Store Connect, причём для отправки версии нужны соответствующие роли аккаунта — Account Holder, Admin или App Manager. После выбора build именно в App Store Connect приложение отправляется на проверку.

Google Play аналогично работает через Play Console и developer account. Для новых приложений Google Play основным форматом публикации является Android App Bundle — .aab.

Поэтому выражение:

разработчик передаёт архив приложения

удобно в бытовом описании, но технически точнее говорить:

разработчик передаёт заказчику готовую релизную сборку или пакет для публикации.

Например для Google Play это обычно:

.aab

Для Apple процесс включает подготовленный iOS build, который загружается в App Store Connect соответствующими инструментами Apple.

Для других магазинов формат может отличаться.

Как WebRuta организует публикацию

Модель выглядит так:

WebRuta
↓
разрабатывает приложение
↓
тестирует
↓
готовит release build
↓
передаёт заказчику

Заказчик
↓
загружает build
в свой Store account
↓
отправляет на review

После этого решение принимает уже сам магазин.

Почему публикацию делает заказчик

Это не попытка переложить работу.

Наоборот, такой подход защищает обе стороны.

Заказчик сохраняет:

полный контроль;
собственный аккаунт;
историю публикаций;
доступ к статистике;
управление приложением.

Разработчик не становится владельцем чужого цифрового продукта.

При необходимости разработчик помогает подготовить публикацию

Например может быть подготовлено:

название приложения;
технические параметры сборки;
версии;
иконки;
screenshots;
описание необходимых permissions;
информация по функционалу;

Но непосредственно:

вход в developer account;
согласие с условиями платформы;
официальная отправка приложения на review;
юридические подтверждения;

остаются на стороне владельца продукта — заказчика.

Что происходит после первой отправки в Store

Есть несколько вариантов.

Вариант 1 — приложение принято

Release build
↓
Store Review
↓
Approved
↓
Publication

Процесс завершён.

Вариант 2 — Store присылает замечания

Например:

нужно изменить поведение;
добавить пояснение;
изменить permission flow;
исправить техническую проблему;

Заказчик получает ответ Store.

После этого передаёт замечания разработчику.

Разработчик анализирует замечание

Очень важно не выполнять текст Store механически.

Сначала нужно понять:

к чему относится замечание;
есть ли реальная техническая ошибка;
какую именно часть приложения нужно изменить;
не нарушит ли изменение другие функции.

После анализа выполняется доработка.

Затем собирается новая версия

Например:

Version 1.0
Build 12

получила замечание.

Разработчик исправляет проблему.

Готовится:

Version 1.0
Build 13

и передаётся заказчику.

Заказчик снова отправляет приложение

Схема:

Store rejection
      ↓
Заказчик получает замечание
      ↓
передаёт разработчику
      ↓
анализ
      ↓
доработка
      ↓
новая release build
      ↓
заказчик загружает
      ↓
повторный Review

Если появляются новые замечания, цикл может повториться.

Это нормальная часть публикации

Отказ первой версии не обязательно означает:

приложение плохое.

Apple официально рассматривает каждую отправляемую версию и связанные с ней материалы через App Review; если выявлены проблемы, они отражаются в коммуникации Review, после чего приложение можно исправить и отправить повторно.

В Google Play обновлённый bundle также создаётся как новая release-версия и снова проходит соответствующий процесс проверки.

Store Review — это внешняя сторона проекта

Здесь находится важное различие.

WebRuta может контролировать:

код;
тесты;
сборку;
архитектуру;
функционал;
исправление технических ошибок.

Но не может контролировать окончательное решение:

Apple;
Google;
RuStore;
другого магазина.

Магазин является независимой стороной.

Поэтому публикацию нельзя гарантировать как техническую функцию

Разработчик способен гарантировать, например:

При нажатии кнопки пользователь создаёт проект.

Потому что эта функция находится внутри приложения.

Но разработчик не управляет:

решением модератора;
изменением правил магазина;
проверкой developer account;
региональными ограничениями;
юридическими требованиями Store.

Поэтому формулировка:

Разработчик гарантирует публикацию в любом случае.

создавала бы обязательство, которое технически невозможно полностью контролировать.

Приложение и публикация — две разные услуги

Именно поэтому в WebRuta их полезно разделять.

Услуга №1 — разработка приложения

Включает:

проектирование;
разработку;
интеграции;
тестирование;
release build;
передачу результата заказчику.

Услуга №2 — сопровождение до успешной публикации

Включает работу с техническими замечаниями Store и подготовку обновлённых release-сборок.

Почему стоимость разработки оплачивается независимо от решения Store

Представим приложение полностью реализовано по ТЗ.

Оно:

запускается;
авторизует пользователя;
работает с backend;
сохраняет данные;
отправляет уведомления;
выполняет заявленные сценарии.

То есть сам разработанный продукт существует и соответствует заказу.

При этом Store может не принять его, например, из-за требований:

к конкретной категории приложения;
business model;
content policy;
аккаунту разработчика;
юридической информации;
способу предоставления услуги.

Отказ Store не уничтожает выполненную разработку.

Поэтому результат разработки оценивается по ТЗ

Основной критерий:

работает ли приложение так, как было согласовано сторонами?

Если:

функции реализованы;
критические дефекты отсутствуют;
требования ТЗ выполнены;
готовая release build передана,

разработка приложения считается выполненной.

Решение Store является отдельным результатом следующего процесса — модерации.

Это особенно важно закрепить заранее

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

Это защищает и заказчика, и разработчика от разного понимания результата.

Но это не означает, что разработчик снимает с себя ответственность

Если Store указывает:

приложение падает;
не работает авторизация;
кнопка ничего не делает;
permissions настроены неправильно;
build технически некорректен,

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

Нельзя прикрывать собственный дефект словами:

Это требования магазина.

Поэтому замечания нужно классифицировать

Условно их можно разделить на три группы.

1. Технический дефект приложения

Например:

crash;
сломанный экран;
ошибка native configuration;
неработающая функция.

Это зона разработчика.

2. Требование к публикационной версии

Например Store просит:

изменить permission flow;
добавить экран;
скорректировать отдельный сценарий;

Это можно доработать в рамках сопровождения публикации, если изменение не превращает исходное ТЗ в новый продукт.

3. Организационное или юридическое замечание

Например:

подтвердить организацию;
предоставить документы;
изменить сведения аккаунта;
подтвердить права на бренд;
заполнить возрастной рейтинг;
дать privacy information.

Такое замечание невозможно исправить изменением исходного кода.

Это зона владельца developer account и бизнеса заказчика.

Может появиться и четвёртая категория — новое требование Store меняет сам продукт

Например по ТЗ приложение разработано правильно.

Но Store требует:

Для публикации эта функция должна работать совершенно иначе.

И изменение означает уже серьёзную новую разработку.

Тогда нужно оценить:

масштаб;
срок;
влияние;

и отдельно согласовать, входит ли такая переработка в первоначальное сопровождение публикации.

Почему нельзя обещать бесконечные бесплатные переделки

Представим исходное ТЗ выполнено.

Но после нескольких reviews появляются новые требования:

переделать платежную модель;
изменить регистрацию;
добавить новую функцию;
изменить backend.

Это уже может быть не «исправлением».

Это новая разработка.

Поэтому в правилах сотрудничества полезно отделить:

исправление замечаний

от:

изменения исходного объёма продукта.

Как устроена оплата в модели WebRuta

Здесь можно сделать достаточно прозрачную схему.

Основная стоимость

Заказчик оплачивает:

разработку приложения по согласованному ТЗ.

Это основная стоимость продукта.

Она не зависит от субъективного решения Store при условии, что разработка выполнена надлежащим образом.

Дополнительная стоимость — только за успешное сопровождение публикации

Для приложений, которым требуется Store Review, можно установить отдельную:

стоимость сопровождения успешной публикации.

Эта сумма не включается автоматически в цену разработки.

Она возникает только если приложение действительно успешно прошло модерацию и было принято Store.

Например

Стоимость разработки:

500 000 ₽

Дополнительная стоимость успешного сопровождения публикации:

50 000 ₽

Сценарий А — приложение прошло модерацию

Разработка:
500 000 ₽

Публикация успешно пройдена:
+50 000 ₽

Итого:
550 000 ₽

Сценарий Б — понадобилось несколько доработок

Например:

Review #1 → замечание
↓
доработка

Review #2 → замечание
↓
доработка

Review #3 → Approved

Поскольку результат:

Публикация успешна

начисляется дополнительная сумма сопровождения публикации:

+50 000 ₽.

Сценарий В — приложение не было принято даже после нескольких доработок

Допустим:

Review #1 → rejection
Review #2 → rejection
Review #3 → rejection

Разработчик выполнил предусмотренные технические доработки.

Приложение работает по ТЗ.

Но Store по своим требованиям так и не разрешил публикацию.

Тогда:

Стоимость разработки:
500 000 ₽

Доплата за успешную публикацию:
0 ₽

Заказчик оплачивает только стоимость разработанного приложения.

Это очень важная модель расчёта

Разработчик не работает бесплатно над самим продуктом.

Заказчик, в свою очередь, не платит дополнительную сумму за результат публикации, который фактически не был достигнут.

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

Разработка выполнена
→ оплачивается.

Store publication succeeded
→ дополнительная плата начисляется.

Store publication не состоялась
→ дополнительной платы нет.

Почему такая схема справедлива

Потому что она разделяет две разные ценности.

Первая:

готовое работоспособное приложение.

Вторая:

успешно пройденная внешняя модерация.

Заказчик платит за каждую ценность только тогда, когда она фактически получена.

При этом разработчик мотивирован помогать с Store

Если публикация состоялась:

разработчик получает дополнительную оплату.

То есть сопровождение модерации имеет понятный коммерческий результат.

Но разработчик не принимает на себя невозможное обязательство:

Добиться положительного решения независимой платформы любой ценой.

В случае если приложение соответствует согласованному ТЗ и является технически работоспособным, однако публикация не была одобрена магазином вследствие его дополнительных, изменившихся или иных требований, находящихся вне согласованного функционала приложения и контроля разработчика, такой отказ сам по себе не является основанием считать разработку приложения невыполненной.

Отдельно стоит определить ответственность заказчика

Для публикации заказчик должен своевременно предоставить то, что находится на его стороне.

Например:

developer account;
достоверные данные компании;
privacy policy;
контактные данные;
возрастные сведения;
права на используемый контент;
необходимые юридические документы;
ответы Store;

Без этого разработчик может технически завершить приложение, но публикационный процесс остановится.

Если заказчик не отправляет приложение на review

Нельзя считать:

Разработчик не выполнил публикацию.

Потому что в выбранной модели отправку выполняет заказчик.

Разработчик может передать:

release build;
инструкцию;
необходимые технические данные.

После этого дальнейшее действие зависит от владельца developer account.

Если заказчик не передал замечание Store

Разработчик физически не знает, что требуется исправить.

Поэтому процесс должен выглядеть:

Store
↓
заказчик
↓
полный текст замечания
↓
WebRuta

Лучше передавать:

оригинальный текст;
screenshots;
номер review;
ссылки Store;

а не пересказ:

Они что-то попросили исправить.

После этого WebRuta формирует ответ

Например:

Замечание:
пункт X.

Причина:
...

Необходимая доработка:
...

Новая сборка:
1.0 build 14.

Так весь цикл остаётся прозрачным.

Желательно вести историю Store Review

Например:

Так через несколько месяцев легко восстановить историю продукта.

Почему нельзя каждый раз отправлять один и тот же build

После технических изменений должна существовать новая версия сборки.

В Google Play обновлённый Android App Bundle должен иметь увеличенный version code и сохранять корректный package/signing identity приложения.

Это ещё одна причина, почему release management должен находиться под контролем разработчика.

Подпись приложения — критичный актив

Заказчик должен понимать:

подписанное приложение

имеет долгосрочную идентичность.

Будущие обновления должны восприниматься Store как обновления того же приложения, а не как новый продукт.

Поэтому:

ключи;
сертификаты;
учётные записи;
идентификаторы приложения

нельзя хранить хаотично.

Кто должен владеть ключами

По возможности долгосрочные production credentials и Store ownership должны быть организованы так, чтобы заказчик не зависел от конкретного исполнителя.

Это часть нормальной передачи проекта.

Что получает заказчик после разработки

В зависимости от проекта может передаваться:

готовая release build;
исходный код;
инструкция;
техническая документация;
информация о версии;
информация о package/application ID;
Store assets;

Конкретный состав передачи фиксируется заранее.

Что означает «приложение готово»

приложение собирается;
запускается;
критические сценарии проходят;
функционал соответствует ТЗ;
production API настроен;
тестовые дефекты устранены;
готова release-сборка.

Это критерии завершения разработки.

А что означает «готово к Store Review»

Дополнительно:

release configuration;
иконка;
version;
permissions;
platform settings;
подпись;

и другие необходимые элементы.

После этого заказчик может отправлять build в свой магазин.

Что означает «публикация завершена»

Только когда соответствующая платформа приняла приложение.

Apple после submission переводит приложение через статусы review и после одобрения оно может быть выпущено в App Store в соответствии с выбранным способом публикации.

Google Play также имеет отдельные состояния приложения, обновления и элементов публикации в Play Console; после review и публикации release становится доступен пользователям.

То есть:

release build ready

и:

Store approved

— два разных milestone.

Почему это важно даже для заказчика

Потому что заказчик заранее понимает:

За что именно я плачу?

Нет ситуации, когда в конце проекта внезапно оказывается:

А публикация в Store — это ещё что-то отдельное.

Всё известно до начала разработки.

Пример полного процесса заказа

Шаг 1. Заявка

Заказчик описывает:

идею;
задачу;
платформы;
основные функции.

Шаг 2. Проработка ТЗ

Фиксируются:

Android/iOS;
экраны;
функции;
backend;
интеграции;
уведомления;
файлы;
платежи;

Шаг 3. Коммерческое предложение

Отдельно указывается:

Стоимость разработки:
X ₽

Сопровождение до успешной публикации:
Y ₽
только при успешном результате.

Шаг 4. Разработка

Architecture
↓
Development
↓
Integration
↓
Testing

Шаг 5. Приёмка приложения

Заказчик проверяет соответствие ТЗ.

Если всё согласовано:

приложение принято как разработанный продукт.

Шаг 6. Release build

WebRuta готовит финальную сборку для Store.

Шаг 7. Передача заказчику

release build
+
необходимые инструкции.

Шаг 8. Заказчик публикует

Через:

свой developer account.

Шаг 9. Store Review

Возможны:

Approved

или:

Revision required.

Шаг 10. Если есть замечание

Заказчик
↓
передаёт его WebRuta
↓
WebRuta анализирует
↓
выполняет согласованную доработку
↓
новая release build
↓
заказчик отправляет повторно

Шаг 11. Цикл повторяется

До:

Approved

либо до ситуации, когда дальнейшее требование выходит за согласованный объём работ или публикация объективно не может быть завершена в рамках текущей модели продукта.

Шаг 12. Расчёт

Если:

Approved

начисляется дополнительная стоимость успешного сопровождения публикации.

Если:

Not approved

доплата:

0 ₽.

Стоимость самой разработки остаётся оплаченной.

Что если Store меняет правила уже после публикации

Это тоже важно.

Приложение успешно опубликовано сегодня.

Через год платформа меняет требования.

И новое обновление требует дополнительной переработки.

Это уже не первоначальная публикация.

Это отдельная задача сопровождения или развития продукта.

Разработчик не может пожизненно гарантировать соответствие будущим правилам Store

Потому что они находятся вне его контроля.

То же самое касается:

новых Android/iOS;
новых SDK;
изменений permissions;
новых требований privacy;
обновления политик магазинов.

У мобильного продукта всегда существует эксплуатационный lifecycle.

Поэтому Store-приложение после запуска требует поддержки

Минимально полезно периодически проверять:

совместимость с новыми ОС;
актуальность SDK;
security updates;
Store requirements;
backend compatibility.

Это отдельная работа от первоначальной разработки.

Что важно указать в договоре или ТЗ

Статья объясняет процесс заказчику.

Но ключевые коммерческие условия лучше продублировать в формальных документах проекта.

Например:

1. Какие платформы разрабатываются.
2. Что считается выполнением ТЗ.
3. Что получает заказчик после разработки.
4. Кто владеет Store-account.
5. Кто отправляет приложение на review.
6. Как передаются замечания.
7. Какие исправления входят в сопровождение публикации.
8. Что считается новой разработкой.
9. Как рассчитывается дополнительная стоимость успешной публикации.
10. Что происходит, если Store не одобрил приложение.

Это убирает большую часть потенциальных споров ещё до начала проекта.

Формулировка о результате разработки

Можно использовать следующий смысл:

Разработка считается выполненной после реализации функционала, предусмотренного согласованным ТЗ, прохождения предусмотренных проверок и передачи заказчику работоспособной релизной версии приложения.

Формулировка о Store Review

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

Формулировка об исправлениях

При получении технических замечаний от Store заказчик передаёт разработчику полный текст замечаний. Разработчик анализирует их и выполняет предусмотренные условиями проекта технические доработки, после чего передаёт заказчику новую релизную сборку для повторной отправки.

Формулировка о неуспешной публикации

Особенно важная:

Если приложение соответствует согласованному ТЗ и является технически работоспособным, но не получило одобрение Store вследствие дополнительных, изменившихся либо иных требований соответствующей платформы, находящихся вне согласованного функционала и контроля разработчика, такой результат не означает невыполнение разработки приложения.

И формулировка об оплате публикации

Дополнительная стоимость сопровождения публикации начисляется только при успешном одобрении приложения соответствующим Store. Если после предусмотренных циклов доработки приложение не было одобрено, дополнительная стоимость за успешное сопровождение публикации не начисляется. Заказчик оплачивает выполненную разработку приложения в соответствии с согласованным ТЗ.

Это одна из самых прозрачных моделей для обеих сторон.

Почему здесь нет конфликта интересов

Разработчик заинтересован:

довести приложение до Store.

Потому что успешная публикация оплачивается отдельно.

Но одновременно заказчик защищён:

нет публикации
→ нет дополнительной платы.

А разработчик защищён от ситуации:

Store не одобрил
→ значит несколько месяцев разработки
якобы ничего не стоят.

Получается сбалансированная схема.

Важное исключение: если публикация не прошла из-за дефекта самого приложения

Разработчик не должен ссылаться на независимость Store, если:

ТЗ не выполнено;
release падает;
функция не работает;
допущен технический дефект.

Такая проблема относится непосредственно к качеству разработки и должна устраняться как дефект.

Именно поэтому нужна объективная приёмка

Лучше иметь:

acceptance checklist.

Например:

Теперь качество разработанного приложения можно оценивать независимо от внешнего Review.

Store Review становится отдельным этапом

Это и есть здоровая модель:

Разработка
      ↓
Техническая приёмка
      ↓
Готовое приложение
      ↓
Store Review
      ↓
Публикационное сопровождение

Не:

Store не принял
↓
значит приложения как будто нет.

Почему такой порядок особенно важен для бизнеса

Заказчик может получить работающее приложение, которое:

можно тестировать;
показывать;
использовать внутри организации;
распространять предусмотренным способом;
дорабатывать.

Решение одного канала распространения не делает созданный программный продукт несуществующим.

Но Store всё равно нужно учитывать ещё при проектировании

Из всего вышесказанного не следует:

Сначала напишем что угодно, а потом будем разбираться с магазином.

Наоборот.

Официальные требования платформ полезно изучать заранее.

Apple прямо рекомендует знакомиться с App Review Guidelines ещё во время проектирования и разработки, чтобы принимать подходящие архитектурные решения до отправки приложения.

Для Google Play также существует отдельный процесс настройки приложения, контента, store listing, тестирования и подготовки release до публичного запуска.

Чем раньше Store-требования учтены, тем меньше ненужных циклов после разработки.

Но полностью предсказать Review невозможно

Потому что существуют:

изменения политик;
особенности конкретного приложения;
новые требования;
ручная интерпретация отдельных сценариев;

Поэтому нужно одновременно:

проектировать с учётом Store

и:

не превращать решение Store
в критерий существования результата разработки.

Практический чек-лист заказчика

Перед началом разработки приложения для Store стоит заранее понимать:

• на каких платформах должно работать приложение;
• кто является владельцем developer account;
• кто оплачивает аккаунты Store;
• кто предоставляет юридическую и privacy-информацию;
• что конкретно входит в ТЗ;
• что считается готовой release build;
• кто отправляет приложение на review;
• как передаются замечания Store;
• сколько и какие доработки входят в публикационное сопровождение;
• что будет считаться новой разработкой;
• как рассчитывается плата за успешную публикацию;
• что происходит, если Store не принял приложение;
• как будут переданы исходники, ключи и документация;
• кто отвечает за дальнейшие обновления.

Чем раньше эти вопросы закрыты, тем предсказуемее весь проект.

Как этот процесс выглядит в WebRuta

Если свести всё к одной схеме:

Заявка
  ↓
ТЗ
  ↓
Оценка
  ↓
Разработка
  ↓
Тестирование
  ↓
Техническая приёмка
  ↓
Release build
  ↓
Передача заказчику
  ↓
Заказчик отправляет в Store
  ↓
Review
  │
  ├── Approved
  │      ↓
  │   Публикация
  │      ↓
  │   Доплата за успешное
  │   сопровождение
  │
  └── Remarks
         ↓
      Заказчик передаёт
      замечания
         ↓
      WebRuta дорабатывает
         ↓
      Новая release build
         ↓
      Повторная отправка

Если после предусмотренного цикла:

приложение не одобрено,

но:

ТЗ выполнено;
приложение работоспособно;
дефекты разработки отсутствуют,

то:

разработка оплачивается;
доплата за успешную публикацию
не начисляется.

Это заранее известное правило.

Не спор после завершения проекта.

Вместо вывода

Разработка приложения для Store состоит из двух больших областей.

Первая находится под контролем разработчика:

архитектура;
код;
интеграции;
тестирование;
release build.

Вторая зависит от независимой платформы:

Store Review;
политики;
аккаунт;
модерация;
финальное решение.

Профессиональная работа начинается с того, что эти области не смешиваются.

Разработчик отвечает за создание приложения согласно ТЗ.

Заказчик владеет developer account и самостоятельно отправляет предоставленную релизную сборку в Store.

Если магазин присылает замечания, заказчик передаёт их разработчику.

Разработчик анализирует требования, выполняет предусмотренные технические доработки и передаёт новую сборку.

Цикл повторяется:

Review
↓
Remark
↓
Fix
↓
New build
↓
Review

до успешного решения либо до окончания предусмотренного процесса сопровождения.

При этом сам факт отказа Store не должен автоматически означать, что разработка не выполнена.

Если созданный продукт:

соответствует ТЗ;
технически работает;
прошёл согласованную приёмку;
передан заказчику,

результат разработки существует независимо от решения внешней платформы.

Поэтому и расчёт разделяется:

Разработка приложения
→ оплачивается как выполненная работа.

Успешная публикация
→ отдельная стоимость,
только если Store действительно одобрил приложение.

Публикация не состоялась
→ дополнительная плата за неё = 0.

Такая модель делает отношения прозрачными.

Заказчик понимает, за что он платит.

Разработчик понимает границы своей ответственности.

А решение независимого магазина приложений перестаёт быть причиной спора о том, существует ли сам разработанный продукт.

Именно так процесс разработки приложения для Store превращается из неопределённого обещания:

«сделать и как-нибудь опубликовать»

в понятную профессиональную процедуру:

разработать → проверить → передать → пройти модерацию → отработать замечания → опубликовать.