Всем привет! Я Игорь Веденеев, руководитель мобильной разработки в 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-код не составит больших проблем, но, если вы делаете приложение вокруг камеры, лучше рассмотреть нативную разработку.

Плюсы и минусы кроссплатформенной разработки

+

Единая кодовая база

Потенциальные риски

Затраты на разработку

Ресурсоемкость

Скорость разработки

Не покрывает все кейсы разработки

Покрывает большое количество кейсов

Сложно найти исполнителей

-

Ограничения по дизайну**

React Native vs Flutter

Итак, вы остановились на кроссплатформе. Что выбрать?

Я бы выбирал Flutter. Он кажется перспективной кроссплатформой. Хотя RN — самая зрелая технология, Flutter уже обгоняет ее по темпам развития. Что касается самой разработки, на Dart можно писать более безопасный код по сравнению с JavaScript что позволяет отлавливать много ошибок до этапа тестирования.


Flutter

React Native

Автор

Google

Facebook

Год создания

2018

2015

Язык

Dart

JavaScript

Принцип работы

Свой движок рендера Skia

Используется React, нативные компоненты вызываются из JS-кода

Features

Null Safety типизированный ЯП;

потенциально меньше проблем при обновлениях ОС из-за своего движка рендеринга;

Flutter web

Теоретическая возможность переиспользования веб-компонентов;

большой рынок разработчиков (на июль 2021);

знания React для веб-разработки будут актуальны

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

Хотя если с разработчиками всё плохо и приложение готово пережить все недостатки RN, то и в нем не вижу больших проблем.

Примеры кроссплатформенных приложений

Flutter

React Native

Ригла (AppStore / GooglePlay)

CoinBase

Дикси (AppStore / GooglePlay)

Mattermost

Свое родное (Россельхозбанк, маркетплейс фермерских продуктов: AppStore / GooglePlay)

Skype

Мир корма (AppStore / GooglePlay)

Bolt Food

eBay Motors (AppStore / GooglePlay)

Wix

Albert Heijn ( голландская «Пятёрочка»: AppStore / GooglePlay)

Discord

Яндекс.Про (AppStore / GooglePlay)

Tesla

Итого

Натив

Кроссплатформа

Производительность, плавность

MVP, приложения без сложной логики

Много логики на клиенте

Скорость и бюджет важны

Обширное использование возможностей платформы

Мало логики на клиенте

Увеличение количества фич, переход к супераппу

Мало использования платформенных возможностей

Есть ресурсы

Готовы терпеть просадку по плавности и скорости работы***

Скорость разработки

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

Натив

Кроссплатформа

64 часа (по 32 на платформу)

28 часов

Вывод

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


* — по сравнению с кроссплатформенными приложениями.

** — целесообразно использовать одинаковый платформенно-нейтральный дизайн для сохранения простоты кода и скорости разработки.

*** — лично мое наблюдение; не говорит о том, что кроссплатформа по умолчанию лагучая, а нативная нет, но тенденция, что натив более быстрый и плавный, есть.

Комментарии (31)


  1. Reformat
    01.11.2021 12:51
    +4

    Как бы я не любил нативную разработку, надо признать что к 2021ому рынок и развитие технологий пришли к тому, что для новых проектов оправдано делать сразу только web-фронтенд с бекендом на сервере. Можно сказать что бекенд это и есть настоящее продолжение нативных/дестопных приложений.
    Web фронтенд дает кроссплатформенность из коробки и очень легко упаковывается в нативное приложение если нужно размещение в сторах. Делать классическое нативное android/iOS/Desktop приложение оправдано только для игр и какого-то ну очень тяжелого ПО вроде фотошопа.


    1. getmaxx Автор
      01.11.2021 12:55
      +2

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


    1. RaymanOne
      01.11.2021 13:26
      +2

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


    1. neochapay
      01.11.2021 14:23

      А потом ты пытаешься сделать нестандартное что то с железом(прочитать NFC или узнать окружение BT и тому подобное) и очень очень груснеешь, а ещё бывает так, что связка WEB-Native сломана и ты сидишь и ждёшь годами, когда её починят.


      1. RaymanOne
        01.11.2021 16:46

        BT и NFC кстати есть в Chromium. Нужно просто требования заранее составить, какие АПИ действительно нужны, какие платформы, и от этого отталкиваться. Много чего можно закрыть нативным вебом, что-то через гибриды, а где-то без натива никак.


        1. General_Failure
          01.11.2021 16:53

          А в сафари есть? Ведь на айфоне любой браузер — сафари


          1. RaymanOne
            01.11.2021 16:57

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


    1. Vorchun
      01.11.2021 15:08

      Вот у нас сейчас задача: ездит человек по селам. Что-то там фотографирует. И должен передать фотоотчет на сервер. Именно фото. Веб не позволит загрузить фото фоном, как я понимаю. А нативное приложение уже позволит. Как только появился интернет - что-то загрузить.

      Хотя, возможно, я ошибаюсь. Мы в выбираем сейчас решение. Сами больше понимаем в классической веб разработке.


      1. RaymanOne
        01.11.2021 16:53
        +1

        Chromium умеет в фон. На Safari никак, придется брать натив или гибрид. Можно попробовать гибрид для Safari через ionic а для хрома как PWA.


    1. Alex_ME
      01.11.2021 16:04
      +2

      >Web фронтенд дает кроссплатформенность из коробки и очень легко упаковывается в нативное приложение

      Зачем тогда вообще приложение? Почему все словно помешались на приложениях? У практически каждого крупного магазина и прочей организации есть приложение. С чем я сталкивался за последнее время: спортмастер, до-до пицца, delivery club, mybox.

      При этом все эти приложения не имеют (я не нашел) какой-либо функциональности, отличной от взаимодействия с сервисом. Приложения полностью повторяют функциональность веб-сайта, теряя такие возможности, как копирование, вкладки, адресную строку и так далее!

      У компании уже есть веб-сайт (адаптивный, кстати). Зачем тратить свои средства на разработку приложений, а ресурсы пользователя (место в памяти, траффик итп) на установку приложения, которое делает всё то же самое? (Mybox - 74 мб, спортмастер - 42 мб, не слишком много для простой "отображалки"?)

      Может, стоит вложить средства в отпимизацию веб-сайта, чтобы он был удобнее и производительнее? Тем более, когда существуют все эти [тысячи спецификаций](https://habr.com/ru/company/dcmiran/blog/493018/), чтобы внести в веб всё новые и новые фичи. Всякие хранилища и сервис воркеры существуют давно.

      Зачем?

      З.Ы. Мысль не нова: https://ithappens.me/story/13155

      З.З.Ы. В комментах хабра сломали Markdown?


      1. RaymanOne
        01.11.2021 16:43
        +1

        Потому что трафик из магазинов приложений не получается игнорировать, тут помешательства нет, просто для массового пользователя это самый привычный сценарий что-то "установить" в свой телефон. Вы совершенно правы, тут на помощь как раз и приходит PWA. Делаете супер оптимизированный адаптивный веб-апп, публикуете его нативно в магазины google, ms, даже apple можно через небольшой костыль. Вес - килобайты, кода никакого не хранится в магазинах. И все, поддерживаете один веб-сайт, собираете трафик со всех платформ + веб.


      1. Reformat
        01.11.2021 17:53
        +1

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


        1. Alex_ME
          02.11.2021 01:43

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


      1. pfffffffffffff
        02.11.2021 21:13

        Приложения позволяют следить за пользователями????


  1. SNNikitin
    01.11.2021 13:55
    +1

    Странно, что не упомянут КММ...


    1. Vorchun
      01.11.2021 15:09

      Он где-то посередине, нет? Логику (то, что не зависит от платформы) пишем на нем. А на чем делать UI?


      1. SNNikitin
        01.11.2021 16:47

        нативно, естественно


  1. Sazonov
    01.11.2021 14:36
    +1

    А в каком состоянии сейчас Qt? Если абстрагироваться от стоимости лицензий и делать, к примеру, open source.


    1. SNNikitin
      01.11.2021 16:49

      Все такой же - сложный, редкий и кривой


    1. getmaxx Автор
      01.11.2021 21:21

      Честно говоря, не погружался в Qt совсем, не могу ответить. Но с учетом распространенности React Native и Flutter мне тяжело придумать кейс, в котором именно Qt себя лучше всего покажет


      1. Sazonov
        02.11.2021 11:10

        Кейс: любые тяжеловесные выборки данных со сложными 2д анимациями. Пока ничего шустрее qml либо native я не встречал.


  1. borovinskiy
    01.11.2021 18:53
    +1

    Adobe AIR уже был (аналог Flutter), при этом на весьма популярном в былые времена AS3. И что, и где он? Это про "Flutter лучше RN". Adobe AIR постоянно ставили в укор не использование нативных компонентов и у RN и было преимущество именно нативные компоненты. В случае с Flutter порицаемый подход AIR почему-то преимуществом оказался.

    Почему-то примеры приложений на RN какие-то скупые вышли, а как-же Facebook, Instagram, Skype и множество других?


    1. getmaxx Автор
      01.11.2021 20:18

      Согласен, обделил вниманием примеры по React Native. Добавил несколько. Facebook/Instagram и прочие по большей части нативные, мне кажется не совсем правильно будет их сюда вносить.


      1. getmaxx Автор
        02.11.2021 12:01

        >>>>> В случае с Flutter порицаемый подход AIR почему-то преимуществом оказался.

        Лично для себя не считаю это плюсом с точки зрения UX на iOS) С точки зрения производительности, пожалуй, можно назвать плюсом


  1. Pro-invader
    01.11.2021 19:01

    Не соглашусь с автором.

    По скрину с замером фпс не видно превосходства у натива.

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

    И если нет какой-либо функциональности, можно написать плагин для взаимодейсвия с ОС.


    1. borovinskiy
      01.11.2021 21:12

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

      С использованием чужих готовых есть риск получить несовместимости на новых версиях ОС и автор оригинальных плагинов может не торопиться их исправлять.

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


      1. Pro-invader
        01.11.2021 21:43

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

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

        И, кстати, нередко можно не писать плагин, а обмениваться данными через MethodChannel.


    1. getmaxx Автор
      01.11.2021 21:17

      мне на iOS не до конца нравилось, как работает, но вижу улучшения:) Насчет витрин - смотря что считать витриной. Может, приведете пару примеров, если NDA позволяет?)


  1. it_monk
    01.11.2021 23:04

    Когда уже во Flutter завезут 3d? А то ситуация странная, на RN хоть игры пиши, на Flutter максимум 3d модель только можно встроить.


  1. greenkey
    02.11.2021 01:08
    +1

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

    https://kotlinlang.org/lp/mobile/


  1. BraveBanana
    02.11.2021 10:00

    Ну, ещё есть Xamarin...