Нативная или кросс-платформенная разработка?

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

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


Основным языком платформы iOS является Swift, язык, который Apple выпустила в 2014 году, и форсирует в качестве основного языка разработки под все продукты Apple (ранее таким языком являлся всё ещё поддерживаемый платформой Objective-C). У Android тоже два основных языка, это классическая и покорившая в своё время технологический мир Java, и новый язык программирования от Google, который активно проталкивается и развивается, Kotlin. Так вот, когда речь идет о программировании на Java или Kotlin для Android или же о Swift или Objective-C для iOS, такой подход называется нативным (нативный, от английского native -- природный, естественный). “Естественный” язык для каждой платформы нужен потому что библиотека всех компонентов операционной системы, которые используются при разработке мобильного приложения использует этот нативный язык, и как следствие, обращаться к этим компонентам, возможно только на этом нативном языке. Причем Kotlin разработан на языке Java, а Swift разработан на языке Objective-C, что обеспечивает языкам совместимость на своих операционных системах и делает их нативными.


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

Тут есть два основных подхода, с очень простой идеей каждый:


Подход первый

Перевести ненативный код в нативный.

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

Давайте сразу на примере. Допустим, вы хотите запустить камеру устройства, чтобы сделать фото внутри мобильного приложения. Принципиального отличия в этом смысле между платформами нет, обе мобильные платформы подразумевают наличие и фронтальной и задней камеры у устройства. Зачем же тогда запускать камеру с помощью одного кода на Android и с помощью другого кода на iOS, если функция одна и та же. Эта проблема решается у кросс-платформенных решений следующим образом: пишется единый код, запускающий камеру, который, в свою очередь, в зависимости от платформы, вызывает внутренние функции самой платформы. Эти внутренние функции объединены в единый пакет, который называется SDK (Software Development Kit), и у каждой платформы он свой.

Основные преимущества:

  • Единая кодовая база. Такие приложения можно написать c помощью С# или Javascript.
  • Нативность работы программы. Благодаря отдельной обертке каждой платформы, мобильное приложение использует все внутренние возможности платформы.
  • Основные недостатки:
  • Дополнительная обертка влияет на размер приложения. Если маленький вес приложения это критичный параметр, стоит задуматься о нативной разработке.
  • Наличие дополнительной обертки может сказаться на стабильности и производительности работы мобильного приложения.


Типичные представители этого “нативно-ненативного” подхода: Xamarin, React Native, Flutter.


Подход второй

HTML5.

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

Основные преимущества:

  • Использование стека веб-технологий при разработке. Javascript, html и css представляют собой распространенный стек технологий, дающий возможность создать мобильное приложение под обе платформы при помощи веб-разработчика.
  • Единая кодовая база. Html и css будут выглядеть одинаково как на iOS, так и Android.

Основные недостатки:

  • Ограниченная функциональность приложения. Браузерному приложению (на основе WebView) доступна меньшая часть возможностей платформы.
  • “Ненативность” внешнего вида приложения. Стандартные элементы библиотек iOS и Android работают из коробки в рамках своих платформ и выглядят естественно для пользователей. В то время как элементы интерфейса на основе html будут выглядеть одинаково на обеих платформах и будут требовать дополнительной кастомизации.
  • Дополнительная нагрузка. Браузер это дополнительное звено, требующее ресурсов процессора и памяти при отображении интерфейса и работе программы, что может привести к задержкам работы приложения.


Типичные представители этого совсем ненативного подхода: PWA, PhoneGap, WebSocket.

Итог


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

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




Хотите обсудить ваш проект?

Спасибо! 
Мы свяжемся с вами в ближайшее время.
При отправке формы произошла ошибка :(