Сравниваем подходы нативной и кроссплатформенной мобильной разработки в 2021 году

Артём Тарасов

Инженер-программист компании «Рексофт»

Не так давно наткнулся на статью былых времён про кроссплатформенную разработку. Она начиналась примерно так: «Не буду томить, давайте сразу проясним, кроссплатформенная мобильная разработка никогда не достигнет уровня нативных решений в плане производительности, опыта пользования и/или разработки». На дворе 2021 год, и за последние несколько лет кроссплатформенная разработка сделала заметный рывок вперед. Посмотрим, как обстоят дела на рынке кроссплатформенных решений сейчас.

В начале десятых годов на рынке смартфонов было много игроков со своими подходами к разработке. Вспомнить хотя бы Symbian, история которого закончилась в 2012 году, и Blackberry OS, с которым мы попрощались в 2013 году. Или Windows Phone, поддержка которого прекратилась в 2015 году. История свела всё к тому, что на рынке остались две доминирующие платформы — Android и iOS. Они заняли в совокупности 99% рынка, не оставив остальным практически ни единого шанса.

Нативными языками для разработки под Android и iOS являются Java/Kotlin и Objective-C/Swift соответственно. Языки (по крайней мере, Kotlin и Swift) поддерживаются компаниями-владельцами платформ: Google и Apple. И разработчики получают доступ ко всем возможностям и «фишкам» платформ, as fast as they can. У нативной разработки тем не менее есть одна существенная проблема – стоимость. При выборе нативной разработки придётся поддерживать минимум две платформы раздельно. Это может привести к трудностям не только с финансовой стороны, но и со стороны дальнейшей поддержки и развития. Для подобной проблемы достаточно быстро нашлось решение – разработка кроссплатформенных решений с единой кодовой базой.

Есть достаточное количество различных фреймворков для создания кроссплатформенных решений. Существуют такие решения, как гибридные платформы/PWA (Progressive Web Applications). Их я предлагаю не рассматривать, так как они (e.g. PhoneGap, Cordova, Ionic) не только не могут отвечать современным требованиям к производительности мобильных приложений. А также заставляют испытать крайне негативный опыт как пользователей, так и разработчиков. Про Cocos2d-x или Unity упоминать в рамках данной статьи тоже не стану. Мы можем получить приложение, которое выглядит схоже на обеих платформах, но нативным не будет выглядеть ни на одной из платформ.

Из оставшихся решений можно выделить три самых многообещающих: Xamarin, Kotlin Multiplatform, Flutter (спойлер: я бы выбирал из последних двух). Предлагаю рассмотреть каждое подробнее.

Xamarin

Фреймворк, созвучный с названием компании-разработчика, которая была приобретена в 2016 году компанией Microsoft, был разработан в 2011 году. Он позволяет войти в мобильную разработку людям, которые пишут на С#. Благодаря возможности при необходимости совмещать кроссплатформенный код с использованием части нативных решений, Xamarin-проект может предоставить пользователю полностью нативный опыт использования. При том, что кодовая база может оставаться практически единой.

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

Однако есть и свои подводные камни. Один из самых очевидных: для работы с платформой всё ещё необходимы навыки работы с нативными решениями, так как Xamarin-библиотеки зачастую не покрывают весь необходимый функционал. Нередко можно столкнуться с тем, что библиотека устаревает, а за её обновление никто не берётся. Найти в наше время разработчиков, прилично работающих одновременно с C#, Kotlin, Swift, сложно, но можно. Однако стоимость таких специалистов будет в большую сторону отличаться от нативщиков.

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

Kotlin Multiplatform

Самое молодое из описанных решений — Kotlin Multiplatform (KMP), разработанное компанией JetBrains (они же создатели языка Kotlin, который является официальным языком для разработки под Android). В концепции это не фреймворк для создания кроссплатформенных приложений, а именно SDK, позволяющий создавать модули с единой кодовой базой, которые впоследствии подключаются к нативным приложениям.

Решение очень привлекательно с точки зрения того, что большая часть Android-разработки уже ведётся на Kotlin, а по своему синтаксису язык очень похож на Swift (и чем дальше, тем больше). Однако всё же некоторое время может уйдёт на обучение. Не стоит ожидать, что любая команда сможет пересесть на работу с KMP за условный час.

Платформа идеально подходит в случае, если уже есть рабочее приложение. Можно объединить части и получить значительное упрощение процесса поддержки и развития. Однако если требуется вести разработку приложения «с нуля», тут я скорее бы обратился к Flutter.

Flutter

Самый быстроразвивающийся фреймворк для кроссплатформенной разработки. Он был представлен в 2017 году компанией Google и успел наделать немало шума. Разработка с использованием этого фреймворка ведётся на довольно-таки бывалом языке Dart, история которого началась ещё в далёком 2011 году (трава была зеленее, а смартфоны разнообразнее).

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

С помощью Flutter создаётся единый UI (с помощью декларативного подхода) для обеих платформ. И тут не будет ограничений по кастомизации нативных UI-компонентов (в Xamarin с этим было туговато). Есть три категории виджетов:

• Material Widget;
• Cupertino Widget;
• остальные (обобщённые) виджеты.

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

Ещё один плюс — достаточно далёкий и прозрачный — в том, что в данный момент Flutter является единственным способом разработки под мифическую Fuchsia OS от Google. Если она когда-нибудь выйдет (а это не точно), Flutter предоставляет возможность быть к этому готовым.

Нельзя не упомянуть о парадигме Everything is widget, которая используется в Flutter. Там нет привычного разделения на какие-то условные Activity и Fragment. Всё, что мы видим перед собой — это виджет. Мы создаем другие виджеты, складывая их вместе. Я считаю этот подход масштабируемым, мощным и простым для понимания.

Однако для раскрытия полного потенциала всё ещё необходимо взаимодействие с нативными компонентами. То есть разработчику помимо языка Dart необходим опыт работы с Kotlin/Swift. И мы снова в тупике с проблемой того, что знания специалиста должны покрывать три языка. А это может выйти боком для бюджета (благо, такие специалисты стоят не в три раза дороже обычных нативщиков).

Есть также проблемы более мелкого плана, вроде проблем с кодогенерацией, работы с Media и JSON. Но надо учитывать, что, во-первых, Flutter всё ещё на стадии активного развития, а во-вторых, эти незначительные проблемы с головой покрывают возможности и перспективы, которые перед нами открывает этот фреймворк.

У Flutter есть огромный потенциал в мире кроссплатформенной разработки, и его можно смело выбирать как фреймворк для разработки в 2021 году. Однако стоит быть готовым к столкновению с некоторыми ограничениями и тем, что может «затормозить» работу.

Итоги

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

Если необходим доступ к глубоким платформенным возможностям, «свобода» в выборе пути развития или решения проблем ПО, и — наверное, так будет всегда — стабильность, то ваш выбор — Native (Kotlin / Swift). Если необходимо минимальное время выхода на рынок (TTM), бюджет сжат или уже есть рабочее приложение и возможность пойти на некоторый риск с новым программным продуктом – кроссплатформенная разработка ждёт Вас. Что же до статистики по возможности сэкономить при выборе кроссплатформенной разработки, официальной статистики нет. Но как правило, удаётся сэкономить 25%-30% времени на разработку по сравнению с нативными решениями.