Чем нативное приложение от разработчика отличается от приложения, созданного в конструкторе? Нативная vs кроссплатформенная разработка: преимущества и недостатки подходов Нативный интерфейс.

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

Первый вопрос, который возникнет у вас - по какой технологии разработки создавать приложение?

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

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

Приложение разрабатывается на “родном” языке для каждой платформы: Java для Android и Objective-C / C++ для IOS.

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

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

Если в нативном подходе одно и то же приложение разрабатывается отдельно и под iOS и под Android, то в кросс-платформенном подходе разрабатывается все за один раз.

Приложение сможет работать на всех платформах.

Языки программирование стандартные, как если бы вы разрабатывали сайт - HTML и CSS.

Гибридный подход

Гибридные приложения объединяют особенности нативной и кросс-платформенной разработки.

По сути, это кросс-платформенное приложение внутри “родной” оболочки.

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

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

Нативная разработка

1 Производительность и скорость

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

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

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

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

3 Нет ограничений

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

4 Удобство тестирования

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

5 Доступность

Пользователи смогут загрузить приложение из “родных” магазинов: App Store, Google Play

6 Адаптивность

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

Недостатки

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

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

2 Издержки на разработку

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

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

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

1 Скорость разработки и снижение затрат

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

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

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

Недостатки

1 Скорость разработки и снижение затра

Несмотря на то, что по идеологии разработки этот пункт отмечается как плюс, практика показывает, что имплементация под две ОС дает много багов. Это увеличивает срок на устранение ошибок. UI отображается по-разному и время на адаптацию также увеличивается.

2 Низкая производительность

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

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

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

В противном случае приложение, построенное согласно Руководству ОС IOS Human Interface будет неудобным Android пользователям. И в конечном итоге вы потратите больше времени, на усовершенствование пользовательского опыта.

4 Обращение к “нейтиву”

Стандартные решения для нейтива все равно не решаются в кроссплатформенной разработке. Поэтому часто для решения функционала привлекают нативных разработчиков.

Когда кросс-платформенность выигрывает:

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

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

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

Гибридная и нативная разработки: сравним?

Гибридные приложения или нативные (от англ. native – родной)? Это один из самых главных вопросов, который возникает у заказчика программного обеспечения, когда ему требуется выпустить новое приложение для пользования потребителем.

Давайте начнем с определения каждого из них. Гибридное приложение, как это и звучит, сочетает в себе элементы как родного (приложение работает без каких - либо внешней поддержки) и Web (приложение работает с помощью браузера и, как правило, написано на HTML5) приложений. Приложение заимствует кросс-совместимые веб - технологии, такие как HTML5, CSS и Javascript и использует часть собственного кода для большей приспособленности к пользовательскому устройству. Гибридные приложения размещаются внутри собственного приложения где находится WebView мобильной платформы (браузер в комплекте внутри мобильного приложения, если можно так выразиться). Проще говоря, гибрид приложение представляет собой веб-сайт, который упакован в оригинальную обертку. Примеры брендов, использующих гибридные приложения: Amazon App Store, Gmail и Yelp.

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

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

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

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

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

Время

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

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

Обновления

Гибридная разработка позволяет обновлять контент непосредственно из Интернета. Если нет какого-то резкого изменения функциональности, то обновления получаются практически незаметные. Многие из этих обновлений могут быть установлены не через App Store. Это делает исправление ошибок и добавление обновлений более эффективным, и заставляет пользователя меньше раздражаться. Тем не менее, есть одно предостережение, связанное с веб-обновлениями.

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

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

Пользователи

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

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

Стоит отметить, что скорость отклика при прочих равных условиях обычно выше у нативных приложений. Это часто ощущается пользователем в игровой среде, которая зависит от графической производительности. Это проявляется даже тогда, когда гибридное приложение использует HTML5 Canvas и WebGL. Разница в скорости составляет доли секунды – вам решать, критично это или нет.

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

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

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

Кросс-платформенная совместимость

Здесь все просто - В этом гибридные приложения выигрывают: нативное приложение, разработанное для iPhone, не будет работать на Android, и наоборот.

Вывод

Вы ищете однозначный ответ? Единственное, что я могу сказать вам так это то, что лучшая форма разрабатываемого приложения это та, которая соответствует вашим уникальным потребностям. Это будет зависеть от ваших ресурсов и потребностей вашего конечного пользователя. Напомню, что вы всегда можете обратиться за разработкой программы ко мне; я могу создать приложение на Java или C#. Есть также опыт разработки под J2ME и Android.

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

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

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

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

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

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

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

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

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

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

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

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

» Александр Кузнецов написал для 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 в долларах.

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

Но есть нюанс

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

Резюме

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

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

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

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

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

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

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

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

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

О нативных и гибридных приложениях мы сегодня поговорим с Денисом Алтуховым - Android-разработчиком в Anadea.

Привет, Денис!
Привет!

Скажи, как профессионал: чем отличаются нативные приложения от гибридных?
Ну смотри: нативные создаются под конкретную платформу, будь то Android, iOS или Windows. Они пишутся на нативных языках - Java в случае Android и Objective C в случае iOS. Скачиваются исключительно из официальных магазинов.

Вроде PlayMarket?
Да, у нас это PlayMarket и AppStore для Apple. Установка и распространение ведётся через эти магазины. Открывается как отдельное приложение, имеет свои окна. Не-нативное, написанное на JavaScript - по сути, это приложение, которое открывается в браузере и там имеется какая-то мобильная вёрстка.

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

В разных браузерах гибридное приложение может отображаться по-разному?
Оно может "плыть", но глобально всё будет выглядеть одинаково. Но, к примеру, если человек привык использовать Android, то он будет ожидать увидеть некоторые стандартные "андроидовские" штучки. И когда браузерное приложение свёрстано не так, как ты ожидаешь, это уже, говоря откровенно, раздражает.

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

Сталкивался с гибридными приложениями в своей практике?
Да. Например, год назад приходил проект, который как раз работал с картами - написан на JavaScript, в особой студии с трудом запускается, сам проект ломаный. Я кое-как смог его запустить лишь на эмуляторе iPhone!

О, Господи!
И это для того, чтобы хоть что-то увидеть! И то, осознать, что там происходит, было довольно трудно. В конце концов, заказчик пришёл к тому, что вместо одного гибридного он заказал два нативных приложения - для iOS и для Android.

То есть, он просто потратил время?
Да. Но его нельзя в этом винить - гибридные приложения разрабатывать и дешевле, и быстрее по времени. Ну и выбор разработчиков куда шире - уже необязателен специалист по мобильным платформам, достаточно обратиться к фронтендеру, который адекватно владеет JavaScript. Зная синтаксис языка, он сможет выполнить заказ, но без глубокого знания платформы многое может упустить и уровень приложения будет низким.

Именно поэтому не-нативные приложения чаще низкого качества?
Да - они "вылетают" или некорректно работают, потому что кто-то пришёл со стороны. Ещё одним проблематичным аспектом "гибридов" является организация нотификаций. Может там эти сервисы как-то и работают, но, к примеру, сейчас мы работаем над социальным приложением для обмена фотографиями, и там в iOS и Android нотификации строятся совсем по-разному. Вот тебе весомое отличие. Как будут выглядеть нотификации в web-приложении на заявленных трёх платформах (iOS, Android, Windows), где у каждой свои индивидуальные особенности… да кто его знает?

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

То есть, сейчас гибридным приложениям до нативных ещё очень и очень далеко?
Разумеется. Смысл в них есть, если ты разрабатываешь что-то очень простенькое, обобщённое, если бюджет невысок и сроки поджимают. Что-то, что не требует всех мощностей устройства, не привязывается к "железу". Если же требуется весь функционал, то в родных операционных системах Google и Apple уже встроена целая гора методов и способов работы с камерой, картами, bluetooth и прочим. И конечно же это будет лучше и качественнее, нежели пере-изобретённый велосипед от каких-то третьих разработчиков.

Абсолютно с тобой согласен. Спасибо, что нашёл время побеседовать!
Всегда пожалуйста.

Подведём итоги нашей беседы с Денисом:

• если вам требуется высокая скорость работы и ваше приложение будет непосредственно использовать "железо" (камера, оперативная память, видеочип, bluetooth, wi-fi, экран и прочее) устройства - разрабатывайте нативное приложение;
• если вас интересует высокий уровень безопасности - разрабатывайте нативное приложение;
• если вы работаете над действительно большим проектом - разрабатывайте нативное приложение;
• если же вам нужно что-то очень простенькое и вышеперечисленные пункты вашему проекту не нужны - тогда можно обойтись и гибридным приложением.