CROSS-PLATFORM РАЗРАБОТКА МОБИЛЬНЫХ ПРИЛОЖЕНИЙ — ПЛЮСЫ И МИНУСЫ

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

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

В этой статье я хочу сфокусироваться на мобильной разработке, рассмотреть преимущества и недостатки кроссплатформенного подхода и ответить на вопрос: «Стоит ли отказываться от классического подхода в сторону кроссплатформенности?».

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

В мире мобильных устройств доминируют две платформы: iOS и Android. Для разработки приложений для этих систем компании Apple и Google выпустили соответствующие SDK. Приложения под Android разрабатываются с помощью Java или Kotlin в Android Studio, под iOS — с помощью Swift в Xcode.

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

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

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

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

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

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

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

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

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

Начать стоит с React Native, кроссплатформенного фреймворка от Facebook, построенного на основе сверхпопулярной JS библиотеки, React Native делает переход от web-разработки к мобильной максимально простым. Технология Fast Refresh позволяет практически мгновенно отображать изменения в коде на устройстве, тем самым сильно ускоряя разработку приложения. Так как фреймворк основан на React Js, разработка на нем осуществляется с помощью JavaScript, позволяя front-end разработчикам быстро переключиться на разработку кроссплатформенных мобильных приложений.

И хотя у React Native есть определенные проблемы с производительностью, он все еще остается самым популярным кроссплатформенным фреймворком с огромным комьюнити, поддерживающим гигантское количество библиотек, что в свою очередь еще сильнее ускоряет разработку и облегчает поиск новых разработчиков. Но конкурент React Native от Google все ближе и ближе подбирается к его популярности.

Flutter — относительно молодой фреймворк, выпущенный в 2017 году, но, несмотря на небольшой возраст, он заработал большую популярность в сообществе разработчиков. Flutter постоянно развивается. Изначально представленный как фреймворк для кроссплатформенной мобильной разработки, он уже перерос это определение. Сейчас на основе набора средств Flutter можно разрабатывать мобильные, web и desktop приложения. Hot Reload, по аналогии с Fast Refresh в React Native, позволяет мгновенно увидеть изменение на экране устройства, а большое количество библиотек практически полностью закрывает собой ограниченный доступ к API системы (хотя в выборе библиотек нужно быть осторожным, так как некоторые из них могут не поддерживать часть платформ) и дает возможность свести написание нативного кода к минимуму или отказаться от него совсем.

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

В Doubletapp на основе набора средств разработки Flutter разработана клиентская часть корпоративной CRM-системы — DTIS. При разработке мы использовали все преимущества Flutter и в итоге запустили систему в виде web-версии, мобильного приложения под iOS и Android, а также настольного приложения для Mac OS, Windows и Linux.

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

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

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

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

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

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

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