company_banner

Кроссплатформенная мобильная разработка: история вопроса

    Когда речь заходит о разработке «сразу для 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

    Проект 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

    Мигель де Икаса ещё в проекте Mono занимался тем, что притаскивал .NET на несвойственные ему платформы (начав с Linux). А когда в 2011-м он вместе со всей командой Mono попал под сокращение, основал новую компанию Xamarin, собрал прежних коллег там, и сосредоточился на мобильных платформах: мол, давайте писать мобильные приложения для них на C#, вот инструмент для этого.

    Надо понимать контекст того времени. Годом ранее компания Microsoft выпустила Windows Phone и стремилась стать третьим большим игроком на мобильном рынке. И даже «большая» Windows лезла на мобильный рынок: готовилась к выходу Windows 8, оптимизированная для планшетов.

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

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

    Ещё порой вызывали недовольство и то, что после появления новых фич в Android/iOS приходилось ждать их поддержки в Xamarin, и стоимость лицензии, и общее состояние экосистемы (документация, поддержка, библиотеки).

    А тем временем компания Microsoft возлюбила опенсорс и сторонние платформы вроде Linux, так что идеи де Икасы оказались ей близки, и в итоге она купила Xamarin. Теперь его наработки вошли в .NET 5, и в прошлом году представили .NET MAUI («Multi-platform App UI») — развитие тулкита Xamarin.Forms. В общем, не забросили купленное.

    Что в итоге: пока всё остаётся в странноватом статусе, когда и масштабного взлёта не получилось, и полностью не прекращено.


    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 апреля в онлайне, и там без освещения кроссплатформы тоже не обойдётся. Так что, если вас заинтересовал этот пост, то вам будет интересно и там.

    JUG Ru Group
    Конференции для программистов и сочувствующих. 18+

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

      +9
      Кросплатферменные фреймворки экономят время на разработку под несколько платформ, чтобы тратить его на поиск и исправление багов фреймворка на каждой платформе.
      Иногда нативная разработка бывает более прогнозируема.
        +1
        Во всем виноват слишком высокоуровневый и кастрированный API мобильных ОС. Если говорить об Android сюда ещё добавляются глюки разных Android-прошивок размазанных на десяток версий с их глюками и криво написанными драйверами. Кросс-платформенные фреймворки тут совсем не виноваты, а виноваты мобильные ОС, которые выстроили зоопарк костылей.
        +13

        Отличная статья, спасибо что разобрали Qt и сослались на мой очерк!
        Есть несколько дополнений/комментариев:


        • К минусам Qt'а я бы добавил падения на некоторых Android-девайсах (в консоли разработчика отчеты о фэйлах с повторящихся марок китайских брендов). Их вообще непонятно как лечить, на каких багтрекерах искать баги и когда ждать фиксы :|
        • Nokia не такую уж и плохую роль сыграла, насколько я помню с их подачи появился QML. Без оного в мобильной разработке шансы были бы околонулевые, как у того же Tizen. А QML хорош, пишу Вам с KDE, прекрасный пользовательский опыт
        • Разработка на Qt все же отличается от разработки на чистом C++ в лучшую сторону. Но порог вхождения намного выше, чем в большинство универсальных решений, тут не поспоришь
          +1
          И вот тут получается прям любопытно. С одной стороны относительно плюсов Qt вроде попроще. А с другой это значит, что (как и с React Native относительно React) — тупо взять С++ разработчика не выйдет, слегка «образ мышления другой», надо привыкнуть. И в итоге у нас нет сразу готового рынка, чтобы набирать с него. И это может быть даже минусом.
            0

            Надо брать тупо Qt разработчика. Не обязательно из мобильной сферы.

          +3
          Из проекта B4X уже много лет использую его для Android и x86. Вот еще начал вполне успешно пробовать B4R и для микроконтроллеров. B4i для iOS не пробовал.
            –9
            Очень странно читать про React Native, как про нишевый фреймворк. Де-факто, сейчас React Native — это такой же стандарт разработки мобильных приложений, как вебовый React — это стандарт разработки веб-приложений. Работа 95% мобильных приложений — это сходить на сервер за данными, показать пользователю эти данные в виде текста и картинок, обработать нажатие пользователя на кнопку и отправить запрос на сервер. Для таких юзкейсов React Native хватает за глаза. API доступа к аппаратным возможностям в нем тоже достаточно. При необходимости можно написать свой нативный код и подключить его к проекту.

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

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

                0
                Года 4 назад на нем активно пытались чет лепить, ныне практически заглох и мертв.
                Но живее конечно чем фонгап и кьют, замарин тот хоть где-то в кровавом интерпрайзе хоть живет худо бедно.

                Сама идея гонять достаточно тугой по скорости язык, с жирной средой исполнения на мобайле выглядит порочно, и даже эволюция в виде флатера/дарт не особо спасает, вон пишут маршалинг в нейтив по 50+миллисекунд занимает.
                Имхо по моей персональной статистике примерно такой щас порядок востребованности (на основании виденных вакансий и общения):
                — флаттер
                — реакт нейтив
                — замарин
                — фонгап кьют и прочие мармелады

                Как ниже писал Imbecile
                Есть какой-никакой Ксамарин. Он работает. Я попробовал. Четвертый год с ним. Плююсь, ругаюсь матом. Но заказчикам достаточно.

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

                Точно та же идея у котлин МП, заставить джава боев сваять че нить под iOS, свою нишу может и займет но вот вряд ли сильно выстрелит.

                Истинно кроссплатформенную нишу давно и прочно держат плюсы, и они с нами еще лет на 15 минимум видимо.
                  0
                  Ваша персональная статистика — это конечно хорошо.
                  Но во статистика на данный момент LinkedIn по вакансиям: в Израиле React Native — 75, Flutter — 28, в Лондоне React Native — 675, Flutter — 167, бухта Сан-Франциско React Native — 616, Flutter 83. То есть на React Native в 3-5 раз больше вакансий.
              +8
              А во-вторых, тут играет на руку «родной» для Android язык: он уже знаком половине мобильных разработчиков, и такого в кроссплатформе раньше не возникало.

              Ну вот нет. Как .NET разработчик я ковырнул WinPhone. А потом, как фрилансер, столкнулся, что хотят мобильные приложения. Теоретически, мог бы в Джаву и Свифт. но зачем? Есть какой-никакой Ксамарин. Он работает. Я попробовал. Четвертый год с ним. Плююсь, ругаюсь матом. Но заказчикам достаточно. И мысли об отдельном котлине и что там сейчас на айосе, не радуют. Энтерпрайз готов терпеть отсутствие красот, если работает. А для меня, с беком на дотнете, дотнет ещё и в мобилке — это счастье.
                +1

                Не увидел в статье электрон. ООн за кроссплатформу не сойдет?

                  +1
                  Статья про мобильную кроссплатформу, а он десктопная. Если правильно понимаю, условия Apple в принципе не позволяют ему появиться на iOS.
                    0

                    На андроиде он есть. И на IOS, как я слышал, урезан, но не запрещен. Или его вообще в магазин не пускают?

                      +2
                      Я не погружался глубоко в вопрос, но вроде бы загвоздка в том, что на iOS запрещены браузерные движки, отличные от WebKit. И даже Гуглу пришлось iOS-версию Chrome сделать на WebKit (в отличие от всех остальных платформ, где у него свой Blink). А поскольку Electron основан на Chromium, он попадает под этот запрет. Сейчас бегло погуглил, про «урезан» ничего не нашёл, только о том, что вообще нельзя.
                        0

                        Говоря об ограничениях я вспоминал эту статью. Не знаю, что там с тех пор поменялось.

                          0
                          В этой статье неправильный перевод: в оригинале говорилось про Mac App Store, а в переводе это превратилось в App Store. Первое — магазин приложений на macOS, а второе — на iOS. Так что проблемы, о которых речь в том тексте, связаны с macOS.
                            0

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

                  0
                  А NativeScript видимо не существует?
                  +5

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


                  Я не согласен с оценками автора:
                  Qt на мобилках конечно никакос, но зато для настольных, особенно для различных Linux, или импортозамещающих настольны ОС(те же Linux) и мобильных (Аврора) это номер один.
                  React Native и Xamarin — очень популярны
                  Flutter подает большие надежды (ведь за ним стоит Гугл)
                  Гибридные в корпоративном секторе весьма популярны, да и на настолках Electron активно используется.


                  Актуальна кроссплатформенная разработка в импортозамещении — сейчас довольно быстрорастущий сектор на рынке.


                  Про кроссплатформенную разработку для Российских ОС (включая мобильную) я в декабрьском номере журнала "Системный администратор" опубликовал статью на основе доклада на конференции OS Day 2020 — http://files.tau-platform.com/Documents%20/SAM_2020_12_article_Crossplatform_solutions_for_Russian_OS.pdf

                    0
                    для корпоративной разработки кроссплатформенный подход ложится просто отлично, ведь обычно нужно очень много «формочек» + довольно обширная «бизнес-логика»

                    Добавлю: и ещё в корпоративной разработке не настолько критично выверять всё до пикселя, поэтому менее страшны «шероховатости» кроссплатформы. Конечно, я не призываю делать внутренние приложения по принципу «и так сойдёт, сотрудники пользоваться всё равно будут, куда они денутся», но даже когда заботишься о сотрудниках и их UX, требования тут отличаются от рыночных.

                    Я не согласен с оценками автора: Qt на мобилках конечно никакос, но зато для настольных номер один

                    Так у поста в заголовке написано «мобильная разработка», в первом предложении — «Android+iOS». То есть успехи Qt на десктопе — это просто за пределами скоупа текста.

                      0
                      У меня вообще постоянно ощущение, что люди хейтят Flutter просто за то, что он вышел не так давно. Хотя вряд ли хоть один фреймворк работал без косяков с самого релиза :) Он ведь не находится в вакууме, а тоже апдейтится и становится лучше. Шероховатости — да, есть, хотя и тут уже есть хорошие примеры приложений для бизнеса на Flutter, а не только корпоративных. Вопрос, конечно, в том, насколько соотносятся время- и трудозатраты с другими фреймворками.
                      +3
                      Интересно, а у кого-то был опыт кросс-платформенной разработки на Дельфи?

                      Какое-то время (5-6 лет) назад это был чуть ли не единственный инструмент для более-менее безболезненного создания простых проектов как под десктопные, так и под мобильные системы с общей кодобазой. Понятно, что маркетинговая политика у нынешнего владельца была несколько странная, но сейчас там есть и Community версия… Может, пробовал кто?
                        0

                        Смотрели https://www.lazarus-ide.org/ ?

                          0
                          Смотрел, конечно. Знаю, что люди на нём много чего пилят, но в основном — десктоп. Мне же интересно из как можно более первых рук про опыт постройки чего-то мобильного…
                        +2
                        А где же Flutter, KMM?
                          +2
                          Отдельных блоков про них нет по причинам, описанным во вступлении, но после вашего комментария в последнем блоке добавил больше про них.
                            0
                            Спасибо!
                          +1

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


                          Поэтому разрабатываем такие приложения и на React Native и даже на Ionic (реинкарнация Кордовы), заказчики более чем довольны.

                            +1
                            А вот про Kotlin Multiplatform Mobile сделать выводы по прошлому у меня не получилось, потому что у него нетипичная ситуация, отличающаяся от предшественников. Во-первых, идея «кроссплатформа годится не для всего» тут заложена прямо в фундамент: «а мы и не предлагаем объединять всё, реализуйте общую бизнес-логику, а остальное на Android и iOS делайте раздельно».

                            Вот вы напрасно не упомянули, что исторически в Xamarin был принят тот же самый подход. Кроме Xamarin.Forms там присутствует полноценное проксирование нативных API в С#, когда разработчик ручками пишет Activity для Android, ViewController для iOS, и в отдельном модуле — общую логику (а-ля «бекенд») для обоих.

                            По моему мнению, это самый архитектурно корректный подход из всех возможных. UI зачастую должен быть разным на разных платформах. Аналогично, жизненный цикл приложений, системные API на разных платформах отличаются, и это нормально. А вот запросы к серверу и «логика расчета стоимости заказа» обычно не зависят от того, на каком телефоне сидит юзер, поэтому их логично выносить в общий код.

                            Kotlin Multiplatform в этом отношении выглядит обнадеживающе. Но там пока что API, доступный в «общих модулях», ну слишком уж урезанный.
                              +1
                              Далее, ситуацию с потенциальной кроссплатформенной разработкой сильно усложняют требования Apple к «используйте Mac для разработки под iPhone». Как следствие, чтобы быть кросс-платформенным разработчиком, нужно в первую очередь быть iOS-разработчиком — мне, андроидщику с убунтой на рабочем ноуте, в кроссплатформе делать как бы нечего.

                              История усугубилась после того, как Xamarin был куплен майкрософтом — они отказались от поддержки Linux в Xamarin Studio. Т.е. теперь, даже если я захочу выступать в кроссплатформенном Xamarin-проекте на стороне Android, мне нужно позарез ставить винду (ну или покупать Mac).
                                  0
                                  Да, чтобы делать KMM для iOS/Mac надо иметь мак.
                                  А чтобы делать для windows — надо иметь windows.
                                  Под android и linux вот компилируется везде :)

                                  Использую KMM. Писать интерфейсы для Windows это адская боль — интеропта с .NET нет и не планируется (приоритет мобилкам, а там Микрософт стал Некрософтом), а делать UI на Win32 API это жёстко.
                                  Зато в платформенно-зависимой части кода можно ковыряться в системе сколько хочешь — тут тебе и реестр и прочие системные запросы.
                                  Вот сейчас пробуем ReactNative натянуть на KMM- посмотрим, что выйдет…
                                  +2
                                  Не вижу в списке Embarcadero с ее RAD-студией.
                                    0
                                    Такое уже не принято вспоминать)
                                    0

                                    Был опыт использования Xamarin 3 года назад. Идея красивая, но основные проблемы были со скоростью загрузки приложения. И google-консоль много рапортовала о ANR, что свело на нет идею его использования. Может сейчас уже поправили, конечно, но слабо верится.

                                      +3
                                      Сейчас уже намного лучше чем раньше, но всё же много шероховатостей. Использую Xamarin для корпоративного приложения под огрызок и ведроид, начинал на ранних версиях Xamarin 4, затем апгрейднул до Shell, и вот недавно обновился до Xamarin 5, посмотрим как там будет дальше дело с MAUI. Отлично разруливается бизнес логика, но частенько возникают мелкие платформоспецифичные вопросы, или незначительные баги в фреймворке, благо огромное сообщество позволяет достаточно быстро найти решение. Полностью отказался от использования XAML, весь UI со временем переписал на C# Markup, теперь даже вспоминать тот XAML не хочется. Хоть и не долюбливаю мелкософт, но должен признать что в плане продвижения шарпа они много сделали в последнее время, приятно писать на этом языке под мобильные платформы, обожаю async/await, LINQ, Rx, Generics. В общем как и везде есть свои плюсы/минусы, Xamarin подойдёт не везде, в некоторых случаях всё таки лучше native приложения под конкретную платформу.
                                        0

                                        Сколько пользователей у приложения? И каков процент ANR, крешей?

                                          +1
                                          Пока что около 20 пользователей, это очень специфичный софт для диагностики, выполнения сервисных функций и обновления прошивки железяк, всё общение при помощи Bluetooth LE. ANR ноль, крешилось немного на яблоке, нашёл свои косяки, больше не падает.
                                            0

                                            В этом случае Xamarin вполне подходит.

                                      +1

                                      Сделал на Xamarin.Forma 4 разных приложения для аудитории в 3-5к пользователей и продолжаю делать. Это читалки, слушалки, тесты, апп для банка. Специфичный для платформы UI выношу в отдельный проект. В остальном — проблем нет.


                                      Возможно только время компиляции и запуска удручает при росте проекта. Тогда разбиваю функционал/UI на модули и запускаю отдельно.

                                        0

                                        Как уже писали выше — xamarin на самом деле популярен. Среди заказных приложений. И react native тоже был, но Facebook сам от него отказался.
                                        Первые версии xamarin были багованные, особенно я помню как я играл в игру — оттебаж за 5 секунд.


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


                                        Я конечно не пользуюсь xamarin сейчас, но ребята из KMM идут близко к его пути. И мне кажется нишу они займут туже, что и xamarin.


                                        А как я говорю лучшая кроссплатформа это С++, если не одно но — С++. Способ интеграции и взаимодействия достаточно удобен (особенно если djinni), код можно дебажить, нет багов. Один минус — ну писать бизнес логику на С++ в 21 веке… Ну уж нет — язык сложный, ещё и буковок много.

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

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