Кросс-платформа VS iOS и Android: что подойдет вашей компании

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

Ключевые критерии выбора

Для начала остановимся на ключевых критериях выбора.

1. Стоимость и cроки разработки

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

Для некоторых стартапов критически важно как можно быстрее протестировать идею и получить финансирование. В таких случаях компании прибегают к смеси no-code и кросс-платформы - например, Flutter Flow. Такие инструменты позволяют создать кросс-плафторменный прототип, не имея команды разработки. Конечно, результат лимитирован возможностями no-code платформ, поэтому не стоит выбирать такие решения для масштабных и долгосрочных проектов.

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

Возможно ваша компания нацелена на рынок США. В таком случае многие стартапы сначала делают приложение только на iOS и в дальнейшем не спешат выпускать приложение на других платформах. Тогда вам вполне подойдёт нативная разработка.

2. Производительность и доступность функциональности

Производительность — это та область, где нативные приложения часто превосходят кросс-платформенные. Они лучше оптимизированы для конкретных устройств, что обеспечивает более высокую скорость работы и стабильность. Нативные приложения также предоставляют удобный доступ к API и функциональности устройств, что особенно важно для приложений, использующих сложные взаимодействия с аппаратным обеспечением, такие как AR, VR или интенсивная графика. Кросс-платформенные решения могут испытывать задержки и ограничения в доступе к новым функциям ОС.

3. Масштабируемость и последующие обновления

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

Некоторые компании не хотят зависеть от маркетплейсов, таких как Play Market или App Store, из-за неудобств работы с ними. Медленное ревью приложений, много правил, затянутый процесс между разработкой новой фичи и ее доставкой до пользователя. Поэтому если вы хотите предоставить пользователю доступ к вашему приложению, обходя маркетплейсы, можно воспользоваться PWA (Progressive Web Applications). По сути это веб сайт, который можно установить на вашу систему и пользоваться им как обычным приложением. Это молодая технология, поэтому могут возникать проблемы при взаимодействии с устройством. Но если ваша задача, к примеру, сделать магазин товаров более удобным для доступа с телефона, то можно использовать PWA, не привлекая большую команду мобильных разработчиков. 

Опыт компаний

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

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

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

Один из самых известных провалов использования кросс-платформы был подробно описан в статье компании Airbnb. Автор обращает внимание, что описывает состояние технологии на 2017 год, и что для каждой компании могут подойти разные технологии в зависимости от задач и размера компании. Airbnb использовал React Native для улучшения качества своего продукта. Хотя в конечном итоге компания отказалась от React Native из-за уникальных бизнес- и технических вызовов, опыт работы с React Native оказался ценным, так как многие разработанные лучшие практики и инструменты были перенесены в нативные приложения. 

Facebook использовал React Native для создания приложения Facebook Ads Manager. Большая часть кода уже была написана на JavaScript, поэтому выбор был очевиден. Такое решение позволило достичь единого внешнего вида на обеих платформах, уменьшить количество ошибок, связанных с разными платформами, и ускорить процесс разработки.

Instagram интегрировал React Native в существующее приложение для обработки push-уведомлений. Благодаря этому удалось сократить команду, необходимую для разработки и поддержки приложения, и увеличить скорость разработки новых функций.

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

Microsoft использует React Native для разработки Office Suite (Word, Excel, PowerPoint, Outlook) для мобильных устройств, чем демонстрирует потенциал фреймворка для работы со сложными, насыщенными данными приложениями и обеспечения стабильной производительности на разных устройствах и ОС.

Изначально разработанный только для iOS, SoundCloud Pulse перешел на React Native для разработки своего приложения для Android, успешно создав его силами небольшой команды уже имеющихся javascript разработчиков.

Alibaba использовала Flutter для создания Xianyu, крупнейшего маркетплейса подержанных товаров в Китае. Flutter был выбран за высокую производительность и существенный рост в скорости разработки, что было критически важно для маркетплейса.

Reflectly перешла с React Native на Flutter для создания своего AI персонального дневника, который быстро стал популярным благодаря своему минималистичному дизайну и богатому функционалу. По словам CTO было рискованно переводить 500 000 пользователей на новую технологию, но они довольны результатом.

BMW выбрали Flutter для расширения своей продуктовой разработки в мобильном секторе, быстро развернув более десятка версий приложения MyBMW с сотней различных функций. Также BMW обладают второй по размеру командой Flutter после Google.

Команда Surf создала первое банковское приложение на Flutter в России для Росбанка. У банка уже было приложение, но клиенты не пользовались им активно, а также скорость и стоимость разработки не устраивала банк, поэтому было принято решение перейти на более масштабируемое решение в виде кросс-платформы. 

Преимущества и недостатки кросс-платформенного подхода

Использование кросс-платформы позволяет сократить стоимость разработки на 30-40% и время разработки в два раза, поскольку требуется только одна команда разработчиков, а не отдельные команды для iOS и Android. Кросс-платформенные приложения обеспечивают схожий опыт для пользователей на разных устройствах, позволяя охватить более широкую аудиторию без необходимости выбора между iOS и Android. Такие решения позволяют выпускать обновления быстрее и одновременно на обе платформы, ускоряя процесс разработки и улучшения функционала.

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

Что выбрать?

Можно сказать, что на данном этапе развития кросс-платформ, они подойдут большинству бизнесов. Точно не стоит использовать кросс-платформу для разработки мобильных игр, потому что кросс-платформенные технологии пока еще либо не имеют поддержку 3D, либо только развивают ее на ранней стадии.

Также, стоит подумать, прежде чем брать кросс-платформу, если ваше приложение требует использования нестандартных возможностей устройства. Например, приложение для стриминга видео будет тяжело тонко настроить для работы в фоне, в свернутом виде, с выключенным экраном. Но если у вас есть возможность нанять очень опытных разработчиков, то можно попробовать, как, например, сделала команда Surf с приложением The Hole.

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

Если боитесь погружаться сразу в кросс-платформу и, вдобавок, у вас уже есть две нативные команды разработчиков, которых не хочется заставлять переходить на новую технологию, можно воспользоваться частичной кросс-платформой, используя Kotlin Multiplatform.

Эта технология позволяет объединить код с бизнес-логикой с разных платформ, оставив нативную часть у каждой платформы для обработки UI. Тем самым мы используем нативные решения со всеми их преимуществами, но также облегчаем и ускоряем разработку путём объединения значительной части кода. Единственный минус: iOS разработчикам нужно будет изучить Kotlin, но он похож на Swift.

Будущее мобильной разработки

Возникает закономерный вопрос - какое будущее нас ждет в области мобильной разработки? Можно ли ожидать, что кросс-платформы захватят умы всех заказчиков и разработчиков без исключения?

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

Что касается полных кросс-платформенных решений, они прочно займут значительный объём рынка, ведь большинство приложений на рынке не использует мощности устройств на полную.