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

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

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

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

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

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

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

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

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

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

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

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

Следующее высказывание с легкостью может прозвучать от того, кто только что начал изучать Titanium:

JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.

Разумеется, у меня были подобные беседы с клиентами, когда я был фриланс-разработчиком на Titanium. И уж конечно, как Developer Advocate, я частенько слышу это когда начинаю объяснять Titanium разработчикам, которые ищут кросс-платформенное решение для создания приложений.

Titanium !== HTML

Каждый раз при сравнении с Phonegap (Cordova), Ionic и чем-либо еще, я начинаю мотать головой, махать руками и громко кричать о том, что в Titanium нет HTML.

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

Но при общении с клиентами или людьми, не очень подкованными в техническом плане, для которых JavaScript вызывает ассоциации с этими технологиями, представление HTML как просто еще одного технического термина не всегда помогает. Кроме того, определение Titanium как чего-то, чем он не является, не совсем правильно.

Что ты имеешь в виду под «Нативной» разработкой?

В ответ я стал спрашивать:

А что делает приложение нативным?

Может быть, то что…

• Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
• Разработчик использует стандартный для платформы язык?
• Приложение использует строительные блоки (API), которые предоставляет платформа?
• Приложение работает так, как ожидает пользователь на этой платформе?

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

Что такое хороший User Experience?

Итак, что же значит соответствующий платформе UI и UX? Ну, в первую очередь то, что мы не печемся о технологии, только о том, что она нам дает; Как приложение выглядит и чувствуется пользователем. Во вторую то, что поведение приложения зависит от платформы.

Выглядит и ведет себя ожидаемо

iOS, Android и Windows имеют различные требования к дизайну (iOS , Android ,Windows) и если вы опираетесь на них, ваше приложение более предсказуемо и следовательно, проще в использовании.
Отличный пример – TabGroups. На Андроиде они, как правило, встроены в Action Bar и будут прокручиваться если их много. На iOS Tab Bar расположен внизу и если у вас больше пяти табов, то пятый будет вести на экран выбора нужного таба. На Windows Pivot Tabs работают почти как на Андроиде, но выглядят немного по-другому, они не являются частью Command Bar, который расположен внизу экрана.


Так что технология, которая используется для разработки нативного приложения, не должна иметь собственные UI контролы, вместо этого она должна использовать те, которые предоставлены платформой.
В Titanium есть кросс-платформенные API почти для всего, и он всегда переводит их в платформенные UI-компоненты. Например, Ti.UI.TabGroup даст вам результат как на картинке выше, но напишете вы при этом один код (Alloy):
Tab A Tab B Tab C
Для тех API, которые представлены не во всех платформах, мы используем пространства имен, например, Ti.UI.Android.CardView .

Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.

Чувствуется ожидаемо

Но есть еще один, менее заметный фактор, который влияет на UX. Взаимодействие с приложением должно вызывать правильные чувства. Здесь мы имеем в виду, что время реакции и визуальный отклик такие, какие вы ждете от платформы.
Исторически этот момент всегда был большой проблемой для кросс-платформенной разработки. Все решения так или иначе имеют некий уровень абстракции над платформенными API. Это потенциальное узкое место. В Titanium мы посвятили массу времени оптимизации. Возьмите например, ListView , он может быть на 60% более отзывчивым, чем его предок, TableView .
В приложениях, которые используют HTML, это продолжает быть проблемой. Плоский интерфейс сделал все для того, чтобы такие приложения выглядели хорошо, но не нужно быть семи пядей во лбу, чтобы заметить разницу в том, как UI реагирует на взаимодействия. Часто он просто «не такой», и вот в чем задача UX: сделать его «таким».

Как достичь классного UX?

Кроме всего прочего, вам нужно классный разработчик. Плохие приложения можно и в XCode со Swift сделать, так что без сомнения, вы можете сделать его и с помощью любой (кросс-платформенной) технологии. Используйте нужные платформо-зависимые UI компоненты в нужных местах, избегайте утечек памяти, пишите чисто и с умом.
Плюс ко всему, используйте имеющиеся в вашем распоряжении строительные блоки, не имитируйте их. Помните, Titanium !== HTML и наши 4 пункта списка. Мы с уверенностью полагаем, что для нативного UX нужно использовать нативные UI и системные API. Для достижения пункта №4 нужно выполнить пункт №3.
Вот поэтому Facebook отказался от HTML приложений и создал React Native.
И да, у нас в Titanium это было с 2009.
Code Strong, Code Native… In JavaScript!

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

Гибридные приложения или нативные (от англ. 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.

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

Своё, родное…

Сначала поговорим о нативной разработке. Здесь всё просто: для каждой платформы существует нативный язык : для Android это Java, для iOS - Objective-C или Swift, для Windows Phone - C# и так далее. Для каждого нативного языка существует свой набор технологий и фреймворков.

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

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

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

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

Разработка “вручную”

Суть первого подхода в том, что код на С++ можно запустить где угодно. В Android для этого используется NDK, Windows Phone - Managed C, другие платформы также имеют свои способы обработать и запустить код. Другое дело - такой код будет ограничен в своих возможностях. Например, в Android он не сможет обратиться к экрану или даже самостоятельно запуститься. Чтобы обойти эти ограничения, сначала пишется библиотека с основной логикой на С++, а затем - обёртка на нативном языке, которая запускает библиотеку и обеспечивает её взаимодействие с устройством. Правда, стоит отметить, что такой подход подойдёт лишь для ограниченного круга приложений - там, где на клиентах находится действительно много логики, которую имеет смысл выносить в отдельную библиотеку.

Технологии

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

React Native в последнее время пользуется особенной популярностью: с ним активно экспериментируют даже такие гиганты рынка, как Uber или Сбербанк. Речь идёт даже не столько о кроссплатформенных приложениях, сколько о принципе «Learn once - write anywhere», то есть о возможности использовать одну и ту же технологию для создания приложений под разные платформы, обеспечивая высокий процент переиспользования кода.

Ещё один вариант написать кроссплатформенное приложение - использовать HTML5 + JavaScript . Кстати, именно так написаны текстовый редактор Atom, Visual Studio Code и Slack (да-да, даже десктопная версия - по сути браузер, который сделали похожим на обычное приложение).

Интересный факт: недавно компания Амперка выпустила необычный микроконтроллер Espruino. Его главная особенность - прошивка, которая крутится на микроконтроллере. Она написана на чистом Си, загружается единожды в отдельное место флеш-памяти микроконтроллера и занимается тем, что исполняет пользовательский JavaScript-код . Так что теперь можно программировать микроконтроллеры и на JS. На JS, Карл!!!

Эта идея кажется абсурдной, но если подумать, и ей можно найти обоснование. С развитием концепции интернета вещей и ростом количества различных IoT-устройств в будущем можно ожидать всплеск спроса на программистов, которые смогут обеспечить их взаимодействие с окружающим миром. А порог вхождения в JavaScript куда как ниже, чем в C или Assembler, тут не поспоришь!

Не всё так просто

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

И все они имеют одну причину: все платформы разные .

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

Негативный пользовательский опыт

Каждая платформа имеет свои стандарты: стандартные жесты и элементы управления, расположение элементов, внешний вид иконок… Например, вам хватит одного взгляда на экран, чтобы понять, iOS перед вами или Android. Разработав приложение, которое будет выглядеть одинаково на всех платформах, вы столкнётесь с тем, что пользователь не сможет использовать привычные ему методы управления и не увидит привычного дизайна, а значит, сочтёт ваше приложение менее удобным, чем нативное.

Этим, например, часто страдают игры, портированные на ПК с PlayStation: многие из них не поддерживают мышь и не позволяют настраивать комбинации клавиш, удобные для игрока, что делает их менее удобными, чем игры, разработанные специально для ПК. И если такие приложения, как Mortal Combat или Final Fantasy могут “выезжать” за счёт ностальгии, то разработчикам новых игр следует подумать, прежде чем лишать пользователей привычных им элементов управления.

Другой пример - Matlab, который на Mac использует не верхнее меню, а меню внутри окна, что типично для Windows и противоречит всем гайдлайнам iOS. Будучи монополистом, MatLab может себе это позволить, но если вы разрабатываете приложение, которое будет конкурировать с другими, стоит задуматься, не отдадут ли пользователи предпочтение привычному для них нативному интерфейсу.

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

Ограничения при разработке функциональности

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

Такое привычное всем действие, как drag and drop, принципиально отличается для Mac и для других платформ. Если на Windows или Linux это действие обрабатывается самим приложением, то на Mac в игру вступает непосредственно операционная система, а значит, разработчику потребуется создавать отдельное событие “открытие файла” для того, чтобы на Mac это действие работало корректно. А значит, придётся смириться или с ростом трудозатрат на разработку, или с тем, что привычный пользователям drag and drop на этой платформе просто не будет работать.

Ещё один пример - открытие определённого документа. На всех платформах это действие запускает приложение и передаёт ему то, какой документ надо открыть, как параметр, на Mac же используется специальное событие “открытие файла”. И снова мы сталкиваемся с ростом трудозатрат, а значит, и стоимости разработки.

Кроссплатформенные приложения тормозят: миф или реальность?

Практически в любом споре, посвящённом преимуществам и недостаткам кроссплатформенной разработки, вы увидите аргумент о том, что кроссплатформенные приложения значительно медленнее своих нативных собратьев. Это и так, и не так. Например, код, написанный на С++ и запущенный на Android с помощью NDK, будет работать даже быстрее нативных приложений. С другой стороны, если вы используете, например, PhoneGap, приложение начинает работать по принципу “Дома, который построил Джек”: PhoneGap вызывает JS, который обращается к Java, которая запускается на Java-машине, которая работает уже на реальном телефоне. Разумеется, о быстродействии речи уже не идёт.

И что же выбрать?

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

Популярную головоломку 2048, например, лучше разрабатывать как кроссплатформенное приложение. Разработанная на веб-технологиях, она будет запускаться везде: вы можете использовать тот же PhoneGap, чтобы запустить её на мобильных платформах, Electron - для Windows, Linux и Mac, а для сайтов, приложений ВКонтакте и Facebook даже не придётся прикладывать усилий: приложение запустится напрямую. Всё, что вам нужно, - собрать программу при помощи разных упаковщиков и создать иконку для каждой платформы. Готово, приложение не отличить от нативного!

На противоположном конце шкалы находится, например, графический редактор Sketch, снискавший завидную популярность у UX и UI дизайнеров (мы в Noveo тоже его используем!). В настоящее время он существует только для OS X, и вопрос, когда же его выпустят для других платформ, задают настолько часто, что он был даже вынесен в FAQ.

“Is Sketch available for Windows or Linux?

Due to the technologies and frameworks exclusive to OS X that Sketch has been built upon, regrettably we will not be considering supporting Sketch on either of these platforms.”

(Есть ли версии для Windows или Linux?

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

Большинство приложений, конечно, лежат где-то между этими точками экстремума, так что для выбора одного из подходов потребуется тщательный анализ. Постарайтесь оценить: какой процент ваших пользователей отпугнёт, например, непривычный вид кнопок или неиспользвание верхнего меню на OS X? Будут ли это те пользователи, за счёт которых окупается ваше приложение? Много ли в приложении функциональных возможностей, которые потребуют значительных доработок для одной или нескольких платформ?

Конечно, точные результаты сможет дать только A/B тестирование, но даже поразмыслив над этим, вы много сделаете для выбора подхода к разработке.

Подведём итоги

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

Существует множество фреймворков и технологий кроссплатформенной разработки. Среди самых популярных можно назвать Ionic, Unity 3D, Xamarin, React Native, а также использование HTML + JavaScript.

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

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

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

Под нативной (родной) разработкой подразумевается использование оригинальных языков и инструментов разработки мобильной операционной системы. Приложения для iOS создаются в среде разработки XCode на языках Objective-C, Swift, C и С++. Для создания приложений под Android используется среда Android Studio и язык Java. Каждая среда разработки содержит целый комплекс утилит для написания кода, проектирования интерфейса, отладки, профилирования (мониторинга) и сборки приложений. И среда, и соответствующий набор утилит созданы специально под каждую мобильную операционную систему и являются максимально удобными и мощными средствами разработки мобильных приложений.

Кроссплатформенная разработка подразумевает использование специальных утилит (фреймворков) для создания приложения на основе семейства языков JavaScript. Вся структура и логика приложения создается с помощью таких инструментов (PhoneGap, Titanium, Xamarin, Cordova и др.) на JavaScript, а затем оборачивается в нативный запускающий элемент, т.е. интегрируется в базовый проект для XCode или Android Studio. Что позволяет создавать сборки проекта с одной и той же логикой под несколько операционных систем сразу.

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

Плюсы кроссплатформенной разработки

Кроссплатформенный подход к разработке имеет следующие положительные моменты:

1. Требуется меньше ресурсов для реализации приложения сразу под несколько платформ. В этом, собственно, и суть кроссплатформенного подхода – один и тот же код работает и на iOS, и на Android. Программистов, занимающихся проектом, нужно ровно в два раза меньше. Дизайнер делает только один набор графики. Все это снижает количество рабочих часов и бюджет проекта.
   ⋅
2. Меньшее время на разработку. За счет отсутствия уникальных элементов интерфейса и более простых технологий, время на создание простых продуктов, как правило, меньше.
   ⋅
3. Упрощенный цикл обновления продукта. Если в проект нужно что-то добавить или исправить какую-то ошибку, это делается сразу для всех платформ, на которые распространяется проект.
   ⋅
4. Возможность использования мобильной версии сайта. Большинство кроссплатформенных решений используют семейство JavaScript языков. Поэтому если у вас уже есть мобильная версия сайта, значительная часть кода и материалов может быть использована в приложении без изменений.
   ⋅
5. Использование единой логики приложения. Логика, заложенная в работу приложения, будет работать гарантированно одинаково для всех платформ. Довольно часто это может являться и минусом из-за разной архитектуры операционных систем. Яркий пример – кнопка “Назад” в навигации между экранами. В Android предусмотрена аппаратная кнопка Back для этих целей. У iOS – движение пальцем от левой части экрана или же наличие кнопки в левой части навигационной панели. Если кнопку не делать вовсе, пользователи iOS не смогут вернуться назад. Если сделать, но не на том месте и выглядящую нестандартно, пользователям iOS будет непривычно и неудобно; а если сделать как в iOS, будет непривычно пользователям Android. Однако написанная и отлаженная один раз логика содержит потенциально меньшее количество ошибок и расхождений в своей работе. Поэтому вам не придется проделывать двойную и тройную работу по поиску проблем на каждой платформе.

Плюсы нативной разработки

Разработка на родных технологиях и языках под iOS и Android имеет следующие положительные моменты:

1. Скорость работы приложения.

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

2. Гибкость в реализации.

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

3. Использование последних технологий и зависимость от кроссплатформенных фреймворков.

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

⋅ 4. Легкость и качество тестирования.

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

5. Полная поддержка со стороны магазинов приложений App Store и Google Play.

Обе компании заинтересованы, чтобы пользователи получали максимально положительный опыт при использовании приложений на соответствующих платформах, который возможен на текущий момент. Это означает, что приложение должно выглядеть максимально качественно (если у экрана высокое разрешение, а изображения расплывчаты, в App Store приложение просто не пропустят), работать настолько быстро, насколько это возможно (если приложение отображает небольшой список элементов за 20-30 секунд, его так же не пропустят), и вообще все должно быть красиво и удобно. Если какие-то из этих параметров слишком низки или вообще не выполнены, приложение не пропустят в магазин. Если же они не на высоте, чего добиться с кроссплатформенными технологиями крайне сложно, а часто и невозможно в принципе, ваше приложение никогда не будет рассмотрено соответствующими компаниями для размещения в специальных рекламных разделах (Featured). Среди приложений, находящихся во Featured-разделах и App Store, и Google Play, нет ни одного, сделанного с помощью кроссплатформенных технологий. За исключением игровых проектов, в которых интерфейс не является системным.

Выводы

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

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

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