мультиплатформенная разработка мобильных приложений
Как выбрать мобильную кросс-платформу в 2021 году
Новый развивающийся бизнес зачастую в первую очередь ориентируется на мобильные технологии: социальные сети, необанкинговые решения, приложения для электронной коммерции, такси и другие. Новый бизнес ориентирован на экономическую эффективность, поэтому переход на кросс-платформенность для разработки мобильного приложения кажется правильным выбором. Посмотрим, что будет в 2021 году и как выбрать правильную технологию.
Познакомимся с Женей
Евгения — солюшн-архитектор. Она должна решить, как построить новое мобильное приложение для изучения английского языка не носителями: людьми из Турции, Италии или России. Давайте посмотрим, как Женя подходит к этой задаче.
Приложение должно включать в себя богатую анимацию, уметь воспроизводить и записывать аудио, показывать видео с субтитрами, а также статические и динамические изображения.
В компании — владельце приложения также ожидают, что разработкой будет заниматься единая команда — как для Android- и iOS-приложений, чтобы свести к минимуму усилия по передаче знаний и максимизировать скорость команды. В будущем также планируют запустить веб-приложения. А еще в компании хотели бы упростить будущий найм.
Прогрессивные веб-приложения
Женя начинает свои исследования. Она гуглит «мобильные веб-приложения» и находит статью. В ней упоминаются «Прогрессивные веб-приложения» (PWA). Что это такое?
Прогрессивные веб-приложения — это, по сути, веб-сайты, которые используют специальные API для доступа к определенным возможностям устройства. Эти API позволяют получить доступ к памяти на устройстве, интегрируются с Push Notifications (на Android) и, что самое важное, работать в отдельной вкладке браузера. Еще их можно установить на устройство «иконкой», как настоящее приложение. Звучит неплохо! Давайте посмотрим на плюсы и минусы PWA:
Кроссплатформенная и нативная разработка мобильных приложений в 2021 году
CEO компании по разработке ИТ-решений FriFlex
В мире более пяти миллиардов смартфонов. Из них около 85% работают на Android, остальные 15% — на iOS, по данным IDC. Казалось бы, выгоднее разработать нативное приложение для Android? Но не все так однозначно, и всегда жаль терять одну из аудиторий.
Чтобы оптимизировать процесс и не программировать мобильное приложение для каждой из операционных систем, можно прибегнуть к кроссплатформенной разработке. В ее основе лежит единый исходный код и стек технологий.
Петр Чернышев, CEO Friflex, компании, которая специализируется на разработке кроссплатформенных приложений, объясняет, что эти технологии дают бизнесу и почему лучше выбирать Flutter.
Получить цифровую карту за 40 секунд — легко!
Содержание:
Что такое кроссплатформенная и нативная разработка?
Рассмотрим три основных варианта разработки приложений.
PWA — это технология, которая трансформирует веб-сайт в мобильное приложение. PWA позволяет открывать приложение с помощью мобильного браузера.
Нативная разработка позволяет создавать приложения только для одной ОС — отдельно для iOS, Android и других. Разработка осуществляется строго на нативном языке программирования ОС. К примеру, в iOS применяются языки Swift/Objective-C, в Android — Java/Kotlin. При выборе нативной разработки придется поддерживать минимум две платформы раздельно. Нативное приложение будет работать только на «своей» платформе. Один код — одна ОС.
Кроссплатформенная разработка, ее также называют мультиплатформенной. В этом случае используется единая кодовая база, которая подойдет для разных платформ, будь то Android, iOS, Windows, macOS, Linux. Технология может применяться даже в умных часах или для программирования бытовой техники.
Различия кроссплатформенной и нативной разработки
Нативная разработка однозначно проигрывает мультиплатформенной с точки зрения финансовых затрат. Ведь для нее нужно практически задвоить все процессы. Разные логика предметной области, кодовая база и технологический стек ведут к:
Когда стоит применять мультиплатформенную разработку?
У кроссплатформенных фреймворков нет ограничений для реализации функций в мобильном приложении. И есть и объективные причины для использования кросс-платформенной разработки:
Но есть и случаи, когда нативная разработка может оказаться предпочтительнее. Однако это не означает, что применение нативной разработки всегда менее целесообразно. В некоторых ситуациях стоит выбрать именно ее:
Лучшие кроссплатформенные фреймворки для приложений
Разберем четыре самые популярные кроссплатформенные технологии и выделим их особенности.
Разработан Facebook для поддержки таких платформ, как iOS, macOS, Apple tvOS, Android, Android TV, Web, Windows и UWP. Технология дает возможность работать с библиотекой React вне браузера для создания нативных приложений, имеющих полный доступ к системным API-платформам.
Позволяет использовать единый исходный код для логики предметной области приложений Android и iOS. Специфичный для платформы код потребуется только в определенных моментах (при работе со специфичными для платформы API или для разработки собственного пользовательского интерфейса).
Фреймворк разработан Google и постоянно обновляется. При том, что технология использует один код для двух ОС, для конечного пользователя приложение не отличается от нативного. Таким образом, Flutter совмещает в себе преимущества кроссплатформенного и нативного подходов, что уже оценили многие крупные компании. Свой выбор в пользу данной технологии сделали Alibaba, Philips Hue, Hamilton, Tencent, Grab, Groupon, ГК «Дикси», «Яндекс.Драйв» и другие мировые и российские компании.
Сравнительная таблица кроссплатформенных фреймворков, по данным на январь 2021
Команда Friflex успела поработать и оценить все фреймворки. Опираясь на богатый опыт, мы выбрали Flutter, который постоянно развивается и предлагает новые функции и разработчику, и бизнесу.
Google активно работает над фреймворком и постоянно его обновляет: в марте 2021 года компания представила обновленную версию Flutter 2. Согласно исследованию Statista, в 2020 году Flutter использовали 39% мировых девелоперов, в 2021 показатель составил 42%, сместив React Native на второе место. Такой рост популярности обусловлен высокой скоростью написания кода.
Опрос на портале Stackoverflow показал, что Flutter входит в тройку любимых фреймворков разработчиков. Пользователи GitHub (крупнейшего сервиса для хранения исходного кода) также положительно оценили Flutter. На данный момент у фреймворка уже 128 тыс. звезд.
Данные сайта insights.stackoverflow.com
Преимущества кроссплатформенной разработки приложений
К преимуществам кроссплатформенной разработки относят скорость разработки (она выше) и стоимость разработки (она ниже). Расскажем о преимуществах на примере фреймворка Flutter:
Google Trends подтверждает растущий интерес к фреймворку Flutter, это видно из сравнительного графика ниже.
Данные сайта trends.google.ru
Flutter используется разработчиками по всему миру. А благодаря сокращению времени разработки кода, увеличению скорости вывода продукта на рынок, производительности, близкой к нативной, и другим преимуществам, нет сомнений, что Flutter будет развиваться и доминировать на рынке в ближайшем десятилетии.
Комбинация кроссплатформенного и нативного подхода в разработке мобильных приложений
Выпускать приложения для лишь одной мобильной платформы – не актуально и нужно заботиться о разработке сразу двух версий, для iOS и Android. И здесь можно выбрать два пути: работать на «нативных» языках программирования для каждой операционной системы или использовать кроссплатформенные фреймворки.
При разработке одного из проектов в компании DD Planet я сделал ставку на последний вариант. И в этой статье расскажу об опыте разработки кроссплатформенного приложения, проблемах, с которыми мы столкнулись, и найденных решениях.
Три подхода в разработке кроссплатформенных мобильных приложений
Для начала рассмотрим, какие подходы используются, когда нужно получить сразу два приложения: под iOS и Android.
Первый – cамый затратный, как по времени, так и по ресурсам: разработка отдельного приложения для каждой из платформ. Сложность этого подхода заключается в том, что каждая из операционных систем требует своего подхода: это выражается как в языке, на котором ведется разработка (для Android – Java или Kotlin, для iOS – Objective-C или Swift), так и способах описания UI части приложения (axml и xib или storyboard файлы соответственно).
Уже этот факт подводит нас к тому, что для такого подхода необходимо формирование двух команд разработчиков. Помимо этого придется дублировать логику для каждой из платформ: взаимодействие с api и бизнес-логику.
А что, если количество используемых API будет расти?
Из этого возникает вопрос: как уменьшить необходимое количество человеческих ресурсов? Избавиться от необходимости дублировать код для каждой платформы. Существует достаточное количество фреймворков и технологий решающих эту задачу.
Использование кроссплатформенного фреймворка (Xamarin.Forms, например) дает возможность писать код на одном языке программирования и описать логику данных и логику UI один раз, в одном месте. Поэтому необходимость использовать две команды разработчиков отпадает. А по итогу компиляции проекта на выходе получаем два нативных приложения. И это – второй подход.
Цель проекта — позволить запускать программы, написанные на C#, на операционных системах, отличных от Windows — Unix-системах, Mac OS и других. Сам же фреймворк Xamarin, по сути своей – библиотека классов, предоставляющей разработчику доступ к SDK платформы и компиляторы для этих них. Xamarin.Forms, в свою очередь, позволяет не только писать под обе платформы на одном языке, но проектировать дизайн экранов с использованием XAML разметки, привычной тем, кто уже имел опыт работы с WPF приложениями. В итоге сборки проекта получаем практически идентичный вид на всех платформах, так как на этапе компиляции все XF контролы преобразовываются в нативные для каждой платформы.
Писать код для каждой платформы разработчик вынужден только в том случае, если нужен доступ к каким-либо платформенным фичам (например, дактилоскопический сканер или уровень заряда батареи) или же необходимо более тонко настроить поведение контрола. В некоторых случаях при разработке приложения может потребоваться написание платформозависимого кода, но даже в этом случае никто не запрещает вынести платформенные функции в интерфейс и взаимодействовать в дальнейшем с ним из общего проекта.
Один язык программирования, мало кода и так далее. Все это звучит красиво но, Xamarin.Forms – не серебряная пуля, и вся его красота разбивается о камни реальности. Как только возникает ситуация, когда встроенные в XF-контролы уже не отвечают предъявленным к ним требованием, структура экранов и контролов становится всё сложнее и сложнее. Для обеспечения комфортной работы с экранами из общего проекта приходится писать все больше и больше кастомных рендеров.
На этом перейду к третьему подходу, который мы и используем при разработке приложений.
Мы уже выяснили, что использование Xamarin Forms может осложнить работу, а не упростить ее. Поэтому для реализации архитектурно сложных экранов, дизайнерских элементов и контролов, кардинально отличающихся от нативных, нашелся компромисс и возможность объединения первого и второго подхода.
Имеем все те же три проекта: общий PCL проект, но уже без Xamarin Forms, и два проекта Xamarin Android и Xamarin iOS. По-прежнему имеется возможность писать всё на одном языке, общая логику между двумя проектами, но нет ограничений единой XAML разметки. UI-составляющая контролируется каждой из платформ и использует нативные средства, на Android – нативный AXML, на iOS – XIB-файлы. Каждая платформа имеет возможность соблюдать свои гайдлайны, так как связь между Core и платформенными проектами организовывается только на уровне данных.
Для организации такой связи можно использовать паттерн проектирования MVVM и достаточно популярную его реализацию для Xamarin – MVVMCross. Его использование позволяет держать общую ViewModel для каждого экрана, где описана вся “бизнес-логика” работы, а его отрисовку доверить платформе. Так же это позволяет двум разработчикам работать с одним и тем же экраном (один с логикой — другой с UI) и не мешать друг другу. Кроме реализации паттерна, получаем достаточное количество инструментов для работы: реализация DI и IoC. Для подъема взаимодействия с платформой на уровень общего кода разработчику достаточно объявить интерфейс и реализовать его на платформе. Для типовых вещей MvvmCross уже предоставляет набор собственных плагинов. В команде мы используем плагин мессенджера для обмена сообщениями между платформой и общим кодом и плагин для работы с файлами (выбор изображений из галереи и др.).
Решаем проблемы сложного дизайна и многоуровневой навигации
Как уже было сказано раньше, при использовании сложных представлений на экране фреймворк может больше усложнить жизнь, чем облегчить. Но что назвать сложным элементом? Так как я занимаюсь преимущественно разработкой iOS, пример этой платформы и будет рассмотрен. Например, такая тривиальная вещь, как поле ввода, может иметь несколько состояний и достаточное количество логики для переключения и визуализации.
1000 строк. И, казалось бы: чего сложного может быть в дизайне поля ввода?
Простой пример сложного контрола мы увидели. А что с экранами?
Для начала уточню, что один экран приложения в большинстве случаев является одним классом – UIViewController, описывающим его поведение. В ходе разработки потребовалась создание многоуровневой навигации. Концепция разрабатываемого приложения сводится к управлению своей недвижимостью и взаимодействию с соседями и муниципальными организациями. Поэтому были построены три уровня навигации: собственность, уровень представления (дом, город, регион) и тип контента. Все переключение осуществляется в рамках одного экрана.
Делалось это для того, чтобы пользователь, где бы он ни находился, понимал, какой контент он видит. Для организации такой навигации главный экран приложения состоит далеко не из одного контроллера. Визуально его можно разделить на 3 части, но кто-нибудь сможет попробовать предположить сколько здесь использовано контроллеров?
Пятнадцать основных контроллеров. И это только для контента.
Вот такой монстр живёт на главном экране и неплохо себя чувствует. Пятнадцать контроллеров для одного экрана это, конечно, очень много. Это сказывается на скорости работы всего приложения, и нужно как-то это оптимизировать.
Мы отказались от синхронной инициализации: все вью-модели инициализируются в фоне и только тогда, когда это потребуется. Чтобы снизить время отрисовки, так же отказались от xib-файлов для этих экранов: абсолютное позиционирование и математика всегда быстрее, чем просчет зависимостей между элементами.
Чтобы уследить за таким количеством контроллеров нужно понимать:
Так как каждый таб представляет собой слайдер контроллеров (для того, чтобы создать на них свайповый переход), нужно понимать: каждый из них может находится в своем состоянии (например на одном открыты “Новости”, на другом “Голосования”). За этим следит всё тот же процессор навигации. Даже сменив уровень представления с дома на регион, мы останемся на том же типе контента.
Управляем потоком данных в реальном времени
Работая с таким количеством данных в приложении, нужно организовать поставку актуальной информации по всем разделам в реальном времени. Для решения этой задачи можно выделить 3 способа:
ASP.Net SignalR – библиотека от компании Microsoft, которая упрощает клиент-серверное взаимодействие в реальном времени, обеспечивая двунаправленную связь между клиентом и сервером. Сервер включает в себя полноценное API для управления соединением, события подключения-отключения, механизм объединения подключенных клиентов в группы, авторизацию.
SignalR может использовать в качестве транспорта и websockets, и LongPolling, и http-запросы. Тип транспорта можно указать принудительно или же довериться библиотеке: если можно использовать websocket, то он будет работать через websocket, если такой возможности нет, то он будет спускаться дальше, пока не найдет приемлемый транспорт. Этот факт оказался очень практичным, учитывая то, что планируется использовать его на мобильных устройствах.
Итого, какую выгоду мы получаем:
Внутри проекта используется обертка над SignalR библиотекой, которая еще больше упрощает работу с ним, а именно:
Второй клиент отвечает за получение нотификаций. Как я уже говорил, контент обычного типа получается посредством http-запросов, в дальнейшем его актуализация ложится на этот клиент, который и сообщает о всех важных изменениях в нём (например голосование перешло из одного статуса в другой, публикация новой новости).
Визуализируем данные в приложении
Одно дело данные получить, другое – показать. В обновлении данных в реальном времени есть свои сложности. Как минимум надо решить, как эти самые обновления презентовать пользователю. В приложении мы используем три вида нотификаций:
Автоматически обновлять данные можно только тогда, когда новый контент не перестраивает экран и не меняет размер контролов. Например, на экране опроса: информация о голосах всего лишь изменит значение прогресс-бара и проценты. Такие изменения не повлекут никакого изменения размеров их можно без проблем применить мгновенно.
Сложности возникают тогда, когда необходимо добавлять новый контент в списки. Все списки в приложении, по сути, являются ScrollView и обладают несколькими характеристиками: размер окна, размер контента и позиция скрола. Все они имеют статичное начало (верх экрана с координатами 0;0) и могут расширяться вниз. Добавить новый контент вниз списка, в конец, не представляет никаких проблем, список продлится. Но новый контент должен появиться вверху, и получается вот такая картина:
Находясь на 3 элементе, мы окажемся на 2 – скролл отскочит вверх. А так как новый контент может поступать постоянно – нормально скроллить пользователь не сможет. Вы, быть может, скажете: почему бы не рассчитать размер нового контента и не сместить скролл вниз на это значение? Да, так можно сделать. Но тогда придется вручную управлять позицией скролла, и если в этот момент юзер скроллил в каком-либо направлении, его действие прервется. Именно поэтому такие экраны нельзя обновлять в реальном времени без согласия пользователя.
Оптимальным решением в этой ситуации будет проинформировать пользователя, что, пока он скроллил ленту, кто-то опубликовал новый контент. В нашем дизайне это выглядит как красный круг в углу экрана. Кликнув на него, пользователь дает свое условное согласие на то, чтобы мы вернули его к началу экрана и показали свежий контент.
Таким подходом мы, конечно, избежали проблем «подсовывания» контента, но их все равно пришлось решать. А именно на экране чата, так как в ходе общения и взаимодействия с экраном новый контент необходимо отображать в разных местах.
Отличие чата от обычных списков заключается в том, что свежий контент находится внизу экрана. Так как это «хвост», добавлять контент туда можно без особых затруднений. Пользователь проводит здесь 90% времени, а это означает, что нужно постоянно держать позицию скролла и смещать его вниз при получении и отправке сообщений. В живой беседе такие действия приходится делать достаточно часто.
Второй момент: загрузка истории при скролле вверх. Как раз при подгрузке истории мы и попадаем в ситуацию, когда необходимо поместить сообщения выше уровня обзора (что повлечет смещение), чтобы скролл был плавным и непрерывным. А как мы уже знаем, чтобы не помешать пользователю, вручную управлять позицией скролла нельзя.
И мы нашли решение: мы его перевернули. Переворот экрана решил сразу две проблемы:
Такое решение помогло так же и ускорить отрисовку, избавив от лишних операций с управлением скроллом.
Кстати, о быстродействии. В первых вариантах экрана обнаружились заметные просадки при скролле сообщений. Так как контент в «баблах» разношерстный – текст, файлы, фотографии, — необходимо постоянно пересчитывать размер ячейки, добавлять и удалять элементы в бабл. Поэтому потребовалась оптимизация баблов. Мы поступили так же, как и с главным экраном, частично отрисовывая бабл абсолютным позиционированием.
При работе со списками в iOS перед отрисовкой ячейки необходимо знать её высоту. Поэтому, прежде чем добавлять новое сообщение в список, нужно в отдельном потоке приготовить всю нужную информацию для отображения, рассчитать высоту ячеек, обработать данные пользователя и, только после того, как мы узнаем и закэшируем всё что нужно, добавить ячейку в список.
В итоге мы получаем плавный скролл и не перегруженный UI поток.
Кроссплатформенная мобильная разработка: история вопроса
Когда речь заходит о разработке «сразу для Android и iOS», начинаются холивары и гадания на кофейной гуще. Что перспективнее, Flutter или Kotlin Multiplatform Mobile? За этими технологиями будущее, или завтра их обе забудут?
Уверенно делать прогнозы по принципу «я так вижу» — занятие весёлое, но бессмысленное. Как подойти конструктивнее? Как известно, «кто забывает об истории, обречён на её повторение». Поэтому я решил вспомнить, какими были решения «Android+iOS» до Flutter/KMM, и посмотреть, что с ними стало. Тогда вместо голых спекуляций будут суровые факты. И эти факты из прошлого полезны для понимания будущего: они показывают, где разложены грабли.
Большинство старых технологий я не использовал лично, но благодаря общению со спикерами нашей конференции Mobius узнал многое об их опыте с этими решениями. Если вы тоже работали с чем-то из перечисленного, смело дополняйте в комментариях, будет интересно и полезно.
Оглавление
Web / PWA
В 2007-м, представляя разработчикам первый iPhone, Стив Джобс объяснял, что нативные приложения не нужны: «В iPhone есть полный движок Safari. Так что можете писать потрясающие Web 2.0 и Ajax-приложения, которые выглядят и действуют на iPhone именно как приложения».
Android на тот момент ещё даже не был анонсирован. Но получается, что исторически первым единым решением для iOS и Android стал веб.
Вот только разработчики не разделили энтузиазм Джобса (неудивительно, учитывая тогдашнее состояние мобильного интернета). И годом позже всё-таки появился App Store для нативных приложений. А его комиссия в 30% стала новым денежным потоком для Apple. В итоге позиция компании сменилась на противоположную: теперь она считает, что правильный подход — это натив (и предпочитает не вспоминать, что там её лидер говорил в 2007-м, Океания всегда воевала с Остазией).
Однако идея веб-приложений не исчезла, а продолжила развиваться. И в 2015-м новое поколение таких приложений назвали «Progressive Web Apps». Они могут хранить данные локально, работать в офлайне, а ещё их можно установить на домашний экран смартфона. Чем это тогда не «настоящие» мобильные приложения? Что ещё для счастья надо?
Ну, например, для счастья нужны push-уведомления. По состоянию на 2021-й iOS не поддерживает их у PWA, и это мощнейший стопор для распространения подхода. Получается, компания, которая первой хвалила веб-приложения, позже сама поставила главное препятствие на их пути. На change.org есть даже петиция, обращённая к Apple: «мы всё понимаем, вы дорожите своими 30%, но эта ситуация должна измениться».
Что в итоге: подход жив, но не стал общепринятым — во многом из-за ограничений Apple. В будущем что-то может измениться, стоит следить.
PhoneGap/Apache Cordova
Это решение тоже связано с вебом, но подход другой — так называемый «гибридный». Тут предложили использовать знакомую троицу HTML/CSS/JS, но результат не публиковать в виде сайта, а упаковать в «контейнер» нативного приложения. В таком случае не сталкиваешься с ограничениями веба и можешь реализовать те же push-уведомления.
PhoneGap появился в 2009-м благодаря компании Nitobi, а в 2011-м Adobe купила её и выделила основу в опенсорсный проект Apache Cordova. У него модульная архитектура, позволяющая подключать плагины. И в сочетании с опенсорсностью это означает, что если Cordova не умеет чего-то нужного (например, взаимодействовать с акселерометром смартфона), сообщество может «научить». Вроде как прекрасно, да?
На практике что-то не очень. В своё время некоторая популярность у проекта была, те же плагины появлялись, но масштабного «захвата рынка» не произошло. А затем всё и вовсе пошло на спад.
Почему так? Среди главных причин называют UX, уступающий нативным приложениям. Всё хуже и с производительностью, и с плавностью. Но основное отличие даже не измерить числами: пользователю попросту заметна разница между гибридным приложением и нативным, они производят разное впечатление. Для людей «через WebView ощущения не те».
А с годами сказалось ещё и развитие веба. Чем лучше становились веб-приложения и чем быстрее становился мобильный интернет, тем меньше преимуществ можно было получить от гибридного подхода.
Интересно, что авторы проекта сами предвидели такое развитие событий и ещё в 2012-м написали, что «итоговая цель PhoneGap — прекратить своё существование». И недавно эта цель была достигнута: в 2020-м Adobe заявили о прекращении разработки PhoneGap, ссылаясь на то, что нишу закрыли PWA. Cordova как опенсорсный проект формально жив, но без участия Adobe вряд ли стоит ожидать в нём большой активности.
Что в итоге: по сути, проекта больше нет.
Проект Qt помогал людям заниматься кроссплатформенной разработкой ещё с 90-х, когда ни о каких айфонах слыхом не слыхивали, и речь шла о десктопных ОС. При этом он завязан на C++, который для Android и iOS не совсем чужой: даже нативные разработчики на этих платформах могут обращаться к «плюсам». Так что, казалось бы, поддержка iOS/Android со стороны Qt просто напрашивалась.
Но поначалу дело осложнялось тем, что в 2008-м проект купила Nokia. Компания тогда делала ставку на Symbian и не горела желанием помогать конкурентам. В 2010-м возможностью запускать Qt-приложения на Android занимались энтузиасты, и на Хабре об этом писали:
В 2011-м Nokia отказалась от Symbian в пользу Windows Phone, а часть проекта Qt продала компании Digia. И тогда началась работа над поддержкой одновременно Windows 8, Android и iOS. Ну вот теперь-то счастье? Спустя 10 лет ясно, что тоже нет.
Вакансии по мобильной разработке на Qt сейчас единичные. Хабрапосты о ней появляются очень редко и не свидетельствуют об успехе: в одном причиной использования Qt стала ОС «Аврора» (экс-Sailfish), в другом попросту «у меня уже был большой опыт с ним».
Что помешало? Я встречал жалобы на то, что недостаточно было использовать сам Qt и писать на С++/QML. Потому что средствами Qt многое было не реализовать, и приходилось-таки иметь дело с конкретной платформой (например, на Android работать с Java, увязывая это с «плюсовой» частью через JNI). Всё это очень неудобно и подрывает исходную идею «бодренько запилим два приложения по цене одного».
При этом здесь пользователь тоже ощущает «не-нативность». А к IDE Qt Creator есть нарекания, рантайм Qt увеличивает размер приложения, бесплатный вариант Qt подходит не всегда и может понадобиться недешёвый коммерческий. Кроме того, мне лично кажется, что ещё сказался язык. Кроссплатформенной разработке желательно быть такой, чтобы нативным разработчикам было попроще перекатиться туда, а с языком C++ слово «попроще» не ассоциируется.
И хотя случаи использования Qt встречаются до сих пор, это скорее исключения из правил, у которых могут быть какие-то особые исходные условия: например, «хотим перетащить на телефоны с десктопа уже имеющуюся кодовую базу на C++».
Что в итоге: крайне нишевое решение, которое не умерло, но используется очень узкой прослойкой.
Xamarin
Надо понимать контекст того времени. Годом ранее компания Microsoft выпустила Windows Phone и стремилась стать третьим большим игроком на мобильном рынке. И даже «большая» Windows лезла на мобильный рынок: готовилась к выходу Windows 8, оптимизированная для планшетов.
В таком контексте идея «писать под все смартфоны на языке от Microsoft» выглядит логично. Ведь если для кроссплатформы применяется «родной» язык одной из главных платформ, то он уже знаком части мобильных разработчиков, и они могут переиспользовать что-то из существующих кодовых баз. В общем, будет проще «наводить мосты».
Но теперь задним числом мы знаем, что мобильные амбиции Microsoft заглохли. И это оставило Xamarin в странном положении: на рынке две живых платформы, а тут предлагают писать для обеих на языке умершей третьей. Ни айосеров, ни андроидоводов такое сильно не привлекает.
Ещё порой вызывали недовольство и то, что после появления новых фич в Android/iOS приходилось ждать их поддержки в Xamarin, и стоимость лицензии, и общее состояние экосистемы (документация, поддержка, библиотеки).
Что в итоге: пока всё остаётся в странноватом статусе, когда и масштабного взлёта не получилось, и полностью не прекращено.
React Native
В 2013-м в Facebook выпустил React, ставший очень успешным во фронтенде, а в 2015-м за ним последовал React Native, приносящий подход в мобильную разработку.
Писать предлагается на JavaScript, поэтому кому-то может показаться, что это реинкарнация PhoneGap и его HTML-подхода, но нет. Когда-то Facebook действительно полагался для мобильных устройств на HTML, но ещё в 2012-м Цукерберг назвал это ошибкой. И у React Native идея не в том, чтобы с помощью HTML/CSS городить что хочешь, а в том, чтобы с помощью JSX использовать нативные элементы UI — так что пользователь ощущал себя «прямо как с нативным приложением».
Насколько это получилось? Шероховатости и «срезанные углы» существуют — с ними сталкиваются и разработчики, и пользователи. Для кого-то они оказываются критичными: особенно нашумел пост Airbnb, где после React Native решили вернуться к нативной разработке. Но какие-то другие компании (вроде самой Facebook) эти ограничения не остановили, использование в индустрии есть.
Поскольку нативной «отполированности» не достичь, это решение часто рекомендуют для случаев, где она и не требуется. Если пользователь залипает в приложении часами (как в соцсетях), то любая неаккуратная мелочь будет бросаться ему в глаза — но вот если юзкейс приложения такой, что его включают на минуту в неделю, то эти мелочи просто никто не заметит.
Если зайти на HeadHunter и сравнить число вакансий по React Native с нативной разработкой, то их немного. Но вот если сравнивать с Qt/Xamarin/PhoneGap — то вакансий окажется больше, чем у них всех, вместе взятых, это наиболее успешный вариант.
Что в итоге: React Native не стал так успешен, как его фронтендовый «старший брат», но определённую нишу занял.
Flutter, KMM и выводы
А теперь, после всего перечисленного, у нас появились новые решения: Flutter и Kotlin Multiplatform Mobile.
Первое от Google, сначала появилось как решение для Android и iOS, а позже заявили также о поддержке десктопа и веба. Flutter предлагает писать на языке Dart и считает весь экран своим холстом: не обращается к нативному UI, как React Native, а рисует что хочет, так что можно делать смелые необычные интерфейсы. Но если хочется не смелости, а чтобы пользователю было привычно, в комплект входит имитация стандартных UI-элементов из Android и iOS.
Второе решение — от JetBrains, и оно совершенно не считает весь экран своим холстом. Оно вообще не про общий UI, а только про общую бизнес-логику — остальные вещи предлагается на каждой платформе делать раздельно. KMM — лишь часть большой инициативы «мультиплатформенного Kotlin»: компания хочет, чтобы люди писали на Kotlin почти всё (и бэкенд, и фронтенд, и мобильные приложения, и не только), переиспользуя часть кода между этим всем.
Пока прошло недостаточно времени, чтобы точно понять, насколько эти два решения окажутся успешны. Но можно ли из опыта предшественников извлечь какие-то выводы, помогающие сделать прогноз?
Обычно в холиварах занимают крайние позиции: «эта крутая штука всех победит» или «все эти глупости скоро отомрут». А у меня после изучения прошлого опыта позиция получилась сдержанной:
«Победит» и «умрёт» — не единственные варианты. Зачастую технология занимает небольшой сегмент рынка и не претендует на мировое господство, но приносит кому-то пользу.
Кроссплатформа — это всегда компромисс. Выдержать планку качества, заданную нативом, не получалось нигде. Везде что-то «вытарчивает» — и пользователи могут заметить разницу, и разработчикам приходится возиться со сложностями. И далеко не для всего кроссплатформа подходит одинаково: если бизнес-логика между платформами шарится хорошо, то с вещами вроде UI всё сложнее.
Но качество ниже нативного не означает, что кроссплатформа плоха и не нужна. Кому-то на этот компромисс вполне стоит идти (например, стартапу, где вся жизнь — один сплошной компромисс). В каждом проекте надо взвешивать свои «за» и «против», и результаты в разных случаях будут различаться.
И всё это приводит меня к такому выводу про Flutter: вместо обсуждений «выиграет он или проиграет» надо обсуждать «в каких конкретно юзкейсах он выигрывает». По-моему, он хорош для определённой ниши, поэтому вряд ли угрожает будущему нативной разработки (она никуда не денется), но закрепиться вполне может. Вопрос в том, каковы размеры этой ниши и попадает ли в неё ваш проект.
А вот про Kotlin Multiplatform Mobile сделать выводы по прошлому у меня не получилось, потому что у него нетипичная ситуация. Во-первых, идея «кроссплатформа годится не для всего» тут заложена прямо в фундамент: «а мы и не предлагаем объединять всё, реализуйте только общую бизнес-логику». Во-вторых, тут играет на руку «родной» для Android язык: он уже знаком половине мобильных разработчиков, и такого в кроссплатформе раньше не возникало. В-третьих, многое зависит от того, насколько Kotlin «взлетит» за пределами мобильной разработки. Так что опыт предыдущих технологий тут непоказателен — остаётся смотреть, что покажет время.
На последнем Mobius было сразу несколько кроссплатформенных докладов (три про Flutter, один про Kotlin Multiplatform) — мы уже выложили все видеозаписи конференции на YouTube, так что можете сами их посмотреть. А мы тем временем вовсю работаем над следующим Mobius: он пройдёт 13-16 апреля в онлайне, и там без освещения кроссплатформы тоже не обойдётся. Так что, если вас заинтересовал этот пост, то вам будет интересно и там.