Короткий ответ
Сначала проверьте, что продукту нужно именно приложение, а не мобильный сайт: его оправдывают уведомления, работа без сети, датчики телефона или место в магазине. Затем выберите способ разработки — нативный, кроссплатформенный или конструктор, — сократите первую версию до одного пользователя и одного сценария, проверьте кликабельный прототип, продумайте сервер, оформите аккаунты разработчика на себя и заложите время на проверку и ежегодные обновления.
Сначала проверьте, нужно ли идее именно приложение
Тот, кто ищет, как создать мобильное приложение, обычно уже решил, что нужно именно оно. Этому решению стоит уделить ещё час: веб многому научился. MDN, справочник Mozilla для веб-разработчиков, описывает прогрессивное веб-приложение как собранное на веб-технологиях, но похожее в работе на приложение под платформу. По его описанию, такое приложение устанавливается на устройство, работает без сети и показывает системные уведомления — и всё это на одном коде.
У приложения под платформу, по списку MDN, от природы есть связь с операционной системой, доступ к камере, GPS и акселерометру и распространение через магазин. На iPhone границу легко почувствовать: команда WebKit писала в феврале 2023 года, что пуш-уведомления в вебе пришли с iOS 16.4 — для веб-приложений, которые человек добавил на экран «Домой». Если продукт живёт ежедневными уведомлениями, датчиками или витриной магазина, делайте приложение. Если его открывают дважды в год, мобильный сайт справится лучше.
Три способа разработки: нативный, кроссплатформенный и конструктор
Нативное приложение пишут отдельно под каждую платформу её собственными инструментами: один проект для iPhone, другой для Android. Вы оплачиваете два набора кода и получаете самый полный доступ к возможностям каждой системы. Второй способ — один код на обе. Сайт Flutter описывает фреймворк для сборки нативно скомпилированных приложений из единой кодовой базы; сайт React Native говорит о себе: написано на JavaScript, отрисовано нативным кодом. Одна команда обходится дешевле, зато свежая возможность платформы может дойти до вас позже.
Третий способ — конструктор без кода: экраны собирают из готовых блоков, а сервис выдаёт приложение. Это самый быстрый путь к тому, что можно дать клиенту в руки, и разумный способ проверить спрос. Пункт 4.2.6 правил проверки Apple, App Review Guidelines, гласит: приложения, созданные по коммерческому шаблону или сервисом генерации приложений, отклоняют, если их не отправил сам владелец контента. Значит, публикуется приложение с вашего аккаунта разработчика, а не с аккаунта конструктора.
Первая версия: один пользователь и один сценарий от начала до конца
Первая версия — не уменьшенная копия мечты. Это один человек, который делает одно дело от первого экрана до результата: клиент записывается на стрижку, курьер закрывает доставку, родитель оплачивает занятие. Запишите этот сценарий как последовательность экранов и вычеркните всё, без чего человек проживёт месяц. Останется кратчайший путь от запуска приложения до результата.
Магазины такую дисциплину вознаграждают. На странице Apple о проверке приложений сказано, что в среднем более 40% нерешённых замечаний относятся к пункту 2.1 о завершённости приложения: сбои, заглушки вместо содержимого, неполные сведения. У узкой первой версии меньше недоделанных углов. И до живых людей она добирается раньше, а их поведение в первую неделю отвечает на вопросы, которые не решит ни одно совещание.
Дизайн до кода: кликабельный прототип и правила интерфейса самих платформ
Код — самое дорогое место для смены решений. Поэтому сценарий сначала превращают в простые экраны, а экраны — в кликабельный прототип: макет, который открывается на телефоне и нажимается. Дайте его пяти людям, похожим на вашего пользователя, и смотрите, где они останавливаются. Заминка, найденная здесь, стоит часа работы дизайнера; та же заминка после выпуска стоит доработки и ещё одной проверки в магазине.
Обе платформы публикуют, как должны выглядеть и вести себя их приложения. Human Interface Guidelines у Apple называют себя сводом рекомендаций и лучших практик для любой платформы компании. Документация Android для разработчиков представляет Material Design 3 как открытую, гибкую систему правил, компонентов и инструментов. Спросите дизайнера, какие стандартные компоненты использует приложение: каждый самодельный элемент — это лишний дизайн, лишний код и ещё одна вещь, которой пользователю придётся учиться.
Серверная часть, которую никто не видит: аккаунты, данные, платежи, уведомления
То, что пользователь держит в руке, — половина продукта. Вторая половина живёт на сервере: клиенты, расписание, заказы и панель управления для ваших сотрудников. Если смета выглядит подозрительно скромной, проверьте, вошла ли в неё эта часть. У аккаунтов есть и правила: по пункту 5.1.1 правил Apple приложение, где можно создать учётную запись, обязано давать удалить её прямо в приложении, и каждому приложению нужна ссылка на политику конфиденциальности. Чего требует ваш закон о персональных данных — вопрос к юристу.
Платежи делятся надвое. По пункту 3.1.1 правил Apple открытие функций или контента внутри приложения идёт через встроенные покупки; по пункту 3.1.3(e) физические товары и услуги, которые потребляют вне приложения, оплачивают другими способами. Платёжная политика Google Play проводит похожую границу. Поэтому студия йоги с занятиями в зале и сервис видеоуроков строят разную оплату. Правило есть и у уведомлений: пункт 4.5.4 допускает рекламу в пуш-уведомлениях только с явного согласия человека.
Публикация: аккаунты разработчика, закрытый тест Google и проверка в магазинах
Для публикации нужен аккаунт разработчика в каждом магазине, и принадлежать он должен вам, а не подрядчику. На странице регистрации Apple участие в Apple Developer Program оценено в 99 долларов США за год. Справка Google Play Console на октябрь 2026 года называет разовый взнос 25 долларов США. Личный аккаунт, созданный после 13 ноября 2023 года, должен ещё провести закрытый тест — минимум 12 тестировщиков 14 дней подряд — и лишь затем подать заявку на доступ к публикации. Обе компании меняют такие условия, поэтому откройте страницы в день регистрации.
Дальше идёт проверка. Apple сообщает, что обычно не меньше половины заявок проверяют быстрее чем за 24 часа, а 90% — быстрее чем за 48. Google предупреждает, что у некоторых аккаунтов разработчика проверка занимает до семи дней, а в исключительных случаях дольше. Отказ — не приговор: Apple называет пункт, который не выполнен, и даёт ответить или подать апелляцию, Google позволяет исправить и отправить снова. Планируйте запуск с запасом в неделю.
Жизнь после запуска: обновления систем, отчёты о сбоях, отзывы и поддержка
Приложение не заканчивается в день выпуска: обе платформы не стоят на месте. В справке Google Play о целевом уровне API сказано, что с 31 августа 2026 года новые приложения и обновления должны быть рассчитаны на Android 16. В перечне требований Apple значится, что с 28 апреля 2026 года приложения для загрузки в App Store Connect собирают в Xcode 26 или новее. Через год цифры будут другими, порядок останется. Примерно раз в год кому-то придётся пересобрать и заново отправить приложение, даже если в вашем бизнесе ничего не изменилось.
Качество тоже измеряют за вас. Документация Android описывает Android vitals — показатели качества, собранные с устройств пользователей, — и ставит порог 1,09% для доли сбоев, заметных пользователю. Выше порога Google Play может снизить видимость приложения и показать предупреждение на его странице в магазине. Отзывы работают на виду: Apple отмечает, что автор отзыва получает уведомление об ответе разработчика и может свой отзыв изменить. Поэтому закладывайте в план человека, который каждую неделю читает отчёты о сбоях и отвечает людям.
Что подготовить до заказа приложения и как выбрать первый объём
До заказа запишите четыре вещи. Пользователя и единственный сценарий первой версии — по шагам. Ответ на вопрос «сайт или приложение» с причиной: уведомления, работа без сети, датчик, магазин. Список того, что происходит на сервере: от аккаунтов и платежей до панели управления. И имена на аккаунтах разработчика. С таким листом любой подрядчик даст сопоставимую оценку, а вы увидите, кто из них его действительно прочитал.
Делать самому реально, когда задача — проверить спрос конструктором или мобильным сайтом. Заказывать стоит, когда приложение работает с деньгами или персональными данными, должно выйти на обеих платформах или когда у вас некому отвечать за ежегодные обновления. VITON13 Studio — одно из мест, где берутся за такую работу; есть ещё фрилансеры и собственные команды. Кого бы вы ни выбрали, вопрос, как создать мобильное приложение, становится заметно меньше, когда первый сценарий умещается на одной странице.
Практический чеклист
- Запишите единственный сценарий первой версии нумерованным списком экранов.
- Выберите между мобильным сайтом и приложением и запишите причину этого выбора.
- Оформите аккаунты разработчика Apple и Google на себя или на свою компанию.
- Перечислите, что делает сервер: аккаунты, данные, платежи, уведомления, панель управления.
- Закрепите письменно, кто пересобирает приложение, когда Android и iOS меняют требования.
Вопросы и ответы
Можно ли сделать приложение, если я не умею программировать?
Да, двумя путями. В конструкторе без кода простое приложение собирают сами — этого хватает, чтобы проверить спрос. Для всего, где есть платежи, персональные данные или две платформы, нанимают тех, кто пишет код, а вам остаются сценарий, содержание и решения. В обоих случаях аккаунты разработчика оформляют на вас.
Сколько длится проверка нового приложения в магазинах?
Apple сообщает, что обычно не меньше половины заявок рассматривают менее чем за 24 часа и 90% — менее чем за 48. Google пишет, что у части аккаунтов проверка дольше: до семи дней и более в исключительных случаях. Новому личному аккаунту Google Play сначала нужно закончить 14-дневный закрытый тест, а заявку на доступ к публикации, по справке Play Console, обычно рассматривают за семь дней или быстрее.
Хватит ли прогрессивного веб-приложения вместо приложения в магазине?
Для первой версии — часто да. MDN описывает веб-приложения, которые устанавливаются, работают без сети и присылают уведомления на одном коде. Ограничения видны на iPhone, где ради пуш-уведомлений пользователь сначала должен добавить веб-приложение на экран «Домой», и в поиске: тот, кто ищет в магазине, не найдёт продукт, которого там нет.
На кого оформлять аккаунты разработчика: на основателя или на подрядчика?
На основателя или его компанию. На странице регистрации Apple сказано, что имя на аккаунте показано в магазине как продавец, и тот, у кого аккаунт, распоряжается каждым обновлением. Организация должна быть юридическим лицом с номером D-U-N-S и работающим сайтом, поэтому начните оформление до разработки, а не в неделю запуска.
Зачем готовому приложению обновления каждый год?
Потому что платформы меняются. Google Play требует, чтобы новые приложения и обновления были рассчитаны на свежую версию Android, а Apple — чтобы сборку делали свежей версией её инструментов. Добавьте исправление сбоев и ответы на отзывы — и поддержка становится постоянной строкой плана, а не сюрпризом второго года.