Нативный интерфейс. Обзор кросс-платформенных решений для разработки мобильных приложений

03.03.2020 Операционные системы

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

Вы знаете что такое нативное приложение?

Для пользователя нативными являются приложения, которые требуют установки. В целом, это верно, как и то, что такие приложения разрабатываются специально под мобильные платформы (iOS, Android, Windows Phone). Поэтому от разработчика требуются навыки программирования в конкретной среде разработки (xCode для iOS, eclipse для Android).

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

Веб-приложения отличаются от нативного приложения

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

Но что же тогда нативное приложение по сравнению с мобильным сайтом? Грань между веб-приложением и мобильным сайтом очень тонка. И в этом вопросе путаются не то что пользователи, но в некоторых случаях – и сами разработчики. А разница есть. Говоря условно, сайт содержит более или менее статичную информацию, и представляет собой нечто вроде цифровой брошюры. В веб-приложении пользователь может управлять какой-то частью этой информации – создать собственные страницы, менять местами ссылки, тексты и пр.

Так что проще веб-приложениями называть все, что принято называть онлайн-сервисами. Веб-приложением может называться еще и то, что когда-то делалось на флэше, а теперь – на HTML5.

Гибридные приложения

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

Что выбрать? нативное приложение, гибридное или веб?

Разработка гибридного приложения дешевле и быстрее, чем создать нативное приложение. А пользователи разницы все равно не заметят. Поэтому гибридные технологии наиболее популярны. Несмотря на всю эту многосложность определиться с выбором технологии для разработки приложения очень просто. Если ваше приложение никак не может работать без нативных функций мобильных устройств, если очень важна высокая скорость обработки данных (игры, соцсети, геолокация), то лучше чем нативное приложение ничего не найти. Когда скоростью работы можно пренебречь, подойдет гибридное приложение. Веб-приложение стоит делать, когда пользователю от вас не нужно ничего, кроме информации, которую он мог бы получить с телефона при наличии интернета.

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

В прошлый раз мы касались кроссплатформенной мобильной разработки и с тех пор многое изменилось. Настала пора поговорить о методах и инструментах снова.

Давайте для начала пройдемся ещё раз по терминологии.

Родные

Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то Objective-C и Swift для iOS или , такое приложение будет называться нативным (от англ. native — родной, естественный).

Преимущества нативных приложений:

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

Недостаток один — дороговизна разработки и поддержки. Для каждой платформы надо писать свой код. С ростом рынка мобильных приложений разработчики стали не просто дороги, а очень дороги.

И не родные

Кроссплатформенные приложения пишутся сразу для нескольких платформ на одном языке, отличном от нативного. Как такой код может работать на разных устройствах? Тут тоже есть два подхода.

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

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

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

Преимущества:

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

Недостатки:

неродной интерфейс или, как минимум, необходимость работы с интерфейсом каждой платформы отдельно. У каждой системы свои требования к дизайну элементов и иногда они взаимоисключающи. При разработке это необходимо учитывать;
проблемы в реализации сложных функций или возможные проблемы работы даже с простыми процедурами в силу ошибок самих фреймворков разработки. Кроссплатформенная среда лишь транслирует запросы к системным вызовам и интерфейсам в понимаемый ею, системой, формат, и потому на этом этапе возможны как сложности с пониманием, так и возникновение ошибок внутри самого фреймворка;
скорость работы. Так как кроссплатформенная среда является «надстройкой» над кодом (не всегда, но в определённых ситуациях), в ней возникают свои задержки и паузы в отработке действий пользователя и выводе на экран результатов. Это было особенно заметно несколько лет назад на смартфонах, более маломощных относительно сегодняшних, однако сейчас, с ростом производительности мобильных устройств, этим уже можно пренебречь.

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

Что выбрать

У вас уже наверняка пошла голова кругом, а понимания что выбрать, так и не появилось. Давайте представим простой список вопросов, который вам поможет:

должно хоть как-то работать на любом устройстве? Выбирайте HTML как основу;
у вас достаточно средств, нет спешки и вы хотите самое качественное приложение? Вам прямой путь в нативную разработку ;
у вас есть «встроенный» веб-разработчик или вы просто хотите быстро и просто попробовать мобильное приложение в деле? Тут можно рекомендовать Cordova/HTML или PWA ;
у вас есть собственная CRM-система и поддерживающий ее C#-разработчик? Берите Xamarin ;
вы «хотите попробовать», но надо сделать всё красиво и модно? Смотрите в сторону React Native или Flutter .

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

простое приложение-визитка? Возьмите React Native или HTML5 и вы получите две платформы за минимальную цену;
у вас есть сайт с большой посещаемостью и вам нужно протестировать гипотезу присутствия в мобильном пространстве? HTML5 ;
сложные приложения с доступом к нужным функциям устройств? Нативная разработка, Xamarin, React Native .

Кроссплатформенная разработка — не панацея

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

У вас остались сомнения и вопросы о кроссплатформенных приложениях? Почитайте о том, как мы создавали приложение для быстрого получения абонемента в одно из спортивных заведений города и попробуйте приложение для оплаты всевозможных видов услуг — от ЖКХ до заказов в интернет-магазинах. А лучше запишитесь на бесплатную консультацию, с указанием примерного бюджета и кратким описанием идеи или свяжитесь с нашим менеджером Катей по телефону

Сегодня предлагаем разобраться, чем приложение, созданное в конструкторе, отличается от того, которое вам разработают в студии.

Нативные приложения рассчитаны на параметры и свойства конкретной платформы (мобильной ОС, связанной с нею экосистемы и технических характеристик самого мобильного устройства) и задействует все возможности аппаратной платформы, которые нужны для работы с приложением - от камеры и модуля GPS до акселерометра, управлением жестами и других аппаратно поддерживаемых свойств конкретного смартфона или планшета. Кроме того, нативное приложение, раработанное в студии, можно получить как готовый продукт и разместить его в магазине мобильных приложений (таком как Google Play или Apple App Store).

Нативное приложение также использует систему уведомлений каждого конкретного устройства, поддерживает Push-уведомления и может работать в оффлайн-режиме.

А что создает большинство онлайн-конструкторов?

Мы опубликовали , но его скорее можно назвать списком пробных инструментов (чтобы посмотреть, как приложение будет выглядеть «в жизни»), а не полноценным решением для тех, кто хочет создать приложение с нуля.

В онлайн-конструкторе создается не нативное, а веб-приложение , которое не является программным продуктом в классическом смысле, по сути это - специальный веб-сайт, которые выглядит и действует как нативное приложение, но по сути таковым не является. Как правило для его работы нужен установленный и настроенный браузер мобильного устройства с выходом в интернет. Самое веб-приложение создано на основе использования HTML5. Отчасти это и объясняет растущую популярность веб-приложений (а также тот факт, что новая мобильная ОС Tizen от Samsung и некоторые модификации Android используют веб-приложения с этой технологией).

Такое веб-приложение подходит не всем проектам (в частности, если СМИ и новостные проекты с блогами могут довольствоваться возможностями HTML5, то для интернет-магазинов и высоконагруженных сайтов подобное решение не подходит).

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

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

Компании часто «клюют» на привлекательность и доступность гибридных приложений как в плане цены, так и в плане скорости разработки (подкупает и возможность соорудить подобное приложение в конструкторе для нескольких платформ одновременно).

Но и здесь есть свои недостатки, которые как правило заметны в дизайне приложений: нативные «фишки» одной платформы могут оказаться некорректно работающими на другой и наоборот. В итоге получается, что даже гибридное приложение не лишено недостатков web-app.

Что стоит выбрать?

У каждого типа приложений есть свои преимущества и недостатки, приведем только наиболее существенные:

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

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

Возможность поиска информации и самого приложения: С поиском по контенту лучше справляются веб-приложения, но если у вас планируется поиск по содержимому приложения без доступа в интернет - то придется делать либо гибридное приложение, либо нативное.

Скорость работы: Быстрее всего работают нативные приложения. В 2012 году Марк Цукерберг заявил, что наибольшей ошибкой его социальной сети стал запуск веб-приложения, а не разработка нативного решения (до того времени Facebook использовал гибридное приложение, где основная часть контента была доступна только при подключении к интернету и основывалась на HTML; с 2012 года его заменили на нативное). Всё дело в скорости отклика .

Процесс установки: Если нативное и гибридное приложения надо устанавливать на свое устройство и давать разрешение на доступ к определенным компонентам программной и аппаратной платформы, то веб-приложение по сути «устанавливается» простым добавлением закладки в мобильный браузер.

Управление приложением и его обслуживание: Нативное приложение после каждого обновления надо повторно размещать в магазине приложений, в тов время как в веб-приложении по сути обновляется страница и контент, «упакованный» в виде своеобразного мобильного сайта.

Привязка к конкретной платформе: Поскольку разные браузеры могут поддерживать разные версии HTML5 независимо от типа аппаратной платформы или установленной мобильной ОС, то для тех, кто хочет «отвязаться» от платформы, выбором станут веб-приложения или гибридные приложения. Если отдельная разработка под каждую отдельную платформу вас не пугает, то можете сделать ставку на нативное приложение.

Работа с контентом, процедура добавления в магазин приложений и дополнительные платежи: Нативные и гибридные приложения проходят специальную процедуру утверждения после добавления их в магазин приложений. Кроме того, на них могут накладываться определенные ограничения в силу правил и внутренней политики App Store и Google Play (особенно если речь идет о «взрослом» контенте, азартных играх, тематике алкоголя или подобных темах).

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

Стоимость разработки: С одной стороны, разработка веб-приложений и гибридных решений стоит на порядо дешевле (к тому же, элементарные версии таких приложений можно вообще создать в конструкторе бесплатно или со значительной скидкой). С другой стороны, даже для создания веб-приложения или гибридного приложения нужно обладать более-менее сносными навыками разработки, а число ограничений по возможностям использования аппаратной платформы ставят под вопрос целесообразность «экономии».

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

Хотите заказать нативное приложение? Отправляйте заявку с темой «Разработка приложения» на наш email - и мы свяжемся с вами в течение 24 часов и уточним всем детали для дальнейшего обсуждения.

Смартфоны продолжают отвоевывать все больше места под солнцем не только как инструмент потребления фотографий котиков и ххх-роликов, но и в качестве рабочего инструмента. Поэтому и спрос на мобильную разработку растет. Принято считать, что тру и кул - это Objective-C/Swift для iOS и Java/Kotlin для Android. Спору нет, тру и кул, но существует большое количество реальных сценариев, в которых использование кросс-платформенных фреймворков более предпочтительно в сравнении с нативными инструментами.

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

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

Зачем нужны кросс-платформенные инструменты?

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

Нативные инструменты = предоставляются владельцем экосистемы.

Все остальные признаки «нативности» ВТОРИЧНЫ - поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.

К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.

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

Для того чтобы решить обе эти проблемы, на рынке уже давно появились инструменты кросс-платформенной разработки (не только mobile), предлагающие:

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

Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt .

Теперь можно поговорить и о мифах.

Миф 1. Магия

Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.

Главный принцип, лежащий в основе кросс-платформенных решений, - разделение кода на две части:

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

Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный мост (bridge) , именно он и определяет возможности и ограничения кросс-платформенных фреймворков.

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

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

Миф 2. Ненативно!

Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.

Все операционные системы: iOS, Android и Windows UWP - предоставляют доступ к следующим подсистемам (наборы системных API):

WebView (встроенный в приложение веб-браузер) используется в гибридных приложениях на базе PhoneGap и фактически выступает средой выполнения локального веб-сайта;
JavaScript-движки используются в React Native и аналогах для быстрого выполнения JS-кода и обмена данными между Native и JS;
OpenGL ES (или DirectX) используется в игровых движках и приложениях на Qt/QML или аналогах для отрисовки интерфейса;
UI-подсистема отвечает за нативный пользовательский интерфейс приложения, что актуально для React Native и Xamarin.

Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:

WebView - приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.

JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.

OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.

Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос - как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.

Если резюмировать - то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.

Миф 3. Костыль на костыле

Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно - взрослые зрелые решения с длительной историей.

Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.

Начнем мы с PhoneGap. Ниже представлена верхнеуровневая архитектура приложения на базе этого фреймворка.

Приложение на PhoneGap - это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части - просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.

При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок - это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.

Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.

Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) - это надстройка над ними.

Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма P/Invoke . Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.

И в завершение рассмотрим Qt, так как о нем появляется много вопросов от опытных разработчиков.

Qt - «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.

Подведем итог: все кросс-платформенные фреймворки используют стандартные нативные возможности операционных систем, являются зрелыми, создаются опытными командами и сообществом open source при поддержке гигантов IT-индустрии. И наконец, пришло время для самого «сильного» аргумента.

Миф 4. Медленно

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

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

PhoneGap: HTML/JS и Native Java / Objective-C / C#;
React Native: JS и Native Java / Objective-C / C#;
Xamarin: Mono и Native Java / Objective-C;
Qt: С++ и Native Java / Objective-C.

Таким образом, при сравнении производительности надо учитывать скорость работы:

кросс-платформенной части;
нативной части;
моста.

Если набрать в поисковике, например, react native vs swift performance, то можно посмотреть множество различных тестов, и во многих из них отмечается, что производительность резко падает при активном использовании моста, включая активное манипулирование UI из кросс-платформенного кода. Для Xamarin ситуация выглядит таким же образом - кросс-платформенная часть очень быстра и сопоставима с нативной в обработке данных, однако при использовании моста может падать производительность. Qt вообще работает на уровне С++, который быстр сам по себе. Если же рассматривать решения на базе PhoneGap, то здесь производительность будет сильно зависеть от WebView, но все же не следует активно менять UI в JavaScript-коде или проводить научные вычисления.

Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.

*В этой статье мы рассматриваем гибридные приложения на основе веб-браузера.

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

Интересно! Согласно статистике от Flurry Analytics 90% всего времени за телефоном мы проводим именно в приложениях.

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

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

ГИБРИДНЫЕ И НАТИВНЫЕ ПРИЛОЖЕНИЯ

Итак, чем же отличаются эти два типа приложений друг от друга?

Нативное приложение является родным для каждой платформы, будь то iOS или Android, и пишется специально для него на определенном языке.

Для написания нативного приложения для iOS будет использоваться Swift или Objective-C. Для нативных Android приложений подойдут Java или Kotlin.

Однако согласно статистике от VisionMobile, 47% всех нативных iOS приложений и 42% всех нативных Android приложений на самом деле также используют HTML5.

А вот и пример нативного приложения:

Известное во всем мире приложение для электронной торговли Bounce было написано нашими разработчиками на языках Swift для iOS и Java для Android.

Приложение доступно в Apple Store и Google Play .

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

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

Приложение доступно в Apple Store и Google Play .

Давайте рассмотрим поближе каждый из типов и узнаем их самые сокровенные тайны. А начнем, пожалуй, с двуликих гибридных приложений.

ПЛЮСЫ ГИБРИДНЫХ ПРИЛОЖЕНИЙ

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

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

МИНУСЫ ГИБРИДНЫХ ПРИЛОЖЕНИЙ

Непрактичность . Даже хорошо проработанное гибридное приложение может быстро устареть. Прогресс не стоит на месте, и владельцы приложений стараются шагать в ногу с ним. Как только появляются новые технологии, каждый из владельцев старается как можно скорее добавить диковинную функцию и в свое приложение. К несчастью гибридов, потребуется от 3 до 6 месяцев, чтобы изменить фреймворк и добавить в него новый функционал. Только после этого разработчики смогут усовершенствовать и ваше приложение тоже. В нативных же приложениях нововведения можно добавлять сразу после их анонсирования.

Маловероятно, что наше приложение будет пользоваться спросом у юзеров, если оно получится некачественным и нестабильным:

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

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

Скроллинг – вертикальная или горизонтальная прокрутка страницы.

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

Компиляция – процесс перевода высокоуровневого языка программирования (PHP, Java, JavaScript) в машинный.

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

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

ПЛЮСЫ НАТИВНЫХ ПРИЛОЖЕНИЙ

Высокое качество . Узко-специализирующийся разработчик нативных приложений напишет вам чистый, уникальный код. Многолетний опыт разработки и четкие стандарты нативных iOS & Android приложений помогут сделать качественный продукт с широким функционалом и снизить риск появления багов практически до минимума.
Низкая вероятность отказа в размещении в App & Play Stores . Поскольку нативное приложение изначально отвечает стандартным требованиям определенной платформы, маловероятно, что вы столкнетесь с какими-либо проблемами при запуске вашего приложения в официальных магазинах App Store и Play Store.
100% использование UX дизайна . Современные пользователи избалованы яркими, детально-проработанными интерфейсами, и простые, стандартизированные приложения навряд ли заинтересуют их. Именно в нативной разработке UX дизайн используется на все 100%, что позволяет сделать качественное и интересное приложение. В гибридном приложении вы получите стандартизированный для двух платформ интерфейс.

Разнообразие инструментов для разработки . Благодаря многолетнему опыту разработки нативных приложений появилось огромное количество различных фреймворков, шаблонов и других проверенных инструментов, которые позволят сделать ваше приложение уникальным, индивидуальным и стабильным.
Большое сообщество разработчиков . Ну и конечно же, разрабатывая нативное приложение, вы навряд ли столкнетесь с проблемой, которую никто не решал до вас. А это значит, что вам не придется тратить лишнее время на поиск подходящего решения, а можно будет обратиться к опыту других программистов.

МИНУСЫ НАТИВНЫХ ПРИЛОЖЕНИЙ

Стоимость . Как говорится, бесплатный сыр только в мышеловке. Нативное приложение – это уникальный, качественный продукт, для создания которого требуется немало времени и, конечно же, высококвалифицированный разработчик с многолетним опытом. Поэтому и стоит такое приложение соответственно.

ИНТЕРЕСНЫЙ ФАКТ

Вы удивитесь, когда узнаете, что на самом деле разработать нативное iOS приложение стоит дешевле гибрида . Не верите? Смотрите сами!

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

В случае с гибридом – вам остается надеяться, что на тот или иной нативный инструмент существует адаптация на базе фреймворка, выбранного для гибридной разработки.

Если же такого инструмента нет – вам придется либо ждать его появления, либо рассматривать альтернативные фреймворки, то есть мороки с гибридом гораздо больше.

Исходя из этого, получается, что, создать одно нативное iOS приложение дешевле, чем одно гибридное iOS приложение .

Если же сравнивать разработку гибридного приложения и двух нативных, то цена гибрида будет ниже, как и ожидалось, ведь в гибридном приложении backend и frontend подходят для двух платформ сразу.

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

HYBRID iOS APP – $11.5K
HYBRID iOS + Android APPS
$12.5K

NATIVE iOS APP – $10K
NATIVE iOS + Android APPS
$18K

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

Вот теперь и думайте, экономить ли при разработке одного приложения, или нет? А может сразу сделать два нативных?

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

КАКОЕ ПРИЛОЖЕНИЕ ВЫБРАТЬ?

В этом случае вы будете на 100% уверены, что деньги потрачены не зря и в результате вы получите именно то приложение, которое заказывали.

ИТАК ,

Выбирайте гибридное приложение , если вы хотите получить:

простое приложение
приложение для двух платформ по бюджетной цене
1 приложение с возможностью быстрого выхода на два рынка (ios/Android)

Выбирайте нативное приложение , если вам нужно:

профессиональное приложение, соответствующее всем стандартам выбранной платформы
сложное приложение с широким функционалом
приложение с высокой скоростью работы

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

Воплотите все ваши самые смелые мечты и идеи в реальность вместе с .