Как узнать приложение нативное или гибридное

Обновлено: 06.01.2025

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

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

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

Родные приложения

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

Веб-приложение для конкретной платформы

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

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

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

Минусы:

По-прежнему подлежит одобрению магазина процесс и распределение доходов. Нет мгновенного обновления.
Производительность приложения по-прежнему зависит от возможностей браузера устройства.

Информированное решение

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

В своей работе я всегда смотрю в будущее, и мой хрустальный шар рассказывает мне очень хорошие вещи о веб-приложениях и расширяющихся возможностях технологий HTML5. Уже есть несколько замечательных примеров игр на основе HTML5, которые дают опыт, который ранее был возможен только с помощью Flash, см. Pirates Love Daisies .

Мобильные приложения для всех!

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

Осталось буквально четыре дня до момента, когда мы закончим принимать заявки на участие во второй «Мобилизации» Яндекса. Она вновь объединит четыре летние школы для начинающих специалистов: Школу менеджмента, Школу мобильного дизайна, Школу разработки интерфейсов и Школу мобильной разработки под Android.

Своим опытом и знаниями с участниками будут делиться не только сотрудники Яндекса, которые делают приложения для миллионов пользователей, но и приглашенные специалисты. Мы не обойдемся только теорией. Будет много практики и командной работы над настоящими продуктами. Как всегда, обучение бесплатное, а всем иногородним студентам Яндекс оплатит проезд и проживание. Если вы еще не отправили заявку, есть немного времени это сделать. Занятия стартуют 3 июля и закончатся 23 сентября — в день двадцатилетия Яндекса.

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

Юрий Подорожный. Руководитель службы разработки мобильных геоинформационных сервисов Яндекса. Работает над Яндекс.Картами и Яндекс.Метро. Занимается мобильной разработкой более восьми лет. Основатель студии Any Void, которая в 2014 году стала частью Яндекса.

Сергей veged Бережной. Руководитель отдела разработки поисковых интерфейсов, в Яндексе с 2005 года. Успел поработать над Поиском, Почтой, Поиском по блогам, Я.ру, Картинками, Видео. Помимо этого, активно занимается развитием внутренних инструментов для создания сайтов.

Лола Кристаллинская. Руководитель департамента дизайна, работает в Яндексе с 2008 года, отвечает за найм, управление и развитие дизайнеров, коммуникации и образовательные программы департамента и всю экосистему дизайна в компании. С Лолы начался коллектив дизайнеров и исследователей дизайна Яндекса. До прихода в компанию руководила отделом создания сайтов Студии Артемия Лебедева.

Лола Кристаллинская:
Давайте для начала дадим определение, что вообще такое нативная и гибридная разработка и в чем между ними разница?

Лола:
В части программирования это было что-то революционно новое?

Юрий:
Конечно, нет. Сам термин «нативная» возник просто на контрасте с гибридным подходом.

Сергей Бережной:
Под гибридной разработкой мы подразумеваем способ писать приложения, когда оно полностью или частично рендерится и работает с помощью веб-технологий. То есть внутри используется что-то, реализованное с помощью HTML, CSS, JavaScript.

Юрий:
На самом деле чистое веб-приложение сейчас не сделать. Веб-вью все равно нужно положить внутрь iOS или Android-приложения, то есть в любом случае нужен контейнер, который написан с помощью Java, Swift или Objective-C. Значит, все равно будет какой-то процент нативного кода. Чистые веб-приложений были, наверное, только первый год существования iPhone, когда еще нельзя было создавать их со стороны. И Apple тогда продвигала тему, чтобы разработчики делали веб-приложения. Кстати, эта функция есть до сих пор. Заходишь в Safari, нажимаешь на экран «домой», на рабочий стол добавляется иконка, по сути, это и есть чистое веб-приложение. Только его, конечно, не распространишь через Store.

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

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

Гибрид для простых задач, натив — для сложных

Лола:
В таком случае актуальна ли вообще проблема выбора? Например, я менеджер, у меня есть продукт и мне нужно сделать мобильную версию. Как принимать решение, что для меня лучше — гибридная разработка или нативная?

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

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

Юрий:
Есть, конечно, удачные примеры гибридных приложений. Например, интересная модель у Basecamp: часть навигации реализована нативно, для того, чтобы переходы осуществлялись быстро и плавно, а отображение контента в списке задач сделано на HTML, благодаря чему у них одинаковые шаблоны для тачовой и мобильной версий. Но у нас в Яндекс.Картах всегда был нативный подход, потому что сделать приложение с картами, которое будет производительным и удобным, с помощью веб-технологий просто невозможно. Единственное место, где мы используем веб, это вывод лицензионного соглашения.

Скованные гайдлайнами

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

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

Кроме того, встает вопрос, хотите ли вы трижды рисовать разный дизайн для каждого приложения. Ведь гайдлайны операционных систем сильно отличаются друг от друга, и как лебедь, рак и щука двигаются в разные стороны в мелочах. Если внимательно прочитать гайды Windows Phone, Android и iOS, то окажется, что нужно хорошо продумать, как ваша пользовательская задача будет оптимально решаться на каждой из платформ.

Лола:
Если приложение сделано не по гайдам, то проверку в Store не пройти?

Юрий:
Можно, конечно. Далеко не все приложения, прошедние проверку в Apple, соответствуют дизайнерским гайдлайнам. Никто особо не следит за соблюдением этих правил.

Сергей:
Но мы же говорим о приложениях A+ и AAA-класса, о высшей лиге. Если такие делать, то вопрос о нативном дизайне для каждой платформы обязательно встанет.

Лола:
А общий дизайн невозможен в нативной разработке: если просто свои кнопки и контролы?

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

Как делают приложения в Яндексе

Лола:
Для многих тот факт, что Facebook разочаровались в веб-технологиях и перешли на нативную разработку, стал доказательством превосходства последней. Насколько это обосновано?

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

Юрий:
У Facebook в первой версии было полностью нативное приложение, потом они перешли на HTML, пару лет пожили с двумя звездочками в Store, потому что продукт реально тормозил, все их ругали, в итоге вернулись к нативу. Вот живая иллюстрация того, как из благих намерений хочешь сделать хороший интерфейс на веб-технологиях, но в итоге все равно упираешься в низкую производительность или недостаток средств для развития.

Лола:
Но поисковое приложение Яндекса, например, сделано гибридно. Почему, если столько недостатков у веб-технологий?

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

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

Юрий:
Помимо UI, есть еще вопрос удобства пользователя. И у каждой платформы свой UX. Пользователи ожидают, что хорошее приложение будет удобным и будет следовать их привычкам.

Лола:
Как вы в своих продуктах решаете проблему баланса между удобством пользователей и единством бренда?

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

Сергей:
Основные движущие факторы наших экспериментов с технологиями — это оптимизация трудозатрат на разработку и желание предоставить пользователям качественный продукт. Изначально мы делали наше поисковое приложение нативно, но столкнулись, например, еще с такой проблемой, как синхронизация команд и релизов. Даже если изначально вы решили потратиться на разных разработчиков под три разные платформы, то в дальнейшем рискуете столкнуться с проблемой управления. Как сделать так, чтобы новый UI, новые фичи на этих платформах везде обновлялись в одно время, и чтобы у них было действительно синхронное понимание этого интерфейса?

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

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

Что нужно знать разработчику, чтобы начать делать приложения

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

Юрий:
Разработчик нативных приложений должен знать Objective-C, или SWIFT, или Java, или C++. Но, на мой взгляд, на каком языке писать, дело наживное, ключевое здесь — базовые знания программирования. Все, с кем я в своей жизни делал приложения, были студенты без мобильного опыта, но с хорошим бэкграундом. Все остальное постигается на практике. Попадешь в хорошую команду профессионалов, вырастешь на порядок быстрее.

Сергей:
Если у человека есть опыт разработки интерфейсов с помощью HTML, CSS или JavaScript, то придется глубже погрузиться в специфику именно мобильных браузеров. Если мы говорим об интерфейсах, то это паттерны взаимодействия — больше пальцами, меньше с клавиатурой. Своя специфика внутри Runtime JavaScript и CSS для мобильных браузеров, но отличий в последнее время все меньше. Как правило, разработка под мобильные проще, чем под широкий спектр десктопных браузеров, потому что у них, как относительно новой технологии, более современная реализация именно веб-стандартов. Но сейчас по мере того, как мобильные платформы стареют, начинают возникать те же проблемы, что на десктопе, когда есть клиенты со старыми браузерами, которые какие-то вещи не поддерживают.

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

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

Сергей:
Согласен, разрабатывать под микроконтроллеры или пользовательские интерфейсы — вещи действительно очень разные, и перепрыгнуть из одной лодки в другую не так-то просто. Но если говорить о мобильной разработке, то в Яндекс мы берем людей, которые верстают наши сайты сразу под декстопные и мобильные версии. То есть они должны понимать, как наша верстка, наш HTML, CSS и JavaScript будут работать в десктопных браузерах, а как в мобильных, какие есть особенности и нюансы. Получается, как с дизайнерами, дополнительный скилл фронтенд-разработчика.

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

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

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

Адаптивная верстка — не панацея

Лола:
Я слышала, что для бедных, но хитрых, есть еще такая вещь, как адаптивная верстка, которая сразу и для веба, и для мобильных.

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

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

Лола:
Давайте резюмируем, как менеджеру, дизайнеру и разработчику учитывать все эти нюансы?

Сергей:
Я рекомендую не быть упоротыми фанатиками и каждый раз осознанно делать выбор, имея в голове как можно более широкий контекст и принимая во внимание все факторы. Не мыслить типа «Раз Facebook перешел с гибридного подхода на нативный, значит, и нам нужно» или «Раз Яндекс верстает свою выдачу в приложении на веб-технологиях, значит, и нам надо делать так». Нужно погрузиться в тему.

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

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

С одной стороны, исследователи прогнозируют, что совокупная доходность мобильных приложений во всем мире в 2023 году превысит сумму в $935,2 миллиарда. С другой стороны, эти показатели ставят перед организациями большую дилемму: какой тип приложения следует создавать для долгосрочного успеха?

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

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

Согласно опросу Buildfire, в мире насчитывается приблизительно 2,7 миллиарда пользователей смартфонов, половина из которых используют планшеты.
Прогноз из доклада eMarketer показывает, что в среднем взрослые американцы в 2018 году проводили в мобильных приложениях немногим более 3-х часов, что превысило предыдущий показатель на 11 минут.
В отчете этого исследования говорится, что в среднем американцы проверяют свои телефоны по 80 раз в день или каждые 12 минут.
В том же докладе eMarketer сказано, что 90% времени использования интернета приходится на долю смартфонов, а также то, что взрослые граждане США прослушивают через мобильные приложения более 50 минут аудио в день. Для сравнения можно отметить, что на социальные сети затрачивается в среднем 40 минут в день.
По данным Statista социальные сети в 2019 году являлись наиболее посещаемыми интернет ресурсами среди индийцев.
Еще одно смежное исследование показало, что Google Play Store является ведущей платформой, содержащей приблизительно 2,56 миллиона приложений, в то время как Apple занимает второе место, предлагая около 1,85 миллионов приложений. Более того, с учетом увеличения числа приложений, предлагаемых разными магазинами, прогнозируется, что к 2022 году количество их скачиваний достигнет показателя в 258,2 миллиарда.

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

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

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

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

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

Обзор

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

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

Нативные приложения создаются для конкретной платформы, нацеливаясь на пользователей либо Android, либо iOS. Если вы хотите сфокусировать внимание на пользователях обеих платформ, тогда будьте готовы к разработке двух отдельных приложений, одно для Google Play Store, а второе для Apple App Store. Поскольку каждая из этих платформ имеет совершенно различные стандарты, для их соблюдения использовались разные языки программирования.

Плюсы:

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

Минусы:

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

Гибридные приложения: пишутся один раз и запускаются на всех устройствах

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

С другой стороны, гибридные приложения — это профессиональное решение для развивающихся стартапов и бутстрэпперов, так как они обеспечивают высокую скорость разработки и позволяют создавать идеальные решения для бизнеса. Если UX и производительность не стоят в качестве приоритетов, тогда гибридное приложение окажется превосходным решением. Среди основных инструментов для их разработки можно назвать Flutter, Ionic, React Native, Visual Studio и др.

Плюсы:

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

Минусы:

Производительность: их производительность ниже, чем у нативных вариантов, так как зависит от качества процессов, отображающих UI и выполняющих код. Поэтому чем быстрее использующее приложение устройство, тем выше его производительность.
Интеграция сторонних сервисов: Вы не можете разрабатывать гибридное приложение на одном только JavaScript. Вам потребуется интегрировать такие фреймворки для гибридной разработки, как Cordove, Ionic или React Native, каждый из которых требует определенных усилий для освоения.

web-приложения: одно приложение для всех типов экранов и платформ

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

Плюсы

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

Минусы:

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

Web-приложения

Web-приложения разрабатываются со сложным интерфейсом и функциональностью, поэтому итоговая стоимость может оказаться несколько выше, чем в случае с гибридными. Средний бюджет такого проекта может составлять от $7,000 до $50,000, а иногда и существенно превышать этот порог.

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

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

*В этой статье мы рассматриваем гибридные приложения на основе веб-браузера.

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

Интересно! Согласно статистике от Flurry Analytics 90% всего времени за телефоном мы проводим именно в приложениях.

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

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

ГИБРИДНЫЕ И НАТИВНЫЕ ПРИЛОЖЕНИЯ

Итак, чем же отличаются эти два типа приложений друг от друга?

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

Для написания нативного приложения для iOS будет использоваться Swift или Objective-C. Для нативных Android приложений подойдут Java или Kotlin.

Однако согласно статистике от VisionMobile, 47% всех нативных iOS приложений и 42% всех нативных Android приложений на самом деле также используют HTML5.

А вот и пример нативного приложения:

Известное во всем мире приложение для электронной торговли Bounce было написано нашими разработчиками на языках Swift для iOS и Java для Android.

Приложение доступно в Apple Store и Google Play.

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

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

Приложение доступно в Apple Store и Google Play.

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

ПЛЮСЫ ГИБРИДНЫХ ПРИЛОЖЕНИЙ

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

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

МИНУСЫ ГИБРИДНЫХ ПРИЛОЖЕНИЙ

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

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

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

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

Скроллинг - вертикальная или горизонтальная прокрутка страницы.

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

Компиляция - процесс перевода высокоуровневого языка программирования (PHP, Java, JavaScript) в машинный.

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

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

ПЛЮСЫ НАТИВНЫХ ПРИЛОЖЕНИЙ

Высокое качество. Узко-специализирующийся разработчик нативных приложений напишет вам чистый, уникальный код. Многолетний опыт разработки и четкие стандарты нативных iOS & Android приложений помогут сделать качественный продукт с широким функционалом и снизить риск появления багов практически до минимума.
Низкая вероятность отказа в размещении в App & Play Stores. Поскольку нативное приложение изначально отвечает стандартным требованиям определенной платформы, маловероятно, что вы столкнетесь с какими-либо проблемами при запуске вашего приложения в официальных магазинах App Store и Play Store.
100% использование UX дизайна. Современные пользователи избалованы яркими, детально-проработанными интерфейсами, и простые, стандартизированные приложения навряд ли заинтересуют их. Именно в нативной разработке UX дизайн используется на все 100%, что позволяет сделать качественное и интересное приложение. В гибридном приложении вы получите стандартизированный для двух платформ интерфейс.

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

МИНУСЫ НАТИВНЫХ ПРИЛОЖЕНИЙ

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

ИНТЕРЕСНЫЙ ФАКТ

Вы удивитесь, когда узнаете, что на самом деле разработать нативное iOS приложение стоит дешевле гибрида. Не верите? Смотрите сами!

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

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

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

Исходя из этого, получается, что, создать одно нативное iOS приложение дешевле, чем одно гибридное iOS приложение.

Если же сравнивать разработку гибридного приложения и двух нативных, то цена гибрида будет ниже, как и ожидалось, ведь в гибридном приложении backend и frontend подходят для двух платформ сразу.

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

HYBRID iOS APP - $11.5K
HYBRID iOS + Android APPS
$12.5K

NATIVE iOS APP - $10K
NATIVE iOS + Android APPS
$18K

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

Вот теперь и думайте, экономить ли при разработке одного приложения, или нет? А может сразу сделать два нативных?

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

КАКОЕ ПРИЛОЖЕНИЕ ВЫБРАТЬ?

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

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

ИТАК,

Выбирайте гибридное приложение, если вы хотите получить:

простое приложение
приложение для двух платформ по бюджетной цене
1 приложение с возможностью быстрого выхода на два рынка (ios/Android)

Выбирайте нативное приложение, если вам нужно:

профессиональное приложение, соответствующее всем стандартам выбранной платформы
сложное приложение с широким функционалом
приложение с высокой скоростью работы

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

Воплотите все ваши самые смелые мечты и идеи в реальность вместе с Umbrella IT.

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

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

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

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

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

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

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

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

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

Гибридная разработка позволяет обновлять контент непосредственно из Интернета. Если нет какого-то резкого изменения функциональности, то обновления получаются практически незаметные. Многие из этих обновлений могут быть установлены не через App Store. Это делает исправление ошибок и добавление обновлений более эффективным, и заставляет пользователя меньше раздражаться. Тем не менее, есть одно предостережение, связанное с веб-обновлениями.

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

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

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

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

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

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

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

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

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

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

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

Читайте также: