Нативный или кроссплатформенный: что выбрать начинающему мобильному разработчику? Ответ экспертов

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

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

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

технический директор ГК «CиДиСи» (CDC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

тимлид Android-разработки в компании «МойОфис»

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

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

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

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

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

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

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

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

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

Полностью кроссплатформенная разработка

Этот тип разработки преодолевает главный недостаток нативной разработки: все три уровня создаются единожды для всех платформ. Яркими примерами являются ReactNative (RN) от Facebook, Flutter от Google и Xamarin от Microsoft.

Основное преимущество: большая часть логики фактически написана один раз.

• со временем, возможно, потребуется изучить детали окончательной платформы;
• приложения могут появляться и вести себя «неестественно» для платформы;
• с точки зрения платформы используются нестандартные языки: JavaScript для RN, Dart для Flutter и C # для Xamarin;
• вы как разработчик попадаете в зависимость не только от конечной платформы, но и от промежуточной.

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

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

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

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

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

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

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

руководитель мобильной разработки IT-компании MediaSoft

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

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

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

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

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

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

программист группы разработки карты рассрочки «Совесть»

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

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

Lead Software Engineer в EPAM

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

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

Выделяются кроссплатформенные приложения, ядра которых написаны на низком уровне, наиболее распространенном для всех операционных систем: на таких языках, как C / 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 и наоборот.

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

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

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

разработчик мобильного приложения FL.ru

На этот вопрос нет однозначного ответа. Все зависит от целей. Часто команда разработчиков конкретной компании выбирает что-то одно. Например, они хотят работать только на устройствах iOS. Оказывается, ваша цель — досконально изучить платформу Objective-C, Swift.

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

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

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

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

технический руководитель проекта департамента разработки ПО компании «Рексофт»

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

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

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

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

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

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