Разработка нативных и гибридных мобильных приложений

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

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

Существуют чистые веб-приложения, которые выглядят почти как нативные. Например, app.ft.com. Их следует отделять от гибридных.

Чистые веб-приложения без сети не работают.

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

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

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

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

Поддержка гибридных приложений обходится дешевле, так как, опять же, вроде как код один для всех платформ. Меняем в одном месте — и готово.

Нативные приложения работают гораздо быстрее гибридных и веб-приложений.

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

При разработке нативных приложений мы получаем оригинальный UI для каждой платформы. Гибридные и веб этого не могут.

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

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

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

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

Гибриды

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

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

Что ты знаешь о боли? WebView для Android версии 4.3 ужасно тормозит, когда требуется показать что-то чуть более сложное, чем текстовую инфу. В версии 4.4 движком для WebView стал Chromium, так что, возможно, это немного исправит ситуацию. В целом, для всех фонгаперов и иже с ними это означает боль и страдание при попытке запустить приложение на Android. На iOS ситуация с этим намного лучше, так как движок на сафари работает получше.

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

Разруха не в клозетах, а в головах. Еще один важный фактор, который почему-то никто не учитывает. Разработчики на PhoneGap — это обычно Фронт-енд разработчики. Они понятия не имеют о том, как должен выглядеть интерфейс под Android или iOS, так как не читали стайл-гайды. Они ничего не знают об особенностях платформы, потому что не читали документацию. Но они хорошо умеют делать сайты. Соответственно, вы получите приложение, похожее на сайт. Оно вам надо? Точно надо? Посмотрите на эту картинку? Вы все еще уверены в своем выборе?

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

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

Нативные

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

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

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

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

Вывод

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

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

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

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

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

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

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

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

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

Время

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

Обновления

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

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

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

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

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

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

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

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

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

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

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

Вывод

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

Недостатки

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

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

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

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

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

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

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

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

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

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

Область мобильных игр

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

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

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

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

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

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

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

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

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

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

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

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

Использование единой логики приложения. Логика, заложенная в работу приложения, будет работать гарантированно одинаково для всех платформ. Довольно часто это может являться и минусом из-за разной архитектуры операционных систем. Яркий пример – кнопка “Назад” в навигации между экранами. В 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). Если какой-то проект нужно сделать быстро для проведения каких-либо тестов, при этом ситуация требует работы проекта именно на нескольких платформах одновременно, кроссплатформенная реализация может быть оптимальным решением.

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

Источник: dstglobal.ru