Кроссплатформенный программы андроид иос. На чём писать мобильные кроссплатформенные приложения

Кроссплатформенная разработка позволяет сделать мобильное приложение, которое будет одновременно функционировать в среде iOS и Android. Это бюджетная альтернатива созданию приложения для каждой операционной системы в отдельности.

Особенности кроссплатформенной разработки

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

Эти особенности надо учитывать до начала проекта:

• В кроссплатформенной среде код пишется один раз . Чтобы приложение работало в другой операционной системе, код переводится на другой язык программирования. Затраты времени и денег на разработку в 1,5 раза меньше.
• Возможна некорректная работа приложений. В кроссплатформенной разработке невозможно учесть все нюансы работы с архитектурой каждой операционной системы, поэтому приложения могут работать медленнее тех, что разработаны специально для iOS или Android.
• Интерфейс и требования к дизайну элементов у разных операционных систем различаются . Например, на iOS отсутствует кнопка Back, как на Android. При разработке единого дизайна этот момент нужно учитывать: в iOS кнопка или останется, но не будет работать, или ее придется вырезать вручную, а это дополнительные работы с кодом.

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

Значит, кроссплатформенная разработка - это плохо?

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

Этот вариант можно выбирать в следующих случаях:

• Охватить все операционные системы при ограниченном бюджете. Если целевая аудитория активнее пользуется iOS или Android, можно начать с нативного приложения для одной операционной системы. Если максимальный охват важен сразу, лучше выбрать кроссплатформенный вариант.
• Проверить нишу . Если есть перспективная идея, но нет уверенности, что она выстрелит, сразу вкладывать большой бюджет в разработку рискованно. Есть смысл начать с кроссплатформенной разработки, изучить реакцию пользователей и принимать стратегические решения на этом основании.
• Приложение не использует сложную анимацию и не ведет расчеты. Эти операции серьезно нагружают устройство, а кроссплатформенное приложение не оптимизировано для полноценного использования ресурсов той или иной платформы.
• Приложение использует только основные функции устройства . Показывать информацию, загружать файлы, использовать геолокацию, оформлять заказ - со всем этим кроссплатформенное приложение справится. Требуется более глубокая интеграция возможностей устройств - придется выбрать нативную разработку.
• Корпоративное приложение для сотрудников. Если приложение разрабатывается для узких внутренних задач и люди будут работать с ним через личные гаджеты, кроссплатформенное приложение будет оптимальным вариантом.

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

Смартфоны продолжают отвоевывать все больше места под солнцем не только как инструмент потребления фотографий котиков и ххх-роликов, но и в качестве рабочего инструмента. Поэтому и спрос на мобильную разработку растет. Принято считать, что тру и кул - это Objective-C/Swift для iOS и Java/Kotlin для Android. Спору нет, тру и кул, но существует большое количество реальных сценариев, в которых использование кросс-платформенных фреймворков более предпочтительно в сравнении с нативными инструментами.

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

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

Зачем нужны кросс-платформенные инструменты?

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

Нативные инструменты = предоставляются владельцем экосистемы.

Все остальные признаки «нативности» ВТОРИЧНЫ - поведение и интерфейс приложений, доступ к возможностям ОС, производительность и прочее.

К тому же практически всегда оказывалось, что нативные инструменты несовместимы друг с другом не только на уровне языков разработки, принятых соглашений и архитектур, но и на уровне механизмов работы с операционной системой и библиотеками. В результате для реализации одних и тех же алгоритмов и интерфейсов требовалось написать приложение для нескольких сред на разных языках программирования, а потом его поддерживать из расчета «одна команда на платформу». При этом возможности и внешний вид приложений на разных платформах практически всегда идентичны на 90%. Сравни ради интереса реализацию любимых программ для iOS и Android.

Второй важный момент - наличие необходимых знаний и опыта внутри команды: если их нет, то потребуется время на обучение.

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

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

Так как языков программирования (и сред) сейчас наплодилось очень много (и специалистов, владеющих этими языками), то и инструментов для кросс-платформенной разработки существует изрядное количество. Мы в качестве примера остановимся на популярных в наших краях PhoneGap, Xamarin, React Native и Qt .

Теперь можно поговорить и о мифах.

Миф 1. Магия

Самый частый миф, будоражащий умы начинающих девелоперов, связан с верой в сверхалгоритмы (и сверхпрограммистов, их создавших), которые волшебным образом превращают кросс-платформенные приложения в нативные. Что-то в духе «преобразования кода JavaScript в Swift и дальнейшая компиляция уже Swift-приложения». Этот миф подогревают и сами разработчики кросс-платформенных инструментов, обещая на выходе создание «нативных приложений». И не то чтобы кто-то здесь лукавил, но богатая фантазия и непонимание базовых механизмов иногда наводят разработчиков на мысли о шаманских приемах.

Главный принцип, лежащий в основе кросс-платформенных решений, - разделение кода на две части:

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

Для того чтобы связывать между собой мир «нативный» и мир «кросс-платформенный», необходимо использовать специальный мост (bridge) , именно он и определяет возможности и ограничения кросс-платформенных фреймворков.

При использовании bridge производительность всегда снижается за счет преобразования данных между «мирами», а также конвертации вызовов API и библиотек.

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

Миф 2. Ненативно!

Итак, у нас есть кросс-платформенная часть приложения, живущая в виртуальном окружении и взаимодействующая с операционной системой через инфраструктуру фреймворка и мост.

Все операционные системы: iOS, Android и Windows UWP - предоставляют доступ к следующим подсистемам (наборы системных API):

• WebView (встроенный в приложение веб-браузер) используется в гибридных приложениях на базе PhoneGap и фактически выступает средой выполнения локального веб-сайта;
• JavaScript-движки используются в React Native и аналогах для быстрого выполнения JS-кода и обмена данными между Native и JS;
• OpenGL ES (или DirectX) используется в игровых движках и приложениях на Qt/QML или аналогах для отрисовки интерфейса;
• UI-подсистема отвечает за нативный пользовательский интерфейс приложения, что актуально для React Native и Xamarin.

Кросс-платформенные приложения имеют нативную часть и такой же полный доступ к системным API, что и «нативные» приложения. Разница в том, что вызов системного метода идет через мост и инфраструктуру фреймворка:

WebView - приложение живет в своем веб-браузере по аналогии с одностраничным веб-сайтом. Нет доступа к нативным контролам (кнопки, списки и прочее), все основано на HTML/CSS/JavaScript. С другой стороны, веб-разработчик почувствует себя как рыба в воде.

JavaScript-движки стали популярны относительно недавно, так как в iOS подобный механизм был добавлен только в версии 7.0. Из особенностей стоит учитывать необходимость сериализации в JSON сложных структур данных, передаваемых между средами JavaScript и Native. Если коротко описать подобный класс решений, то в JavaScript-среде выполняется JS-код, управляющий нативным приложением.

OpenGL ES и DirectX являются подсистемами низкого уровня и используются для отрисовки пользовательского интерфейса в играх и, например, Qt/QML. То есть при использовании OpenGL/DirectX разработчики сами рисуют контролы и анимации, которые могут быть лишь похожи на нативные. С другой стороны, это подсистема низкого уровня с очень высокой производительностью, поэтому она используется и в кросс-платформенных игровых движках.

Все кросс-платформенные приложения имеют нативную часть, а следовательно, потенциально такой же полный доступ к системным API, что и «нативные». Также кросс-платформенные приложения собираются и упаковываются «нативными» инструментами в «нативные» установочные пакеты. Ключевой вопрос - как организовано взаимодействие между кросс-платформенной частью и нативной. Например, внутри WebView или с помощью Open GL ES / DirectX нет возможности создать пользовательский интерфейс с полностью нативным look’n’feel, но при этом есть полный доступ к GPS, Push-уведомлениям и другой функциональности. А код на JavaScript или C# вполне свободно может управлять нативным приложением и его поведением, обеспечивая полностью нативный look’n’feel.

Если резюмировать - то да, «ненативно» с точки зрения используемых инструментов разработки (не от Apple, Google). Но приложение может быть полностью нативным с точки зрения доступа к системным API и обеспечивать полностью нативный внешний вид и поведение. А мы движемся к следующему мифу.

Миф 3. Костыль на костыле

Здесь стоит понимать, что нативные API по умолчанию костылями не считаются (хотя и здесь есть разные мнения), поэтому все негодование направлено на кросс-платформенную часть. Очевидно, что исполняющую среду (например, WebView, JavaScript-движок или Mono) костылем тоже назвать сложно - взрослые зрелые решения с длительной историей.

Похоже, что костылем называют то, как кросс-платформенная часть интегрируется с нативной. Чтобы лучше понять, как работают различные фреймворки, мы на примере PhoneGap, Xamarin, Qt и React Native рассмотрим те механизмы операционных систем, которые используются для связывания кросс-платформенной и «нативной» частей.

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

Приложение на PhoneGap - это по факту нативное приложение, которое в качестве единственного UI-контрола отображает WebView. Именно через него и идет взаимодействие с нативной частью. Все стандартные WebView в iOS, Android и Windows UWP поддерживают возможность добавить свои нативные обработчики для JS-свойств и методов. При этом JS-код живет в своей изолированной среде и ничего не знает о нативной части - просто дергает нужные JS-методы или меняет нужные JS-свойства. Все внутри стандартного вебовского DOM, в который просто добавляются новые элементы, связанные с нативной реализацией.

При создании приложений на React Native разработчику практически всегда будет необходимо реализовывать нативную часть на Objective-C, Java или C#, а само управление нативным приложением будет идти из JavaScript. По факту JavaScript-движок - это элемент WebView, который доступен отдельно. Взаимодействие идет через такой же JS-мост, как и в случае с PhoneGap. Однако в React Native JS-код управляет не вебовским DOM-деревом, а нативным приложением.

Необходимо учитывать, что из-за ограничений iOS (нет возможности реализовать JIT) код JavaScript на лету интерпретируется, а не компилируется. В целом это не особо сказывается на производительности в реальных приложениях, но помнить об этом стоит.

Теперь рассмотрим классический Xamarin.iOS и Xamarin.Android, так как Xamarin.Forms (поддерживающий Windows UWP) - это надстройка над ними.

Xamarin использует библиотеку Mono для взаимодействия с целевой операционной системой, которая позволяет вызывать нативный код с помощью механизма P/Invoke . Он же задействуется и для общения с нативными API в iOS/Android. То есть для всех публичных нативных API-методов создаются обертки на C#, которые, в свою очередь, вызывают системные API. Таким образом, из Xamarin-приложения можно обращаться ко всем системным API.

И в завершение рассмотрим Qt, так как о нем появляется много вопросов от опытных разработчиков.

Qt - «вещь в себе», в этом есть и плюсы, и ограничения. Библиотеки Qt просто подключаются к системным API на C++, которые есть во всех операционных системах. Для отрисовки пользовательского интерфейса используются механизмы низкого уровня, но свой графический движок, поддерживающий стилизации «под нативку». При этом на Android приходится обращаться к Java API через специальный мост (JNI bridge), а для Windows UWP использовать конвертер вызовов Open GL ES в DirectX, так как Open GL недоступен для UWP.

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

Миф 4. Медленно

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

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

• PhoneGap: HTML/JS и Native Java / Objective-C / C#;
• React Native: JS и Native Java / Objective-C / C#;
• Xamarin: Mono и Native Java / Objective-C;
• Qt: С++ и Native Java / Objective-C.

Таким образом, при сравнении производительности надо учитывать скорость работы:

• кросс-платформенной части;
• нативной части;
• моста.

Если набрать в поисковике, например, react native vs swift performance, то можно посмотреть множество различных тестов, и во многих из них отмечается, что производительность резко падает при активном использовании моста, включая активное манипулирование UI из кросс-платформенного кода. Для Xamarin ситуация выглядит таким же образом - кросс-платформенная часть очень быстра и сопоставима с нативной в обработке данных, однако при использовании моста может падать производительность. Qt вообще работает на уровне С++, который быстр сам по себе. Если же рассматривать решения на базе PhoneGap, то здесь производительность будет сильно зависеть от WebView, но все же не следует активно менять UI в JavaScript-коде или проводить научные вычисления.

Медленно? Да, возможны падения производительности при неумелом взаимодействии с операционной системой через мост. Однако сами по себе кросс-платформенные миры такие же быстрые, как и нативные.

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

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

Давайте для начала пройдемся ещё раз по терминологии.

Родные

Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то Objective-C и Swift для iOS или , такое приложение будет называться нативным (от англ. native — родной, естественный).

Преимущества нативных приложений:

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

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

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

И не родные

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

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

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

Предполагается, что большая часть такого кода может переносится между платформами — очевидно, что, например, логика совершения покупок, сохранения товара в корзину, просчёта маршрута для такси, написания сообщения в мессенджер не меняется в зависимости о того, Android у клиента или iOS. Нужно лишь доработать UI и UX для платформ, но сейчас, в определённых пределах, даже это можно объединить — например, меню-гамбургер активно используется как на Android, так и на iOS. Так что даже внесений исправления в интерфейс для того, чтобы приложение отвечало духу и букве нужной платформы — вопрос желания, необходимой скорости и качества разработки.

Преимущества:

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

Недостатки:

• неродной интерфейс или, как минимум, необходимость работы с интерфейсом каждой платформы отдельно. У каждой системы свои требования к дизайну элементов и иногда они взаимоисключающи. При разработке это необходимо учитывать;
• проблемы в реализации сложных функций или возможные проблемы работы даже с простыми процедурами в силу ошибок самих фреймворков разработки. Кроссплатформенная среда лишь транслирует запросы к системным вызовам и интерфейсам в понимаемый ею, системой, формат, и потому на этом этапе возможны как сложности с пониманием, так и возникновение ошибок внутри самого фреймворка;
• скорость работы. Так как кроссплатформенная среда является «надстройкой» над кодом (не всегда, но в определённых ситуациях), в ней возникают свои задержки и паузы в отработке действий пользователя и выводе на экран результатов. Это было особенно заметно несколько лет назад на смартфонах, более маломощных относительно сегодняшних, однако сейчас, с ростом производительности мобильных устройств, этим уже можно пренебречь.

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

Популярные платформы и инструменты кроссплатформенной мобильной разработки

Как мы написали выше, есть два подхода — превращение кода в нативный на этапе сборки или добавление определённой обёртки, транслирующей вызовы к системе и от неё.

Cordova и PWA — два инструмента, работающие как раз в идеологии обёртки.

Cordova и HTML5

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

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

Для такого подхода создано огромное количество фреймворков, но все они делают фактически одно и тоже. Различие между ними в том, что Cordova (PhoneGap) не задаёт ограничений и шаблонов на логику и UI для вашего HTML5-проекта, а фреймворки оперируют собственными готовыми UI-элементами, имитирующими мобильные платформы, и своей логикой разработки. В качестве примера такого подхода можно указать: Ionic Framework — обёртка; Framework7, Mobile Angular UI, Sencha Touch, Kendo UI — интерфейсные фреймворки.

PWA

Модная технология от Google — это те же самые веб-приложения, но за счёт использования определённых технологий (в первую очередь это так называемые Service Worker — работающие в фоновом режиме скрипты, и Web App Manifest — описание веб-приложения в понятном для мобильной системы виде) они без обёртки из PhoneGap могут работать как нативные. Они могут устанавливаться на домашний экран в обход магазина приложений, работать в офлайне, работать с пуш-уведомлениями, с нативными функциями.

Проблема в том, что не все платформы даже сейчас поддерживают эти «определённые технологии». В первую очередь это касается Apple, которой, видимо, очень не нравится возможность распространять приложения в обход App Store.

Учтя все недостатки HTML5-решений, многие компании создали инструменты, которые позволяют писать код на одном, не нативном, языке, а он потом транслируется в нативный. Так убивается два зайца одновременно: кодовая база получается одна, а приложения получаются максимально близки к нативному.

Xamarin

Платформа компании Microsoft. Используется стандартный для Enterprise-разработки язык программирования С#, кроссплатформенная среда разработки — Visual Studio. На выходе — нативные приложения для iOS, Android и Windows. Правда, относительно большого размера.

React Native

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

Будучи относительно молодой платформой, React Native пока очевидно (хоть и не катастрофически) страдает от недостатка средств разработки и документации.

Flutter

Естественно, не мог обойти тему кроссплатформенной разработки Android и iOS-приложеий и такой гигант, как Google. Flutter, пока, правда, существующий только в бета-версии, исповедует отличный от React Native и Xamarin подход. Он не превращает исходный код в нативный, который выполняется платформой, а на самом деле рисует окно на экране смартфона и отрисовывает все элементы сам. В качестве языка используется «фирменный» Dart, который Google создал как усовершенствованную версию JavaScript.

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

Платформа быстро развивается и Google вкладывает в это много сил и средств. Но по сравнению с Flutter даже React Native кажется вполне устоявшейся и впечатляющей экосистемой.

Что выбрать

У вас уже наверняка пошла голова кругом, а понимания что выбрать, так и не появилось. Давайте представим простой список вопросов, который вам поможет:

• должно хоть как-то работать на любом устройстве? Выбирайте HTML как основу;
• у вас достаточно средств, нет спешки и вы хотите самое качественное приложение? Вам прямой путь в нативную разработку ;
• у вас есть «встроенный» веб-разработчик или вы просто хотите быстро и просто попробовать мобильное приложение в деле? Тут можно рекомендовать Cordova/HTML или PWA ;
• у вас есть собственная CRM-система и поддерживающий ее C#-разработчик? Берите Xamarin ;
• вы «хотите попробовать», но надо сделать всё красиво и модно? Смотрите в сторону React Native или Flutter .

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

• простое приложение-визитка? Возьмите React Native или HTML5 и вы получите две платформы за минимальную цену;
• у вас есть сайт с большой посещаемостью и вам нужно протестировать гипотезу присутствия в мобильном пространстве? HTML5 ;
• сложные приложения с доступом к нужным функциям устройств? Нативная разработка, Xamarin, React Native .

Кроссплатформенная разработка — не панацея

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

У вас остались сомнения и вопросы о кроссплатформенных приложениях? Почитайте о том, как мы создавали приложение для быстрого получения абонемента в одно из спортивных заведений города и попробуйте приложение для оплаты всевозможных видов услуг — от ЖКХ до заказов в интернет-магазинах. А лучше запишитесь на бесплатную консультацию, с указанием примерного бюджета и кратким описанием идеи или свяжитесь с нашим менеджером Катей по телефону