Сравнительный анализ нативных и web-приложений

Охват

Мобильный рынок фрагментирован. Для того, чтобы охватить всех пользователей, необходимо создавать приложения для iPhone, Android, Blackberry, Symbian, Windows Phone. Это сопряжено со значительными издержками.
Наши клиенты приняли решение создавать приложения для устройств на базе iOS и Android, которые вместе составляют до 55% американского рынка мобильных устройств.

Мобильные веб-приложения имеют гораздо более широкий охват. Однако, рынок мобильных браузеров также фрагментирован, и существует более 60 различных версий браузеров. Использование платформ для разработки мобильных веб-приложений, таких как Sencha Touch, JQuery Mobile или Sproutcore, позволяет снизить необходимость проверки работоспособности приложения во всех браузерных движках.

Пользователь- ский интерфейс

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

User experience веб-приложений обычно менее богат. Однако, мы использовали Sproutcore, мощный JavaScript-фреймворк, основанный на разработанной Apple платформе Cocoa. Sproutcore позволяет веб-приложениям выглядеть и управляться примерно так же, как десктоп-программы. Это достигается ценой сложных программных ухищрений, так что может страдать производительность приложения. Нам пришлось провести несколько оптимизаций, чтобы такие опции, как скроллинг, работали гладко и без задержек.

Доступ к аппаратным возможностям

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

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

Поддержка

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

Обновления веб-сайта вступают в силу немедленно после внесения изменений.

Фрагментация

Причина фрагментации — различия в аппаратных параметрах мобильных устройств, а также в операционных системах и даже в различных версиях одной и той же OS. Разработчикам нативных приложений необходимо обеспечить работу приложения на всех поддерживаемых устройствах и платформах, а в отсутствие определённых возможностей у конкретного устройства или платформы приложение, тем не менее, должно работать, пусть и в ограниченном варианте.
В случае PBS нам пришлось разрабатывать iPad-приложение, позволяющее пользователю просматривать (частично или полностью) видео на устройстве. Приложение также определяло ближайшую станцию телевещания на основе геотаргетинга. Поскольку целью разработки был iPad, мы решили создать нативное приложение. Случай с Carfax оказался более сложным — была необходима поддержка Android и iPhone и нескольких форм-факторов и версий каждой платформы. Кроме того, для сканирования номеров был нужен непрерывный автофокус камеры, более того — мы намеревались использовать вспышку. Поэтому мы разработали нативное приложение. Первоначально приложение проверяло, поддерживает ли камера непрерывный автофокус и есть ли вспышка. Если непрерывный автофокус не поддерживался, кнопка сканирования отключалась. Если вспышки не было, отключалась кнопка управления вспышкой. Однако, огромное разнообразие устройств на этих платформах сделали тестирование совместимости очень сложным процессом.

Хотя для мобильных браузеров фрагментация также характерна, почти 85% браузеров для смартфонов используют Webkit, открытый движок, применяемый в устройствах на базе Android, iOS, Symbian и BlackBerry. Единственные браузеры, не имеющие в основе Webkit, — Opera и Mozilla.
Однако производители могут разрабатывать для своих устройств собственные браузеры, основанные на модифицированном Webkit. В результате Webkit-браузеры отличаются друг от друга, поэтому веб-приложения приходится тестировать для всех возможных комбинаций OS/браузер. Как было сказано выше, использование готовых программных библиотек, проверенных и работающих в большинстве браузеров, снижает необходимость в широком тестировании.

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

Нативные приложения оптимизированы под архитектуру устройства и используют аппаратное ускорение. Для таких приложений, как игры со сложной 2D- и 3D-графикой или с высоким уровнем интерактивности, нативное приложение — единственный вариант.

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

Расходы на разработку

Опытные разработчики нативных приложений сейчас пользуются большим спросом, что повышает расходы на разработку. Кроме того, различные мобильные платформы имеют совершенно разные программные модели и API. Поэтому необходимо разрабатывать (и поддерживать) отдельные приложения для каждой OS (и даже для разных версий одной и той же OS). Это приводит к существенному росту затрат.

Разработчики веб-приложений встречаются гораздо чаще. Однако, как было сказано выше, для создания богатого user interface мы использовали Sproutcore, мощный, но сложный фреймворк. Мы решили пожертвовать лёгкостью разработки ради совершенства интерфейса.

Монетизация

Нативные приложения могут использовать платёжные механизмы, предоставляемые апп-стором. Однако, доходом придётся делиться с владельцем магазина. Например, Apple забирает себе 30% продажной стоимости приложения.

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