Или наш опыт разработки мобильного приложения для "Взрослых"

План статьи

  1. Репрезент проекта

  2. Стек технологий

    1. Клиентская часть

    2. Серверная часть

    3. Контент и SMM технологии

    4. Трекинг задач

  3. Первоначальные задачи

    1. Разработка первого макета

    2. Наброски бизнес логики

    3. Административная панель

  4. Аккаунт разработчика

    1. AppStore

    2. GooglePlay

  5. Процесс разработки

    1. Разработка и деплоинг с expo-cli (eas, expo-dev)

    2. Покупки внутри приложения (RevenueCat)

  6. Улучшение дизайна

  7. Маркетинговая часть

    1. Релиз в Play Market (Блокировка в Play Market)

    2. Релиз в AppStore

  8. Результаты спустя время


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

Спустя полгода мы обнаружили себя в середине лета с затянувшимся проектом, переписанной архитектурой и осознанием, что разработать игру это только 20% пути. Остальные 80% это война с гайдлайнами сторов, настройка подписок и попытки пролезть в Play Market там, где нас не ждут.

В этой статье я честно расскажу:

  • Как мы собрали стек на React Native + Expo + .NET.

  • Почему Trello победил Notion.

  • Как мы пытались «схитрить» с контентом во время модерации и к чему это привело.

  • Сколько стоит опыт в $125 (спойлер: аккаунты разработчиков не вечны).


1. Репрезент проекта

Игра для пар 18+, где каждый игрок обязан выполнять выпадающие действия.

Основная идея игры очень проста: есть два экрана. На первом пользователи выбирают для себя пакеты. На втором экране эти действия случайным образом выпадают пользователям, и по мере игры уровень увеличивается вплоть до финала.

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

2. Стек технологий

2.1 Клиентская часть

Самое первое важно решить на чем будет разработана клиентская часть. Нужно было универсальное решение для IOS и Android, которое было бы в меру производительно для такого характера игры. В данной статье я приведу два способа разработки под IOS и Android.

Это такие технологии, как Flutter и React Native.

Flutter использует язык программирования Dart и компилируется в машинный код. Устройства понимают этот код, что обеспечивает быструю работу и высокую производительность.

React Native является инструментом для создания приложений, написанных на ReactJS, который предоставляет возможность взаимодействовать через JavaScript код с различными платформами: Android, iOS и т.

Выбор их этих двух, без сомнения имеющих право на жизнь технологий, был отдан React Native, так как уже имелся большой опыт в разработки на React и до этого было написано пару простых приложений на React Native.

Но помимо разработки мобильного приложения, нужна была административная панель, которая была бы написана соответственно также на React-е и некоторые куски кода можно было бы переиспользовать и в React Native, но об этом позже.

Конечно одним React Native сыт не будешь и нужны другие вспомогательные инструменты и таким инструментом является Expo. Для глобального стора был использовав Redux ToolKit

Expo — это набор инструментов, с помощью которого вы можете написать приложение React Native в кратчайшие сроки. Он включает в себя готовые инструменты, такие как конфигурации Android Studio / XCode, управление сертификатами в Apple & Google и push-уведомления, и это лишь некоторые из них.

2.2 Серверная часть

2.3 Контент и SMM технологии

2.4 Трекинг задач

По началу мы создали беседу в телеграмме, но как оказалось этого было не достаточно, сперва мы планировали все задачи разбивать в ноушене, но он слишком громоздкий для подобных задач. В нем трудно было ориентироваться. Нам нужен был такой сложный инструментарий который предствляет Jira или GitHub Projects, и тогда мы решили воспользоваться Trello, простой dashboard, который отлично подходит для стартапов подобного вида.

Финальный стек проекта

  • Typescript

  • React / React Native / Next JS

  • Expo

  • Redux ToolKit

  • .Net

  • Postgere / Redis / Swagger

  • Figma

  • Trello

  • ...

3. Первоначальные задачи

Существует множество способов начать разработку. Например у вас есть заранее прописанная документация. Еще один вариант разработать макет интерфейса и затем к нему уже прикручивать новые фичи.

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

3.1 Разработка первого макета

Главное меню 23.02.2023
Главное меню 23.02.2023

Репа с проектом была инициализирована 16 февраля 2023 года.

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

Главное меню 23.02.2023
Главное меню 23.02.2023

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

Игровой экран
Игровой экран

Устройство главного экрана состоит из

Текущий прогресс игры

Текущее действие игрока

Две кнопки для выбора друго действия и передачи очереди дальше.

3.2 Наброски бизнес логики

Первое и самое важное приложение должно легко и на лету обновлять свои данные через админ панельку через веб‑сайт. В нашем случае нужно обновлять пакеты их действия и предметы. Без интернета оно должно работать, с последними скаченными данными. Сперва мы планировали каждый раз скачивать при присутствие интернета, а данные хранить в локальном хранилище (AsyncStorage в React Native).

Изначально мы хотели просто запрашивать актуальный контент (пакеты действий) при каждом запуске и хранить его в AsyncStorage. Но когда база данных разрослась, «холодный старт» приложения стал занимать 3–4 секунды — недопустимо для простой игры.

Решение: Мы внедрили систему версионности контента (Content Versioning). При запуске приложение отправляет на бэкенд только ID текущей версии базы. Если на сервере есть билд свежее — клиент скачивает дельту обновлений. Если нет мгновенно запускается на локальных данных. Это снизило нагрузку на сервер и дало пользователям тот самый "instant feel".

примерный алгоритм работы при запуске приложения
примерный алгоритм работы при запуске приложения

Сверху вы можете видеть, как приложение принимает новый билд. Систему билдов и её работы можно будет прочитать в разделе бэкенд.

В любом случае данный подход избавил нас от требования каждый раз делать под запрос на 3-4 секунды и ослабить нагрузку на сервер и базу данных.

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

3.3 Административная панель

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

Технологии:

  • React Query

  • MUI

CRUD операции над действиями
CRUD операции над действиями
Страница настроек (с билдами)
Страница настроек (с билдами)

Конечно она выглядела совершенно по другому в первых версиях, но со временем приняла форму, которой обладает сейчас частично совпадая с дизайном приложения, ведь куда приятнее пользоваться красивой админкой банально желания зайти и что‑то поменять будет больше. К тому же я до сих пор занимаюсь улучшением кодовой базой (изначальная архитектура и в целом качество кода было посредственное) для дальнейших проектов, которые могут быть завязанные на этой админке.

4. Аккаунт разработчика

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

4.1 GooglePlay, 4.2 AppStore

Для того, чтобы у вас была лицензия для разработки приложений под Google Play Market вам необходимо единоразово купить аккаунт разработчика за 25$. За такую скромную сумму у вас появляется возможность стать богаче тех кто качает нефть или остаться ни с чем (в нашем случае мы окупили эти 25$ и на этом всё). Помимо платежа вам необходимо подтвердить свою личность. Это нужно чтобы в дальнейшем отслеживать другие созданные вашей персоной аккаунты. Ведь если вы были заблокированные однажды то это ударит по вашей репутации на долго.

В AppStore ситуация обстоит куда с большим порогом вхождения в размере 100$ ежегодного платежа. Такая стоимость даёт небольшие преимущества в меньшем количестве конкурентов путем отсеивания менее мотивированных разработчиков.

Конечно приобретение лицензии далеко не всё что вам необходимо в дальнейшем я расскажу о том, какие правила вам не стоит обманывать Google, чтобы ваше приложение не заблокировали в Play Market.

5. Процесс разработки

Так как разработка на React Native не сильно отличается от React и вполне легко может быть применима любая современная архитектурная парадигма, а в новых версиях Expo навигацию можно осуществлять так же как и в Next.js что дает нам SEO. Да и в целом эта технология разработки 3 в 1 сейчас активно развивается и например используется в веб версии X (Twitter).

5.1 Разработка и деплоинг с expo-cli (eas, expo-dev)

В данном разделе я опишу некоторые особенности разработки на expo и взаимодействия с EAS. Так как у меня как и у многих начинающих не всегда есть хорошее представление зачем некоторые инструменты в Expo нужны и пользуются лишь на интуитивном уровне.

Если эту статью читают люди не имеющие опыта разработки на Expo или React Native, то Expo это некая оболочка над RN, которая может сильно ускорить и упростить вашу разработку избавив вас от лишних проблем. Еще пару лет назад Expo считался не самым лучшим выбором для продакшен про��ктов, так как в нем не было нативных модулей (что это такое будет нижу). Но спустя годы доработок Expo практически вплотную подобрался к функционалу RN, а те что необходимы можно легко сделать через создание Dev Build‑а.

Тут мы подходим к тому как же реализуются билды на Expo, для этого существует файл eas.json. Снизу вы можете видеть урезанный пример файла, с нашего проекта. Для его запуска существует команда eas build --profile production --platform ios

{
  "cli": {
    "version": ">= 0.38.2",
    "appVersionSource": "local"
  },
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal",
      "env": {
        "REVENUE_CAT_API_APPLE": "KEY",
        "REVENUE_CAT_API_GOOGLE": "KEY"
      }
    },
    "simulator-development": {
      "env": {
        "REVENUE_CAT_API_APPLE": "KEY",
        "REVENUE_CAT_API_GOOGLE": "KEY"
      },
      "ios": {
        "simulator": true,
        "developmentClient": true,
        "distribution": "internal"
      }
    },
    "apk-build": {
      "env": {
        "REVENUE_CAT_API_APPLE": "KEY",
        "REVENUE_CAT_API_GOOGLE": "KEY"
      },
      "android": {
        "buildType": "apk"
      }
    },
    "production": {
      "env": {
        "REVENUE_CAT_API_APPLE": "KEY",
        "REVENUE_CAT_API_GOOGLE": "KEY"
      }
    }
  }
}

где флаг --profile production может быть заменен на любой из объекта build в конфиге eas и соответсвенно ‑platform на ios/android/eas

После этого билд будет отправлен на сборку в облако Expo. Приятно отметить, что интерфейс облака Expo дружелюбен и поможет вам ориентироваться в многочисленных сборках и различных проектах. Однако, в бесплатной версии количество билдов в месяц ограничено, а на Android часто приходится ждать очереди до нескольких часов. Сами билды сохраняются в течение 30 дн��й с возможностью их скачать. Для тех, кому не обязательно фиксировать хронологию билдов, существует флаг ‑local, позволяющий собрать проект локально на вашей машине. При наличии хорошего оборудования это будет быстрее, чем облачная сборка.

это лишь часть из различных окон данного сайта
это лишь часть из различных окон данного сайта
так же недавно добавили возможность CD (на данный момент не разбирался)
так же недавно добавили возможность CD (на данный момент не разбирался)

Что нам дает каждый из видов билда?

  • production — Билд как ясно из названия пригодный для продакшена, .ipa и .aab файлы для AppStore и PlayMarket соответственно.

  • apk‑build — после блокировки в AppStore, мы всё еще хотели поддерживать работоспособность версии на Android и для этого нам нужен был APK файл для тестирования.

  • development — билд созданный в приложении expo, к которому можно подключиться в режиме dev и вести разработку приложения с нативными модулями предварительно установленными в ваш проект (иначе вы не сможете разрабатывать и будете получать ошибку об отсутствии модуля в нативных компонентах)

  • simulator‑development — такой же билд как и предыдущий, но если вы разрабатываете на Mac OS, то вам понадобиться билд для симулятора.

5.1 Покупки внутри приложения (RevenueCat)

RevenueCat — это мобильный SDK и API для управления подписками в приложениях, которая берет на себя ответственность за поддержку сложных систем подписок в App Store и Google Play Store и помогаем нам сосредоточиться на ведении своего бизнеса.

Существует хорошая документация, а так же поддержка огромного количества технологий. В разработке на React Native Expo эта библиотека действительно упросит жизнь, даже в официальной документации Expo в разделе о внутренних покупках лежит ссылка на этот гайд (https://www.revenuecat.com/blog/engineering/expo‑in‑app‑purchase‑tutorial). В данном гайде вас попросят создать dev build, как это сделать уже было сказано выше, так как библиотека react-native-purchases использует нативные модули.

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

Во первых хотелось бы с самого начала объяснить, что такое мобильная покупка в данных магазинах. Предположим мы уже создали пару уникальных айди в админке нашего магазина. Таким образом в самом API RevenueCat мы будем иметь массив строк из названия наших айди.

["purchase_name_date_id1", "purchase_name_date_id1", "purchase_name_date_id1" ]

Помимо них у нас так же будет объект с полями: название, описание и цена (с локалью выставленной в магазине).

Теперь мы можем отрисовать наши предложения для покупки, но как узнать, что пользователь уже приобрёл продукт? В объекте пользователя появится массив с уже совершёнными покупками. Всё, что нам остаётся сделать, — это проверить, есть ли продукт в этом массиве, и присылать только те предложения, которые ещё не куплены. Проверка производится как на стороне бэкенда, так и на фронтенде. Например, если RevenueCat сообщает, что у пользователя есть покупка, а в текущих загруженных данных она отсутствует, мы выполняем принудительный запрос на бэкенд и получаем подтверждённые RevenueCat покупки с бэкенда. Примерно так, в общих чертах, работает наше приложение.

Purchases.syncPurchases();

Функция описанная выше должна использоваться после конфигурации и до получения данных с

Purchases.getOfferings();

Таким образом для операционной системы Android мы сможем восстановить все покупки с акаунта play market. Но для IOS такой подход не сработает и чтобы обработать эту ситуации рекомендуется даже самими Apple внедрять кнопку «Restore Purchases». Которая будет вызывать метод Purchases.restorePurchases();
После чего анонимный токен должен будет синхронизироваться.

Насчет создания уникального айди покупки через AppStore/PlayMarket всё просто и без проблем создается через админку.

6. Улучшение дизайна

Безусловно, каким бы замечательным нам ни казалось наше приложение, всегда необходим взгляд со стороны. Поэтому мы обратились к UI/UX‑дизайнеру, который работал над многими проектами. Он разработал интересный и свежий дизайн, который мы интегрировали в основное приложение.

Макеты дизайна
Макеты дизайна
Как выглядит финальный результат (начало 2024 года)
Как выглядит финальный результат (начало 2024 года)
Дизайн приложения (с конца 2024 года по наше время 2026 год январь)
Дизайн приложения (с конца 2024 года по наше время 2026 год январь)

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

7. Маркетинговая часть

7.1 Релиз в Play Market

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

Первы дни релиза в плей маркет
Первы дни релиза в плей маркет

Спустя несколько обновлений и исправлений мы начали получать уведомления о том, что наше приложение не соответствует политике Google Play Маркета. Сначала мы исправили скриншоты приложения, размывая и удаляя части с контентом 18+. Затем мы начали получать предупреждения о том, что контент самого приложения не соответствует цензурным требованиям магазина.

Однако у нас была идея, как это обойти. По сути, нам нужно было только выпустить релиз, который ничем не отличался от уже существующего в магазине. Мы считали, что главное — пройти модерацию. Благодаря встроенной в приложение возможности получать пакеты удалённо, мы создали специальный набор пакетов, который загружался на эту версию Android до релиза (во время модерации). Таким образом, мы смогли обойти цензуру и выйти в магазин.

«Мы думали, что умнее алгоритмов Google. План с "удаленной подменой контента" казался гениальным: на модерацию отправляем целомудренную версию, а после аппрува включаем "клубничку".»

Где мы просчитались: Google проводит не только первичную проверку, но и периодические ревизии (иногда автоматические, иногда по жалобам). Как только наши метрики пошли вверх, мы попали под радар. Вердикт: обман системы — это прямая дорога в пожизненный бан аккаунта без права на восстановление«.»

Информация о блокировке приложения
Информация о блокировке приложения

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

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

7.2 Релиз в AppStore

Так как это было первое наше приложение в AppStore мы не понимали до конца всей требовательности этой прекрасной компании и релиз затянулся аж до месяца:C. Связано это было не только с тем что одна проверка могла занять 3–5 дней, но и так же со многими переделками скринов (цензура 18+) и моментов внутри приложения.

И так в октябре нам удалось сделать релиз. И мы были в шоке от первой недели из‑за количества скачиваний ведь их было 30–40 в день! Что было на порядок больше чем в PlayMarket. У нас быстро начала появляться база пользователей (и не только наши знакомы или друзья). Ведь первые покупки не заставили себя долго ждать, что было для нас откровением.

Кстати лишь спустя год мы узнали о такой вещи как недельный буст от Apple в момент релиза нового приложения, а так же о важности ASO .

8. Результаты спустя время

Хотелось бы сразу отметить что статью я начинал писать еще в 2024 году. Сейчас 2026 и хотелось бы отметить что многое в продукте изменилось ASO/Дизайн/Монетизация.

Как минимум мы перешли на подписочную модель (недельный + годовой) способ монетизации приложения, что дало не плохой буст в месячной выручке. Но всё еще не достаточной для беззаботной жизни :D

результаты спустя время
результаты спустя время

8.1 Бонус (Автоматизация рутины: SMM-ферма на n8n)

К 2025 году мы окончательно поняли: мы разработчики, а не маркетологи. Ежедневная генерация контента для соцсетей (Shorts, Reels, посты в Telegram/Pinterest) превратилась в пытку и отнимала драгоценное время от написания кода. Нанимать SMM-агентство бюджет не позволял, поэтому мы решили проблему инженерным путем — собрали автоматическую ферму контента.

В качестве оркестратора выбрали n8n (self-hosted версию, чтобы не платить за лишние исполнения). Мы настроили цепочки сценариев, которые работают полностью автономно:

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

И того у нас вышло делать каждые 8 часов видео для Запрещеннограмма/Тиктока/Ютуба на 5 языков. (да да мы AI-Slop и мертвый интернет), но тем не менее, кто-то лайкает наши видео, так что они не совсем бесполезны!

workflow на n8n + posted
workflow на n8n + posted
Статистика просмотров, в момент ямок машина переставала работать(profile views не работает корректно)
Статистика просмотров, в момент ямок машина переставала работать(profile views не работает корректно)

Често это тема для отдельной статьи насчет n8n и автоматизации генерации контента.

Заключение

Этот путь от «сделаем за неделю» до стабильного продукта длиной в три года научил нас главному: написание кода — это, пожалуй, самая предсказуемая и управляемая часть стартапа. Куда сложнее бороться с собственными иллюзиями и жесткими правилами платформ.

Потеря аккаунта Google Play стала для нас болезненной, но отрезвляющей пощечиной. Мы на практике убедились, что игра в кошки-мышки с модерацией — это стратегия, обреченная на провал. Зато AppStore, к которому мы изначально относились со скепсисом из-за высокого порога входа ($99) и строгих проверок, в итоге стал нашим спасательным кругом.

Если вы сейчас стоите на пороге создания своего первого приложения, вот три главных вывода из нашего опыта:

  1. Технологии готовы: Не бойтесь Expo и React Native. Мифы о их непроизводительности остались в 2020 году. Для стартапов это идеальный инструмент.

  2. Маркетинг важнее фич: Мы потратили месяцы на код, но реальные деньги пришли только после работы над ASO и внедрения подписок.

  3. Честность выгоднее: Не пытайтесь обмануть сторы. Это марафон, а не спринт, и срезать углы здесь обходится слишком дорого — ценой всего бизнеса.

Сейчас, в 2026 году, проект продолжает жить и приносить прибыль, пусть и не такую баснословную, как в мечтах 2023-го. Но опыт, полученный за эти $25 (цена аккаунта Google) и сотни часов рефакторинга, окупился стократно.