Что такое нативная разработка мобильных приложений
Нативная разработка vs кросс-платформенная — нужно ли выбирать?
Привет, Хабр! Сегодня мне хотелось бы остановиться на вопросе выбора между нативной и кроссплатформенной разработкой для мобильных приложений. Как показала практика, это актуальная дилемма как для заказчиков, так и для начинающих разработчиков, которые хотят приобрести наиболее полезный опыт для дальнейшей карьеры. Так что делюсь под катом опытом нашего отдела и некоторыми выводами, которые мы сделали для себя.
Если перед вами возникает задача разработать какое-то мобильное приложение, выбор платформы зависит от двух факторов: «Какие языки программирования вы знаете?» и
«Какие задачи стоят перед вами?»
Когда речь идет об одиночном разработчике, он не сможет сделать приложение для iOS и Android ни на чем кроме React Native, если он знаком только с Java Script. Но зато, используя кроссплатформенный фреймворк RN, человек может сделать рабочее приложение для двух (а то и больше) операционных систем.
Программирование в нативной среде требует знания соответствующих языков. Для Android это Kotlin и/или Java, а для iOS — Swift и/или Objective-C. В принципе можно обойтись и одним из двух для каждой платформы, тем более, что Google активно развивает Kotlin, а Apple вкладывает большие усилия в совершенствование Swift.
Интересная ситуация с Flutter — еще одним популярным кроссплатформенным фреймворком. Для работы с ним нужно знать типизированный язык программирования Dart. Он уже достаточно популярен в рядах программистов, особенно — энтузиастов, так что желающих программировать на Flutter становится все больше (в их числе — создатели мобильных версий eBay, Aliexpress и даже Meduza.io.
Таким образом, если речь идет о небольшой команде или вообще о гордом фрилансере, арсенал разработки будет ограничен теми компетенциями в языках программирования, которые уже имеются.
Задачи, требующие нативной разработки
Второй аспект — это стоящие перед командой разработчиков задачи. Преимущество кроссплатформенной разработки заключается в скорости (одно приложение на две платформы) и стоимости проекта. Но иногда заказчику важны другие требования:
Производительность. Если от приложения нужно добиться максимальной производительности, то вам подойдет только нативная разработка. Даже при том, что Flutter прекрасно справляется с анимацией, максимальную отдачу от вычислительной подсистемы устройства можно получить только в нативной среде, не используя промежуточные библиотеки.
Размер приложения. Если нужно сделать приложение максимально компактным, например, если вы разрабатываете для специализированных устройств, или в случае реально большого объема самого приложения, нативная разработка поможет уменьшить его в разы.
Поддержка низкоуровневых функций. Порой, разработчику нужно обратиться к компонентам смартфона напрямую. Это может касаться гироскопа, компаса, модуля распознавания отпечатка пальца или любого другого железа. Как правило, для этого требуется нативное программирование. Также это касается функций шифрования, необходимых для банковского сектора.
Самые современные функции. Наконец, все новшества платформ отражаются в нативных языках в день релиза. На фреймворках они появляются чуть позже — если это очень важные обновления, и намного позже, если это что-то второстепенное. Взять например, виртуальную реальность VR — ее поддержка в RN и Flutter реализована только на базовом уровне, а всех эффектов вы сможете добиться только в нативных средах.
Нюансы комплексных проектов
Впрочем, если приложение представляет собой что-то более сложное, чем отображение веб-контента на мобильном устройстве, нужно иметь в виду, что кросс-платформенные фреймворки тоже связаны с нативом.
Нередко приходится править код каких-то компонентов или писать свои модули на нативных языках. То есть на практике получается, что нативные языки в большинстве случаев не требуются при кроссплатформенной разработке, но знать их все-таки нужно!
Mix — смешать, но не взбалтывать
Иногда меня спрашивают: “Зачем же разрабатывать на RN или Flutter, если в команду все равно приходится набирать нативных разработчиков?”. Но это только поверхностное мнение, так как при ведении проектов у того же RN есть свои плюсы. Например, на React Native намного удобнее описывать интерфейс, в для многих проектов этого и вовсе оказывается достаточно.
Таким образом, часто логика и низкоуровневые моменты кодятся на нативе, а интерфейс создается на Flutter или RN. Например, нам недавно нужно было подключить Яндекс.Метрику в проект на React Native. Но в RN не было актуальной метрики — поддерживалась только старая версия, которая не работала. Потребовалось сделать доработку на Java для Android и на Objective-C для iOS, чтобы реализовать полноценную поддержку Яндекс.Метрики.
Когда мы разрабатывали приложение для интернет-радио, в Android-версии использовался плеер, который не поддерживает метаданные в потоке и не показывает исполнителя и название композиции. Пришлось открывать исходный код, дописывать обработку метаданных и собирать полноценный модуль на Java, чтобы подключить его к приложению на RN.
Внешний облик и разные платформы
Еще один аспект — это внешний облик приложения. На просторах интернета часто говорят о том, что внешний вид и поведение некоторых элементов может отличаться на разных платформах при кросс-платформенной разработке. Однако случается это не часто, и если даже проблема возникает, ее несложно поправить, если в штате есть разработчики, знакомые с нативными языками.
К тому же кроме минусов у разработки интерфейса на кроссплатформенных фреймворках есть и большие плюсы — есть дополнительные бонусы. Например, благодаря активной поддержке Microsoft, уже сегодня существует React Native Desktop, который позволяет написать приложение под Windows, опять же, опираясь на один только JS. Кстати, до определенной версии десктопный Skype был реализован именно на React Native.
В Flutter активно развивается веб-направление, которое позволяет сделать приложение для браузера. Мы уже проверили на практике, что такой подход будет работать — как на настольной системе, так и на мобильной. Но, естественно, обращение к низкоуровневым компонентам поддерживаться не будет — это касается гироскопа, компаса и другого железа.
Например, по такому принципу построены приложения британского сервиса Moneypex. Для разработки всех своих приложений, включая веб, они используют Flutter.
Заключение
Подводя небольшой итог, скажу, что в моей команде большинство разработки ведется кросс-платформенно, однако и нативных разработчиков в штате становится больше,
Дело в том, что сегодня уже создано достаточно много библиотек, и кроссплатформенная разработка занимает меньше времени, чем кодинг приложения дважды на двух разных языках. Например, именно так было сделано приложение для отеля Luciano.
К тому же, большинство приложений — это клиентские модули, которые отображают какую-то часть веба, предлагают достаточно простые функции. в этом случае просто нет смысла использовать нативную разработку.
Тем временем, закодить небольшие дополнения или поправить что-то в самих фреймворках на нативных языках оказывается намного быстрее и проще, чем изначально делать всю работу на нативе. Поэтому фактически сегодня эффективная мобильная разработка требует использования фреймворков для увеличения скорости и снижения стоимости проектов, а также знания всех нативных языков для реализации поддержки низкоуровневых функций и допиливания напильником самих фреймворков, когда вы сталкиваетесь с очередным артефактом или багом.
Кстати, очень интересно узнать и ваше мнение — так что не забывайте участвовать в опросе и оставлять комментарии!
Мобильная разработка: Cross-platform или Native
Всем привет! Я Игорь Веденеев, руководитель мобильной разработки в AGIMA. Поговорим немного о нативной и кроссплатформенной разработке. Раньше я по большей части скептически относился ко второй: не устраивало качество конечных приложений в первую очередь. Однако за последний год темпы развития кроссплатформенных фреймворков уже не в первый раз заставляют пересмотреть свое мнение насчет такого подхода. Поэтому давайте еще раз сравним самые популярные кроссплатформенные решения и нативную разработку.
На всякий случай
Если вы не знаете, что такое нативная и кроссплатформенная разработка:
нативная разработка (2 независимых приложения на языках Swift и Kotlin);
кроссплатформенная разработка — общая кодовая база для iOS и Android (с применением фреймворков Flutter или React Native (далее RN)).
У каждого способа есть свои особенности, плюсы и минусы. Соответственно, под каждый конкретный проект и каждую конкретную цель подходит какой-то один из них. Сейчас объясню, как выбрать и на что обращать внимание.
Нативная разработка
Нативная разработка — это классический способ создания приложения для iOS и Android. Ведется она с использованием инструментов и языков программирования, предложенных вендорами — Apple и Google. Языки в данном случае — Swift (iOS) и Kotlin (Android), а инструментов для профилирования и отладки в нативной разработке очень много.
Однако мы должны понимать, что в данном случае мы делаем два независимых приложения. Разрабатываются они параллельно. Каждое приложение может реализовать фичу по-своему, и у каждого могут быть свои баги. И самое главное, нативная разработка никуда не денется: пока существуют iOS и Android, Apple и Google будут предоставлять инструментарий для создания приложений.
Нативная разработка позволяет создать самое качественное и функциональное приложение, но взамен придется разрабатывать и отлаживать всё 2 раза и следить, чтобы приложения соответствовали друг другу функционально.
Среди разработчиков это пока самый популярный способ создания приложений. Поэтому собрать команду, даже большую, в этом случае проще, чем для кроссплатформы. В первую очередь из-за количества предложений на рынке.
Плюсы и минусы нативной разработки
2 независимых приложения
Стоимость разработки и отладки
Меньше потребляемых ресурсов*
Богатый инструментарий для разработки
Широкий рынок разработчиков
Кроссплатформенная разработка
Кроссплатформенная разработка подразумевает, что мы используем один и тот же код и на iOS, и на Android. Вообще говоря, это всё такое же нативное приложение, но, запустив его, мы сразу проваливаемся в мир Flutter или RN, и всё происходит уже там. Стоит отметить, что разработка на Flutter/RN идет быстрее. Причем не только за счет того, что мы делаем 1 приложение вместо 2-х, а еще и за счет концепций создания приложений, в частности UI.
Но, увы, не всё так хорошо: кроссплатформа имеет ряд проблем, на которые стоит обратить внимание, прежде чем выбирать этот подход для своего приложения. React Native и Flutter всё же сторонние Open Source-решения. В них могут встречаться баги. Новые фишки iOS и Android там будут появляться не так быстро, как при нативных решениях. Может прекратиться поддержка, в конце концов.
Также, довольно часто придется полагаться на сторонние Open Source-библиотеки, что тоже несет в себе риски потенциальных проблем: например, совместимость версии Flutter/RN. Не исключен вариант, что нужной библиотеки не существует в природе, и тогда придется реализовывать всё с нуля самому. Также нельзя добавить расширения для iOS-приложений или, например, приложение на часы. Это касается и Flutter, и RN.
То есть для реализации определенных фич придется добавлять нативный код, что приведет к смешению технологий. Как минимум надо будет иметь в них компетенции. Как максимум — организовывать передачу данных из нативного кода в кроссплатформенный и наоборот.
Если в приложении много логики и есть необходимость сделать ее многопоточной, это тоже будет проблемой и во Flutter, и в RN. Это возможно, но, скажем, это не то, для чего были предназначены эти фреймворки. Также каждый из фреймворков имеет достаточно тяжелую исполнительную среду, что делает кроссплатформенные приложения более ресурсоемкими и требовательными к процессору/оперативке телефона.
Если приложение подразумевает обширное использование аппаратных возможностей телефона, взаимодействия с ОС, то я бы тоже не рекомендовал использовать кроссплатформу — есть риск, что в какой-то момент или код станет очень запутанным, или мы упремся в ограничения одной из платформ или самого фреймворка. Еще стоит учесть, что нам стоит использовать платформенно нейтральный UI, чтобы не создавать потенциальных проблем с различным поведением на платформах и в принципе не снижать на этом скорость разработки.
На картинке ниже представлены результаты теста с простым списком с изображениями: видим, что нативное приложение выигрывает вчистую. Да, на более новых моделях телефонов разница будет не такой значительной, но тенденцию можно видеть. Результаты остальных тестов тут.
Если проще, то кроссплатформа позволяет разработать приложение в кратчайшие сроки. Лучше всего подходит для приложений-витрин услуг или товаров среднего/малого объема без обширного использования платформенных возможностей. То есть снять фотку на аватар или отсканировать QR-код не составит больших проблем, но, если вы делаете приложение вокруг камеры, лучше рассмотреть нативную разработку.
Плюсы и минусы кроссплатформенной разработки
Нативная и кроссплатформенная разработка: как сделать правильный выбор в 2021
Просто и понятно о том, в каком случае можно использовать кроссплатформенную разработку, а когда не обойтись без нативной.
Я знаю, что это далеко не первый текст на данную тему. Но до сих пор в топовых позициях находятся статьи с устаревшей и неверной информацией (например, что кроссплатформенные приложения нельзя опубликовать в магазинах). Поэтому я решил актуализировать информацию и рассказать об отличиях в подходах в простой форме, для тех, кто однажды столкнётся с разработкой мобильных приложений.
Представим себе Сергея, у которого есть автопарк. Сергей хочет получать больше заказов и поэтому решается на разработку собственного приложения для вызова такси. Разумеется, он хочет охватить больше клиентов: поэтому ему нужно программное обеспечение как для IOS, так и для Android. Сергей понимает, что это будет два разных приложения, но что-то слышал о том, что можно сделать одно, которое будет работать на всех смартфонах.
Теперь Сергей знает, что есть что. На первый взгляд, кроссплатформенная разработка кажется более выгодной, но он понимает, что в подходах есть существенные различия.
Логично было бы предположить, что кроссплатформенная разработка должна стоить в два раза меньше, чем нативная, ведь разрабатывается одно приложение вместо двух. Но это не так и вот почему. Несмотря на то, что при кроссплатформенной разработке у продукта будет одинаковая бизнес-логика и навигация, экраны для каждой системы будут отличаться. Таким образом, для IOS и Android отрисовываются и реализуются собственные экраны приложения. Если говорить о цене, то стоимость кроссплатформенной разработки в среднем на 70% ниже, чем нативная.
Нативное приложение всегда будет выглядеть лучше, чем то, что разработали по мультиплатформенной технологии. Дизайн, скорость загрузки, доступ ко всем функциям устройства (камера, геолокация, календарь и так далее), интерфейс – все это будет давать нативной разработке сто очков вперед. Кроссплатформенные приложения в этом плане уступают нативным – работают медленнее, а интерфейс значительно отличается.
Нативная разработка дороже, так как придется задействовать как минимум двух разработчиков, специализирующихся на разных платформах. Кроме того, такой подход требует больше времени.
Главным достоинством кроссплатформенного подхода является то, что скорость разработки выше, нежели у нативной, а времени и ресурсов затрачивается меньше.
Наш Сергей немного запутался, попробуем до бавит ь конкретики .
Кроссплатформенная разработка не подходит для серьезных бизнес-проектов. Такое решение оптимально при написании простого приложения, в котором мало экранов и много общих элементов для разных платформ. Например, данный тип разработки выгоден при написании прототипа приложения под несколько платформ в сжатые сроки, для игрового или тестового приложения.
Для приложений с уникальными интерфейсами и сложной бизнес-логикой больше подходит нативный способ разработки.
Теперь Сергею понятно, зачем нужна кроссплатформенная и нативная разработка, он принял решение для своего проекта, но все равно еще все обсудит с профессионалами.
Нативная разработка на нескольких платформах выгоднее для веб-студий, но мы в Yusmp Group не навязываем такие услуги проекту, которому это не требуется. Если заказчику нужна демонстрационная версия, а сроки и бюджет ограничены, то разумнее выбирать кроссплатформенную разработку.
Что такое нативная разработка мобильных приложений
Что такое нативная и кроссплатформенная мобильная разработка, чем они отличаются, как сделать выбор. Объясняет Surf.
«А зачем мне вообще в этом разбираться, — скажет заказчик. — Приду к разработчику, он знает, как лучше». И да, и нет. Разработчик объяснит технические детали и добавит недостающие элементы в картинку. Но он вряд ли станет беспристрастно оценивать ваш бизнес, анализировать бюджет и сроки. Кроме того, даже у профи могут быть личные пристрастия и привычки в работе.
Поэтому мы решили рассказать, что такое нативная и кроссплатформенная мобильная разработка, чем они отличаются и как между ними выбирать. В этой статье не будет сложных технических терминов — только знания, которые помогут вам понять разницу и выбрать подходящее решение.
Кто мы: Surf более 10 лет занимается разработкой мобильных приложений. Среди наших клиентов Росбанк, Магнит, KFC, «Лабиринт» и другие флагманы индустрии.
Натив и кроссплатформа: что это вообще такое
Это два типа разработки. Нативное приложение создаётся для конкретной операционной системы на языке программирования, который ей понятен. Пишутся два отдельных кода для двух ОС.
В случае кроссплатформы программисты используют фреймворки — программные каркасы, на которые затем вешают необходимые функции. Фреймворки универсальные — с их помощью создают приложения сразу для нескольких ОС. Код один, а систем много.
Кроссплатформенная разработка — относительно новое явление. И в этом есть как плюсы, так и минусы. С одной стороны, репутация фреймворков пока кажется ненадёжной. С другой — они создавались и тестировались с учётом опыта, который накопила к этому времени сфера мобильной разработки.
Например, первое устройство на Android вышло в 2008 году, а кроссплатформа Flutter стартовала только в 2017. Но её создатели смогли учесть накопившиеся боли коллег, упростили и оптимизировали подходы к разработке. Теперь многие вещи делаются буквально «из коробки», экономя время и нервы разработчика.
Натив: что это, кому подходит, примеры
Программирование в нативной среде ведётся на нескольких языках. Для Android это Kotlin и Java, а для iOS — Swift и Objective-C.
Нативная разработка — мощный инструмент. Подходит для тех, у кого мобильное приложение — основной канал продаж, и большой бюджет на развитие.
Плюсы нативного подхода
Система лучше понимает свой язык. С приложением, написанным специально под iOS или Android, будет меньше технических сложностей, в том числе с обновлениями. Его проще оптимизировать, сделать быстрее или легче. А чем меньше весит приложение, тем охотнее его скачивают пользователи.
Никаких ограничений: можно смело браться за реализацию любых идей, связанных с работой устройства — камерой, GPS, сенсорами, файловой системой устройства и так далее.
В нативной разработке намного больше специалистов — нет проблем с тем, чтобы найти сотрудников на проект или просто с кем-то посоветоваться.
Нативные приложения хороши всем, кроме стоимости. Это дорогой проект: для каждой ОС придётся разрабатывать свою логику, интерфейс и вёрстку. Под каждую платформу нужно держать отдельный штат разработчиков и тестировщиков. В зависимости от региона зарплата опытного мобильного разработчика начинается от 90 000 рублей, а у старшего специалиста может достигать 350 000 рублей.
Итог: нативное приложение оптимально для конкретной операционной системы, меньше весит, быстрее работает и даёт все возможности для реализации сложных функций. Но будьте готовы к большим расходам.
Например: «Лабиринт» и «Бетховен»
Нативная разработка точно нужна крупным компаниям, которые собираются создавать продукт со сложным каталогом и многоступенчатой вложенностью. Так мы создавали приложение для книжного интернет-магазина «Лабиринт». Это крупнейший проект с большой базой лояльных клиентов. Мобильное приложение для «Лабиринта» — важнейший канал продаж. Поэтому мы сначала разработали приложение для iOS, включая версию для айпада, и затем специально для Android.
Другой пример эффективного использования нативной разработки — магазин зоотоваров «Бетховен». За видимой простотой приложения — главная, каталог, корзина, оформление заказа, оплата — скрывается большая работа. Surf добавил каталог с фильтрами, голосовой поиск, развёрнутый профиль пользователя с программой лояльности и многие другие функции.
Оба приложения можно было сделать на Flutter, и пользователи не увидели бы разницы. Однако мобильные приложения настолько важны для обеих компаний, что они не хотели идти на компромиссы. Немалые инвестиции оправдали себя — получились флагманские приложения в своих категориях. Конверсия приложения «Бетховена» — более 15%, это очень высокий показатель для отрасли. А приложение «Лабиринта» стало для магазина одним из основных каналов продаж.
Кроссплатформа: что это, кому подходит, примеры
На рынке представлено много кроссплатформ: React Native, Xamarin, PhoneGap, Titanium, Ionic, Flutter. Однако глобально выбор сводится к двум вариантам: React Native и Flutter. Это наиболее популярные и развитые фреймворки. Для них быстрее и проще найти разработчика.
Оба решения дают качественный пользовательский опыт. В большинстве случаев существенной разницы между ними нет, но мы отдаём предпочтение Flutter. И не мы одни: к апрелю 2020 года его опробовали больше двух миллионов разработчиков. 500 тысяч заявили, что используют фреймворк ежемесячно. 92% высоко оценили Flutter и отметили, что планируют работать с ним дальше.
При работе с кроссплатформенным приложением пользователь должен воспринимать его как нативное — плавные анимации, высокая скорость работы, работа с жестами. С этим пока целиком справляется только Flutter.
В каких случаях стоит выбрать кроссплатформу
Вы небольшая компания. Мобильное приложение вам необходимо, но тратить миллионы на его разработку нет возможности.
Вы представляете крупную компанию, но именно по вашему проекту бюджет ограничен. Например, у него вторичная роль в бизнесе, как в случае приложения для водителей Яндекс. Такси, которое сделали на Flutter. Специалистам Яндекса требовалась iOS-версия приложения Таксометр, которое водители используют для приёма заказов. На разработку с нуля было всего 2,5 месяца, а само приложение должно было интегрироваться с актуальными версиями Android. Нативное приложение не подходило из-за сроков разработки, не получилось бы добиться одинакового поведения обоих приложений, нельзя использовать общую библиотеку компонентов. Поэтому приложение сделали на кроссплатформе.
У вас стартап и нужно сделать MVP (минимально жизнеспособный продукт) быстро и эффективно. Тот случай, когда чем быстрее сделаете и меньше денег потратите, тем лучше.
Приложения для разных ОС получаются практически одинаковыми. Так часто бывает в ритейле. Функции и пользовательские сценарии, программы лояльности, каталог, онлайн-магазин — всё одинаковое. Нет смысла просто дублировать приложения.
95% ваших пользователей сидят на одной ОС. Содержать отдельную команду и поддерживать приложение ради 5% дорого и нецелесообразно. Так случилось с нашим корпоративным приложением для KFC. У 95% сотрудников был Android, а у 5%, среди которых менеджеры и управляющие ресторанами, — iOS. Можно раздать сотрудникам корпоративные андроиды, но получится дорого и неудобно. А создавать два нативных приложения означает вдвое увеличить бюджет. Подходящим решением стало кроссплатформенное приложение на Flutter.
Дешевле не значит хуже: почему кроссплатформа экономичнее
Нативные приложения требовательны в разработке. Нужно синхронизировать две команды и закладывать двойной бюджет практически на всё: тестирование, релиз, обновления.
В случае кроссплатформы можно переиспользовать основную часть кода, а бизнес-логика, интерфейс и вёрстка почти не требуют изменений. Меньше расходы, компактнее команда разработчиков, короче показатель time-to-market — с помощью Flutter можно выпустить продукт на рынок за 2–3 месяца. Можно быстрее запускать новые функции и обновления, то есть зарабатывать с помощью приложения больше и быстрее. По нашим подсчётам, экономия бюджета на Flutter составляет до 40%.
Например: Росбанк Бизнес
Кросс-платформа подходит не только для заведомо бюджетных проектов. На ней отлично можно создавать сложные и дорогие приложения. Так Surf создал Росбанк Бизнес — первое в России и второе в мире банковское приложение на Flutter. Мы выбрали этот фреймворк во многом благодаря скорости запуска, критически важной для заказчика.
6 вещей, которые нужно знать при выборе мобильной разработки
1. Натив — два кода под две системы. Кроссплатформа — один код под несколько ОС.
2. Нативная разработка под конкретные операционные системы — хорошее, но дорогое и более медленное решение.
3. Кроссплатформы подходят, когда есть ограничения по срокам и бюджету, потому что можно создать одно предложение вместе двух отдельных.
4. Кроссплатформа позволяет сэкономить до 40% бюджета и сокращает показатель time-to-market.
5. У современных кроссплатформенных фреймворков широкие возможности: на них можно делать сложные продукты, которые с точки зрения пользователя неотличимы от нативных приложений.
6. Кроссплатформ сегодня много, но Flutter по пользовательскому опыту превосходит аналоги, а популярность фреймворка среди разработчиков растёт. Поэтому, если вы выбрали кроссплатформу, смотрите в сторону Flutter.
Подробнее о нашем опыте разработки на Flutter читайте в блоге Surf.