Кроссплатформенное приложение: что экономится, а что нет
Из трёх страниц направления эта единственная, где решение принимается не про платформу, а сразу про обе. Общий код экономит разработку и поддержку кода — и не экономит ничего из того, что удваивается снаружи: магазины, учётные записи, очереди проверок, парки устройств.
- Экраны, списки, формы и переходы на общем коде от родных неотличимы
- Считаем экономию вслух до сметы, а не обнаруживаем её меньшей после подписания
- Где общий код проигрывает — железо, тяжёлая графика, фоновые задачи — названо до договора
- Логика пишется один раз, плюс небольшие куски под особенности каждой платформы
- Магазины, очереди проверок и парки устройств остаются в двух экземплярах
- Проигрывает на железе, тяжёлой графике, фоновых задачах и свежих возможностях системы
- Вход от 300 000 ₽ — ступень та же, что у родной пары, но объём работы внутри меньше
- Логика пишется дважды, каждый раз на родном для платформы языке
- По возможностям не проигрывает нигде — разница только в деньгах и сроках
- Новое в системе становится доступно сразу, а не когда появится поддержка в инструментах
- Вход от 300 000 ₽ — та же ступень сметы, но работы внутри заметно больше
- Пишется тем же кодом, что и сайт, и обновление доезжает до человека сразу
- Ни магазинов, ни очередей: проверять надо браузеры, а не два парка устройств
- Ограничения браузера складываются со всеми ограничениями общего кода
- Вход от 40 000 ₽ — и это отдельное направление, а не ступень этого
Строка про магазины, очереди проверок и парки устройств — главное, что стоит унести с этой страницы. Обещание «сделаем одно приложение вместо двух и сэкономим вдвое» верно ровно наполовину, и вторую половину мы считаем вслух до сметы.
Где общий код проигрывает родному
Мы делаем на общем коде большую часть приложений и считаем это разумным выбором по умолчанию. Но у выбора есть граница, и называть её надо до договора, а не в середине проекта.
Первое: работа с железом на пределе. Обработка видео, сложная работа с камерой, распознавание в реальном времени, точная работа с датчиками. Общий код обращается к возможностям устройства через промежуточный слой, и там, где важны миллисекунды и полный доступ, этот слой мешает. Если ваш сценарий об этом — говорим сразу и считаем родную разработку.
Второе: тяжёлая графика и сложная анимация. Обычные экраны, списки, формы и переходы на общем коде выглядят и работают неотличимо. Но игра, редактор или интерфейс с непрерывной анимацией поверх больших данных упрутся в тот же промежуточный слой, и пользователь это заметит — он увидит не «другую технологию», а подтормаживание.
Третье: фоновая работа. Обе платформы жёстко ограничивают то, что приложение делает, пока его не видно на экране, и делают это по-разному. Общий код здесь всё равно опускается до родных механизмов, и выигрыша почти нет, — а сложность растёт. Если фоновые задачи — суть продукта, экономия оказывается меньше, чем кажется в начале.
Четвёртое: ранний доступ к новым возможностям системы. Когда платформа выпускает что-то новое, родной код получает это сразу, а общий — тогда, когда поддержка появится в используемом наборе инструментов. Обычно это не критично. Критично становится, если ваш продукт строится вокруг свежей возможности платформы.
И то, что стоит сказать прямо про обратный ход. Переезд с общего кода на родной в середине проекта — это не доработка, а новый проект: переписывается всё, кроме серверной части. Поэтому решение принимается на разборе и опирается на сценарий, а не на предпочтения. Та же мысль другими словами есть на странице направления — мы намеренно говорим её с обеих сторон.
Сравнений «на сколько процентов быстрее» мы не приводим: измерений своих у студии нет, а чужие зависят от сценария и версии инструментов настолько, что переносить их на ваш проект бессмысленно.
Экономика двух полок построчно
Центральная таблица страницы. Слева то, что действительно делается один раз; справа то, что остаётся в двух экземплярах, сколько бы ни был общим код.
| Статья работы | Делается один раз | Остаётся в двух экземплярах |
|---|---|---|
| Экраны и логика приложения | Да — основная экономия проекта именно здесь | Небольшие куски под особенности каждой платформы |
| Дизайн | Макеты общие, компоненты общие | Системные элементы и привычные жесты у платформ разные, и подгонка нужна |
| Учётные записи и страницы в магазинах | Нет | Дважды: свои аккаунты, описания, скриншоты, анкеты о данных |
| Публикация и проверки | Нет | Дважды при каждом обновлении, и по правилам каждой площадки отдельно |
| Проверка на устройствах | Нет | Оба парка: однородный с одной стороны и очень разный с другой |
| Поддержка правил площадок | Нет | Требования меняются у каждой по своему расписанию, и двигаться надо под обе |
| Серверная часть | Да, и она общая при любом выборе — даже при двух родных разработках | Нет |
Практический вывод для планирования. Экономия общего кода видна на разработке и на дальнейших доработках: правка делается один раз и уезжает на обе платформы. Постоянные расходы — публикации, проверки, устройства, магазинные правила — она не уменьшает. Значит, чем активнее вы собираетесь развивать приложение, тем выгоднее общий код; а если приложение выпускается один раз и почти не меняется, разница между подходами заметно меньше, чем принято думать.
Кому общий код подходит, а кому нет
Четыре условия слева и три случая справа. Правая колонка написана не для симметрии: там, где она про вас, общий код обернётся переписыванием в середине проекта.
- Приложение про экраны, данные и уведомления. Каталог, заявки, кабинет, запись, статусы, история. Это подавляющее большинство задач, и разницу с родным кодом пользователь здесь не увидит
- Обе платформы нужны одновременно. Аудитория смешанная, и выпустить только под одну означает потерять половину людей — это и есть случай, ради которого общий код придуман
- Приложение будет развиваться. Каждая последующая правка делается один раз вместо двух — и вот здесь экономия становится по-настоящему заметной
- Команда, которая будет вести его дальше, небольшая. Один комплект кода вместо двух — это ещё и вдвое меньше мест, где что-то может разойтись между платформами
- Продукт строится вокруг железа или графики. Обработка видео, распознавание в реальном времени, игра, редактор. Считайте родную разработку сразу — переезд в середине обойдётся дороже, чем сделать правильно с начала
- Нужна одна платформа, и только она. Корпоративный парк, узкая аудитория, внутренний инструмент. Тогда выбирайте одну из двух и не платите за универсальность, которая вам не нужна
- Бюджета хватает на одну платформу, а нужны обе. Общий код это не решает: две полки всё равно стоят дороже одной. Здесь честнее смотреть на этаж ниже — там обе системы закрываются сразу и без магазинов
Третий пункт справа — самая частая причина, по которой сюда приходят. Общий код называют дешёвым входом в мобильность, а он им не является: это всё ещё мобильное приложение со всеми магазинными расходами. Дешёвый вход — этажом ниже по лестнице, и мы говорим это прямо.
Шесть вопросов: упрётся ли ваш сценарий в железо
Отмечайте то, что про вас. Шкала здесь перевёрнута: чем больше отметок, тем больше оснований считать родную разработку, а она дороже. Ничего никуда не отправляется.
Вердикт появится после первой отметки. Шкала перевёрнута: больше отметок — больше оснований для родной разработки.
Совпало 0 из 6
Ни одной отметки — обычный и самый частый результат, и он означает общий код без оговорок. Одна-две отметки разбираются поштучно: иногда тяжёлую часть выносят в родный модуль и подключают к общему коду, и это дешевле двух полных разработок.
Прислать сценарий на разбор
Опишите сценарий — скажем, упрётся ли он в железоЧто приложение делает, что берёт с устройства и должно ли работать в фоне. Скажем, хватит ли общей кодовой базы, где придётся дописать родный модуль и во что обойдутся две полки вместе. Разбор бесплатный.
Если ищете дешёвый вход в мобильностьКак идёт работа
Пять шагов. Особенность здесь одна и она в третьем: приложение проверяется на обоих парках устройств параллельно, а не «сначала одна платформа, потом вторая».
-
01
Разбор сценария и выбор подхода
Смотрим, упирается ли задача в железо, графику или фоновую работу. Здесь же решаем, нужны ли обе платформы сразу или одна из них подождёт. Бесплатно и до договора: ошибка в этом выборе стоит дороже всего остального.
-
02
Сценарий и прототип с учётом двух платформ
Макеты общие, но системные элементы и привычные жесты у платформ разные, и это закладывается в дизайн сразу. Прототип показываем людям с телефонами обеих систем — на этом шаге видно, где придётся расходиться.
-
03
Разработка с проверкой на обоих парках
Каждый готовый кусок сразу смотрим на устройствах обеих систем. Откладывать проверку второй платформы «на потом» — верный способ обнаружить расхождения тогда, когда переделывать дорого.
-
04
Две подготовки к публикации
Два комплекта: учётные записи, страницы приложений, описания, скриншоты под разные размеры, анкеты о данных. Работа не удваивается по сложности, но удваивается по объёму, и в смете она стоит отдельной строкой.
-
05
Выпуск и наблюдение по обеим платформам
Отчёты о сбоях смотрим раздельно: одна и та же ошибка может проявляться только на одной системе. Правка при этом делается один раз — и это та экономия, ради которой всё затевалось.
Своего срока у этой страницы нет: 11–16 недель — срок второй сметы направления, той, что рассчитана на две платформы. К нему добавляется время проверок в магазинах, и его мы не обещаем: оно не наше и у каждой площадки своё.
Три случая, когда общий код пришлось переписывать
Без имён и без процентов. Три ситуации, которые мы видели в чужих проектах, когда нас звали чинить. В каждой выбор был сделан правильно по форме и неправильно по существу.
-
Продукт про камеру, а решение принималось про бюджет
Приложение распознавало документы прямо в видоискателе. На общем коде это завелось, но работало с задержкой, и пользователи жаловались не на технологию, а на то, что «плохо ловит». Переписать пришлось не всё приложение, а только работу с камерой — родным модулем внутри общего кода. Мы предлагаем такой путь сразу, когда тяжёлая часть одна и её видно на разборе.
-
Вторую платформу проверили в конце
Разрабатывали и смотрели на одной системе, вторую отложили «на финал». В финале выяснилось, что часть экранов на ней ведёт себя иначе, а уведомления не доходят из-за экономии заряда. Срок вырос заметно, и вырос он там, где его не планировали. Поэтому у нас проверка на обоих парках идёт с первого готового куска, а не после приёмки.
-
Приложение взяли ради экономии, а нужна была одна платформа
Внутренний инструмент для сотрудников с корпоративным парком устройств одной системы. Общий код тут ничего не сэкономил: вторая платформа не использовалась вовсе, зато интерфейс пришлось подгонять под обе, а сборка поддерживала то, чего никто не открывал. Универсальность стоит денег, и платить за неё имеет смысл, только если она нужна.
Общее у трёх случаев: выбор делался до разбора сценария, по общим соображениям про экономию. Разбор занимает полчаса и стоит ноль — а каждый из этих трёх проектов заплатил за пропущенный разговор месяцами.
Условия, при которых мы сами предложим остановиться
Четыре строки, и три из них уводят на более дешёвые или более честные решения. Четвёртая — про момент, когда становится ясно, что подход выбран не тот.
| Когда | Что обнаруживается | Что делаем |
|---|---|---|
| На разборе | Нужна одна платформа, а не обе: корпоративный парк или узкая аудитория | Предлагаем сделать одну или другую и не платить за универсальность. Это меньшая сумма, и мы называем её сами |
| На разборе | Общий код ищут ради дешёвого входа в мобильность, а не ради двух платформ | Объясняем, что магазины, проверки и устройства остаются в двух экземплярах, и показываем этаж ниже: там обе системы закрываются сразу, без публикации |
| На разборе | Сценарий упирается в железо, графику или постоянную фоновую работу | Считаем родную разработку или выносим тяжёлую часть в отдельный модуль внутри общего кода. Говорим это до сметы: переезд в середине проекта — это новый проект |
| В работе | Родных кусков под каждую платформу становится больше, чем общего кода | Останавливаемся и пересобираем решение вместе с вами. Общая кодовая база, наполовину состоящая из платформенных исключений, теряет смысл и при этом сложнее двух отдельных разработок |
Про деньги при остановке — общее для студии и написано на странице оплаты и гарантий. Остановка на разборе не стоит ничего: разбор бесплатный.
От чего зависит цена
Своей сметы у формата нет. Приложение для двух платформ — вторая смета направления, от 300 000 ₽, срок 11–16 недель; приложение с кабинетом и интеграциями — третья, от 500 000 ₽. Разброс внутри задают четыре вещи.
-
Сколько родных кусков придётся дописать
Главный фактор именно этого формата. Пока всё живёт в общем коде, экономия максимальна. Каждый модуль, который приходится писать отдельно под каждую платформу, съедает её кусок: такой модуль делается дважды и проверяется дважды. Сколько их будет, видно на разборе сценария, а не после начала работы.
-
Насколько разные парки устройств у вашей аудитории
Проверка не экономится общим кодом совсем. Если с одной стороны однородный набор устройств, а с другой — массовый и разный, объём проверок складывается. Это та часть сметы, которую чаще всего недооценивают, потому что её не видно в списке функций.
-
Сколько магазинов в списке
Два — минимум для двух платформ. Если к одной из них добавляются дополнительные каналы, каждый приносит свою учётную запись, свою страницу и свою выкладку при каждом обновлении. Это постоянный расход, и считать его надо не в смете разработки, а в сопровождении.
-
Есть ли готовая серверная часть
Она общая при любом выборе — и при общем коде, и при двух родных разработках. Если сайт, бот или Mini App уже работают со своим бэкендом, приложение подключается к нему; если серверной части нет, она входит в объём и становится самой крупной строкой сметы.
Три сметы направления с составом и сроками — на странице мобильных приложений. Сравнений «на сколько дешевле, чем две родные разработки» мы не приводим числом: разница зависит от того, сколько родных кусков придётся дописать, и считается она на вашем сценарии.
Эта страница — один из форматов направления
Здесь написано только про выбор между общим кодом и родным и про экономику двух платформ. Общие правила магазинов, тест «нужно ли вам приложение» и три сметы — на странице направления.
Разбор «нативно или кроссплатформа» одним абзацем есть и на странице направления — там он для тех, кто ещё выбирает между PWA, Mini App и приложением. Здесь то же решение разобрано по статьям расходов. Мобильные приложения
Когда кроссплатформенное приложение вам не нужно
Четыре случая. Первые два означают, что платформа нужна одна; третий — что задача про железо; четвёртый — что приложение вообще не то, с чего стоит начинать.
-
Если пользователи — ваши сотрудники с корпоративным парком
Устройства закуплены одной партией, система у всех одна. Вторая платформа тогда не используется, а платить за универсальность приходится: интерфейс подгоняется под обе, сборка поддерживает то, чего никто не открывает. Выбирайте одну платформу — или посмотрите вариант без установки
-
Если по вашей статистике одна платформа заметно преобладает
Тогда разумный порядок — сделать её первой, проверить на живых людях и добавить вторую, когда первая себя оправдает. Мы это предложим сами: выпустить одну платформу и посмотреть дешевле, чем выпустить обе и узнать, что приложение вообще не нужно.
-
Если продукт строится вокруг железа или графики
Обработка видео, распознавание в реальном времени, игра, редактор, постоянная фоновая работа. Здесь общий код проигрывает, и проигрыш видит пользователь. Считайте родную разработку сразу — или выносите тяжёлую часть в отдельный модуль, что дешевле двух полных разработок.
-
Если задача закрывается без установки вовсе
Нужна иконка на экране и уведомления — это PWA, от 40 000 ₽, и работает она сразу на обеих системах без магазинов. Аудитория живёт в мессенджере — это Mini App, от 50 000 ₽. Оба варианта дешевле, и мы называем их до разговора о приложении, а не после.
Куда идти, если решение другое
Четыре страницы. Первая — если вход в мобильность нужен дешёвый, вторая — если аудитория в мессенджере, третья про дизайн отдельной строкой, четвёртая — если серверной части ещё нет.
Кроссплатформенная разработка: что стоит знать до заказа
Общая кодовая база — разумный выбор по умолчанию для большинства мобильных приложений, и мы делаем так чаще, чем иначе. Но обещание «одно приложение вместо двух — экономия вдвое» верно только наполовину, и вторая половина обнаруживается уже после подписания. Экономится разработка и последующие доработки: код пишется один раз и правится один раз. Не экономится ничего из того, что живёт снаружи кода.
Что остаётся в двух экземплярах
Учётные записи разработчика в двух магазинах. Страницы приложений с описаниями, скриншотами и анкетами о данных — в каждом магазине свои. Публикация и проверка при каждом обновлении — дважды и по правилам каждой площадки. Проверка на устройствах — оба парка целиком, а они очень разные: с одной стороны однородный набор, с другой массовый и пёстрый. И поддержка меняющихся правил площадок, у каждой по своему расписанию.
Практический вывод: чем активнее приложение будет развиваться, тем выгоднее общий код, потому что экономия накапливается на каждой правке. Если приложение выпускается один раз и почти не меняется, разница между подходами меньше, чем принято думать.
Где общий код проигрывает родному
В четырёх местах. Работа с железом на пределе: обработка видео, распознавание в реальном времени, точная работа с датчиками — промежуточный слой мешает. Тяжёлая графика и непрерывная анимация: пользователь увидит не технологию, а подтормаживание. Фоновая работа: обе платформы ограничивают её по-своему, общий код всё равно опускается до родных механизмов, а сложность растёт. И ранний доступ к новым возможностям системы: родной код получает их сразу, общий — когда поддержку добавят в набор инструментов.
Обычные экраны, списки, формы, заявки, каталог, кабинет и уведомления к этому списку не относятся: там разницы с родным кодом пользователь не видит. Именно поэтому общий код и стал выбором по умолчанию.
Почему решение принимается до разработки
Переход с общего кода на родной в середине проекта — это не доработка, а новый проект: переписывается всё, кроме серверной части. Поэтому мы разбираем сценарий до сметы и, если тяжёлая часть одна, предлагаем промежуточный путь — вынести её в отдельный родный модуль внутри общего кода. Это дешевле двух полных разработок и сохраняет экономию на всём остальном.
Сколько стоит приложение для двух платформ
Приложение под две платформы — вторая смета направления мобильной разработки, от 300 000 ₽, срок 11–16 недель. Приложение с личным кабинетом и интеграциями — третья, от 500 000 ₽. Разброс внутри задают четыре вещи: сколько родных кусков придётся дописать, насколько разные парки устройств у вашей аудитории, сколько магазинов в списке и есть ли готовая серверная часть.
Сравнений в процентах — «на сколько дешевле двух родных разработок» — мы не приводим: разница зависит от числа родных модулей и считается на вашем сценарии. Общее правило простое: чем ближе приложение к экранам и данным, тем больше выигрыш; чем ближе к железу, тем он меньше.
Вопросы про общий код
Шесть вопросов, которые задают именно про выбор между общим кодом и родным. Про договор, этапы оплаты и гарантии — на странице оплаты и гарантий.
Остался вопрос?
Написать в Telegram, отвечаем за 30 минутВдвое дешевле становится разработка экранов и логики — и это основная часть работы, так что экономия настоящая. Но публикация, учётные записи, страницы в магазинах, проверки площадок и тестирование на устройствах остаются в двух экземплярах. Поэтому полная смета сокращается не вдвое, а заметно меньше. Мы считаем это построчно на разборе и показываем обе половины: ту, что экономится, и ту, что нет.
В обычных сценариях — нет. Списки, формы, переходы, каталог, кабинет и уведомления работают и выглядят одинаково. Заметит он в двух случаях: если приложение упирается в железо или графику и начинает подтормаживать, и если интерфейс сделан без учёта привычек каждой платформы — системные элементы и жесты там разные, и «чужое» ощущается именно в мелочах. Второе решается на этапе дизайна и входит в работу.
Да, и это самый разумный путь, когда тяжёлая часть одна: работа с камерой, сложная графика, специфическая фоновая задача. Такой модуль пишется отдельно под каждую платформу и подключается к общему коду. Дороже чистого общего кода, но заметно дешевле двух полных разработок. Мы предлагаем это сразу, если видим на разборе, что упор в железо локальный, а не сквозной.
Родной код получает новые возможности системы сразу, общий — когда их поддержку добавят в используемый набор инструментов. В большинстве проектов это не имеет значения: новые возможности платформ редко относятся к спискам и формам. Значение это имеет, если ваш продукт строится вокруг свежей возможности системы — тогда мы скажем об этом на разборе и посчитаем родную разработку.
Любая команда, работающая с тем же набором инструментов, — и таких специалистов на рынке заметно больше, чем связок «разработчик под одну платформу плюс разработчик под другую». Это отдельный довод за общий код, о котором редко думают в начале. Обратная сторона: если у вас уже есть свои разработчики под конкретную платформу, их умения важнее наших предпочтений, и мы это спрашиваем на разборе.
Можно, и на общем коде это проще, чем при родной разработке: вторая платформа получает готовую логику, и остаётся подготовить публикацию и проверить на устройствах. Мы часто сами это предлагаем: выпустить преобладающую платформу, посмотреть на живых людях и добавить вторую, когда первая себя оправдала. Это дешевле, чем выпустить обе и узнать, что приложение не было нужно вовсе.
Опишите сценарий — скажем, хватит ли общего кода и во что обойдутся две полки
- Разбор 30 минут: сценарий, упор в железо, парки устройств и список магазинов
- Посчитаем построчно, что экономится общим кодом, а что остаётся двойным
- Если хватит одной платформы или PWA, услышите это первым и бесплатно
Заявка принята
Вернёмся в течение рабочего дня. Если срочно — напишите в Telegram.
Или напишите сразу:
Telegram · отвечаем лично за 30 минут