Pull to refresh

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

Reading time 9 min
Views 11K
Original author: 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 лет использовал нативную мобильную разработку в качестве основного набора инструментов. Одна из многих причин, по которым я доволен своим решением, состоит в том, что я нашел время, чтобы рассмотреть как можно больше тонкостей для каждого инструмента. Я знаю плюсы и минусы, и это дает мне преимущества.
Я надеюсь, что эта статья поможет вам задать правильные вопросы при выборе инструмента. Не принимайте маркетинг за чистую монету, и ПОЖАЛУЙСТА, не следуйте за хайпом. Копайся, пачкайся и думай критически.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+6
Comments 27
Comments Comments 27

Articles