Создание приложения для мобильных устройств — это цепочка из шести этапов: идея и сценарий, прототип экранов, выбор способа разработки, сама разработка, тестирование на реальных устройствах и публикация в магазине. Код — только один из этих этапов, и не с него стоит начинать.
Содержание
Ниже — что делать на каждом этапе, как выбрать между конструктором, нативной и кроссплатформенной разработкой, от чего зависят сроки и на чем чаще всего спотыкаются новички. Состояние инструментов и правил магазинов описано на сентябрь 2026 года.
Три слова, которые путают
- Нативное приложение написано на языке и инструментах самой платформы: Kotlin для Android, Swift для iOS. Под каждую систему — свой проект.
- Кроссплатформенное приложение собирается под Android и iOS из общей кодовой базы (Flutter, React Native, Kotlin Multiplatform, .NET MAUI). Общей бывает не вся база: часть кода под конкретную систему обычно остается.
- Конструктор (no-code или low-code) — сервис, где экраны и логику собирают из готовых блоков без кода или почти без него.
Отдельно стоит PWA — сайт, который можно добавить на главный экран телефона. Это не приложение из магазина, но для каталога, расписания или простой формы его иногда достаточно.
Этап 1. Идея и один главный сценарий
Сформулируйте, кто пользователь и какое одно действие он выполняет в приложении. «Трекер привычек: отметить выполненное за день и увидеть серию» — рабочая формулировка. «Приложение для здорового образа жизни» — нет, из нее нельзя вывести экраны.
Затем выпишите функции и разделите их на две группы: без чего главный сценарий не работает и все остальное. Первая группа — это MVP, минимальная версия, которую можно отдать людям. Вторая ждет следующих релизов.
Результат этапа — полстраницы текста: пользователь, сценарий, список функций первой версии.
Этап 2. Прототип экранов
Нарисуйте все экраны первой версии и переходы между ними: на бумаге или в графическом редакторе вроде Figma. Задача прототипа — не красота, а проверка логики: куда человек попадает после запуска, как возвращается назад, что видит, когда данных еще нет.
Покажите прототип двум-трем людям из целевой аудитории и попросите выполнить главный сценарий без подсказок. Места, где они запнулись, дешевле исправить сейчас, чем после написания кода.
Уже здесь продумайте планшет. Растянутый телефонный экран на планшете выглядит пустым, поэтому для широкого окна обычно делают вторую компоновку: список слева, детали справа. Это же пригодится на складных устройствах и в режиме разделенного экрана.
Этап 3. Выбор способа разработки
Выбор зависит от трех вещей: нужен ли вам результат или навык, на каких платформах должно работать приложение и насколько глубоко оно использует возможности устройства.
| Способ | Что нужно знать | Когда подходит | Главное ограничение |
|---|---|---|---|
| Конструктор | Логика экранов и данных, без кода | Проверить идею, сделать каталог, запись, внутренний инструмент | Зависимость от сервиса и его тарифа; нестандартную функцию можно не собрать вовсе |
| Нативно | Kotlin и Android Studio или Swift и Xcode | Нужна одна платформа, глубокая работа с камерой, датчиками, фоновыми задачами; цель — профессия разработчика | Вторая платформа — это второй проект |
| Кроссплатформа | Dart (Flutter), JavaScript или TypeScript (React Native), Kotlin (Kotlin Multiplatform), C# (.NET MAUI) | Нужны Android и iOS сразу, команда маленькая | Свежие возможности систем приходят с задержкой, для части задач все равно нужен нативный код |
Два практических условия, о которых узнают слишком поздно. Сборка под iOS требует Xcode, а он работает только на macOS: без Mac или облачной сборки iOS-версию не выпустить, какой бы способ вы ни выбрали. Для Android достаточно компьютера с Windows, macOS или Linux.
Если вы учитесь и платформа не задана заказчиком, начните с одной. Нативный Android на Kotlin — типичный старт: не нужен Mac, а проверить приложение можно на своем телефоне.
В старых руководствах встречаются Xamarin и PhoneGap. Для нового проекта их не берут: поддержка Xamarin завершена в мае 2024 года, его преемник — .NET MAUI; PhoneGap закрыт Adobe в 2020 году. Гибридный подход «веб-страницы в оболочке» жив в связке Ionic и Capacitor.
Этап 4. Разработка
Порядок, который экономит время:
- Соберите пустой проект из шаблона среды разработки и запустите его на телефоне. Так вы сразу проверите, что инструменты установлены верно.
- Сделайте главный сценарий целиком на выдуманных данных, зашитых в код. Пусть некрасиво, но от первого экрана до результата.
- Добавьте хранение данных: локальную базу на устройстве или сервер, если данные нужны на нескольких устройствах.
- Обработайте состояния, которых нет в прототипе: пустой список, нет сети, ошибка сервера, долгий ответ.
- Сделайте компоновку для планшета и проверьте поворот экрана.
- Только теперь доводите внешний вид.
С первого дня ведите проект в Git. Ключи API, пароли и файл ключа подписи приложения в репозиторий не кладите: ключ подписи храните в двух надежных местах, потому что без него обновить опубликованное приложение будет сложно или невозможно.
Запрашивайте только те разрешения, без которых сценарий не работает, и в момент, когда они понадобились. Приложение, которое при первом запуске просит контакты, геолокацию и микрофон, чаще удаляют и дольше проверяют в магазинах.
Если приложение собирает данные людей (почту, телефон, геолокацию), понадобится политика конфиденциальности, а при работе с пользователями из России — соблюдение закона о персональных данных. Эту часть стоит обсудить с юристом до релиза, а не после.
Подробный разбор первых шагов именно на Android — в статье как написать программу или игру на Android.
Этап 5. Тестирование
Эмулятор показывает, что приложение запускается. Он не показывает, удобно ли попадать пальцем по кнопке и как ведет себя приложение на слабом устройстве. Минимальный набор проверок перед релизом:
- маленький телефон, большой телефон и планшет, в обеих ориентациях;
- самая старая версия системы, которую вы заявили как поддерживаемую;
- запуск без сети и с обрывом сети посреди действия;
- увеличенный системный шрифт и темная тема;
- сворачивание и возврат: введенные данные не должны пропадать;
- установка «с нуля» и обновление поверх предыдущей версии.
Затем отдайте сборку нескольким людям, которые не видели проект. У магазинов для этого есть закрытое тестирование: TestFlight у Apple, тестовые треки в Google Play.
Этап 6. Публикация в магазинах
Для публикации нужен аккаунт разработчика, подписанная релизная сборка и страница приложения: название, описание, иконка, скриншоты для телефона и планшета, ссылка на политику конфиденциальности, сведения о собираемых данных и возрастной рейтинг.
| Магазин | Плата за аккаунт | Что учесть |
|---|---|---|
| Google Play | 25 долларов один раз | Формат загрузки — Android App Bundle. Личные аккаунты, созданные после 13 ноября 2023 года, перед выходом в общий доступ проводят закрытый тест: не меньше 12 тестировщиков 14 дней подряд. На аккаунты организаций это требование не распространяется |
| App Store | 99 долларов в год | Сборка и загрузка через Xcode на Mac; каждую версию проверяет модерация. С 28 апреля 2026 года принимаются сборки, сделанные в Xcode 26 с SDK iOS 26 |
| RuStore | Бесплатно | Российский магазин для Android; принимает APK и AAB |
Суммы и условия меняются, а оплата аккаунтов Google и Apple из России осложнена, поэтому перед регистрацией сверьтесь с актуальными страницами магазинов. Сам процесс регистрации разобран в статье про аккаунт разработчика в Google Play и App Store.
После первого релиза работа не заканчивается: магазины каждый год поднимают требования к версии SDK. В Google Play с 31 августа 2026 года новые приложения и обновления должны быть нацелены на Android 16 (API 36). Уже опубликованное приложение с целевым уровнем ниже Android 15 (API 35) перестает показываться новым пользователям на устройствах с более свежей версией системы.
От чего зависят сроки
Честного «за N дней» не существует: срок определяют число экранов, наличие сервера и входа по учетной записи, платежи, число платформ и ваш опыт. Для оценки полезнее не общая цифра, а понимание, что двигает срок сильнее всего.
| Что добавляем | Как влияет |
|---|---|
| Сервер и синхронизация между устройствами | Появляется вторая часть проекта: API, база, авторизация |
| Вторая платформа нативно | Объем клиентской работы почти удваивается |
| Платежи и подписки | Отдельная интеграция и более строгая проверка магазина |
| Первое приложение автора | К разработке добавляется время на изучение языка и инструментов |
| Первый релиз в магазине | Регистрация аккаунта, обязательный закрытый тест в Google Play, модерация, возможные возвраты на доработку |
Грубый ориентир для одного человека и приложения на три-пять экранов без сервера: на конструкторе счет идет на дни или недели, с кодом и с учетом обучения — на месяцы. Это оценка порядка, а не обещание. На публикацию закладывайте отдельный запас: у нового личного аккаунта Google Play только закрытый тест занимает две недели.
Типичные ошибки и что делать
| Симптом | Вероятная причина | Что делать |
|---|---|---|
| Проект тянется месяцами, релиза нет | В первую версию попало все, что придумалось | Вернуться к этапу 1 и оставить один сценарий |
| На планшете пустые поля и огромные кнопки | Компоновка сделана под один размер экрана | Добавить вариант для широкого окна, проверить поворот |
| Магазин отклонил сборку | Нет политики конфиденциальности, лишние разрешения, описание не совпадает с функциями | Прочитать причину в письме модерации, исправить именно ее, отправить снова |
| Приложение падает у пользователей, у вас работает | Проверялось на одном устройстве и одной версии системы | Подключить сбор отчетов о сбоях, расширить набор тестовых устройств |
| Не получается выпустить обновление | Потерян ключ подписи | Обратиться в поддержку магазина; на будущее хранить ключ в двух местах |
| В конструкторе нельзя сделать нужную функцию | Предел возможностей сервиса | Проверять ключевую функцию в конструкторе до того, как собирать остальное |
Выводы
- Создание мобильного приложения — шесть этапов: идея, прототип, выбор способа, разработка, тестирование, публикация. Первые два проходят без кода и экономят больше всего времени.
- Конструктор подходит для проверки идеи, нативная разработка — для одной платформы и глубокой работы с устройством, кроссплатформа — когда Android и iOS нужны сразу при маленькой команде.
- iOS-версию нельзя собрать без macOS; для Android хватит любого компьютера.
- Планшет — это отдельная компоновка экрана, а не растянутый телефон; закладывать ее нужно на этапе прототипа.
- Публикация занимает время сама по себе: аккаунт, страница приложения, закрытый тест и модерация.
Где применяется / связь с практикой
Описанная цепочка одинакова и для личного проекта, и для коммерческой разработки: в компании этапы делят между аналитиком, дизайнером, разработчиками и тестировщиками, а в одиночку вы проходите их сами. Быстрее всего навык появляется, когда вы доводите до магазина одно маленькое приложение, а не изучаете платформу по частям.
Освойте тему на практике
Если вы выбрали Android и хотите пройти этот путь с наставником и разбором кода, посмотрите программу курса Android-разработчик. Базовый уровень. Познакомиться с форматом и преподавателями можно на открытых уроках Otus.
FAQ
Можно ли распространять Android-приложение без магазина?
Да, APK-файл можно передать напрямую, но пользователю придется разрешить установку из неизвестных источников, а обновления он будет ставить вручную. Для узкого круга знакомых это приемлемо, для широкой аудитории — нет.
Есть и новое правило Google: на сертифицированных устройствах приложение должно быть привязано к разработчику, который подтвердил личность, где бы оно ни распространялось. С 30 сентября 2026 года правило действует в Бразилии, Индонезии, Сингапуре и Таиланде, на другие страны его планируют распространить в 2027 году. Для учебных и личных проектов есть упрощенный режим с раздачей не более чем на 20 устройств, а установка через adb остается доступной.
На iOS установка в обход App Store для обычных пользователей сильно ограничена.
Нужно ли одно приложение для телефона и планшета или два разных?
Обычно одно: сборка общая, а компоновка экрана выбирается по ширине окна. Отдельное приложение для планшета делают редко, когда сценарии использования различаются принципиально.
Можно ли начать с конструктора, а потом переписать на код?
Можно, но переносить придется почти все: проект конструктора, как правило, не превращается в исходный код, с которым удобно работать дальше. Конструктор стоит воспринимать как способ проверить идею, а не как первую версию будущей кодовой базы.
