Обзор кросс-платформенных решений для разработки мобильных приложений
В этой статье мы сравним 6 решений для кросс-платформенной разработки, которые были популярны в 2016 году и попытаемся найти лучшее решение.
Кросс-платформенные фреймворки PhoneGap, Xamarin, Unity, Qt и Appcelerator Titanium, Telerik Platform на сегодняшний день занимают 80% рынка кросс-платформенной разработки для мобильных устройств.
В таблице ниже представлены основные характеристики для каждого фреймворка:
PhoneGap | Xamarin | Unity | Qt | Appcelerator Titanium | Telerik AppBuilder | |
Языки | JavaScript, HTML5, CSS3 и нативные языки (Java, Objective-C, C#) | C#, Xaml | C#, UnityScript, Boo | C++ QML | JavaScript, Python, Ruby, PHP | .Net, JavaScript, HTML5, Java, PHP |
Поддерживаемые латформы | Android, iOS, Windows Phone, Blackberry, WebOS, Symbian, Bada, Ubuntu, Firefox OS. | iOS, Android, Windows Phone and Windows 8/RT, Tizen | Android, iOS, Windows Phone, Tizen, PS 4, Xbox One | Android, iOS, WinRT, Windows, Symbian, Linux, QNX | iOS, Android, BlackBerry, Windows, Tizen, Denso | iOS, Android, BlackBerry, Windows, Windows Phone |
Цены | Цены PhoneGap |
Платная версия: от 9.99$
Бесплатная версия: доступна
Adobe Creative Cloud Membership: доступно
Xamarin
Xamarin Studio Community: бесплатно
Visual Studio Community: бесплатно
Visual Studio Professional: доступно
Visual Studio Enterprise: доступно
Unity
Personal Edition: бесплатно
Professional Edition: от 75 $ в месяц
Qt
Есть бесплатная версия. Платные версии начинаются от 79$.
Appcelerator
Есть бесплатный пробный период
Indie: 39$ в месяц
Pro: $99 в месяц
Telerik AppBuilder
Есть бесплатный пробный период
Цена от 39$ в месяц
PhoneGap
PhoneGap позволяет создавать мобильные приложения используя стандартные веб технологии (HTML5, JavaScript and CSS3). В результате это привело к быстрому росту популярности фреймворка, с его помощью можно обойтись без разработки на таких языках программирования как :Java for Android, Objective-C for iOS и C#.
PhoneGap Build позволяет делать сборки для iOS, Android и Windows Phone одновременно, без необходимости устанавливать какие-либо SDK tools (конечно, в этом есть доля лукавства – при разработке всё равно лучше делать сборку локально, хотя бы на Android, перед отправкой на тестирование). Но что более важно, этот сервис позволяет делать сборки для iOS в облаке без наличия Mac.
Установка PhoneGap требует неимоверных усилий, потому советую освободить пол дня… Шутка. Установка для XCode заняла минуты 3 — заключалась в скачивании архива, распаковке и установке. Вот собственно и все.
PhoneGap представляет возможность использовать нативные функции мобильного устройства по работе с:
- акселерометром,
- камерой,
- компасом,
- контактами,
- файловым хранилищем,
- геолокацией,
- базой данных,
- событиями, уведомлениями,
- медия и др.
Если приложение не выходит за рамки данных пунктов, то скорость разработки с использованием фреймворка PhoneGap будет на порядок выше, чем разработка нативного приложения для каждой из платформ. Видео с разработкой приложения и описанием PhoneGap.
- PhoneGap имеет простое API, что позволит легко начать разработку, для тех кто сталкивался с HTML, CSS и JavaScript.
- Возможность использования любых существующих JavaScript библиотек (JQuery, Prototype, Sencha Touch)
- Поддержка всех мобильных платформ
Недостатки:
- Пользовательский интерфейс визуализируется с помощью встроенного браузера. Это создает трудности в получении обратной связи по сравнению с нативным приложением.
- Часто существующие плагины оказываются устаревшими, поэтому иногда придется писать свои.
Xamarin
Xamarin второй в нашем списке кросс-платформенный фреймворк. Xamarin позволяет создавать одну единственную логику приложения с применением C# и .NET.
Функционально платформа Xamarin представляет ряд субплатформ. Эти субплатформы играют большую роль — через них приложения могут направлять запросы к прикладным интерфейсам на устройствах. Определяется визуальный интерфейс, привязывается логика на C#, и все это будет работать на Android, iOS и Windows Phone. Видео с разработкой приложения на Xamarin.
- Большое и развивающееся сообщество.
- Разработчики могут использовать TestCloud для тестирования приложений автоматически.
- Если вы уже знакомы с C# и .NET то вам не нужно будет тратить много времени на изучение нескольких новых фреймворков.
- Можно повторно использовать уже написанный код.
- Приложения под разными системами будут выглядеть очень похоже.
- Динамическая верстка для iOS в бесконечное число раз проще, чем использование constraints вручную.
- За счет CustomRenderer‘ов стандартные контролы легко дополняются произвольными свойствами (например, сделать градиентную заливку кнопок — дело пары минут, хотя «из коробки» это не работает).
- Некоторые интерфейсные паттерны тяжело реализовать на monodroid и очень тяжело на monotouch, так как решения по умолчанию для той или иной фитчи опираются на костыли платформы, которые могут попросту не работать в Xamarin.
- Возникают проблемы со стороны платформы mono, monotouch и monodroid. Ваше приложение должно удовлетворять особенным требованиям стабильности.
- Android страницы невозможно расположить как часть уже существующего Activity/Fragment.
- Реализованы не все контролы.
Telerik AppBuilder
Одной из основных причин использовать AppBuilder является полноценная онлайн IDE. Она позволяет создавать, тестировать и даже публиковать гибридные приложения с любого компьютера или мобильного устройства, без необходимости в его загрузке.
Возможность создавать iOS приложения работая на Windows или Linux еще одно преимущество.
И напоследок, принадлежность AppBuilder к Telerik Platform дает вам возможность пользоваться такими фичами как аналитика, всплывающие уведомления, авторизация пользователей и облачным хранилищем. Подробное описание в статье и видео.
- Telerik предоставляет плагины Visual Studio и Sublime Text для AppBuilder.
- AppBuilder предлагает быстрый способ импорта плагинов Cordova.
- Полноценная онлайн IDE.
- Легок в использовании и изучении
Unity
Мультиплатформенный инструмент для разработки 2D и 3D приложений и игр Unity, также один из лучших инструментов для демонстрации 3D контента. Созданные с помощью Unity приложения работают под операционными системами Windows, OS X, Linux, Android, Apple iOS, Windows Phone, BlackBerry, а также на игровых приставках Wii, PlayStation 3 и Xbox 360. Видео с разработкой мобильной игры на Unity.
- Отличный вариант для создания мобильных игр для целого ряда устройств
- 3D-движок дает высококачественные результаты без каких-либо сложных конфигураций
- Есть много хороших бесплатных плагинов
- Unity позволяет разработчику сделать свои собственные шейдеры и изменить путь, которым Unity визуализирует игру.
- UI и сложность в использовании для новичков
- Исходный код недоступен
- Компиляторы Unity не оптимизированы для ARM процессоров на некоторых мобильных устройствах.
Qt библиотека для создания кроссплатформенных оконных приложений на C++. Qt стоит рассматривать не столько как набор классов для создания GUI, а скорее как полноценный инструментарий классов на все случаи жизни. Есть возможность разрабатывать программы не только на C++, но и языке QML, сильно схожим с JavaScript. Это особая ветвь развития Qt, направленная на быстрое прототипирование и разработку мобильных приложений. Видео с разработкой Tiled Map Editor на Qt.
Преимущества:
- Qt имеет множество хороших инструментов которые помогут в разработке, например: IDE QT Creator, Qt Designer и code profiling.
- Он имеет библиотеки, содержащие интуитивно понятные API интерфейсы для элементов, таких как сети, анимации и многое другое.
- Qt сложен для начинающих
Appcelerator Titanium
Titanium — это полностью открытая платформа для разработки, развертывания, распространения, и, в конечном итоге, для исполнения веб-приложений. Appcelerator Titanium позволяет создавать мобильные приложения на JavaScript, HTML и CSS.
Вы можете создавать современные, а главное — нативные приложения, используя любую популярную на сегодняшний день операционную систему: Windows, GNU/Linux или MacOS X.
Приложения созданные с помощью данного SDK будут действительно нативными. Контроллер навигации на Андроиде будет выглядеть привычно и не так как на iOs. Причем не только вид, но и сам код приложения будет тоже нативный. Это кстати не мешает вам создавать и классический WebView и наполнить его желаемым web контентом.
- JavaScript позволяет легко разрабатывать приложения без использования языков платформы.
- Appcelerator позволяет делать аналитику в режиме реального времени
- Использование native API даст более высокую производительность для приложений, которые не очень велики.
- Есть задержки при запуске приложения из-за загрузки библиотеки
- Трудно создавать сложные приложения, так как использование JavaScript отрицательно сказывается на производительности приложений.
React Native
Что такое React Native? Это JS-фреймворк, основанный на JS и React — JS-библиотеке для создания UI (View-уровня).
Технология очень перспективная, но молодая, поэтому платформа кое-где еще сырая. Версия для Android появилась позже, поэтому для iOS-приложений пока есть больше компонентов. Также стоит учитывать, что при разворачивании приложения на устройство пользователя попадет весь JS, поэтому на уровне презентации не стоит держать секретную бизнес-логику. Можно сказать, что сейчас React Native можно использовать для быстрого прототипирования мобильных версий ваших веб приложений. Причем если веб приложение уже написано на ReactJS, то скорость переноса возрастает в разы. Пример разработки на React Native.
- Единый воркфлоу и инструменты: неважно, работаете ли вы на Android- или iOS-версией — все равно используете одни инструменты.
- По этой причине — скорость и простота разработки.
- Обвязка унаследованного приложения в JS API и гибридные приложения: допустим, у вас уже есть готовое приложение для iOS, и вы хотите перейти на React Native. Тогда можно обернуть нативные компоненты так, чтобы они были доступны в React Native. Так вы можете постепенно переходить на React, и получается гибридное приложение — половина его нативная, а половина — в React, и несколько унаследованных компонентов — в JS API.
Нет идеального решения, каждый фреймворк имеет свои плюсы и минусы. Для очень простых приложений я бы посоветовал использовать PhoneGap пока отзывчивость не станет ключевым критерием. А для более серьезной разработки лучше использовать Xamarin, но даже с Xamarin лучше совмещать нативную разработку для большинства элементов пользовательского интерфейса.
— Первый сервис по продвижению на Реддит:Buy Reddit Upvotes
Источник
Кроссплатформенная мобильная разработка: история вопроса
Когда речь заходит о разработке «сразу для 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
Мигель де Икаса ещё в проекте 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 апреля в онлайне, и там без освещения кроссплатформы тоже не обойдётся. Так что, если вас заинтересовал этот пост, то вам будет интересно и там.
Источник