Кроссплатформенные приложения ios android. Натив или кроссплатформа — что выбрать начинающему мобильному разработчику? Отвечают эксперты

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

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

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

Зачем нужны кросс-платформенные инструменты?

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

Нативные инструменты = предоставляются владельцем экосистемы.

Все остальные признаки «нативности» ВТОРИЧНЫ - поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.

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

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

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

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

Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt .

Теперь можно поговорить и о мифах.

Миф 1. Магия

Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.

Главный принцип, лежащий в основе кросс-платформенных решений, - разделение кода на две части:

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

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

При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.

Итак, все кросс-платформенные приложения обязаны иметь нативную часть, иначе операционная система просто не сможет их запустить. Поэтому давай рассмотрим подробнее, какие системные API и механизмы предоставляются самими iOS, Android и Windows. Переходим к следующему мифу.

Миф 2. Ненативно!

Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.

Все операционные системы: iOS, Android и Windows UWP - предоставляют доступ к следующим подсистемам (наборы системных API):

• WebView (встроенный в приложение веб-браузер) используется в гибридных приложениях на базе PhoneGap и фактически выступает средой выполнения локального веб-сайта;
• JavaScript-движки используются в React Native и аналогах для быстрого выполнения JS-кода и обмена данными между Native и JS;
• OpenGL ES (или DirectX) используется в игровых движках и приложениях на Qt/QML или аналогах для отрисовки интерфейса;
• UI-подсистема отвечает за нативный пользовательский интерфейс приложения, что актуально для React Native и Xamarin.

Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:

WebView - приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.

JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.

OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.

Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос - как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.

Если резюмировать - то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.

Миф 3. Костыль на костыле

Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно - взрослые зрелые решения с длительной историей.

Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.

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

Приложение на PhoneGap - это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части - просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.

При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок - это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.

Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.

Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) - это надстройка над ними.

Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма P/Invoke . Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.

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

Qt - «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.

Подведем итог: все кросс-платформенные фреймворки используют стандартные нативные возможности операционных систем, являются зрелыми, создаются опытными командами и сообществом open source при поддержке гигантов IT-индустрии. И наконец, пришло время для самого «сильного» аргумента.

Миф 4. Медленно

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

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

• PhoneGap: HTML/JS и Native Java / Objective-C / C#;
• React Native: JS и Native Java / Objective-C / C#;
• Xamarin: Mono и Native Java / Objective-C;
• Qt: С++ и Native Java / Objective-C.

Таким образом, при сравнении производительности надо учитывать скорость работы:

• кросс-платформенной части;
• нативной части;
• моста.

Если набрать в поисковике, например, react native vs swift performance, то можно посмотреть множество различных тестов, и во многих из них отмечается, что производительность резко падает при активном использовании моста, включая активное манипулирование UI из кросс-платформенного кода. Для Xamarin ситуация выглядит таким же образом - кросс-платформенная часть очень быстра и сопоставима с нативной в обработке данных, однако при использовании моста может падать производительность. Qt вообще работает на уровне С++, который быстр сам по себе. Если же рассматривать решения на базе PhoneGap, то здесь производительность будет сильно зависеть от WebView, но все же не следует активно менять UI в JavaScript-коде или проводить научные вычисления.

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

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

Что такое кроссплатформенные приложения?

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

Напомним: нативные приложения, в отличие от кроссплатформенных, пишутся под конкретную ОС.

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

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

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

1. Большая зависимость от мобильного устройства

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

2. Недружелюбный пользовательский интерфейс

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

Проблема в том, что для кроссплатформенной разработки не бывает гайдлайнов – стандартов разработки от создателей ОС. Поэтому кроссплатформенное приложение, сделанное «под Android», не будет удобным пользователю iOS, и наоборот. Можно, конечно, создать отдельные дизайны для каждой платформы, но по объёму трудозатрат это будет равно созданию двух разных приложений, хоть и на одном языке.

3. Борьба за первенство среди инструментов разработки

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

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

Какое приложение подойдёт вашему бизнесу?

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

1. Чем пользуется ваша аудитория?

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

Связь между выбором мобильного устройства и уровнем платёжеспособности в очередной раз подтвердила компания App Annie. В результате исследования числа загрузок и объёма продаж мобильных приложений в Google Play и App Store за первый квартал 2018 года выяснилось, что пользователи Android-смартфонов скачали на 135% больше приложений, чем посетители iOS-магазина. В то же время App Store принёс своим владельцам на 85% больше дохода, чем Google Play.

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

2. Сколько у вас времени на разработку?

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

С нативным приложением таких проблем точно не будет, что очень важно для удержания аудитории, которая крайне не толерантна к ошибкам и багам. По статистике компании Compuware, 79% пользователей готовы перезапустить приложение, если оно некорректно заработало во время первого запуска, но вот дать ему ещё один шанс согласны всего 16%. Остальные, скорее всего, просто удалят программу.

3. Какие функции устройства вы планируете использовать?

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

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

4. К каким результатам вы стремитесь?

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

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

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

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

Казалось бы, вот у нас кроссплатформенная разработка, которая даёт возможность создавать универсальные приложения для разных платформ. Написал приложение быстрее, сразу везде выпустил - profit! И никакая нативная разработка не нужна. Или всё-таки нужна? О нюансах обоих подходов к разработке мобильных приложений мы спросили у наших экспертов.

«Мобильный разработчик» - широкое понятие. Разработчик, реализующий части мобильной операционной системы, - это тоже мобильный разработчик. И если цель стать именно таким разработчиком, то начинать надо вообще с изучения C++, мобильной операционной системы и «железа» мобильных устройств.

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

Почему так? Нативная разработка позволяет лучше и глубже изучить возможности конкретных операционных систем (и приложений для них) и мобильного «железа».

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

Изначальная идея кроссплатформенной разработки - это сокращение трудозатрат разработчика. Коротко её можно выразить так: «Сделал один раз, работает на чём угодно». Идея хорошая и верная (с точки зрения разработчика), но есть вопросы по качеству. В любой универсальности изначально заложен компромисс, и область мобильной разработки - не исключение.

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

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

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

Повысить Понизить

, директор по технологическому развитию ИТ-компании «АйДи – Технологии управления»

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

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

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

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

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

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

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

Повысить Понизить

, декан факультета iOS-разработки GeekUniversity, образовательного портала GeekBrains

Краткий ответ: если нет опыта в программировании - то, конечно, нужно выбирать нативную разработку. Кроссплатформенная разработка хороша для специалистов, которые переходят из смежных сфер в мобильную разработку. Например, если вы работаете frontend-разработчиком, с хорошим знанием JavaScript при помощи фреймворка React Native (созданного на основе фреймворка React) вы можете быстро и безболезненно попробовать освоить мобильную разработку. Аналогично.NET-разработчику легче будет освоить фреймворк Xamarin.

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

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

Спрос на обе сферы достаточно высокий, но на нативную разработку несколько выше: по запросу Swift на hh.ru в России - 369 ваканский, Kotlin - 397, React Native - 111, Flutter - 13 Xamarin - 18. Но будьте уверены, хороший специалист в любой сфере без работы не останется.

Повысить Понизить

Для начала важно отметить, что любое мобильное приложение состоит из нескольких слоев:

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

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

Саму разработку можно разделить на три вида: нативную, полностью кроссплатформенную и гибридную.

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

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

Преимущества нативной разработки:

Гибридная разработка

Этот тип разработки сочетает оба предыдущих подхода. Слой бизнес-логики строится в виде «переносимого» компонента, а UI и платформенная интеграция создаётся с помощью стандартных инструментов. Существует несколько языков для написания общей логики: C/C++ (зрелое и мощное решение), KotlinNative (очень активно развивается) и JavaScript (наименее распространено).

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

• нативными остаются наиболее подходящие для этого компоненты;
• общая логика создаётся один раз.

Недостатки:

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

С какого типа разработки лучше начать?

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

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

Повысить Понизить

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

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

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

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

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

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

Повысить Понизить

Выбор кроссплатформенного или нативного подхода зависит фактически от двух факторов: характера мобильной разработки, которым вы лично хотите заниматься, или запроса работодателей, с которыми вам интересно сотрудничать. Так, например, если рассмотреть Upwork (платформа по поиску удалённых специалистов на проекты и задачи), то можно заметить явный перевес по предложениям в сторону Xamarin и React Native. Преимущества тут очевидны: это дешево, быстро и позволит реализовывать проекты сразу на все платформы. Однако, если рассматривать крупные IT-компании с поиском сотрудников in house, то существенный упор наблюдается в сторону нативной разработки, несмотря на то что этот тип требует больше времени и стоит дороже.

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

Повысить Понизить

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

Если есть просто желание написать программу, которая будет работать в том числе и на телефонах, то можно сильно не задумываться и выбрать то, к чему больше лежит душа или в чём есть какой-то заметный опыт: C++, React Native, Xamarin или пятьсот тысяч JS-фреймворков для кроссплатформенной разработки. Или вообще продолжить делать свои [адаптивные] веб-сайты.

Я, признаться, довольно скептически отношусь к самой идее кроссплатформенной разработки на таких разных (и расходящихся) платформах, как Android и iOS. Никто из вендоров не любит «неверных» разработчиков, пытающихся усидеть на двух стульях одновременно. Все пытаются привязать программистов к инструментам и окружению, и никакой тенденции к сближению в обозримом будущем ожидать не приходится. Что там говорить, Apple в этой гонке отказался даже от OpenGL, самой кроссплатформенной из всех библиотек после Curl, но зато теперь у них есть свой собственный Metal, который делает вроде бы то же самое, только лучше и другим языком.

С другой стороны, очень часто мобильная разработка - это создание двух выглядящих одинаково приложений для какого-нибудь сетевого сервиса. Заказчики не всегда готовы платить за два продукта, которые на вид совершенно неотличимы, поэтому спрос на технологии кроссплатформенной разработки существует и, надо признать, довольно высокий. Программисты тоже не прочь сэкономить, особенно если мобильное приложение продать хочется, учить Swift/Kotlin никакого желания нет, зато JS/C# уже есть на кончиках пальцев.

Разумеется, кроссплатформенная разработка несёт с собой массу неочевидных нюансов. Все универсальные решения вынуждены строить замки на песке: либо опираясь на сложные и хрупкие технологические решения (как Xamarin), либо на мобильные движки JavaScript, как React Native. При этом платформенные вендоры и не думают поддерживать ни одно из решений, и каждое обновление нативного SDK - большая головная боль для любого кроссплатформенного фреймворка. Не говоря уже о таких специфических для конкретной системы особенностях, как доступ к камере, кейчейну или даже банальной галерее фотографий, которые каждый пытается обходить с разной степенью успешности. Разработчики, выбравшие универсальный путь, оказываются в заложниках у своего фреймворка, и часто разработка, обещавшая существенную экономию, превращается в борьбу с граблями.

Также часто в кроссплатформенных решениях принято жертвовать тем, что обозначается термином user experience (UX): многие фреймворки пытаются использовать элементы управления, максимально обобщенные для обеих систем, и почти всегда это решение одинаково неудобно для всех. Или тормозит. Или выбивается из общего стиля. Или расходует батарейку. Продолжите список сами.

Особняком стоят кроссплатформенные приложения, ядра которых пишутся на низком уровне, максимально общем для всех операционных систем: на языках типа C/С++. В этом случае принято обобщать использование кода, обслуживающего бизнес-логику, а интерфейс пишется для каждой платформы отдельно. В идеале можно было бы избежать дублирования критически важной части приложения, и при этом сохранить пользовательский опыт, характерный для каждой платформы. Однако в реальной жизни всё сложнее. Например, Dropbox несколько лет подряд пытались жить с низкоуровневым ядром, но в итоге отказались по многим причинам, и теперь счастливы с нативными платформенными приложениями. Интересующихся отсылаю к любопытной их статье на эту тему.

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

Повысить Понизить

, старший разработчик программного обеспечения Тверского технологического центра Accenture

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

Для нативной разработки на платформе Android существует Java или обёртка над JVM - Kotlin. Для iOS можно использовать Objective-C или обёртку над ним - Swift. Всё это - ООП-языки, которые многое унаследовали от Smalltalk и C.

Для кроссплатформенной разработки сейчас используют Flutter от Google, для которого нужно будет знать Dart. Или же React Native от Facebook.

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

При этом Objective-C для iOS-разработки взял многое от Smalltalk, как и Java, поэтому при желании можно сделать выбор и в пользу iOS. Но стоит учитывать, что разработка под Android может происходить на Windows или Linux, но для iOS необходима MacOS X. А вот для JavaScript-разработчика со знанием React, очевидно, самым быстрым путем будет React Native. Также как для Dart-разработчиков выбор будет в пользу Flutter.

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

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

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

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

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

Каковы основные преимущества и недостатки мобильной нативной и кроссплатформенной разработки? Нативная разработка сама по себе дорогая, потому что компании нужно инвестировать в две команды - iOS и Android. Для простых приложений, скорость разработки на Flutter / React Native выше.

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

Кроссплатформенная разработка - тоже крутая вещь. Но пока не сильно развита на IT-рынке труда в России. Толковых специалистов - по пальцам пересчитать. Инфраструктура фреймворков молода, но ситуация постепенно меняется к лучшему. Такая разработка даёт возможность сразу писать под несколько устройств. Даже если вы пишете на Flutter, например, он легко интегрируется с нативным кодом.

Повысить Понизить

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

Дайте ещё мнение

Всё понятно, покажите выводы

Итак, какой подход к разработке стоит выбрать?

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

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

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

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

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

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

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

Эти особенности надо учитывать до начала проекта:

• В кроссплатформенной среде код пишется один раз . Чтобы приложение работало в другой операционной системе, код переводится на другой язык программирования. Затраты времени и денег на разработку в 1,5 раза меньше.
• Возможна некорректная работа приложений. В кроссплатформенной разработке невозможно учесть все нюансы работы с архитектурой каждой операционной системы, поэтому приложения могут работать медленнее тех, что разработаны специально для iOS или Android.
• Интерфейс и требования к дизайну элементов у разных операционных систем различаются . Например, на iOS отсутствует кнопка Back, как на Android. При разработке единого дизайна этот момент нужно учитывать: в iOS кнопка или останется, но не будет работать, или ее придется вырезать вручную, а это дополнительные работы с кодом.

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

Значит, кроссплатформенная разработка - это плохо?

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

Этот вариант можно выбирать в следующих случаях:

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

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

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

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

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

Родные

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

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

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

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