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

Автор оригинала: Rob Barber
  • Перевод
image
Позвольте мне с вами кое-чем поделиться. Мне нравится идея кросс-платформенной разработки. Возможность использовать один набор инструментов для всех моих задач — это мечта. Кто не хотел бы использовать только один инструмент, чтобы успешно выполнять свои задачи? Пиши один раз, запускай везде? Я хочу!


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

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

Нативная, кросс-платформенная, гибридная? Шта?


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

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


При нативной разработке мы используем специализированные инструменты для создания приложений для iOS или Android. То есть существует одна кодовая база для каждой платформы. В наборы инструментов обычно входят Swift / Objective-C + Xcode/AppCode для iOS и Kotlin/Java + Android Studio для Android.

Кросс-платформенная разработка


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

Некоторые примеры инструментов: Xamarin, React Native, Flutter

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


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

Примеры инструментов: Cordova и Ionic

Первичные vs неотъемлемые характеристики


Чтобы правильно понять мой выбор, мне необходимо объяснить два разных типа характеристик инструмента.

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

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


Почему я выбираю нативную разработку


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

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

1. Постоянная популярность


Когда я впервые начал программировать в 2013 году, было много хайпа вокург Cordova и Appcelerator. Через несколько лет хайп перешел на Xamarin. Через несколько лет это уже был React Native. В настоящее время? Сейчас набирает популярность Flutter.

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

image
График Google Trends примерно отображает результаты количества поисковых запросов для различных кросс-платформенных мобильных технологий.
Хотя эта диаграмма является приблизительной оценкой популярности (поскольку она представляет только результаты количества поисковых запросов), она действительно дает некоторое представление о том, что я испытывал как разработчик. Предприятия и частные лица, как правило, используют то, что является новым. Это не обязательно означает, что инструмент лучше или хуже (так как многие статьи будут спорить за/против, независимо от даты выпуска), но люди всегда переходят на что-то более новое.

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

Противопоставлением этому является нативная разработка, которая гарантированно получит поддержку. Пока Apple поддерживает iOS, а Google поддерживает Android, нативная разработка всегда будет актуальна. Вот почему нативная разработка имеет самую большую экосистему разработчиков; это было только вокруг дольше и было последовательно в его популярности.

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

2. Business Values/Vision


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

Например возьмем Xamarin. Еще в феврале 2016 года Microsoft купила Xamarin примерно за 400–500 миллионов долларов. В то время видение Microsoft было связано преимущественно с разработкой мобильных приложений. Они добились значительных успехов с этим инструментом и даже включили его в качестве надстройки «из коробки» для Visual Studio и Visual Studio для Mac. Перенесемся через несколько лет, и видение Microsoft перешло на искусственный интеллект.

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

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

Притирка при переходе к новому инструменту приводит к увеличению накладных расходов и упущенной выгоде


Я признаю, что у нативной разработки тоже есть свои проблемы здесь. Например, Apple обычно пытается заставить разработчиков развиваться по определенному пути (например, используя Storybords или шаблон MVC). Инструментарий также не всегда идеален, поэтому я фактически использую AppCode для большей части своей разработки под iOS. Тем не менее, и Apple, и Google тратят огромное количество времени и денег, чтобы добиться того, чтобы разработчикам было комфортно разрабатывать нативные решения. Достаточно взглянуть на Android Jetpack, SwiftUI или даже перейти на Kotlin и Swift.

В конечном счете, у Google или Apple не лучшее видение в мире, но оно последовательное. Существует минимальная вероятность, что компании в одночасье откажутся от поддержки своих инструментов.

3. Сохранение времени


Ах да, экономия времени. Святой Грааль эффективности развития. Эта горячо обсуждаемая тема, касающаяся ЛЮБОГО инструмента разработки, может создать или разрушить бизнес. Эта тема находится на переднем крае любого проекта, поскольку напрямую влияет на стоимость. Но давайте сделаем шаг назад и ​​зададим себе вопрос.

Что мы можем сделать, чтобы сэкономить время?


Я объясню. Как и в программном обеспечении в бизнесе, обычно существует несколько способов решения проблемы. Решение в основном исходит из ситуации конкретного человека или бизнеса. Это означает, что подход «одно решение подходит всем» опасен; это также очень близко подходит к менталитету «мы всегда так делали». К сожалению, когда речь заходит о мобильной разработке, общий подход к экономии времени заключается в выборе кросс-платформенного инструмента. Но так ли это хорошо? Можем ли мы, скажем, придумать другой метод решения проблемы? В бизнесе есть поговорка «Люди превыше процессов, превыше инструментов».
Люди превыше процессов, превыше инструментов


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

Инструмент сможет решить плохой менталитет при разработке?

Позволяет ли инструмент упорядочить процесс разработки?

Может ли слегка измененный процесс или менталитет привести к лучшим результатам, экономящим время?

Можем ли мы использовать инфраструктуру для решения наших задач?

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

Поскольку нативная разработка по-умолчанию будет производить продукт более высокого качества и поддерживаться практически до бесконечности, я выберу этот набор инструментов. Мои личные ценности определяют этот выбор (стремиться к совершенству). Собственное развитие действительно занимает больше времени (насколько больше сильно варьируется). Есть ли способ сэкономить время? Должен ли я вообще экономить время? Должен ли я просто искать проекты, где бюджет не является проблемой?

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

4. Прочие умозаключения


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

Вещи, которые я рассмотрел перед выбором нативной разработки:
1. Время на Onboarding разработчика
2. Вспомогательная инфраструктура
3. CI/CD Pipelines
4. Стоимость поддержки legacy проектов
5. Слои абстракции = больше возможностей для ошибок
6. Наличие разработчиков (количество разработчиков, использующих указанный инструмент)
7. Бизнес-иерархия (у Airbnb есть отличная серия блогов, которая затрагивает эту тему)
8. Зависимость платформы от плагинов
9. Счастье разработчика при использовании инструмента
10. Затраты на проектирование: необходимость проектирования таким образом, чтобы поддерживать обе платформы
11. Нестандартная структура проекта
12. Ресурсы знаний — количество областей знаний, необходимых (например, Xamarin требует: + платформа Xamarin Api, C #, специфическая функциональность Android, специфическая функциональность iOS и знание особенностей каждой платформы и того, как они взаимодействуют через Xamarin.)
13. Лицензирование + стоимость
14. Ландшафт мобильных операционных систем. Например: как долго будет только 2 основных платформы?

Выводы


В течение последних 2 лет использовал нативную мобильную разработку в качестве основного набора инструментов. Одна из многих причин, по которым я доволен своим решением, состоит в том, что я нашел время, чтобы рассмотреть как можно больше тонкостей для каждого инструмента. Я знаю плюсы и минусы, и это дает мне преимущества.
Я надеюсь, что эта статья поможет вам задать правильные вопросы при выборе инструмента. Не принимайте маркетинг за чистую монету, и ПОЖАЛУЙСТА, не следуйте за хайпом. Копайся, пачкайся и думай критически.
Поддержать автора
Поделиться публикацией

Похожие публикации

AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 27

    –1
    Как насчет Delphi? Нативная кроссплатформенная разработка в одной среде. Есть бесплатная версия.
      +2
      Ни одной вакансии не видел)
        0
        Насчёт iOS и Android не знаю (не пробовал), а вот на десктопе (Windows, Mac, Linux) работает (пробовал). Не без косяков, с особенностями, но работает.
          0
          об этом и говорится в статье, что кроссплатформа несет очень много накладных расходов и чаще бывает проще написать код два раза, чем один, который работает везде
            0
            Зависит от приложения. Чем оно больше и сложнее, тем меньше эти накладные расходы в процентном соотношении (конечно, если не основано на специфических для платформы фичах).
            Игры, например, почти все делают на кросс-платформенных движках.
            И, опять же, придирки к классификации, если сделать всю логику приложения в виде dll-ки, а на платформах делать только морду и связующий слой, оно считается кросс-платформенным или нет?
              0
              hygrid
                0

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

          +1
          Как насчет Qt?
            0
            53 вакансии QT против 1200 Android и 1000 вакансий iOS по данным HH
              +1
              А сравнение было между вакансиями на один qt и вакансиями на все языки программирования и инструменты для андроида?
            0
            Elements от RemObjects пытаются совместить нативный подход к разработке UI и общую кодовую базу на одном из языков: Oxygene (Object Pascal), C#, Swift, Java. Не знаю на сколько успешно (не пробовал).
              0
              к сожалению вообще первый раз слышу
                0
                На мой взгляд идея очень правильная — UI родной для каждой платформы, а бизнес-логика общая.
                  0
                  идея правильная, но пока еще никем нормально не реализованная
              +2
              а как же моднейший Flutter, например?
                0
                ну так суть статьи — не вестись за хайпом, он приходит и уходит
                  0
                  Но суть статьи еще и в том что нативные средства разработки хороши тем что их поддерживают эпл и гугл. Ну, собственно, Flutter это гугл.
                0

                Недавно Dropbox выпустил похожую статью.


                В проекте где я работаю организованно таким образом что есть portable ядро C/C++ и UI нативный для каждой платформы. UI хоть и нативный, но с ним все равно свои проблемы. Во первых, вы добавили фичу, нужно обновить 6 UI и каждый по своему. Второе что нативные средства также устаревают как и кросс-платформенные. Например Windows UI основный на Win32 или MFC уже не такой уж нативный в современном Windows 10. Андроид тоже постоянно сдвигает парадигму, Android 2.x -> Фрагменты -> Kotlin -> Jetpack Compose или Flutter.


                Мне кажется было бы ок если бы у нас был кросс-платформенный UI, написанный единожды. Однако подходящих технологий пока нет. Flutter вроде бы планирует поддерживать и desktop и Web, но по текущим демкам видно что оно не готово.

                  +1
                  называние проекта начинается на яндекс, а заканчивается на карты? :)
                    0

                    Ни одной буквы не угадали :-) Проект малоизвестный на самом деле в сфере удаленного управления.

                  +1

                  Наша фирма разрабатывает проекты на xamarin и я не согласен с вашими выводами. Я так понимаю вы писали больше о xamarin forms? Xamarin forms сейчас очень быстро развивается и в данный момент получил важные фичи: списки на основе recyclerview, collectionview, быстродействие которых на порядок выше, hot reload, carousel view, indicator view и т.д. (с мобильного не очень удобно писать, так бы много чего перечислить можно). Да, бывают обновления что-то ломающие, но обновляться постоянно без причины на последнюю версию, это странное решение, все нужно проверять тестами. Также большинство проектов мы пишем на xamarin.native и это наше спасение по ускорению работы и, что самое главное, одинаковому поведению на разных платформах. Только переход на общее ядро дал возможность нормально унифицировать работу приложений. C# дает огромное преимущество в работе по сравнению с java или swift.
                  Я мог бы описать все плюсы и минусы, с которыми приходится мириться, но это будет целая огромная статья.
                  Популярность кроссплатформенных решений никогда не перевалит популярность инструментов от гугл и apple, но все не так уж плохо как вы пишите

                    0
                    Уточните пожалуйста, какие огромные преимущества у С# по сравнению с Java и Swift?
                      +1
                      Возможно прозвучало слишком холиварно. Имел ввиду больше преимущество для бизнеса. Есть возможность быстрой переквалификации Xamarin работника с разработки приложений c Android на iOS и обратно, использование одного кода на нескольких платформах.
                      По языку тоже есть плюшки: реализация асинхронной работы, LINQ, реализация делегатов и событий, неймспейсы (swift) но это больше уже нюансы.
                      Я ни разу не против разработки используя Kotlin/Swift, у нас эти подходы тоже используются. Есть и приложения на Xamarin Forms, а также на Xamarin.Native. Везде свои преимущества.
                      0

                      я тоже делаю на xamarin, правда у меня сам алгоритм портируется, но зато идеально (программа ёфикатор)

                      +1
                      прочитал статью и не заметил серьезных доводов за и против. Нативная разработка позволяет сделать приложение более качественным, многогранной. Но не всегда это нужно. Одно дело делать игры, другое калькулятор. Не всегда идеальное пользователям необходимо идеальное качество. Иногда банально надо мобильную версию сайта перетащить в приложение и добавить уведомления
                        0
                        Как раз игры делают в основном кроссплатформенными, а вот калькулятор все-равно как писать))
                          0
                          Скорее неправильно выразился, хотел донести, что нативная разработка не единственное правильное решение ))

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

                      Самое читаемое