Стоимость разработки приложения для iOS и Android: 9 факторов, которые двигают цену вверх

«Сделаем сначала приложение для iOS, а Android добавим позже — так ведь почти вдвое дешевле?»

Этот вопрос я слышу регулярно, и логика в нём кажется очевидной: одна платформа вместо двух — значит примерно половина работ. Но значительная часть сметы вообще не относится ни к iOS, ни к Android: бизнес-логика, серверная часть, база данных, интеграции и административная панель создаются один раз.

Поэтому вопрос лучше ставить иначе — не сколько стоит iOS отдельно от Android, а какая часть сметы действительно зависит от второй платформы. Разберу по порядку: что делится между платформами, девять факторов, которые двигают цену вверх, когда одна платформа правда выгоднее и что на стоимость влияет меньше, чем принято думать.

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

Почему цена разработки приложений для iOS и Android — это одна смета, а не две

Считать iOS и Android отдельно логично только на бумаге. В реальном проекте значительная часть дорогих работ делается один раз для обеих платформ.

Левая колонка не про телефон вообще — и именно поэтому отказ от второй платформы не делит смету пополам.

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

Девять факторов, которые двигают стоимость разработки приложения вверх

1. Одна платформа или обе

Один из самых заметных платформенных факторов — и один из немногих, который вы решаете сами, а не вслед за задачей.

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

2. Нативная разработка или кроссплатформенная

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

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

3. Сколько версий операционных систем поддерживаем

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

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

4. Разброс устройств: чем цена разработки приложения для Андроида отличается от iOS

Здесь и появляется разница, из-за которой цена разработки приложения для Андроида не совпадает с ценой для iOS.

Устройств Apple немного, и они предсказуемы. Android — это сотни моделей разных производителей с разными экранами, версиями системы и собственными надстройками. Код при этом общий, а вот тестирование и доводка на реальных устройствах занимают больше времени. Это не «Android дороже вообще» — это конкретная статья работ, которая на iOS меньше.

5. Возможности устройства

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

Разброс внутри одного пункта больше, чем кажется. Отправить push — одна задача. Построить логику «кому, при каком событии, в какое время и на какой экран вести после нажатия» — другая, и она уже не про платформу, а про ваш продукт.

6. Платежи внутри приложения

Этот пункт легко пропустить на этапе предварительной оценки.

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

Правила площадок меняются, поэтому проверять их надо на момент старта проекта, а не по статье двухлетней давности.

7. Требования площадок к входу и данным

Здесь бюджет растёт не от функций, а от требований площадок.

У Apple и Google есть собственные требования к способам входа, к обработке персональных данных и к раскрытию информации о том, что приложение собирает и как это использует. Требования зависят от функций приложения и меняются, поэтому проверять их нужно перед началом разработки и ещё раз перед публикацией.

Каждый пункт по отдельности невелик. Вместе они складываются в работу, которой нет ни в одном макете.

8. Публикация и модерация

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

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

9. Поддержка после релиза

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

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

Когда действительно имеет смысл начать с одной платформы

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

Одна платформа оправдана, когда:

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

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

Главное правило: решение «делаем только iOS» или «только Android» принимается по данным о пользователях, а не по предполагаемой экономии. Если данных нет — это не аргумент за одну платформу, это повод сначала их собрать.

Что само по себе мало говорит о стоимости

Три вещи, которые в разговорах называют первыми, хотя цену по ним не определить.

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

Дизайн. Цена зависит не от того, насколько приложение выглядит «красиво», а от объёма уникальных компонентов, состояний, анимаций и требований к дизайн-системе. Собственная дизайн-система — отдельная статья бюджета, а не вопрос вкуса.

Размер команды. Удвоение числа разработчиков не сокращает срок вдвое: добавляются координация и зависимости между задачами. Срок реально сокращает уменьшение объёма первой версии.

Сколько стоит разработка приложения для iOS и Android: порядки сумм

Можно отдельно оценить сценарий запуска только на iOS и отдельно — стоимость разработки приложения для Android. Но складывать эти две оценки, чтобы получить цену приложения для обеих платформ, неправильно: в каждой из них уже учтена общая часть проекта — бизнес-логика, серверная часть, база данных и интеграции.

Поэтому дальше — про экономию на одной платформе.

Отказ от второй платформы не делит смету пополам. Разбор задачи, роли, структура экранов, серверная часть, база данных, интеграции и админ-панель остаются в полном объёме — они не про телефон вообще. Уходит интерфейсный слой второй платформы, её тестирование и её публикация, то есть меньшая часть работ. Поэтому «сделаем пока только под iOS» экономит заметно меньше, чем ожидают, а вернувшись за Android через полгода, вы доплатите ещё и за повторный выпуск.

Три ориентира с моей страницы цен:

• MVP — от 250 000 ₽. Один главный сценарий, доведённый до конца. Подходит, когда надо проверить идею, а не строить всю систему сразу — подробнее на странице MVP.
• Веб-приложение или личный кабинет — от 450 000 ₽. Если ваши пользователи работают за компьютером, сторы и две сборки вам просто не нужны.
• Мобильное приложение для iOS и Android — от 950 000 ₽. Состав работ расписан на странице разработки мобильных приложений.

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

Ориентир по срокам полноценного приложения — несколько месяцев, у MVP — несколько недель. Точный срок называется после разбора задачи, и подрядчик, который называет его до разбора, называет его наугад.

С чего начать, чтобы не переплатить

Три вопроса, которые стоит закрыть до того, как запрашивать оценку.

1. Кто ваши пользователи и с чего они заходят? Этот ответ определяет, нужно ли вообще оплачивать работы по второй платформе.
2. Сколько у вас ролей? Клиент, менеджер, курьер, администратор — каждая роль это свои экраны и права, фактически отдельное приложение внутри проекта.
3. Что обязано быть в первой версии, а что подождёт? Сокращение объёма первой версии — один из самых надёжных способов уменьшить стартовый бюджет, не ухудшая качество того, что вы всё-таки делаете.

Ответы на эти три вопроса позволяют заметно сузить вилку ещё до разговора с подрядчиком.

Быстрый самотест

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

Состав ролей и границы первой версии я бы уточнял до запроса сметы: они могут заметно изменить объём разработки ещё до выбора технологий.

Что делать дальше

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

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