Если погуглить на тему сабжа, найдете два типа статей.
Нативное приложение или на PhoneGap? И о бизнесе
Сибирикс
Нативное приложение или на PhoneGap? И о бизнесе
Если погуглить на тему сабжа, найдете два типа статей.
Владимир Завертайлов
Генеральный директор scrum-студии Сибирикс
Одни писали нативщики, в них четко прослеживается линия партии: нативные приложения (сделанные на API конкретной ОС — Java, Objective C, … — и скомпилированные в бинарники для этой платформы) — богоугодны. Все другие решения — по определению должны гореть.

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

Вторые писали парни из лагеря html5 и JavaScript. Они говорят, что html5-приложения (на PhoneGap, например) — это гибкость, будущее технологий, что натив с его мегабайтными дистрибутивами скоро загнется и настанет эра, когда приложения будут ловко выполняться на стороне сервера, обмениваясь с клиентом пакетами данных.

Приложения на Фонгапе вообще можно (ну почти) мигом экспортировать во что угодно: iOS-приложение, Андроид-приложение и т. д. Что по функциональности технология пока не дотягивает до натива — ничего, скоро наверстаем (#оптимизм).
Отдельно про PhoneGap. Это фреймворк, «каркас», служащий для ускорения процесса разработки (и не только). Именно PhoneGap позволяет делать приложения на html5 + JavaScript, после чего компиллировать их в установочные файлы под любую операционную систему: iOS, Android, Windows Phone, да хоть BlackBerry. Что сокращает время производства приложения.

Иван Кожевин
Руководитель отдела программирования
Второй тип приложений, не нативные, еще называют гибридными.
Еще можно сделать чисто веб-приложение (третий путь, ага), которое вообще не нужно будет устанавливать в телефон. Открывается в браузере. По факту это сайт, хорошо оптимизированный под мобильных пользователей. Где там кончается мобильный сайт и начинается мобильное веб-приложение — на самом деле, мало кто понимает. Ну, например, любой более-менее сложный онлайн-сервис, вроде Яндекс.Карты — веб-приложение. Не парьтесь, сегодня про такое не будем.
Что обычно приводится в плюсах и минусах натива и гибрида:
Нативные приложения Гибридные html5-приложения
+ - + -
Быстро работает. Долго и дорого разрабатывать. Кроссплатформенность (сделав одно приложение, его можно экспортировать под любую ОС). Меньше возможностей по интеграции с «начинкой» смартфона (только основное).
Почти не зависит от интернет-соединения. Нужны разработчики именно под определенную ОС. Достаточно будет хороших разработчиков html5/JavaScript — фактически веб-программистов.
Имеет полный доступ к техническим возможностям смартфона. Работает только с определенной платформой. Сроки разработки меньше, чем нативного. Работает медленнее, чем натив.
В общем, плюсов и минусов примерно поровну. Если присмотреться, становится понятно, что одни обвиняют других в чем-то, вслед быстро прикрываясь аргументом «а у нас с этим всё круто!». Противники действуют абсолютно идентично.

Конкурентная война, что с нее взять.

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

Немного исторических параллелей — и станет понятно, почему, собственно, столько камней летит в огород PhoneGap-разработчиков и столько брызжут слюной ярые сторонники тру-нативной разработки.
Человечество вынуждено жить в условиях барьеров — языковых, культурных, территориальных, экономических и так далее.
Причем всегда находятся те, кто хочет объединять и унивесализировать.

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

Надоела пограничная волокита при въезде из Бельгии в Германию? А давайте сделаем Шенгенскую зону!

Почему я не могу положить индийский ковер рядом с венским гарнитуром, а на стену с лепниной барокко приделать корабельный штурвал? Давайте оправдаем мои дизайнерские взгляды и придумаем новый стиль, а назовем его пиздец эклектикой.
Исторический пример: В 1887 польский окулист Заменгоф создал искусственный язык эсперанто, который базировался на простоте грамматики, отсутствии исключений и очень логичном и простом словообразовании. Предполагалось, что он станет единым языком для всех народов, сотрет языковые барьеры. И ныне это самый распространенный искусственно созданный язык. Толкиновский квэнья, на котором разговаривает эльфийский народ и толпы фанатов, не в счет :)
Одни попытки объединять и универсализировать удаются, другие не очень — но тенденция к сохраняется и жить будет всегда. Откуда (и у кого, что важно) берется это желание — все привести к общему знаменателю?
Барьеры, которые построила конкуренция. Конкуренция, которую породили барьеры.
Ну например, наш случай: есть конкурирующие ОС-лидеры: iOS и Android. Дабы отстроиться друг от друга, у каждой ОС есть свой стор (магазин приложений), а чтобы сделать нативные приложения для той и другой площадки — нужно фактически два разных разработчика. Ну или один мультиспециалист, редкий вид. Уже барьер для желающего выложить свое приложение.

Помните картинку из учебников по истории?
Чтобы усилить сей барьер, сторы могут надавать по шапке за ненативные «универсальные» html5-приложения — не пройдете контроль качества. Не факт, но вероятность есть.

Барьер выгоден ИМ, как владельцам стора, «рыночной площади». В глобальном смысле — крупным игрокам.
  • Во-первых, так достигается какая-никакая эксклюзивность предложения. Собрался делать приложение — решай, где оно появится первым.
  • Во-вторых, так отсеиваются низкопробные проекты. Тот же PhoneGap очень заманчиво обещает, что сделаете одно приложение — и как начнете плодить его на всех сторах! Что, естественно, провоцирует появление тучи проектов, сделанных на коленке. Которые сторам не нужны.
Ок, мы обещали о бизнесе. А вам, как заказчику, нужен такой барьер?
Можно, конечно, пуститься в рассуждения, что, мол, да, нужен. Что барьер играет нам на руку, и это круто, что мы делаем эксклюзив для iPhone, а всяким там ведроидоводам он будет недоступен — это подстегнет спрос яблокофилов.

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

Продавцу нужен барьер? Нет. Как только он заявил это свое «нет», появился спрос на универсальное решение. Пользоваться таким — выгодно НАМ (заказчику и разработчику).
  • Заказчик экономит на времени разработки, приближает дату старта.
  • Заказчик получает по рабочему приложению на всех выбранных ОС.
  • Заказчик экономит бюджет на разработку (еще на маркетинг оставить надо).
  • Разработчик экономит ресурсы команды, плюс ему тоже интересно делать больше проектов, а не застревать на одном по году.
Понятное дело, что у универсального средства будут свои недостатки, но и возможностей открывается масса — у тех, кто раньше только помышлял о своем мобильном приложении, теперь есть осязаемая возможность.
Итого
Собственно, вся разница: нативные дорого делать по деньгам и времени. Универсальные на html5 — можно быстрее запустить и их производство дешевле. Натив работает быстрее и стабильнее. Приложение на html5 — всё-таки пристройка, хотя PhonеGap позволяет делать таки очень качественные пристройки, по личному опыту. Он, конечно, не единственное решение, но из всего, что попробовали — подошел почти идеально.

Кто знает, может, настанет время, когда можно будет писать натив под все ОС сразу, будет дружба и мир, а надобностью в Фонгапах отпадет сама собой ;)
В общем, если у вас амбициозные планы по покорению аппсторов всех осей — звоните, проконсультируем, как вам лучше быть.