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

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

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

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

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

» Александр Кузнецов написал для VC колонку об отличиях нативных приложений от кроссплатформенных, в которой объяснил, какой тип разработки будет предпочтительным в тех или иных обстоятельствах.

Время приложений

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

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

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

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

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

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

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

Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то Objective-C и Swift для iOS или Java для Android, такое приложение будет называться нативным (от англ. native - родной, естественный). «Нативки» могут получать доступ ко всем службам, сервисам и примочкам телефона: камере, микрофону, геолокатору, акселерометру, календарю, медиафайлам, уведомлениям и так далее - в общем, полноценно обживаются и чувствуют себя как дома.

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

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

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

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

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

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

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

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

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

Сравнение подходов

Рынок предложений растёт. Статистика продаж мобильных приложений показывает, что год от года пользователи гаджетов всё чаще меняют стандартные сервисы на альтернативные. Так, родной менеджер задач заменяется на Wunderlist, почтовый клиент - на приложение Mailbox, Evernote оказывается предпочтительнее стандартных заметок.

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

Зависимость от платформы

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

Дизайн интерфейса

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

Языковая среда, в которой разрабатываются нативные приложения, обладает необходимыми инструментами для создания привычного пользователю интерфейса. Другая ситуация с веб-технологиями: чтобы сделать кроссплатформенное приложение похожим на нативное, придётся приложить немало усилий. Разные кроссплатформенные фреймворки (Framework 7, Sencha Touch, Kendo UI, Ionic и другие) помогают с той или иной степенью достоверности имитировать нативный интерфейс, но чаще всего отзывчивость, скорость анимации, эффекты и дизайн будут другими. Этому и посвящен следующий пункт.

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

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

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

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

Ограничения

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

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

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

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

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

Комплексное обслуживание нативных приложений для двух платформ (поиск и исправление ошибок, обновление и любое незначительное изменение) в среднем занимает в два раза больше ресурсов по причине необходимости как минимум двух разных специалистов (iOS и Android). С кроссплатформенным приложением может управляться один разработчик.

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

Быстрая и дешёвая кроссплатформенная разработка - миф или реальность

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

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

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

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

Исходя из вышесказанного, был произведен расчёт стоимости мобильной разработки в случае нативного и кроссплатформенного подходов, представленный в двух таблицах. Результаты в таблице 1 отталкиваются от средней почасовой ставки фрилансеров из баз freelansim.ru и fl.ru в рублях, в таблице 2 - средней почасовой ставки фрилансеров и студий из международной базы upwork.com в долларах.

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

Но есть нюанс

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

Резюме

К нативной разработке стоит прибегать, если:

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

Ваш вариант - кроссплатформенная разработка, если:

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

К выбору той или иной стратегии всегда приводят индивидуальные обстоятельства, ни одна статья не даёт универсального ответа.

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

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

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

Следующее высказывание с легкостью может прозвучать от того, кто только что начал изучать Titanium:

JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.

Titanium !== HTML

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

Что ты имеешь в виду под «Нативной» разработкой?

А что делает приложение нативным?

• Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
• Разработчик использует стандартный для платформы язык?
• Приложение использует строительные блоки (API), которые предоставляет платформа?
• Приложение работает так, как ожидает пользователь на этой платформе?

Что такое хороший User Experience?

Выглядит и ведет себя ожидаемо

Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.

Чувствуется ожидаемо

Как достичь классного UX?

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

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

Давайте для начала пройдемся ещё раз по терминологии.

Родные

Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то Objective-C и Swift для iOS или , такое приложение будет называться нативным (от англ. native — родной, естественный).

Преимущества нативных приложений:

• скорость работы и отклика интерфейса. Приложение реагирует на нажатия мгновенно, практически отсутствуют задержки в анимации, скроллировании, получении и выводе данных;
• понятный и простой доступ к функциям и датчикам устройства. Для разработчика не представляет проблемы работа с геолокацией, пуш-уведомлениями, съёмкой фото и видео через камеру, звуком, акселерометром и другими датчиками;
• возможность углублённой работы с функциями смартфона. Как и в предыдущем пункте, такие вещи, как анимации, создание сложных интерфейсов и работа нейросетей прямо на устройствах реализуются, может быть, и не просто, но прогнозируемо;
• . Нативные приложения обычно оперируют «платформенными» элементами интерфейса: меню, навигация, формы и все остальные элементы дизайна берутся от операционной системы и потому привычны и понятны пользователю.

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

И не родные

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

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

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

Предполагается, что большая часть такого кода может переносится между платформами — очевидно, что, например, логика совершения покупок, сохранения товара в корзину, просчёта маршрута для такси, написания сообщения в мессенджер не меняется в зависимости о того, Android у клиента или iOS. Нужно лишь доработать UI и UX для платформ, но сейчас, в определённых пределах, даже это можно объединить — например, меню-гамбургер активно используется как на Android, так и на iOS. Так что даже внесений исправления в интерфейс для того, чтобы приложение отвечало духу и букве нужной платформы — вопрос желания, необходимой скорости и качества разработки.

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

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

Недостатки:

• неродной интерфейс или, как минимум, необходимость работы с интерфейсом каждой платформы отдельно. У каждой системы свои требования к дизайну элементов и иногда они взаимоисключающи. При разработке это необходимо учитывать;
• проблемы в реализации сложных функций или возможные проблемы работы даже с простыми процедурами в силу ошибок самих фреймворков разработки. Кроссплатформенная среда лишь транслирует запросы к системным вызовам и интерфейсам в понимаемый ею, системой, формат, и потому на этом этапе возможны как сложности с пониманием, так и возникновение ошибок внутри самого фреймворка;
• скорость работы. Так как кроссплатформенная среда является «надстройкой» над кодом (не всегда, но в определённых ситуациях), в ней возникают свои задержки и паузы в отработке действий пользователя и выводе на экран результатов. Это было особенно заметно несколько лет назад на смартфонах, более маломощных относительно сегодняшних, однако сейчас, с ростом производительности мобильных устройств, этим уже можно пренебречь.

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

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

Как мы написали выше, есть два подхода — превращение кода в нативный на этапе сборки или добавление определённой обёртки, транслирующей вызовы к системе и от неё.

Cordova и PWA — два инструмента, работающие как раз в идеологии обёртки.

Cordova и HTML5

Одно из самых популярных направлений в кроссплатформенном программировании, которое часто по-народному называют PhoneGap. Фактически создаётся мобильный сайт, который «оборачивается» небольшим платформенным кодом, транслирующим вызовы от системы к приложению и обратно.

Все недостатки и достоинства тут выражены как нигде ярко. Вы можете использовать веб-разработчиков (HTML, CSS и JavaScript как основные технологии) и за месяц или даже пару недель сделать первую версию приложения за относительно небольшие деньги. Да, она будет подтормаживать в работе, возможно, в ней будет не совсем точная геолокация, но она будет работать на всех устройствах и позволит вам, как минимум, протестировать спрос со стороны клиентов на мобильных устройствах.

Для такого подхода создано огромное количество фреймворков, но все они делают фактически одно и тоже. Различие между ними в том, что Cordova (PhoneGap) не задаёт ограничений и шаблонов на логику и UI для вашего HTML5-проекта, а фреймворки оперируют собственными готовыми UI-элементами, имитирующими мобильные платформы, и своей логикой разработки. В качестве примера такого подхода можно указать: Ionic Framework — обёртка; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI — интерфейсные фреймворки.

PWA

Модная технология от Google — это те же самые веб-приложения, но за счёт использования определённых технологий (в первую очередь это так называемые Service Worker — работающие в фоновом режиме скрипты, и Web App Manifest — описание веб-приложения в понятном для мобильной системы виде) они без обёртки из PhoneGap могут работать как нативные. Они могут устанавливаться на домашний экран в обход магазина приложений, работать в офлайне, работать с пуш-уведомлениями, с нативными функциями.

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

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

Xamarin

Платформа компании Microsoft. Используется стандартный для Enterprise-разработки язык программирования С#, кроссплатформенная среда разработки — Visual Studio. На выходе — нативные приложения для iOS, Android и Windows. Правда, относительно большого размера.

React Native

Платформа от — приложения пишутся на JavaScript и с использованием CSS-подобных стилей. Интерфейс получается родной, а код интерпретируется уже на платформе, что придаёт ему нужную гибкость.

Будучи относительно молодой платформой, React Native пока очевидно (хоть и не катастрофически) страдает от недостатка средств разработки и документации.

Flutter

Естественно, не мог обойти тему кроссплатформенной разработки Android и iOS-приложеий и такой гигант, как Google. Flutter, пока, правда, существующий только в бета-версии, исповедует отличный от React Native и Xamarin подход. Он не превращает исходный код в нативный, который выполняется платформой, а на самом деле рисует окно на экране смартфона и отрисовывает все элементы сам. В качестве языка используется «фирменный» Dart, который Google создал как усовершенствованную версию JavaScript.

У этого есть как преимущества (например, внешне идентичные интерфейсы), так и недостатки (например, перерисовка интерфейса требует определённых затрат памяти и процессорного времени).

Платформа быстро развивается и Google вкладывает в это много сил и средств. Но по сравнению с Flutter даже React Native кажется вполне устоявшейся и впечатляющей экосистемой.

Что выбрать

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

• должно хоть как-то работать на любом устройстве? Выбирайте HTML как основу;
• у вас достаточно средств, нет спешки и вы хотите самое качественное приложение? Вам прямой путь в нативную разработку ;
• у вас есть «встроенный» веб-разработчик или вы просто хотите быстро и просто попробовать мобильное приложение в деле? Тут можно рекомендовать Cordova/HTML или PWA ;
• у вас есть собственная CRM-система и поддерживающий ее C#-разработчик? Берите Xamarin ;
• вы «хотите попробовать», но надо сделать всё красиво и модно? Смотрите в сторону React Native или Flutter .

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

• простое приложение-визитка? Возьмите React Native или HTML5 и вы получите две платформы за минимальную цену;
• у вас есть сайт с большой посещаемостью и вам нужно протестировать гипотезу присутствия в мобильном пространстве? HTML5 ;
• сложные приложения с доступом к нужным функциям устройств? Нативная разработка, Xamarin, React Native .

Кроссплатформенная разработка — не панацея

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

У вас остались сомнения и вопросы о кроссплатформенных приложениях? Почитайте о том, как мы создавали приложение для быстрого получения абонемента в одно из спортивных заведений города и попробуйте приложение для оплаты всевозможных видов услуг — от ЖКХ до заказов в интернет-магазинах. А лучше запишитесь на бесплатную консультацию, с указанием примерного бюджета и кратким описанием идеи или свяжитесь с нашим менеджером Катей по телефону

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

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

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