Лого vc.ru

Кроссплатформенные приложения против нативных: сравнение и выбор подходов

Кроссплатформенные приложения против нативных: сравнение и выбор подходов

Генеральный директор компании-разработчика «Лайв Тайпинг» Александр Кузнецов написал для VC колонку об отличиях нативных приложений от кроссплатформенных, в которой объяснил, какой тип разработки будет предпочтительным в тех или иных обстоятельствах.

Поделиться

Время приложений

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

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

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

Эта статья призвана рассказать о двух подходах к разработке приложений — нативном и кроссплатформенном.

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

Нативный подход

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

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

Кроссплатформенный подход

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

Зачастую они создаются на языке разметки и стилей (HTML, CSS и JavaScript), как и мобильные сайты. Логически такой поступок оправдывается тем, что, в конце концов, весь интернет-контент — это HTML-страницы. Такие приложения пишутся одновременно для всех платформ и адаптированы к большинству устройств, потому что для их работы в основном используется браузерный движок.

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

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

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

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

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

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

Сравнение подходов

Рынок предложений растёт. Статистика продаж мобильных приложений показывает, что год от года пользователи гаджетов всё чаще меняют стандартные сервисы на альтернативные. Так, родной менеджер задач заменяется на Wunderlist, почтовый клиент — на приложение Mailbox, Evernote оказывается предпочтительнее стандартных заметок.

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

Зависимость от платформы

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

Дизайн интерфейса

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

Языковая среда, в которой разрабатываются нативные приложения, обладает необхоимыми инструментами для создания привычного пользователю интерфейса. Другая ситуация с веб-технологиями: чтобы сделать кроссплатформенное приложение похожим на нативное, придётся приложить немало усилий. Разные кроссплатформенные фреймворки (Framework 7, Sencha Touch, Kendo UI, Ionic и другие) помогают с той или иной степенью достоверности имитировать нативный интерфейс, но чаще всего отзывчивость, скорость анимации, эффекты и дизайн будут другими. Этому и посвящен следующий пункт.

Пользовательский опыт

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

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

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

Ограничения

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

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

Безопасность

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

Обслуживание и поддержка

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

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

Быстрая и дешёвая кроссплатформенная разработка — миф или реальность

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

Всегда нужно помнить, что время и стоимость регулируется сложностью и уровнем качества выполнения задачи. Допустим, что для разработки кроссплатформенного продукта у нас есть один специалист, который знает HTML, CSS, JavaScript и имеет опыт работы в PhoneGap. Один специалист — это одна абстрактная единица ресурса (допустим, один человеко-месяц).

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

Справедливым будет вопрос: «Как так — полтора? Почему не один?» Увы, на практике кроссплатформенное приложение, хорошо работающее на iOS, будет плохо работать на Android — у всех браузерных движков своя специфика, и как следствие, оптимизацию под Android может уйти ещё половина человеко-месяца.

Исходя из вышесказанного, был произведен расчёт стоимости мобильной разработки в случае нативного и кроссплатформенного подходов, представленный в двух таблицах. Результаты в таблице 1 отталкиваются от средней почасовой ставки фрилансеров из баз freelansim.ru и fl.ru в рублях, в таблице 2 — средней почасовой ставки фрилансеров и студий из международной базы upwork.com в долларах.

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

Но есть нюанс

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

Резюме

К нативной разработке стоит прибегать, если:

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

Ваш вариант — кроссплатформенная разработка, если:

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

К выбору той или иной стратегии всегда приводят индивидуальные обстоятельства, ни одна статья не даёт универсального ответа.

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

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

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

Популярные статьи
Показать еще
Комментарии отсортированы
как обычно по времени по популярности

еще забыли про React Native, который уже есть для iOS. Для Android активно разрабатывается

0

Кто-то может привести пример приложения на веб-движке (под ios), которое не тормозит и которым приятно пользоваться? Пусть даже оно не по гайдлайном. Или таких действительно нет?

0

Таких очень много достаточно посмотреть шоукейсы на сайтах популярных html5 фреймворков.
framework7 — www.idangero.us/framework7/showcase/#.VfG-k_ntlBc
ionic — showcase.ionicframework.com/
Appgyver — www.appgyver.com/showcase

Автору стоило бы отдельно упомянуть о новой категории инструментов для разработки:
Nativescript — www.nativescript.org/
Tabrisjs — tabrisjs.com

Топлю за tabrisjs.com
Так же писал на ionic. Неплохо ребята за последний год платформу развили, но там cordova, так что тормозит всё неплохо.

Остальное всё поделки.

Последний ионик ни разу не тормознул за последний квартал

0

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

довольно спорный на мой взгляд аргумент. Приложение не обязано иметь доступ(постоянный) в интернет, взять те же игры написанные на стеке html+css+js. Да и приложения которые уже сейчас поддерживают всякие LocalStorage с IndexedDB.

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

"если речь идет именно о приложениях, а не играх"

следует читать как

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

Тоже поддержу. Статья выглядит немного устаревшей

Школьник писал какой-то видимо

Еще один плюс приложений это конечно же push уведомления. Сложность при разработке нативных или кроссплатформенных приложений в том, что клиенту сложно объяснить все прелести нативки. Когда начинаешь объяснять всё это, понимаешь, что им совершенно плевать как это будет и на чем) именно по этому часто за нативные подсовывают приложения сделанные на phonegap или даже попадались запиленные сайты под видом мобильного приложения. Но был случай, когда мы договорились с клиентом о создании нативного приложения под android, после моей фразы: "мы выложили приложение на google play", полученный ответ: "а на app store закинули?" немного приводит к ступору. И долгие объяснения, что мы вроде как договорились на нативное приложение под android ни к чему не приводят) поэтому уважаемые разработчики мобильных приложений из личного опыта оформляйте договор или подробное тз, чтобы не было недопонимания, испорченных отношений и тому подобное.)

Печальная история. Интересно, как менеджеры могли такое проморгать при общении с заказчиком?

Пуш отлично делает кордова либой с оффсайта (почти из коробки)

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

0

"На appstore тоже закинули?" распечатаю себе на стену в рамке.

Фраза "приложение не предполагает сложной анимации и не занимается расчетами" в развернутом виде звучит так:

* Приложение не предполагает глубокой интеграции с мобильной ОС;
* Приложение не предполагает сколько-нибудь сложной криптографии;
* Приложение не предполагает работы с большими объемами данных;
* Приложение не умеет работать с локальной БД и ФС;
* Приложение не умеет приемлемо обрабатывать изображения;
* Приложение не будет работать с GPU/шейдерами;
* Приложение не предполагает использования сетевых протоколов помимо HTTP;
* Приложение не предполагает сложного кастомного UI;
* Приложение не предполагает сложного взаимодействия с внешними устройствами по Bluetooth/WiFi;
* Приложение не выдержит сколь-нибудь серьёзной конкуренции с в-обязательном-порядке-нативными продуктами известных компаний;
* Приложение не будет поддерживать сложные форматы файлов (яркий пример PDF);
* Приложение не сможет нормально работать в фоне;
* Приложение не умеет обрабатывать аудио/видео в реальном времени;
* Да что там обрабатывать - забудьте даже о качественном воспроизведении аудио и видео без залипонов;
* Приложение не будет обладать ни одной уникальной характеристикой, выделяющей его среди миллионов клонов;
* На Андроиде, с его бешеной фрагментацией велика вероятность эпичнейше обосраться. Наблюдал случаи, когда время разработки вырастало не в 1.5 раза, а на порядок например, упершись в банальную невозможность решения задачи на встроеном андроидном браузерном говнодвижке. С последующим наймом крутого и дорогого C++-ника для запиливания внутри аппа кастомизированного хромиума с уникальными характеристиками. Сэкономили блджад.

Подытожив: с вероятностью 99.99% приложение будет унылым говном на выброс. Никогда не сможет тягаться с лидерами. И будет отсвечивать разве что в showcase'ах ионика и фонгапа, в окружении таких же лузерских поделий. Но никак не в топах аппстора.

И на заметочку - такая с виду нехитрая штука, как вайбер, потребовала 20 лямов зелени на разработку. Примерно та же клиническая картина практически у всех обитателей верхнего сегмента пищевой цепочки аппстора.

Короче, не распыляйтесь, пилите натив под iOS. В случае коммерческого успеха переходите к Андроиду.

PS. Все вышесказанное неверно в случае, если вы хотите тупо мобильный сайт в оболочке приложения. Контентный проект без развеситых фич можно запилить и кроссплатформенно. Но реальные бивни такое за приложения не считают ;)

99.9 фигня,хотя технически почти и верно. В 50% где пох. на все (к примеру меню ресторана или заказ такси) подобие фонегапов (а их до .... много), самое то. И время и силы и деньги экономят.

Спасибо, избавили от необходимости всё это писать :)

а я вообще корону сдк с луа люблю )
Очень приятная штука )

−1

Хотел бы я, чтобы клиенты в реальности так оплачивали работу как в таблице :)

0

Да вроде нормальные цены, могло быть и больше.

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

−1

Статью писал дилетант

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

Как Xamarin разработчик добавлю пару нюансов. Xamarin кстати можно назвать гибридной кросс-платформой, т.к. он предоставляет все возможности ОС и позволяет шарить 90% кода.

1. Не используйте кросс-платформенный фреймворк для одной платформы. Встречал неоднократно когда полностью нативное приложение для iOS написано на Xamarin. Это рожает кучу проблем и не даёт никаких преимуществ. Если пишите на кросс-платформенный фреймворке - пишите сразу Shared код. Иначе закажите нативное.

2. Читайте гайдлайны. Хитрость кросс-платформенной разработки в том что вы должны знать гайдлайны всех платформ и использовать их. Нет ничего хуже когда какой-нибудь нижний toolbar суют в Android. Это вам как разрабу видно сразу все и хочется унификации, пользователи на Android никогда не увидят вашу iOS версию приложения - уважайте их. Да, нужно три пакета графики, три интерфейса, но это единственно верный способ.

3. Стоимость разработки действительно от 1.5 до 2.5 стоимости нативных приложений. Почему? Все зависит от используемых библиотек. Экоструктура Xamarin довольно широкая и все же меньше чем нативная. Если в вашем продукте большое количество сторонних зависимостей которые надо интегрировать - то это вам выйдет дорого.

0

Кто может по React Native что-нибудь сказать?

0

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

Сейчас обсуждают
Vladislav Eliseev

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

IKEA оспорит арест 9 млрд рублей на счетах российской «дочки»
1
Filipp Lyakh

> а год выпуска написан винтажным шрифтом.

Пиксельный шрифт — новый винтаж)

15 примечательных винных бутылок: шрифт Брайля, зашифрованный портвейн и посадочный талон
0
Александр Кадетов

Вот эту вкладку можно вообще навсегда удалить.

Кейс из России: Зачем команда «Альфа-Мобайл​» меняет дизайн своего приложения
0
Michael

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

DamProdam — сайт покупки-продажи подержанной техники
0
Anton Mansurov

У Билайна нет больше поддержки на 0611. Просто нет такого выбора "поговорить с оператором". Чат на сайте и в приложении весьма убогий. Если что-то оборвалось - пиши заново, никакой истории. Так что случись какая проблема - остаешься с ней один на один. Ну или или в офис, к некомпетентным сотрудникам. Вот куда перевести свои 6 номеров?)

Как избавиться от лишних платных подписок — советы абонентам «Мегафона», МТС, «Билайна» и Tele2
0
Показать еще