Мобильный телефон стал основной платформой для распространения контента для компаний, важным средством доступа к рабочим данным и ключом к выполнению множества транзакций. При разработке мобильных приложений есть два варианта: стать нативным или создать кросс-платформенный. Чем отличаются эти два подхода к мобильной разработке? Какие варианты использования лучше всего подходят для каждого? Давайте выясним.
Все мы в изобилии потребляем контент на наших мобильных телефонах. Но что действительно определяет наш опыт, так это представление контента. В самом деле, все мы знакомы с плавным переходом этих замечательных приложений на наши телефоны, часто чувствуя желание вернуться, чтобы получить еще больше такого удобного использования.
Всего несколько лет назад именно так родные приложения были отделены от кроссплатформенных подражателей - качество последних было просто не лучшим.
Начало кроссплатформенной мобильной разработки было суровым , мягко говоря.
Но когда-то на сцене мобильных операционных систем было много игроков. У вас были Windows, BlackBerry, iOS и Android. Создание доступных приложений, которые могли бы работать на всех платформах, было оправданным.
Потребность в более широком охвате привела к компромиссу в отношении низкой производительности, плохого удобства использования и частых сбоев для малых предприятий, которым приходилось платить за гибридные приложения. Кросс-платформенные инструменты и фреймворки для мобильной разработки были незрелыми и не совсем готовыми к производству .
В 2015 году все стало меняться. Во-первых, на сцену вышел React Native , придавая приложениям, созданным с его помощью, видимость нативности (React Native привязывается к собственным компонентам пользовательского интерфейса). Затем, в 2018 году, Google выпустил Flutter , который позволил разработчикам создавать нативные приложения.
Тем не менее, обе технологии не смогли превзойти нативные приложения ни с точки зрения производительности, ни с точки зрения удобства использования. Кроме того, им не хватало зрелости, необходимой для долгоживущих проектов, требующих постоянной поддержки и обслуживания.
Перенесемся в 2020 год. Технологии кроссплатформенной разработки процветали и теперь достаточно зрелы, чтобы производить высококачественное потомство. И хотя все еще есть случаи, когда собственные приложения превосходят гибридные (о чем мы поговорим ниже), разница между ними перестала быть такой резкой.
Хотя в настоящее время существует довольно много достойных кроссплатформенных инструментов мобильной разработки (Cordova, Ionic, NativeScript или Xamarin), мы сосредоточимся здесь только на двух - React Native и Flutter .
Без лишних слов, давайте начнем сравнение с краткого обзора того, что происходит в мире гибридной и нативной мобильной разработки.
Родные приложения написаны на языках программирования и комплекты разработчика (SDK) , поставляемые поставщиками операционных систем (ОС) они работают на:
Android - Java или Kotlin
IOS , - Objective-C или Swift
Гибридные приложения написаны на языках программирования и средства разработки , предлагаемые компаниями беспартийным с оператором мобильной платформы. Их также обычно называют кроссплатформенными приложениями.
Flutter - Дарт
React Native - JavaScript
Нативные приложения выполняются без предварительной интерпретации кода, что приводит к быстрым приложениям со знакомым внешним видом.
Гибридные приложения можно разделить на две категории:
Гибридные веб- приложения написаны на комбинации HTML / CSS / JS и выполняются как веб-сайт в оболочке мобильного приложения. Это верно для приложений Ionic и Cordova.
Гибридные собственные приложения выполняются изначально во время выполнения, то есть они отображают собственные элементы пользовательского интерфейса (React Native) или рисуют свои собственные элементы пользовательского интерфейса (Flutter).
У каждого типа приложения своя целевая аудитория и разные требования, которые необходимо детально проанализировать, чтобы принять обоснованное решение о том, какой подход к мобильной разработке выбрать. Используйте приведенное ниже руководство, чтобы определить, какой технический стек лучше для вашего мобильного приложения.
Основное внимание, которое владельцы бизнеса обычно уделяют разработке мобильных приложений, - это стоимость .
Разработка собственного приложения для iOS и Android по сути равносильна созданию двух отдельных приложений, поддерживаемых двумя отдельными группами разработчиков. Естественно, это может оказаться дорогостоящим мероприятием.
В гибридных приложениях код приложения разрабатывается одной командой. Это не означает, что стоимость разработки гибридных приложений сокращается вдвое по сравнению с нативным подходом, но наличие единой кодовой базы и одной команды разработчиков, безусловно, снижает стоимость . Но есть нюанс.
В сложных приложениях вы должны использовать мосты и плагины, чтобы получить доступ к специфическим для платформы функциям - они должны быть написаны в машинном коде, что требует от разработчиков, которые имеют существенные знания о любой из платформ.
Сложность приложения является одним из ключевых факторов, определяющих при выборе между нативной и кроссплатформенной разработкой.
Хороший способ определить сложность приложения - это подсчитать количество функций, фреймворков и SDK, включенных в приложение - или, другими словами, чем больше приложение зависит от аппаратного обеспечения устройства или функций ОС (Bluetooth, GPS, гироскоп, акселерометр, обмен файлами и т. д.), тем он сложнее . Сложность приложения - это не количество экранов - приложение с 200 экранами может мало зависеть от ресурсов устройства и ОС.
Интеграция платформы упрощается при использовании собственных SDK . Фактически, кроссплатформенная мобильная разработка может привести к дополнительным затратам и потенциальным накладным расходам в виде разработки мостов / подключаемых модулей, которые интегрируются с особенностями платформы и устройства.
Сокращение времени вывода на рынок - одна из основных целей для компаний, желающих выпустить приложение. Одновременная разработка двух нативных приложений потребует значительных ресурсов и большой команды разработчиков.
Благодаря кроссплатформенной мобильной разработке время вывода продукта на рынок сокращается, поскольку код можно повторно использовать на разных платформах. Хотя количество повторного использования кода зависит от проекта, нередко повторное использование до 90% кода . Код также может быть передан веб-версии приложения, особенно бизнес-логике.
Когда много кода используется повторно, вы можете получить унифицированное приложение, которое не использует специфичные для платформы функции.
Плавный пользовательский интерфейс и плавные переходы пользовательского интерфейса - важнейшие характеристики хороших приложений, характеристики, которые должны оставаться неизменными даже во время обработки тяжелых данных . Нативные инструменты мобильной разработки предлагают решения, которые делегируют операции обработки данных отдельным потокам, обеспечивая удобство работы пользователей.
Раньше гибридные веб-приложения выполняли множество операций одновременно в одном потоке, из-за чего пользовательский интерфейс плохо реагировал. Однако в настоящее время существуют решения, позволяющие гибридным веб-приложениям делегировать процессы фоновым потокам, что освобождает ресурсы. Однако производительность приложения при таком подходе все равно снижается.
Но это не относится к гибридным нативным приложениям, созданным на React Native или Flutter, которые подходят к делу иначе.
Flutter - отображает элементы пользовательского интерфейса с помощью высокопроизводительного движка, который обеспечивает производительность на уровне приложений, разработанных в собственном коде.
Реагировать Native - используется специальный механизм , который выполняет код JavaScript для собственных элементов пользовательского интерфейса, что позволяет операции интерфейса работает независимо от кода JavaScript.
В нативных приложениях, когда выходит новая версия ОС, язык и инструменты поддерживаются мгновенно, автоматически принимая новые функции.
При кросс-платформенной разработке может возникнуть задержка с введением поддержки новых функций для гибридных инструментов и фреймворков. Более того, чтобы отразить изменения, реализованные в новой версии ОС, вам может потребоваться изменить код гибридного приложения - в противном случае, особенно если изменения будут значительными, ваше приложение может некорректно работать с новой ОС.
Срок службы мобильного приложения значительно короче, чем у многих программных решений. Но мы можем с уверенностью предположить, что три года - это приличный срок службы мобильного приложения, прежде чем его потребуется переписать.
Имея это в виду и в зависимости от типа мобильного приложения, выбор нативного стека обычно предпочтительнее для приложений, которые должны оставаться на рынке дольше (то есть более трех лет).
Но если вы создаете недолговечное приложение (например, маркетинговое приложение для поддержки разового мероприятия), выберите кроссплатформенную разработку - будет дешевле и быстрее разработать приложение с хорошей производительностью .
Мобильный мир - это динамичная среда. Мобильные решения, которые когда-то были широко популярны, практически исчезли с рынка (например, BlackBerry или Windows Mobile).
Вот почему важно учитывать время жизни вашего приложения, думая о нативной или кросс-платформенной разработке. Эмпирическое правило заключается в том, что чем дольше срок службы, тем больше он полагается на стабильные технологии с долгосрочным планом обновления.
Собственные технические пакеты предлагают множество инструментов и руководств, которые упрощают переход на новую версию. Кроме того, поскольку на рынке мобильных устройств правят iOS и Android, мы можем с уверенностью предположить, что эти платформы будут поддерживаться годами.
Немного по-другому обстоит дело с кроссплатформенными инструментами, которым может не хватать графика долгосрочного обновления. И хотя Flutter и React Native достигли уровня стабильности и зрелости, достойного доверия, и создали вокруг себя значительные сообщества, официальные разработчики когда-нибудь в будущем могут отказаться от обеих технологий. Это сопряжено с риском того, что вам придется серьезно переписать приложение через несколько лет после его выпуска.
После выпуска вашего приложения вам необходимо рассмотреть возможность обслуживания приложения и итерацию новых функций .
Кодовая база для гибридного приложения используется на двух платформах. Поэтому устранять ошибки и разрабатывать новые функции проще, потому что у команды есть только один код для работы.
Выбор зависит от тщательного анализа и проверки вашего бюджета, функций приложения, аудитории и сложности приложения. Всегда консультируйтесь при разработке продукта с опытными разработчиками, которые помогут вам решить, какой подход лучше всего подходит для вашего приложения.
Что нужно помнить:
Собственная разработка дает вам доступ к долгосрочному пути обновления, поддержке инструментов и отличной производительности приложений . Единственными недостатками нативной разработки могут быть ее стоимость и необходимость иметь две команды для поддержки приложения после выпуска.
Кросс-платформенная мобильная разработка - это экономичный подход к созданию надежных и высокопроизводительных приложений . Несмотря на то, что возможны некоторые компромиссы с интеграцией функций, специфичных для платформы, и новыми обновлениями функций ОС, текущие гибридные инструменты мобильной разработки способны предоставлять собственные возможности.