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

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

Алексей Анастасьев

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

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

Павел Новиков

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

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

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

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

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

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

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

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

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

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

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

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

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

Недостатки:

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

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

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

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

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

Недостатки:

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

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

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

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

Степан Ермилов

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

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

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

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

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

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

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

Владислав Мельников

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

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

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

Также часто в кроссплатформенных решениях принято жертвовать тем, что обозначается термином 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 и наоборот.

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

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

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

Ренат Сарымсаков

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

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

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

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

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

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

Алексей Прядко

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

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

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

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

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

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

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

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