--- name: "cp-app" description: "Помогает решить, нужно ли мобильное приложение вообще, и если нужно — спланировать минимальную версию, описать её требованиями, выбрать стек под задачу и команду, спланировать выпуск, обновления и продвижение карточки. Начинает с честной развилки «мобильный сайт или PWA против нативного приложения»: приложение ради присутствия в магазине окупается редко. По магазинам приложений скилл принципиально не берёт условия из памяти и требует проверки на дату по каждому — доступность публикации для российских разработчиков, требования к раскрытию данных, комиссии, способы оплаты и сроки модерации меняются, и устаревшие цифры здесь дороже отсутствия цифр. Сайт и лендинг ведёт cp-web, бота как альтернативу приложению — cp-bot. Use when the user asks whether to build a mobile app, how to plan an MVP, which stack to choose, or how to publish and promote an app. Триггеры — «мобильное приложение», «нужно ли приложение», «PWA или нативка», «выложить в магазин приложений», «RuStore», «ASO», «карточка приложения», «скриншоты для магазина», «обновление приложения», «сколько стоит приложение»." --- Перед применением прочитай [правила интеграции «Блог с нуля»](../../context/10-blog-runtime.md). Они задают единый запуск, текущий проект и производственные ограничения; не начинай второй независимый бриф. # cp-app · Мобильное приложение Приложение — самый дорогой канал из всех, что есть у контентного проекта, и единственный, где пользователя надо сначала уговорить установить. Поэтому скилл начинает не с «как сделать», а с «нужно ли». Если после развилки ответ «нужно» — дальше идёт нормальная продуктовая работа: минимальная версия, требования, стек, выпуск, обновления, карточка. ## Когда не этот скилл - Нужен **сайт, лендинг, PWA, хостинг, скорость** → `cp-web`. Сюда — только если решение про приложение уже обосновано. - Нужен **бот в мессенджере** как замена приложению → `cp-bot`. Для большинства задач «личный кабинет и уведомления» это дешевле и быстрее. - Нужны **тексты продвижения, посты и запуск** вокруг приложения → обычные контентные скиллы через `content-producer`. - Нужен **правовой вердикт** по сбору данных и согласиям → `cp-compliance`. ## Контекст Читай из `context/`: `03-legal-ru.md` §7 (персональные данные, локализация), §8 (оплата и чеки), §9 (права на контент и шрифты); `09-tech-ru.md` §5 (хостинг и локализация), §8 (приём платежей); `07-evidence.md` (почему здесь нельзя цифры из памяти). Профиль бренда — `brands//`: `offer.md` (что продаётся и как — от этого зависит модель монетизации), `audience.md` (кто и на чём сидит), `assets.md` (что уже есть: сайт, бот, база), `rules.md` (границы). Не нашлось — скажи одной строкой и работай по врезке ниже, факты спрашивай, не выдумывай. --- ## Врезка констант ### Главное ограничение скилла > **Условия магазинов приложений в этом скилле не приводятся и из памяти не берутся.** > > Доступность публикации для российских разработчиков, требования к аккаунту и к раскрытию сбора данных, комиссии, доступные способы оплаты, правила встроенных покупок и сроки модерации **менялись многократно и продолжают меняться**. Любая цифра или условие, названные по памяти, с высокой вероятностью устарели — а на них человек будет строить бюджет и сроки. > > Правило: **по каждому магазину — RuStore, Google Play, App Store, магазины производителей устройств — условия проверяются на текущую дату в его официальной документации для разработчиков.** До проверки числа не называются вообще. Так и говори пользователю прямо: «Условия по магазинам я не назову по памяти, их надо посмотреть на дату — вот список вопросов, на которые надо получить ответ». Это не отговорка, это единственный честный режим работы с этой темой. ### Что можно утверждать без проверки - Приложение требует **постоянной поддержки**: обновления ОС и требований магазинов ломают работающие сборки без участия разработчика. - Установка — **дополнительный барьер**, которого нет у сайта, бота и мессенджера. - Публикация — **не разовое действие**, а процесс: проверка магазином, возможные отказы, повторная подача. - Приложение, собирающее персональные данные граждан РФ, подчиняется тем же требованиям 152-ФЗ, что и сайт: уведомление РКН, политика, раздельные согласия, база на территории РФ. ### Правило порядка величин Стоимость и сроки разработки называются только на основании реальных смет, полученных от исполнителей под конкретные требования. «Приложение стоит примерно столько» без требований — выдуманная цифра, а не оценка. --- ## Вход Одним блоком. 1. Какую задачу пользователя решает приложение и чем она не решается сайтом или ботом. 2. Как эту задачу закрывают сейчас — и что конкретно в этом плохо. 3. Кто аудитория: iOS, Android, соотношение. Откуда данные о соотношении (счётчик сайта, а не ощущение). 4. Как приложение зарабатывает или экономит: продажи, подписка, удержание, снижение нагрузки на поддержку. 5. Кто будет поддерживать после запуска и на какие деньги. Если ответа нет — это стоп-сигнал. 6. Что уже есть: сайт, бот, база пользователей, аккаунты разработчика в магазинах. 7. Срок и бюджет — порядок величин. --- ## Развилка · нужно ли приложение Отвечать по признакам, а не по желанию «быть в сторах». | Признак | Хватит сайта / PWA / бота | Нужно нативное приложение | |---|---|---| | Сценарий использования разовый или редкий | да | — | | Основной вход — из поиска и соцсетей | да, приложение обрубит этот трафик | — | | Нужны только контент, каталог, заявка, оплата | да | — | | Нужны уведомления и личный кабинет | часто хватает бота в мессенджере → `cp-bot` | — | | **Ежедневный или еженедельный повторяющийся сценарий** | — | да | | **Работа без сети или с плохой сетью** | — | да | | **Плотная работа с железом устройства**: камера в реальном времени, датчики, фоновая геолокация, шагомер | — | да | | **Фоновая работа и надёжные push-уведомления** | ограничено, возможности PWA различаются по платформам | да | | **Продукт сам по себе является приложением** | — | да | | Есть кому платить за поддержку годами | — | обязательное условие | **Про PWA честно.** Возможности прогрессивного веб-приложения — установка на домашний экран, работа офлайн, уведомления — **различаются по платформам и версиям ОС и меняются**. Конкретный набор проверяется по документации платформы на дату, а не берётся из статьи двухлетней давности. PWA — рабочий промежуточный шаг: дешевле, обновляется мгновенно, не зависит от модерации; но часть возможностей устройства недоступна. **Порядок проверки гипотезы, если решение неочевидно:** сначала мобильный сайт или PWA → замерить, сколько людей возвращается и как часто → если частота реально высокая и упирается в ограничения браузера, тогда приложение. Приложение как первый шаг — почти всегда преждевременно. --- ## Процесс ### 1. Сформулируй одну задачу Одно предложение: «Приложение нужно, чтобы <кто> мог <что делать> <как часто>, чего он не может <в текущем канале> из-за <ограничение>». Не сходится — вернись к развилке. ### 2. Собери минимальную версию Минимальная версия — это **один завершённый сценарий целиком**, а не «половина функций каждой». Правило отбора: убираешь пункт — сценарий рвётся? Оставляешь. Не рвётся? В следующий выпуск. Типовой состав первой версии: вход, один основной сценарий, экран с результатом, минимальные настройки, обратная связь. Всё остальное — список «потом», записанный явно, чтобы не всплывал в разработке. ### 3. Опиши требованиями, а не пожеланиями Формулировка каждого пункта: **роль → действие → результат → проверяемое условие**. ``` Как <роль>, я <делаю действие>, чтобы <результат>. Готово, когда: <проверяемое условие 1>; <условие 2>; <условие 3>. ``` Плохо: «удобная авторизация», «быстро работает», «красивые уведомления». Проверить нельзя — принять нельзя — спор с подрядчиком гарантирован. Отдельными разделами: какие данные собираются и зачем; что происходит без сети; что происходит при ошибке; какие экраны обязательны для магазина (политика, удаление аккаунта, обратная связь — **состав требований проверять на дату**). ### 4. Выбери стек под команду, а не под моду | Ситуация | Направление | |---|---| | Одна платформа, глубокая работа с железом, высокие требования к производительности | нативная разработка под эту платформу | | Две платформы, ограниченный бюджет, обычный набор функций | кроссплатформенное решение | | Основная ценность — контент, который и так есть на сайте | сначала PWA, приложение позже | | В команде уже есть компетенция | **решающий фактор**: стек, который некому поддерживать, — худший выбор при любых характеристиках | Вопрос «а на чём сейчас модно» не задаётся. Задаётся «кто это будет чинить через год и сколько таких людей на рынке». ### 5. Спланируй выпуск Порядок работ, а не сроки: сборка → внутреннее тестирование на реальных устройствах → подготовка карточки → подача в магазин → реакция на замечания → публикация. **Сроки модерации закладывать по данным конкретного магазина на дату подачи.** Отказ на первой подаче — рабочий сценарий, а не катастрофа; закладывай запас на повторную подачу. Дату публичного анонса не назначай раньше, чем приложение реально опубликовано. ### 6. Спланируй обновления Обновление приложения — не как обновление сайта: пользователь может не обновиться никогда. Отсюда: - старые версии должны продолжать работать или **корректно сообщать**, что пора обновиться; - изменения на стороне сервера не должны ломать установленные версии; - поддержка ОС и требований магазинов пересматривается регулярно, иначе сборка перестанет собираться; - отзывы и падения читаются как источник задач, а не как фон. --- ## Продвижение карточки Карточка — это единственная посадочная страница, которую владелец приложения полностью контролирует в магазине. | Элемент | Задача | Что учесть | |---|---|---| | **Название** | сказать, что это, словами пользователя | лимиты длины и правила у каждого магазина свои — **проверять на дату** | | **Иконка** | быть узнаваемой в мелком размере | смотреть на реальном экране среди других иконок, не в макете | | **Первые скриншоты** | показать сценарий и результат за один взгляд | подпись на каждом кадре — не «экран приложения», а что человек получит | | **Первые строки описания** | ответить, кому и зачем | остальное описание читают единицы | | **Категория и ключевые слова** | попасть в поиск магазина | набор полей и их правила различаются по магазинам | | **Отзывы и оценки** | снять сомнение | просить отзыв после успешного сценария, а не при первом запуске | **Что влияет на конверсию в установку — уровень C.** Публичных методологически раскрытых исследований по российским магазинам найти не удалось, а алгоритмы поиска внутри магазинов не публикуются. Значит: любые «иконка даёт +N% установок» — гипотезы. Проверяются собственным A/B, если магазин даёт такой инструмент, или последовательной заменой одного элемента с фиксацией результата. **Связь с контентом.** Приложение не продвигается «в магазине» — оно продвигается там, где живёт аудитория, а магазин закрывает последний шаг. Практическая связка: контент показывает задачу и результат → пост или ролик ведёт на страницу приложения → карточка повторяет то же обещание теми же словами. Расхождение между обещанием в контенте и текстом карточки — главная причина отвала на последнем шаге. Тексты и запуск — через `content-producer`, посадочная страница под приложение — `cp-landing`. --- ## Правовое Информация на 04.08.2026, не юридическая консультация; применимость определяет юрист. Разбор конкретной ситуации — `cp-compliance`. **Приложение, собирающее данные, — оператор персональных данных со всеми обязанностями.** | Обязанность | Как выглядит в приложении | |---|---| | **Уведомление в РКН до начала обработки** (ст. 22 152-ФЗ) | подаётся до публикации, а не после первых установок | | **Политика обработки** (ч. 2 ст. 18.1) | доступна из приложения и по постоянной ссылке; ссылка указывается и в карточке магазина | | **Согласие** (ст. 9) | конкретное и раздельное: обработка — отдельно, рекламные уведомления — отдельно. Согласие «нажатием кнопки Продолжить» без явного выбора — риск | | **Локализация базы в РФ** (ч. 5 ст. 18) | серверная часть и база — на территории РФ. Зарубежный бэкенд «потому что удобнее» — нарушение | | **Трансграничная передача** (ст. 12) | отдельное уведомление до начала передачи. Сторонние SDK аналитики и рекламы, отправляющие данные за рубеж, — часть цепочки обработки, а не «просто библиотека» | | **Утечка** (ч. 3.1 ст. 21) | уведомления в РКН: **24 часа** и **72 часа**. Отвечает оператор, даже если инцидент у подрядчика | | **Раскрытие сбора данных для магазина** | у магазинов свои формы раскрытия того, какие данные собираются и куда передаются. **Состав и формат — по документации магазина на дату.** Заполненное «на глаз» раскрытие — причина отказа и претензий | **Оплата.** Правила встроенных покупок, разрешённые способы оплаты и комиссии различаются по магазинам и меняются — **проверять на дату**. Налоговая сторона не зависит от магазина: доход остаётся доходом, чек нужен (самозанятый — в приложении ФНС, ИП и ООО — касса по 54-ФЗ), приём на личную карту недопустим. Подробно — `03-legal-ru.md` §8 и `cp-compliance`. **Контент внутри приложения.** Шрифты — по лицензии типа app, изображения и музыка — по лицензии. Правила те же, что для сайта, лицензия другая: web-лицензия шрифта приложение не покрывает. --- ## Что проверить на дату · список вопросов Отдаётся пользователю как задание, а не заполняется по памяти. По **каждому** магазину, где планируется публикация: 1. Доступна ли регистрация аккаунта разработчика для лица из РФ и в каком статусе (физлицо, самозанятый, ИП, юрлицо). 2. Стоимость аккаунта разработчика и способ её оплаты. 3. Доступные способы приёма оплаты от пользователей и правила встроенных покупок. 4. Комиссия магазина и от чего она зависит. 5. Требования к раскрытию собираемых данных: форма, состав, где заполняется. 6. Обязательные элементы приложения и карточки (политика, удаление аккаунта, обратная связь, возрастной рейтинг). 7. Требования к материалам карточки: размеры и число скриншотов, лимиты текстов. 8. Порядок и ориентировочные сроки проверки, типовые причины отказа. 9. Правила обновлений и что происходит со старыми версиями. 10. Ограничения по тематике и по контенту. Источник ответа — **официальная документация магазина для разработчиков**, а не статья и не форум. Дата проверки записывается рядом с ответом. --- ## Выход ``` РЕШЕНИЕ приложение <нужно / не нужно> — потому что <признак из развилки> если не нужно: <что вместо: PWA / мобильный сайт / бот> → ЗАДАЧА «Приложение нужно, чтобы <кто> мог <что> <как часто>, чего он не может <где> из-за <ограничение>» МИНИМАЛЬНАЯ ВЕРСИЯ сценарий целиком: <шаги> внутри: <перечень> сознательно НЕ входит: <перечень> ← явный список, чтобы не всплыло в разработке ТРЕБОВАНИЯ <роль → действие → результат → проверяемые условия готовности> СТЕК <направление> — потому что <задача + кто поддерживает> ВЫПУСК порядок работ, запас на повторную подачу, анонс — только после публикации КАРТОЧКА название / иконка / скриншоты с подписями / первые строки описания ПРАВОВОЕ <уведомление РКН, политика, согласия, локализация, SDK за рубежом, раскрытие данных для магазина> ПРОВЕРИТЬ НА ДАТУ ← обязательный блок <10 вопросов по каждому магазину, с местом под дату проверки> ``` ## Чек-лист перед выдачей - Развилка «нужно ли приложение» пройдена по признакам, а не по желанию. - Названо, кто поддерживает приложение после запуска и на какие деньги. - Ни одной цифры по комиссиям, срокам модерации и требованиям магазинов не названо из памяти. - Блок «Проверить на дату» есть и заполнен вопросами, а не ответами. - Про PWA сказано честно: возможности различаются по платформам и проверяются на дату. - Минимальная версия — один завершённый сценарий, список «не входит» записан явно. - Требования сформулированы с проверяемыми условиями готовности. - Стек выбран под команду и поддержку, а не под моду. - Правовой блок: локализация, согласия, сторонние SDK, раскрытие данных для магазина. - Сроки и стоимость разработки не названы без реальных смет под требования. ## Красные линии 1. **Не называть комиссии, сроки модерации, требования и правила магазинов из памяти.** Только после проверки на дату по официальной документации. 2. **Не советовать приложение по умолчанию.** Для большинства контентных проектов это дороже и хуже сайта или бота. 3. **Не обещать сроков публикации и результата в магазине.** Модерация не под контролем ни автора, ни разработчика. 4. **Не выдумывать стоимость разработки** без требований и реальных смет. 5. **Не размещать бэкенд с персональными данными граждан РФ за пределами РФ.** 6. **Не запускать сбор данных** без уведомления РКН, политики и раздельных согласий. 7. **Не заполнять раскрытие собираемых данных «на глаз».** Это и отказ магазина, и правовой риск. 8. **Не давать инструкций по обходу правил магазинов и блокировок.** 9. **Не выдавать ASO-приёмы за измеренные нормы.** Алгоритмы магазинов не публикуются — это гипотезы.