Следующее высказывание с легкостью может прозвучать от того, кто только что начал изучать 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!

В настоящее время 9 из 10 потенциальных клиентов обращаются с запросом разработки приложения сразу под 2 платформы - iOS и Android. Это вполне логично, ведь упомянутые платформы в сумме занимают более 95% рынка, и экономически целесообразно разрабатывать мобильное приложение именно под эти платформы.

Во время общения с заказчиками техническому директору компании Mauris Владимиру Бондаренко часто приходится объяснять, в чем разница разработки под каждую из платформ и почему это два абсолютно разных продукта. Многие считают, что программисты разрабатывают одно приложение, которое потом регистрируют в маркетах App Store и Google Play. В некоторых случаях это действительно так, но далеко не всегда. Владимир рассказал об основных подходах к разработке мобильных приложений.

Их всего четыре:

Конструктор приложений - готовый сервис, который позволяет за 30 минут собрать мобильное приложение.

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

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

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

• Скорость работы. Интерфейс кроссплатформенных приложений отзывчив.
• Время разработки. За счет единого решения под 2 платформы время разработки существенно сокращается.
• Техническая поддержка платформ.

Недостатки:

Недостатки:

• Ограниченный API. Хоть React Native и поддерживает огромное количество API-интерфейсов, все еще существует потребность в использовании других API через встроенные модули.
• Различия платформ Android и iOS.
• Относительно низкая производительность. Если вы планируете разрабатывать сложное приложение, React Native вам не подойдет.

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

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

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

• Удобство разработки и отладки. В целом разработка нативных приложений намного удобнее, чем, например, разработка кроссплатформенных. Это связано с тем, что в нативной разработке отсутствуют дополнительные прослойки между кодом приложения и исполняемым файлом и, в целом, инструменты натива более развиты.
• Наличие документации и регулярной технической поддержки
• Скорость работы. Нативные приложения обеспечивают высокую скорость работы и производительность.
• Юзабилити. Нативные приложения предоставляют возможность реализовать интерфейс и общее поведение программы наиболее естественным для данной платформы способом.

Недостатки:

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

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

Существует еще ряд менее популярных технологий для реализации приложений, но все они вписываются в градацию, описанную выше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Миф 1. Магия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примерно 2 года назад я захотел приобрести микрофон. Как обычно, перед покупкой я посмотрел несколько обзоров наиболее популярных моделей, узнал о тех характеристиках, которые отличают микрофоны, и зашел на сайт магазина, где собирался приобрести аппарат. Мой выбор пал на модель М1 (дабы исключить обвинения в рекламе и продакт-плейсменте заменим название микрофона). Эта модель была в двух комплектациях: обычный микрофон и вариант с USB-подключением, который стоил дороже. Кроме этого, эти две вариации ничем не отличались. Хорошо, берем деньги и идем в магазин. В магазине на витрине лежали обе модели. Я выловил девушку-консультанта и попросил показать понравившийся мне микрофон. «А не хотите взять эту модель?», — спросила девушка, показывая на более дорогой вариант с USB. «Разве она чем-то лучше? Именно в плане звука?» Девушка подумала немного: «Да, конечно лучше!». Мой совет: не верьте продавцам!

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

Гибриды против натуралов

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

1. Существуют чистые веб-приложения, которые выглядят почти как нативные. Например, app.ft.com . Их следует отделять от гибридных.
2. Чистые веб-приложения без сети не работают.
3. Интересное наблюдение: контент чистых веб-приложений легче искать. Просто вбейте интересующий вас запрос в поисковике и, если Google вас любит, пользователь увидит именно ваш сайт на первой странице поисковой выдачи.
4. Еще одно интересное наблюдение: гибридные и нативные приложения должны соответствовать определенным правилам, для того чтобы их можно было опубликовать в AppStore или GooglePlay. С другой стороны, вы вполне можете запилить свой уютненький сайт-приложение с чернухой и вырвиглазным дизайном, и вам слова никто не скажет.
5. Трудозатраты при написании гибридных приложений меньше, в сравнении с нативными, так как весь код пишется сразу на все платформы.

Да и разработчиков нужно меньше. Просто найдем пару крепких парней, которые знают HTML и JavaScript. Они нам все и напишут. А то ищи всяких Java, С#, С++, Objective-C разработчиков и потом еще всей этой ораве деньги плати.

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

Срываем покровы

Казалось бы, теперь мы знаем, чем отличаются гибридные и нативные приложения. На этом можно спокойно закончить статью и заняться делом — идти писать код. Но нет! Мы же помним: «Не верьте продавцам!». А большая часть людей, которые писали все эти пункты - именно продавцы, в той или иной форме. Так что, разбираемся дальше.

Веб-приложения

Сама идея сайта, который выглядит как приложение, — это, конечно, интересно. У этого подхода есть как минусы, так и определенные плюсы. Но есть один большой вопрос: «Зачем?». Представьте, что вы пользователь, не обремененный особыми познаниями в IT-технологиях. Открываете вы какой-то сайт и … О, Боже! У меня открылось приложение! Демоны! Это, наверное, вирус какой-то! Хотя стоп, а почему строка браузера видна? Это сайт что-ли такой? Или все-таки приложение? Хм, в списке установленных его нет. Работает он ужасно медленно. Установлю-ка я лучше нормальное приложение, а не это не пойми что.

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

Гибриды

Так как опыта работы с PhoneGap и с другими фреймворками подобного рода у меня не особо много, то я решил обсудить этот вопрос с нашим JS/HTML разработчиком, который писал программу при помощи фреймворка PhoneGap. Оказывается, на данный момент большая часть описанных проблем решена. На этой страничке переодетый Черный Властелин обещает нам, что теперь реакция на клики будет проходить быстро и безболезненно. Существует вагон и маленькая тележка различных плагинов , которые позволяют получить доступ к различным системам целевого устройства. А если чего и нету, то можно свой плагин написать. И кажется, что вот оно — отличное решение для кросс-платформенной разработки мобильных апп! Но давайте задумаемся поглубже над этой проблемой.

Что это за волшебные пилюли — плагины, которые решают все проблемы? Может, это какая-то магия? К сожалению, магии в нашем мире нет. По крайней мере, в IT. Плагины — это JavaScript обертки над нативным кодом Android или iOS. То есть, по сути, PhoneGap — это GUI, который на самом деле является веб-приложением, выполняемым в WebView. Логическая часть программы, выполняющаяся при помощи плагинов, которые на самом деле являются вызовами нативного кода через JavaScript, взаимодействует с устройством. Теперь, зная составляющие фонгап приложения, мы можем порассуждать о том, как все это будет работать.

1. Что ты знаешь о боли? WebView для Android версии 4.3 ужасно тормозит, когда требуется показать что-то чуть более сложное, чем текстовую инфу. В версии 4.4 движком для WebView стал Chromium, так что, возможно, это немного исправит ситуацию. В целом, для всех фонгаперов и иже с ними это означает боль и страдание при попытке запустить приложение на Android. На iOS ситуация с этим намного лучше, так как движок на сафари работает получше.
2. — Простите, вы женщина? — Я буду кем ты захочешь, малыш. В зависимости от девайса, для интерфейса приложения могут применяться разные стили. Это, конечно, не плохо, но логики дизайна не меняет. Есть кнопка Назад» на iOS - значит, будет она и на Android. И не важно, что она там никому не нужна. Еще один пример - Actionbar. На iOS он традиционно находится внизу экрана, на Android — в верхней части экрана. В приложении на PhoneGap у вас Actiobar не будет менять положение в зависимости от девайса, он будет просто выглядеть по-разному. И еще один момент: каждая OC имеет определенные особенности. Например, анимация. Посмотрите на iOS и Android. Анимация переходов между экранами. Она разная! Гибридные приложения не смогут воспроизвести эти особенности.
3. Разруха не в клозетах, а в головах. Еще один важный фактор, который почему-то никто не учитывает. Разработчики на PhoneGap — это обычно Фронт-енд разработчики. Они понятия не имеют о том, как должен выглядеть интерфейс под Android или iOS, так как не читали стайл-гайды. Они ничего не знают об особенностях платформы, потому что не читали документацию. Но они хорошо умеют делать сайты. Соответственно, вы получите приложение, похожее на сайт. Оно вам надо? Точно надо? Посмотрите на эту картинку? Вы все еще уверены в своем выборе?

1. Гномики? Это вы? Далее к плагинам. Это просто куски кода, которые решают некоторые задачи. Вы также можете использовать их в нативном приложении. Проблема в том, что зачастую ваше приложение должно решать задачи, которые чуть-чуть, самую малость, отличаются от тех, что решают эти куски кода. То есть, их нужно будет менять, но кто это будет делать? Ваш разработчик знает только JavaScript и HTML. Еще один тонкий момент - совмещение плагинов от разных разработчиков. Если плагины работают в смежных областях, они вполне могут использовать одни и те же компоненты. За счет этого можно получить интересные побочные эффекты. И последний камень в огород плагинов: некоторые из них не особо популярны и, как следствие, плохо оттестированы. Будьте готовы к тому, что вам самим придется выступить в роли тестировщика.

В общем, что я хочу сказать? Кроссплатформенность в данном случае мнимая, и приложения будут выглядеть странно. Я думаю, гибридные приложения стоит использовать в качестве прототипов, на которых можно оценить реакцию пользователей на вашу идею и получить некоторый фидбек. Для продакшн-версии лучше все-таки использовать нативные приложения. Эти рассуждения актуальны для всех гибридов, работающих на связке HTML/JS.

Нативные

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

Тру кроссплатформенность

На мой взгляд, едиственный фреймворк, который может действительно позволить вам написать кроссплатформенное мобильное приложение в данный момент — это С++ Qt. Этот фреймворк генерит нативный Android код с использованием Android NDK. Поэтому производительность должна быть на уровне кода, написанного программистом при помощи Android SDK, а для фрагментов, использующих тяжелые расчеты еще и выше — за счет NDK. Qt — это качественная, протестированная библиотека. Это означает, что вы не будете в процессе ловить какие-то левые баги. В случае какой-либо проблемы, вы можете взглянуть на исходники Qt. Это, действительно, очень нужная возможность для разработчиков. В некоторых случаях это единственный способ побороть баг. Для того, чтобы получить программу для целевой платформы (Android или iOS), вам нужно просто перекомпилировать исходники. Хотя, насколько я знаю, иногда все-таки придется писать нативный код для платформы, т. к. не все возможности доступны через библотеки Qt. Надеюсь, это вскоре будет исправлено.

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

Вывод

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