Нативная разработка vs кросс-платформенная — нужно ли выбирать?

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



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

    Когда речь идет об одиночном разработчике, он не сможет сделать приложение для iOS и Android ни на чем кроме React Native, если он знаком только с Java Script. Но зато, используя кроссплатформенный фреймворк RN, человек может сделать рабочее приложение для двух (а то и больше) операционных систем.

    image

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

    Интересная ситуация с Flutter — еще одним популярным кроссплатформенным фреймворком. Для работы с ним нужно знать типизированный язык программирования Dart. Он уже достаточно популярен в рядах программистов, особенно — энтузиастов, так что желающих программировать на Flutter становится все больше (в их числе — создатели мобильных версий eBay, Aliexpress и даже Meduza.io.

    image

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

    Задачи, требующие нативной разработки


    Второй аспект — это стоящие перед командой разработчиков задачи. Преимущество кроссплатформенной разработки заключается в скорости (одно приложение на две платформы) и стоимости проекта. Но иногда заказчику важны другие требования:

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

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

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

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

    Нюансы комплексных проектов


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

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

    Mix — смешать, но не взбалтывать


    Иногда меня спрашивают: “Зачем же разрабатывать на RN или Flutter, если в команду все равно приходится набирать нативных разработчиков?”. Но это только поверхностное мнение, так как при ведении проектов у того же RN есть свои плюсы. Например, на React Native намного удобнее описывать интерфейс, в для многих проектов этого и вовсе оказывается достаточно.

    image

    Таким образом, часто логика и низкоуровневые моменты кодятся на нативе, а интерфейс создается на Flutter или RN. Например, нам недавно нужно было подключить Яндекс.Метрику в проект на React Native. Но в RN не было актуальной метрики — поддерживалась только старая версия, которая не работала. Потребовалось сделать доработку на Java для Android и на Objective-C для iOS, чтобы реализовать полноценную поддержку Яндекс.Метрики.

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

    Внешний облик и разные платформы


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

    К тому же кроме минусов у разработки интерфейса на кроссплатформенных фреймворках есть и большие плюсы — есть дополнительные бонусы. Например, благодаря активной поддержке Microsoft, уже сегодня существует React Native Desktop, который позволяет написать приложение под Windows, опять же, опираясь на один только JS. Кстати, до определенной версии десктопный Skype был реализован именно на React Native.

    image

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

    image

    Например, по такому принципу построены приложения британского сервиса Moneypex. Для разработки всех своих приложений, включая веб, они используют Flutter.

    Заключение


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

    image

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

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

    Кстати, очень интересно узнать и ваше мнение — так что не забывайте участвовать в опросе и оставлять комментарии!

    Only registered users can participate in poll. Log in, please.

    Что вы предпочитаете для мобильной разработки?

    • 14.0%RN22
    • 25.5%Flutter40
    • 61.8%нативные языки97
    • 15.3%другое24

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 21

      +3
      Когда речь идет об одиночном разработчике, он не сможет сделать приложение для iOS и Android ни на чем кроме React Native, если он знаком только с Java Script.

      PhoneGap (ранее Cordova), например. Сам использовал, и остался доволен — идеально для «хуяк-хуяк и в продакшен», или для создания прототипов. И более понятный, чем RN.

      Можно даже взять приложение, написанное на обычной React.js и обернув в PhoneGap получить, нормальное приложение на смартфон.
        –3
        Тоже вариант. Просто мы его не используем :)
          +2
          Это как сказать, что люди бывают только мужчинами, потому что вы не женщина.
          0
          А чем PhoneGap лучше PWA?
            0
            Ну, в том, что PWA — это, по сути, просто сайт, развёрнутый в full-screen, а PhoneGap — это приложение, внутри которого ваш сайт. Примерно, как Electron.
              0
              Ок, чем фонгап лучше чем вебвьюха с PWA внутри?
                0
                Ок, я не говорил, что он прямо лучше. Но разница однозначно есть.

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

          Простите, коллеги, помогите, пожалуйста, найти в этом предложении несколько слов… Сейчас, дайте вспомнить… «Производительность», кажется… «Удобство» ещё вроде, заморское «UX» тут всплыло… Ещё вроде что-то говорили о том, что не все смартфоны оборудованы топовым железом, но это ведь бред какой-то, правда? Кому они нужны, давайте всё лепить абы как, точно, это же дешевле и проще!
            0
            дешевле хочет бизнес, заодно он хочет это быстрее.
              0
              Бывает необходимо проверить гипотезу, и не хочется тратить на это много денег.
              Бывает просто бюджет ограничен, но сильно хочется.

              Если есть спрос, должно быть предложение. Иначе зачем вообще тогда Facebook/Google разрабатывают кросс-платформенные решения? Думаете у них не хватает ресурсов?
              0
              Но, естественно, обращение к низкоуровневым компонентам поддерживаться не будет — это касается гироскопа, компаса и другого железа.

              Даже с этим?

                –1
                Обычно на нативных языках доступ к функционалу низкоуровневых компонентов гораздо шире.
                  +2

                  Всё-таки между "поддерживаться не будет" и "функуционал гораздо шире" довольно приличное такое не одно и тоже. И я просто взял первый попавшийся пакет по запросу "gyro". Ну и как я понимаю вызов нативного кода из Дарта это не прям уж рокетсаенс. https://flutter.dev/docs/development/platform-integration/platform-channels

                +5
                Я вот гордый программист-одиночка. Фуллстек. Знаю C# и JavaScript. Поэтому пишу под мобильные платформы… На Xamarin. И потому некоторые ваши преимущества нативной по сравнению с кроссплатформенной звучат для меня странно. Обратиться к гироскопу? Да пожалуйста. Отпечаток пальца? Нате!
                  0

                  А Вы пользуетесь Xamarin.Forms? Или же просто на шарпе пишете нативный (насколько это можно так назвать) код платформы?
                  Просто я пробовал Xamarin.Forms достаточно давно, когда каждый второй кросс-платформенный компонент на андроиде жутко сбоил. Мне было бы интересно узнать, как сейчас с этим дела.

                    0
                    На Xamarin.Forms. Сейчас всё сильно стабильнее стало по сравнению с тем, что было ещё года два назад. Плюс, многие сторонние плагины для кроссплатформенной работы с аппаратной частью заменены реализацией в Essentials. И оно как-то стабильнее стало.
                    Пока единственные проблемы со стабильностью, с которыми сталкиваюсь, касаются фич в preview (experimental) статусе. Остальное очень даже работает.
                  +2
                  Когда разработчик знает только javascript и собирается писать приложение для смартфона, напрашивается вывод, что он всё-таки web-разработчик. А это как бы не одно и то же. Согласно голосованию в конце статьи, самым адекватным вариантом было бы писать на нативном для этой платформы языке. Иначе ленивым web-программистам не придётся выходить за рамки любимой связки JS+фреймворки, а людям придётся обновить в очередной раз свои телефоны. Надо соблюдать баланс между удобством разработки и последующим использованием софта.
                    0

                    Следующий браузер будет написан на JS-фреймворке.

                      0

                      В идеальном мире этот баланс определяет бизнес, получив оценки типа: "нативно мы затратим N денег на разработку и покроем P1 процентов целевой аудитории, выбрав X мы затратим на разработку M денег и покроем P2".

                      +1

                      А Qt Framework не рассматриваете? Здесь вам и JavaScript, и наивный C++, iOS/android/win/mac/Linux и ещё куча платформ.

                        0
                        Взять например, виртуальную реальность VR — ее поддержка в RN и Flutter реализована только на базовом уровне, а всех эффектов вы сможете добиться только в нативных средах.
                        Пример выбран не очень. VR-приложения пишут обычно на игровых движках. AR ещё куда ни шло, его по хайпу везде пихают… Хотя в простом виде можно вообще использовать WebXR.

                        Only users with full accounts can post comments. Log in, please.