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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сначала поговорим о нативной разработке. Здесь всё просто: для каждой платформы существует нативный язык : для 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 .

Примерно 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 фреймворки, но я бы не советовал их применять для разработки сложных продакшн-приложений. В этой сфере разработки альтернативы нативным приложениям в данный момент нет.

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

Кросс-платформенные фреймворки PhoneGap, Xamarin, Unity, Qt и Appcelerator Titanium, Telerik Platform на сегодняшний день занимают 80% рынка кросс-платформенной разработки для мобильных устройств.

В таблице ниже представлены основные характеристики для каждого фреймворка:

	PhoneGap	Xamarin	Unity	Qt	Appcelerator Titanium	Telerik AppBuilder
Языки	JavaScript, HTML5, CSS3 и нативные языки (Java, Objective-C, C#)	C#, Xaml	C#, UnityScript, Boo	C++ QML	JavaScript, Python, Ruby, PHP	.Net, JavaScript, HTML5, Java, PHP
Поддерживаемые латформы	Android, iOS, Windows Phone, Blackberry, WebOS, Symbian, Bada, Ubuntu, Firefox OS.	iOS, Android, Windows Phone and Windows 8/RT, Tizen	Android, iOS, Windows Phone, Tizen, PS 4, Xbox One	Android, iOS, WinRT, Windows, Symbian, Linux, QNX	iOS, Android, BlackBerry, Windows, Tizen, Denso	iOS, Android, BlackBerry, Windows, Windows Phone
Цены	Цены PhoneGap Платная версия: от 9.99$ Бесплатная версия: доступна Adobe Creative Cloud Membership: доступно	Цены Xamarin Xamarin Studio Community: бесплатно Visual Studio Community: бесплатно Visual Studio Professional: доступно Visual Studio Enterprise: доступно	Цены Unity Personal Edition: бесплатно Professional Edition: от 75 $ в месяц	Цены Qt Есть бесплатная версия. Платные версии начинаются от 79$.	Цены Appcelerator Indie: 39$ в месяц Есть бесплатный пробный период Цена от 39$ в месяц
Open source	+	-	-	+	+	-
UI	Web	Native	UI Canvas	Native	Native	Web

PhoneGap

PhoneGap позволяет создавать мобильные приложения используя стандартные веб технологии (HTML5, JavaScript and CSS3). В результате это привело к быстрому росту популярности фреймворка, с его помощью можно обойтись без разработки на таких языках программирования как:Java for Android, Objective-C for iOS и C#.

PhoneGap Build позволяет делать сборки для iOS, Android и Windows Phone одновременно, без необходимости устанавливать какие-либо SDK tools (конечно, в этом есть доля лукавства – при разработке всё равно лучше делать сборку локально, хотя бы на Android, перед отправкой на тестирование). Но что более важно, этот сервис позволяет делать сборки для iOS в облаке без наличия Mac.

Установка PhoneGap требует неимоверных усилий, потому советую освободить пол дня… Шутка. Установка для XCode заняла минуты 3 - заключалась в скачивании архива, распаковке и установке. Вот собственно и все.

PhoneGap представляет возможность использовать нативные функции мобильного устройства по работе с:

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

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

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

• PhoneGap имеет простое API, что позволит легко начать разработку, для тех кто сталкивался с HTML, CSS и JavaScript.
• Возможность использования любых существующих JavaScript библиотек (JQuery, Prototype, Sencha Touch)
• Поддержка всех мобильных платформ

Недостатки:

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

Xamarin

Xamarin второй в нашем списке кросс-платформенный фреймворк. Xamarin позволяет создавать одну единственную логику приложения с применением C# и.NET.

Функционально платформа Xamarin представляет ряд субплатформ. Эти субплатформы играют большую роль - через них приложения могут направлять запросы к прикладным интерфейсам на устройствах. Определяется визуальный интерфейс, привязывается логика на C#, и все это будет работать на Android, iOS и Windows Phone. Видео с разработкой приложения на Xamarin.

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

• Большое и развивающееся сообщество.
• Разработчики могут использовать TestCloud для тестирования приложений автоматически.
• Если вы уже знакомы с C# и.NET то вам не нужно будет тратить много времени на изучение нескольких новых фреймворков.
• Можно повторно использовать уже написанный код.
• Приложения под разными системами будут выглядеть очень похоже.
• Динамическая верстка для iOS в бесконечное число раз проще, чем использование constraints вручную.
• За счет CustomRenderer‘ов стандартные контролы легко дополняются произвольными свойствами (например, сделать градиентную заливку кнопок - дело пары минут, хотя «из коробки» это не работает).

Недостатки:

• Некоторые интерфейсные паттерны тяжело реализовать на monodroid и очень тяжело на monotouch, так как решения по умолчанию для той или иной фитчи опираются на костыли платформы, которые могут попросту не работать в Xamarin.
• Возникают проблемы со стороны платформы mono, monotouch и monodroid. Ваше приложение должно удовлетворять особенным требованиям стабильности.
• Android страницы невозможно расположить как часть уже существующего Activity/Fragment.
• Реализованы не все контролы.

Telerik AppBuilder

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

Возможность создавать iOS приложения работая на Windows или Linux еще одно преимущество.

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

• Telerik предоставляет плагины Visual Studio и Sublime Text для AppBuilder.
• AppBuilder предлагает быстрый способ импорта плагинов Cordova.
• Полноценная онлайн IDE.
• Легок в использовании и изучении

Недостатки:

• Небольшое сообщество

Unity

Мультиплатформенный инструмент для разработки 2D и 3D приложений и игр Unity, также один из лучших инструментов для демонстрации 3D контента. Созданные с помощью Unity приложения работают под операционными системами Windows, OS X, Linux, Android, Apple iOS, Windows Phone, BlackBerry, а также на игровых приставках Wii, PlayStation 3 и Xbox 360. Видео с разработкой мобильной игры на Unity.

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

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

Недостатки:

• UI и сложность в использовании для новичков
• Исходный код недоступен
• Компиляторы Unity не оптимизированы для ARM процессоров на некоторых мобильных устройствах.

Qt библиотека для создания кроссплатформенных оконных приложений на C++. Qt стоит рассматривать не столько как набор классов для создания GUI, а скорее как полноценный инструментарий классов на все случаи жизни. Есть возможность разрабатывать программы не только на C++, но и языке QML, сильно схожим с JavaScript. Это особая ветвь развития Qt, направленная на быстрое прототипирование и разработку мобильных приложений. Видео с разработкой Tiled Map Editor на Qt.


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

• Qt имеет множество хороших инструментов которые помогут в разработке, например: IDE QT Creator, Qt Designer и code profiling.
• Он имеет библиотеки, содержащие интуитивно понятные API интерфейсы для элементов, таких как сети, анимации и многое другое.

Недостатки:

• Qt сложен для начинающих

Appcelerator Titanium

Titanium - это полностью открытая платформа для разработки, развертывания, распространения, и, в конечном итоге, для исполнения веб-приложений. Appcelerator Titanium позволяет создавать мобильные приложения на JavaScript, HTML и CSS.

Вы можете создавать современные, а главное - нативные приложения, используя любую популярную на сегодняшний день операционную систему: Windows, GNU/Linux или MacOS X.

Приложения созданные с помощью данного SDK будут действительно нативными. Контроллер навигации на Андроиде будет выглядеть привычно и не так как на iOs. Причем не только вид, но и сам код приложения будет тоже нативный. Это кстати не мешает вам создавать и классический WebView и наполнить его желаемым web контентом.

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

• JavaScript позволяет легко разрабатывать приложения без использования языков платформы.
• Appcelerator позволяет делать аналитику в режиме реального времени
• Использование native API даст более высокую производительность для приложений, которые не очень велики.

Недостатки:

• Есть задержки при запуске приложения из-за загрузки библиотеки
• Трудно создавать сложные приложения, так как использование JavaScript отрицательно сказывается на производительности приложений.

React Native

Что такое React Native? Это JS-фреймворк, основанный на JS и React - JS-библиотеке для создания UI (View-уровня).

Технология очень перспективная, но молодая, поэтому платформа кое-где еще сырая. Версия для Android появилась позже, поэтому для iOS-приложений пока есть больше компонентов. Также стоит учитывать, что при разворачивании приложения на устройство пользователя попадет весь JS, поэтому на уровне презентации не стоит держать секретную бизнес-логику. Можно сказать, что сейчас React Native можно использовать для быстрого прототипирования мобильных версий ваших веб приложений. Причем если веб приложение уже написано на ReactJS, то скорость переноса возрастает в разы. Пример разработки на React Native.

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

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

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

В настоящее время 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 достаточно сложно ввиду специфичности данной области и более высокого порога входа в технологию.

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

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

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

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