Натив или кроссплатформа
"Разбираемся что выбрать: Разработку нативного или кроссплатформенного приложения"
Время чтения: 5 минут
Как правило, выход любого бизнеса в интернет протекает по следующему сценарию: сначала компания запускает сайт, его сразу адаптируют под мобильные устройства, и если наблюдается прирост трафика, появляется смысл закрепиться среди владельцев мобильных гаджетов, и компания выпускает приложение.
Сравнивать мобильный сайт и приложение нет смысла — второе однозначно выигрывает за счет широты своих возможностей и отзывчивого интерфейса, взаимодействовать с которым через телефон или планшет гораздо комфортнее. Кроме того, приложение может работать без постоянного подключения к интернету.
Вне зависимости от того, на чем построен ваш бизнес — на продажах, предоставлении услуг или просветительской деятельности, сегодня невозможно не учитывать время, которое люди проводят перед экранами мобильных устройств. Эта статья призвана рассказать о двух подходах к разработке приложений — нативном и кроссплатформенном.
Каждый из подходов обладает своей спецификой, критически влияющей на конечный результат. И дабы облегчить понимание между заказчиком и разработчиком, хочется рассказать о том, что собой представляют оба подхода, разобрать их достоинства и недостатки, разрушить закрепившиеся стереотипы о разработке и дать ответ на главный вопрос: как сделать выбор в пользу того или иного подхода по принципу целесообразности. Поехали!
Нативные приложения — это приложения, с которыми вы сталкиваетесь с первого дня использования устройства. Это установленные по умолчанию браузер, почтовый клиент, адресная книга, будильник, календарь и другие стандартные программы.
Как создать нативное приложение? Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то Objective-C и Swift для iOS или Java для Android, такое приложение будет называться нативным (от англ. native — родной, естественный). «Нативки» могут получать доступ ко всем службам, сервисам и примочкам телефона: камере, микрофону, геолокатору, акселерометру, календарю, медиафайлам, уведомлениям и так далее — в общем, полноценно обживаются и чувствуют себя как дома.
Кроссплатформенные приложения — что это? Представьте себе мобильный сайт, которому не всегда нужен интернет, а с точки зрения дизайна он ближе к мобильным приложениям, а не к веб-страницам. Примерно так можно описать кроссплатформенные приложения.
Так на чём писать кроссплатформенные приложения? Зачастую они создаются на языке разметки и стилей (HTML, CSS и JavaScript), как и мобильные сайты. Логически такой поступок оправдывается тем, что, в конце концов, весь интернет-контент — это HTML-страницы. Такие приложения пишутся одновременно для всех платформ и адаптированы к большинству устройств, потому что для их работы в основном используется браузерный движок.
Как видно, планка для входа в более чем перспективную область разработки мобильных приложений значительно снизилась. Кто-то может подумать, что теперь верстальщики, которые не идут дальше проверенных HTML и CSS, будут отнимать хлеб у настоящих программистов. Другие видят за кроссплатформенным подходом будущее, в котором время и затраты на разработку приложений будут полностью оптимизированы. С обеих сторон найдутся аргументы, объясняющие, почему правильным является именно этот, а не другой подход к разработке.
Но когда мы говорим о решении определённых задач, эффективнее будет эти подходы скомбинировать — использовать кроссплатформенные преимущества HTML для оформления контента, а требовательные к скорости отзывчивости меню и элементы управления сделать нативными, затратив на это минимум усилий, времени и бюджета. Такие приложения называются гибридными. В этом случае только объём нативного кода определяет, какому подходу больше соответствует разработка приложения.
Какие ситуации приводят к слиянию подходов? Предположим, что клиенту нужна незатейливая новостная лента, где не будет ничего, кроме текста и изображений. Исходя из этой задачи, разработчик принимает решение использовать кроссплатформенный подход. Но если через некоторое время заказчик пожелает, чтобы приложение хранило большое количество данных или обрабатывало звук и графику, задача усложняется. Для этих целей нужно писать нативный код под каждую конкретную платформу, и некогда полностью кроссплатформенное приложение превращается в гибридное.
Распространено заблуждение, что за любой иконкой на рабочем столе пользователя ждёт нативное приложение. Это заблуждение пустило корни настолько глубоко, что даже в профессиональных кругах грешат формулировками высокого градуса абсурдности вроде «нативное фонгэп-приложение». Но на рабочий стол можно вывести даже ярлык для сайта, поэтому иконка ничего не гарантирует, и по ту сторону с равной вероятностью может оказаться как нативное приложение, так и любое другое.
Рынок предложений растет. Статистика продаж мобильных приложений показывает, что год от года пользователи гаджетов всё чаще меняют стандартные сервисы на альтернативные. Так, родной менеджер задач заменяется на Wunderlist, почтовый клиент — на приложение Mailbox, Evernote оказывается предпочтительнее стандартных заметок.
Заказчику важно знать преимущества и недостатки каждого из подходов и не завышать ожидания, делая выбор. Проводить сравнительный анализ будет уместно по ряду критериев.
Зависимость от платформы Могло сложиться впечатление, что кроссплатформенному приложению комфортно на всех платформах, вплоть до самых непопулярных. Требуется оговорка: чтобы это убеждение соответствовало действительности, под каждую платформу, возможно, придётся писать кусок дополнительного кода. В случае же нативных приложений можно рассчитывать на их отличную работу, но для каждой платформы требуется разрабатывать свою версию.
Не затронуть гайдлайны в контексте разработки мобильных приложений невозможно. Гайдлайны — это ценные указания от компаний-производителей платформ в адрес разработчиков мобильных приложений, направленные на то, чтобы подогнать их дизайн и функциональность под стандарты. Гайдлайны — это фундамент, на котором зиждется психология и комфорт пользователей платформы. Проще говоря, элементы интерфейса имеют привычный внешний вид и расположение.
Языковая среда, в которой разрабатываются нативные мобильные приложения, обладает необходимыми инструментами для создания привычного пользователю интерфейса. Другая ситуация с веб-технологиями: чтобы сделать кроссплатформенное приложение похожим на нативное, придётся приложить немало усилий. Разные кроссплатформенные фреймворки (Framework 7, Sencha Touch, Kendo UI, Ionic и другие) помогают с той или иной степенью достоверности имитировать нативный интерфейс, но чаще всего отзывчивость, скорость анимации, эффекты и дизайн будут другими. Этому и посвящен следующий пункт.
Первое, чего на подсознательном уровне ждёт пользователь от своего приложения — это отзывчивости. За действием пользователя тут же следует ответная реакция, прокрутка страницы и анимация протекают плавно и без подвисаний. Кроссплатформенные приложения в этом плане значительно уступают нативным, а если не ходить вокруг да около, они тормозят, и это их главная проблема.
Также пользователь уверен в том, что каждый элемент управления, каждая иконка будут иметь стандартный вид и положение на экране приложения. Для разных платформ эти стандарты будут разными, и если создание кроссплатформенного приложения осуществлялось по гайдлайнам iOS, то пользователям Android это доставит дискомфорт, и наоборот.
Одним из ярчайших примеров может стать кнопка Back: это типичная для Android функция, которая не имеет аналога на iOS. Поэтому, когда вы создаете кроссплатформенное мобильное приложение, компромиссов в этой ситуации может быть только два: либо дизайн един для обеих платформ, и пользователи одной из них вынуждены приспосабливаться, либо вы создаете два разных дизайна с учётом особенностей каждой платформы. По сути, во втором случае создаются два приложения, но на одном кроссплатформенном языке.
Нативное приложение, написанное под конкретную платформу, чувствует себя её полноправным обитателем, получая максимальный доступ ко всем устройствам и сервисам устройства. Проектируя кроссплатформенное приложение, разработчик учитывает только возможности фреймворка, налагающего свои ограничения.
Может создать проблему и то, что у фреймворков есть множество версий, и чем старее версия, тем больше ограничений. В любом случае, кроссплатформенному приложению открыты двери далеко не ко всем фишкам платформы. Не всегда возникает необходимость в полной интеграции — её глубина зависит от задач, которые должно решать приложение.
Для всех популярных браузеров существует стандартный безопасный протокол передачи данных — HTTPS. Но если требуется особый уровень шифрования, решение этой проблемы ложится на разработчика. Обеспечение надёжной защиты данных возможно только при нативной разработке мобильных приложений, так как связано с математикой, а подобные операции требуют максимально эффективного использования аппаратных ресурсов.
Комплексное обслуживание нативных Android и iOS-приложений (поиск и исправление ошибок, обновление и любое незначительное изменение) в среднем занимает в два раза больше ресурсов по причине необходимости как минимум двух разных специалистов (iOS и Android). С кроссплатформенным приложением может управляться один разработчик.
Стоимость мобильной разработки и затрачиваемом времени опутана заблуждениями и мифами, а потому хотелось бы затронуть эти вопросы отдельно и если не расставить все точки над i, то хотя бы этому поспособствовать.
Быстрая и дешевая разработка кроссплатформенных приложений — миф или реальность?
Кроссплатформенная разработка мобильных приложений обходится дешевле, что объясняется меньшими объемами работ относительно нативной разработки. Но и здесь есть свои подводные камни, разглядеть которые можно, только поняв принципы ценообразования.
Всегда нужно помнить, что время и стоимость регулируется сложностью и уровнем качества выполнения задачи. Допустим, что для разработки кроссплатформенного продукта у нас есть один специалист, который знает HTML, CSS, JavaScript и имеет опыт работы в PhoneGap. Один специалист — это одна абстрактная единица ресурса (допустим, один человеко-месяц).
Для работы над нативным приложением таких ресурсов требуется два — iOS и Android. В итоге, для завершения нативного проекта требуется два человеко-месяца, для завершения кроссплатформенного — полтора или даже месяц.
Справедливым будет вопрос: «Как так — полтора? Почему не один?» Увы, на практике кроссплатформенное приложение, хорошо работающее на iOS, будет плохо работать на Android — у всех браузерных движков своя специфика, и как следствие, оптимизацию под Android может уйти еще половина человеко-месяца.
Когда мы сравнивали подходы по нескольким критериям, мы сказали, что степень интеграции приложения в платформу обусловлена сложностью задачи, решаемой приложением. Использование того или иного шаблона или готового решения может быть довольно дешевым способом сделать приложение, пока возможностей шаблона или решения достаточно для выполнения конкретной задачи.
И он заключается в структурной особенности приложения. Чаще всего оно предполагает наличие серверной части, куда пользователи приложения сохраняют данные и через которую обмениваются ими с другими пользователями, и она тоже требует финансовых вложений. Работа над ней может занимать до трети всего времени разработки, и оно увеличивается при необходимости создания административной панели для удобного управления данными.
К нативной разработке стоит прибегать, если:
- вашему приложению требуется свободный доступ ко всем ресурсам и сервисам телефона;
- вы хотите получить максимально отзывчивое приложение;
- приложение должно уметь работать в офлайне;
- ваше приложение должно максимально эффективно использовать аппаратные части устройства;
- использование в проекте ИИ;
- использование в проекте функции дополненной/виртуальной реальности (AR/VR);
Ваш вариант - кроссплатформенная мобильная разработка, если:
- вы готовы примириться с низкой отзывчивостью;
- приложение не предполагает сложной анимации и не занимается расчетами;
- приложению необходим постоянный доступ в интернет, чтобы загружать контент;
- вам нужно быстро выйти на рынок для тестирования идеи;
- у вас есть сайт, и вы хотите обернуть его в приложение за минимальную цену.
К выбору той или иной стратегии всегда приводят индивидуальные обстоятельства, ни одна статья не даст универсального ответа.
Наш материал скорее дает вводную информацию общего характера, помочь заказчику и разработчику наладить диалог на понятном для обоих языке.
Окончательное решение стоит принимать после консультаций с разработчиками. Чем больше аргументов относительно того или иного подхода вы услышите, тем лучше.
Напоминаем вам, что наша команда предоставляет услуги по разработке мобильных приложений и веб-сервисов. Мы предлагаем вам разработку как кроссплатформенных приложений, так и нативных, и всегда готовы помочь вам сделать правильный выбор.