Как я выпускаю Android-приложения в одиночку в 2026 году

Самое сложное в выпуске Android-приложения в одиночку в 2026 году — не код. Compose зрелый, инструментарий Play хорош, а библиотек больше, чем кто-либо успеет прочитать. Сложность в том, чтобы закончить. Рамки расползаются, полировка съедает календарь, и однажды ты понимаешь, что приложение, начатое три месяца назад, технически впечатляет сильнее — и всё ещё не в магазине.

Я выпустил два приложения именно так, третье в разработке, и в итоге остановился на плане, который проводит меня от идеи до опубликованной страницы примерно за четыре-шесть недель. Ничего хитрого в нём нет. Всё сводится к тому, чтобы говорить «нет».

1. Обрезайте рамки безжалостно — один экран, один глагол

Прежде чем написать хоть строку Kotlin, я делаю одно упражнение: описываю приложение одним предложением с одним глаголом. Granyn — записать расход в два касания. Hydrame — получить спокойное напоминание, пока не забыл выпить воды. Subly — сфотографировать счёт и извлечь подписку прямо на устройстве. Если в предложении есть «и», то это два приложения.

Это одно предложение становится правилом для каждого решения о функции. Графики? Только если они поддерживают глагол. Облачная синхронизация? Только если без неё глагол ломается. Настройки? Чем меньше, тем лучше. Самый недооценённый приём в одиночной разработке — не строить лишнего.

Если в вашей однофразовой презентации есть «и», вы строите два приложения.

Реальный способ этого добиться: напишите страницу Play Store — название, короткое описание, подзаголовок на 80 символов — прежде чем написать хоть строку кода. Если вы не можете продать приложение в 80 символах, вы не построите его и за восемь недель.

2. Выберите крошечный, скучный стек

Для Android в 2026 году весь мой стек намеренно крошечный:

• Kotlin + Jetpack Compose (никаких XML-разметок, никаких fragment)
• Одна activity с androidx.navigation.compose
• Room с Flow и suspend-функциями для всего локального
• DataStore (вариант preferences) для настроек
• WorkManager для фоновых задач, AlarmManager только там, где нужна точность
• Material 3 для компонентов, с собственной цветовой схемой
• Hilt для внедрения зависимостей — но только если приложение достаточно большое, чтобы это оправдать (Granyn да, крошечная утилита нет)

Вот и весь список. Никаких тяжёлых генераторов на KSP, никакого сетевого слоя, пока приложение реально не общается с сервером, никаких сторонних UI-китов. Правило: новая зависимость должна заслужить свою строку в build.gradle.kts обоснованием в одно предложение, которое я готов записать.

3. Сначала стройте скучные экраны

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

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

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

@Composable
fun App() {
    val navController = rememberNavController()
    Scaffold(
        bottomBar = { AppBottomBar(navController) },
    ) { inner ->
        NavHost(
            navController = navController,
            startDestination = Routes.Home,
            modifier = Modifier.padding(inner),
        ) {
            composable(Routes.Home) { HomeScreen() }
            composable(Routes.Stats) { StatsScreen() }
            composable(Routes.Settings) { SettingsScreen() }
        }
    }
}

Вот и вся «архитектура» половины моих приложений.

4. Зафиксируйте модель данных рано, мигрируйте вечно

Миграции схемы — тихий убийца инди-приложений. Решение — думать о базе данных как о публичном API: как только она в продакшене, каждое изменение — это миграция с тестом. Room делает это управляемым:

@Database(
    entities = [Expense::class, Category::class],
    version = 4,
    autoMigrations = [
        AutoMigration(from = 1, to = 2),
        AutoMigration(from = 2, to = 3, spec = MigrateNotesField::class),
        AutoMigration(from = 3, to = 4),
    ],
    exportSchema = true,
)
abstract class AppDatabase : RoomDatabase() { ... }

Самое полезное, что я делаю: exportSchema = true и коммит этих JSON-файлов в git. Тогда тест, управляемый Room, ловит регрессии схемы ещё до того, как они попадут на устройство пользователя. Я не сосчитаю, сколько испорченных вечеров это мне сэкономило.

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

Пирамида тестов одиночного разработчика: горстка чистых юнит-тестов для того, что легко тестировать и невозможно иначе отладить (арифметика валют, арифметика дат, извлечение полей по OCR в Subly). Ноль UI-тестов. Плотное ручное дымовое тестирование на трёх реальных телефонах: Pixel, среднебюджетный Samsung и по-настоящему дешёвый Xiaomi. Дешёвый телефон не обсуждается — именно он реально есть у ваших пользователей.

И Samsung, и Xiaomi вскроют настоящие проблемы, которых нет в эмуляторе. Уведомления, убитые агрессивной оптимизацией батареи, точные будильники, тихо перепланированные, паттерны вибрации, срабатывающие на 200 мс позже. Если вашему приложению нужны надёжные уведомления (Hydrame они нужны), тестируйте на Samsung, иначе узнаете об этом уже после запуска.

6. Страница в Play Store — это половина вашего приложения

Потратьте выходные на страницу в магазине. Название и короткое описание — это SEO. Скриншоты — это конверсия. Feature graphic — это первые 1,6 секунды, которые человек проводит с вашим брендом.

Реалистичный чек-лист:

• Название с основным ключевым словом (не умничайте — «Granyn — Budget & Expense Tracker» лучше, чем «Granyn»)
• Короткое описание (80 символов) с глаголом и единственным отличием
• Длинное описание из трёх-пяти коротких абзацев, с подзаголовками и эмодзи, используемыми умеренно
• Скриншоты в 1080×2400 или выше, где первый скриншот — ваш главный кадр. Большинство пользователей никогда не листают.
• Feature graphic (1024×500). Текста по минимуму — это баннер, а не билборд.
• URL политики конфиденциальности — обязателен. Хостите её сами (GitHub Pages подойдёт), чтобы редактировать без выпуска релиза.
• Возрастной рейтинг — заполните анкету честно. Это быстрее, чем кажется.
• Категоризация приложения — форма Data Safety. Отнеситесь к ней серьёзно; это публичная версия вашей политики конфиденциальности.

Форму Data Safety большинство заполняет наспех. Заполняйте её так, будто объясняете юристу. Если вы не можете поставить галочку «данные не собираются», объясните точно, какая третья сторона (Firebase, AdMob, Play Billing) обрабатывает какое поле. Google с каждым годом строже сверяет это с поведением во время выполнения.

7. Запускайте тихо, следите за воронкой

Сначала сделайте мягкий запуск в своей стране. Не анонсируйте его. Первые 50 установок — это ваша бета: следите за отчётами о сбоях, ANR и соотношением установок/удалений. Если удержание на первый день ниже 30%, чините онбординг, прежде чем заниматься маркетингом.

Первое, что я проверяю каждое утро в Play Console первые две недели:

• % пользователей без сбоев
• частота ANR
• Vitals (избыточные пробуждения, застывшие кадры)
• отзывы на 1 звезду — читайте каждое слово. Это золото.

Затем я раскатываю шире — на остальную Европу, потом глобально. Поэтапная раскатка (10% → 25% → 50% → 100%) бесплатна; используйте её.

8. Скучная работа после запуска

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

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

Что бы я сделал иначе в следующий раз

Короткий список, ведь ретроспектива — лучший учитель:

1. Сначала напишите страницу Play Store. Относитесь к ней как к спецификации. Я не шучу.
2. Более крупные пустые состояния с первого дня. Пустой экран убивает первое впечатление; продуманное пустое состояние покупает вам второй запуск.
3. Онбордингу — один экран. Максимум два. Если нужны три, у вас проблема с UX, которую надо чинить в приложении, а не удлинять онбординг.
4. Настройте Crashlytics в первый же день. Да, даже для крошечной утилиты.
5. Политика конфиденциальности на собственном домене или GitHub Pages. Вы будете обновлять её чаще, чем думаете, и вам не нужна повторная проверка Play Console из-за каждой правки.

Весь этот план намеренно неромантичен. Романтика инди-разработки — это свобода выпускать; план — это то, что защищает эту свободу от вашего же расползания рамок.

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