Один код для iOS и Android: что важно знать

Для большинства бизнесов приложение, работающее только на одной платформе, это лишь половина приложения. Ваши клиенты носят iPhone и Android примерно поровну, и просить половину из них подождать или строить два отдельных нативных приложения с нуля редко бывает разумной тратой бюджета. Именно поэтому создание одного кода для iOS и Android на React Native и Expo стало отправной точкой по умолчанию для многих основателей, и именно поэтому это обычно стоит намного дешевле двух нативных сборок. Настоящий вопрос редко в том, идти ли в кроссплатформу, а в том, какая часть вашего конкретного продукта может безопасно жить в общем коде.

Как работает общий код

React Native позволяет писать приложение на JavaScript и TypeScript, используя компоненты, которые под капотом отображаются в настоящие нативные элементы интерфейса. Вместо рисования поддельных кнопок он отрисовывает настоящие элементы управления iOS и Android, поэтому приложение ощущается нативным, а не как сайт в оболочке. Expo надстраивается сверху и берет на себя большую часть рутинной настройки: сборочные пайплайны, обновления по воздуху и доступ к функциям устройства вроде камеры или пуш-уведомлений через готовые модули. Что важно, весь код держится на одном языке и одной цепочке инструментов, поэтому инженер, собравший экран для iPhone, фактически собрал его для Android тем же движением. Для основателя это значит, что бюджет уходит в функции продукта, а не в двойную оплату одной и той же обвязки, и каждый нанятый инженер сразу вносит вклад в обе платформы одновременно.

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

Что можно переиспользовать и что вы экономите

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

• Бизнес-логика и работа с данными пишутся один раз.
• Экраны и навигация общие для обеих платформ.
• Исправления и новые функции доходят до iOS и Android одновременно.
• Одна команда и один набор навыков вместо двух параллельных усилий.

Сколько стоит один код против двух нативных сборок

Конкретные цифры делают довод яснее. В AXYL Studio кроссплатформенное мобильное приложение сразу под iOS и Android обычно стоит примерно от 12000 € до 24000 €, а по уровням это около 12000 € за MVP, 25000 € за приложение производственного уровня и 45000 € за сложную сборку. Два отдельных нативных приложения, напротив, означают, что большую часть этой работы придется писать и поддерживать дважды, что приближает совокупный бюджет к двойному при сопоставимом результате. Общий код не делает все вдвое дешевле, но убирает крупнейший источник дублирующихся усилий и избавляет от того, чтобы каждую будущую функцию оценивать дважды. Если ваша идея еще не проверена, старт с уровня MVP позволяет проверить спрос сразу на обеих платформах, прежде чем брать на себя больший производственный бюджет. Поскольку один и тот же код обслуживает оба магазина, последующий переход от MVP к production обновляет один проект, а не два, и второй счет остается меньше, чем была бы нативная сборка с нуля.

Когда все же нужна работа под конкретную платформу

Переиспользование не значит, что все одинаково, и делать вид, что это так, ведет к приложению, которое ощущается неуместным. Некоторые ситуации действительно требуют внимания к конкретной платформе. У двух операционных систем разные принципы дизайна, и их соблюдение делает приложение уместным, а не чужеродным. Глубокие интеграции, такие как отдельные платежные сценарии, фоновая обработка или специализированное оборудование, иногда требуют нативного кода под каждую сторону. Expo покрывает большинство задач из коробки, но когда вам его становится мало, React Native все же позволяет спуститься до нативных модулей там, где это нужно, поэтому вы редко платите за полную нативную переписку. Цель не в том, чтобы делить ради самого деления, а в том, чтобы делить все, чего клиент не видит, и тратить нативные усилия только там, где это заметно улучшает опыт. На практике большинство команд держат этот нативный список коротким и четко определенным, поэтому редкий уход в специфику платформы никогда не подрывает экономию, которую дает единый код.

Комиссии магазинов и платежей, которые стоит заложить

Сборка не единственная статья расходов при выпуске мобильного продукта, и эти комиссии одинаково касаются нативных и кроссплатформенных приложений. Если ваше приложение продает цифровые товары или подписки, Apple и Google берут комиссию с покупок внутри приложения, обычно от 15 до 30 процентов, причем сниженная ставка 15 процентов доступна в их программах для малого бизнеса. Если вы принимаете оплату за физические товары или услуги картами, Stripe берет около 1,5 процента плюс 0,25 € за транзакцию по европейским картам. Ничто из этого не меняется от того, что вы выбрали один код, но это должно быть в плане с самого начала. Моделирование этих процентов относительно ожидаемой выручки часто важнее для ваших маржей, чем разовая цена сборки, особенно для приложения по подписке, где комиссия повторяется каждый месяц.

• Apple App Store и Google Play: от 15 до 30 процентов с покупок внутри приложения и подписок.
• Сниженная ставка 15 процентов действует в программах для малого бизнеса Apple и Google.
• Stripe: примерно 1,5 процента плюс 0,25 € за транзакцию по европейским картам.
• Эти комиссии одинаковы, строите ли вы натив или кроссплатформу.

Выигрыш в поддержке

Самая большая долгосрочная выгода тише, чем сам запуск. Любому приложению годами нужны обновления, патчи безопасности и небольшие улучшения, и с общим кодом эта постоянная работа сокращается примерно вдвое, релизы остаются синхронными, а ваш продукт не расползается медленно на две расходящиеся версии. Постоянная поддержка обычно начинается примерно от 2500 € в месяц, и поскольку эта работа не дублируется на два нативных приложения, абонемента хватает дольше. На горизонте двух лет такое вдвое меньшее обслуживание нередко экономит больше, чем сам разрыв между MVP и производственной сборкой. Для команд без большого инженерного бюджета такая предсказуемость нередко ценнее любой отдельной функции. Накопленное за весь срок жизни приложения, это ровное и недублируемое сопровождение и есть то, где единый код тихо окупает себя, спустя долгое время после того, как отгремели заголовки о запуске.

Если вы взвешиваете, подходит ли кроссплатформенность вашему продукту, мы будем рады рассмотреть ваш случай. В AXYL Studio мы каждый день собираем мобильные приложения на React Native и Expo и можем дать честную оценку, уровень за уровнем, того, что один код будет означать для ваших сроков и бюджета.