Каждый день количество мобильных пользователей растет, развивается мировой рынок мобильных приложений. Грамотный бизнесмен не может не заметить эту тенденцию и сделает все, чтобы влиться в нее. Мобильное приложение - отличный вариант для стартапа.

Первый вопрос, который возникнет у вас - по какой технологии разработки создавать приложение?

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

Нативный подход

Приложение разрабатывается на “родном” языке для каждой платформы: Java для Android и Objective-C / C++ для IOS.

Изначально по такому методу разработаны приложения, которые “вшиты” в устройство - будильник, браузер, галерея, музыкальный проигрыватель.

Кросс-платформенный подход

Если в нативном подходе одно и то же приложение разрабатывается отдельно и под iOS и под Android, то в кросс-платформенном подходе разрабатывается все за один раз.

Приложение сможет работать на всех платформах.

Языки программирование стандартные, как если бы вы разрабатывали сайт - HTML и CSS.

Гибридный подход

Гибридные приложения объединяют особенности нативной и кросс-платформенной разработки.

По сути, это кросс-платформенное приложение внутри “родной” оболочки.

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

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

Нативная разработка

1 Производительность и скорость

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

Проще реализуются жесты, мультитач и отслеживание географического положения.

2 Пользовательский опыт

Если клиент привык к интерфейсу Android, то он будет некомфортно чувствовать себя при использовании ОС IOS. Проектирование нативного приложения даст уверенность пользователям и интуитивное понимание внешнего вида и функционала.

3 Нет ограничений

Приложение имеет полный доступ к службам и функциям смартфона (базы данных, геолокация, камера).

4 Удобство тестирования

Легко контролируется производительность приложений. Если приложение потребляет больше памяти, чем ожидалось, или больше ресурсов процессора - в процессе тестирования это сразу видно.

5 Доступность

Пользователи смогут загрузить приложение из “родных” магазинов: App Store, Google Play

6 Адаптивность

На рынке большое количество Android-устройств и приспособить дизайн макетов для всех из них эффективнее через нативную разработку.

Недостатки

1 Скорость разработки

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

2 Издержки на разработку

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

3 Обслуживание и поддержка

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

1 Скорость разработки и снижение затрат

В отличие от нативной разработки, приложение разрабатывается только один раз под все платформы. Это снижает затраты и сокращает время создания. По этой методике приложение сделать дешевле.

2 Обслуживание и поддержка

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

Недостатки

1 Скорость разработки и снижение затра

Несмотря на то, что по идеологии разработки этот пункт отмечается как плюс, практика показывает, что имплементация под две ОС дает много багов. Это увеличивает срок на устранение ошибок. UI отображается по-разному и время на адаптацию также увеличивается.

2 Низкая производительность

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

3 Пользовательский опыт

Необходимо разработать такой интерфейс, который был бы интуитивно понятным и для пользователей iOS и для Android.

В противном случае приложение, построенное согласно Руководству ОС IOS Human Interface будет неудобным Android пользователям. И в конечном итоге вы потратите больше времени, на усовершенствование пользовательского опыта.

4 Обращение к “нейтиву”

Стандартные решения для нейтива все равно не решаются в кроссплатформенной разработке. Поэтому часто для решения функционала привлекают нативных разработчиков.

Когда кросс-платформенность выигрывает:

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

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

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

В этой статье мы сравним 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$ в месяц Есть бесплатный пробный период Цена от 39$ в месяц
Open source	+	-	-	+	+	-
UI	Web	Native	UI Canvas	Native	Native	Web

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 еще одно преимущество.

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

• 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 лучше совмещать нативную разработку для большинства элементов пользовательского интерфейса.

Сегодня предлагаем разобраться, чем приложение, созданное в конструкторе, отличается от того, которое вам разработают в студии.

Нативные приложения рассчитаны на параметры и свойства конкретной платформы (мобильной ОС, связанной с нею экосистемы и технических характеристик самого мобильного устройства) и задействует все возможности аппаратной платформы, которые нужны для работы с приложением - от камеры и модуля GPS до акселерометра, управлением жестами и других аппаратно поддерживаемых свойств конкретного смартфона или планшета. Кроме того, нативное приложение, раработанное в студии, можно получить как готовый продукт и разместить его в магазине мобильных приложений (таком как Google Play или Apple App Store).

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

А что создает большинство онлайн-конструкторов?

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

В онлайн-конструкторе создается не нативное, а веб-приложение , которое не является программным продуктом в классическом смысле, по сути это - специальный веб-сайт, которые выглядит и действует как нативное приложение, но по сути таковым не является. Как правило для его работы нужен установленный и настроенный браузер мобильного устройства с выходом в интернет. Самое веб-приложение создано на основе использования HTML5. Отчасти это и объясняет растущую популярность веб-приложений (а также тот факт, что новая мобильная ОС Tizen от Samsung и некоторые модификации Android используют веб-приложения с этой технологией).

Такое веб-приложение подходит не всем проектам (в частности, если СМИ и новостные проекты с блогами могут довольствоваться возможностями HTML5, то для интернет-магазинов и высоконагруженных сайтов подобное решение не подходит).

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

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

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

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

Что стоит выбрать?

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

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

Работа без доступа к интернету: Нативное приложение - ваш выбор, если важно, чтобы оно работало без подключения к интернету в каком-либо виде. Веб-приложения зависят от интернет-подключения и от кэширования в браузере.

Возможность поиска информации и самого приложения: С поиском по контенту лучше справляются веб-приложения, но если у вас планируется поиск по содержимому приложения без доступа в интернет - то придется делать либо гибридное приложение, либо нативное.

Скорость работы: Быстрее всего работают нативные приложения. В 2012 году Марк Цукерберг заявил, что наибольшей ошибкой его социальной сети стал запуск веб-приложения, а не разработка нативного решения (до того времени Facebook использовал гибридное приложение, где основная часть контента была доступна только при подключении к интернету и основывалась на HTML; с 2012 года его заменили на нативное). Всё дело в скорости отклика .

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

Управление приложением и его обслуживание: Нативное приложение после каждого обновления надо повторно размещать в магазине приложений, в тов время как в веб-приложении по сути обновляется страница и контент, «упакованный» в виде своеобразного мобильного сайта.

Привязка к конкретной платформе: Поскольку разные браузеры могут поддерживать разные версии HTML5 независимо от типа аппаратной платформы или установленной мобильной ОС, то для тех, кто хочет «отвязаться» от платформы, выбором станут веб-приложения или гибридные приложения. Если отдельная разработка под каждую отдельную платформу вас не пугает, то можете сделать ставку на нативное приложение.

Работа с контентом, процедура добавления в магазин приложений и дополнительные платежи: Нативные и гибридные приложения проходят специальную процедуру утверждения после добавления их в магазин приложений. Кроме того, на них могут накладываться определенные ограничения в силу правил и внутренней политики App Store и Google Play (особенно если речь идет о «взрослом» контенте, азартных играх, тематике алкоголя или подобных темах).

Кроме того, нативные приложения, которые продают платную подписку в рамках приложений, добавленных в App Store, должны делиться отчислениями с Apple. Соответственно, ценообразование и бюджеты в случае нативных приложений надо корректировать с учетом суммы этих отчислений.

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

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

Хотите заказать нативное приложение? Отправляйте заявку с темой «Разработка приложения» на наш email - и мы свяжемся с вами в течение 24 часов и уточним всем детали для дальнейшего обсуждения.

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

Своё, родное…

Сначала поговорим о нативной разработке. Здесь всё просто: для каждой платформы существует нативный язык : для Android это Java, для iOS - Objective-C или Swift, для Windows Phone - C# и так далее. Для каждого нативного языка существует свой набор технологий и фреймворков.

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

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

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

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

Разработка “вручную”

Суть первого подхода в том, что код на С++ можно запустить где угодно. В Android для этого используется NDK, Windows Phone - Managed C, другие платформы также имеют свои способы обработать и запустить код. Другое дело - такой код будет ограничен в своих возможностях. Например, в Android он не сможет обратиться к экрану или даже самостоятельно запуститься. Чтобы обойти эти ограничения, сначала пишется библиотека с основной логикой на С++, а затем - обёртка на нативном языке, которая запускает библиотеку и обеспечивает её взаимодействие с устройством. Правда, стоит отметить, что такой подход подойдёт лишь для ограниченного круга приложений - там, где на клиентах находится действительно много логики, которую имеет смысл выносить в отдельную библиотеку.

Технологии

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

React Native в последнее время пользуется особенной популярностью: с ним активно экспериментируют даже такие гиганты рынка, как Uber или Сбербанк. Речь идёт даже не столько о кроссплатформенных приложениях, сколько о принципе «Learn once - write anywhere», то есть о возможности использовать одну и ту же технологию для создания приложений под разные платформы, обеспечивая высокий процент переиспользования кода.

Ещё один вариант написать кроссплатформенное приложение - использовать HTML5 + JavaScript . Кстати, именно так написаны текстовый редактор Atom, Visual Studio Code и Slack (да-да, даже десктопная версия - по сути браузер, который сделали похожим на обычное приложение).

Интересный факт: недавно компания Амперка выпустила необычный микроконтроллер Espruino. Его главная особенность - прошивка, которая крутится на микроконтроллере. Она написана на чистом Си, загружается единожды в отдельное место флеш-памяти микроконтроллера и занимается тем, что исполняет пользовательский JavaScript-код . Так что теперь можно программировать микроконтроллеры и на JS. На JS, Карл!!!

Эта идея кажется абсурдной, но если подумать, и ей можно найти обоснование. С развитием концепции интернета вещей и ростом количества различных IoT-устройств в будущем можно ожидать всплеск спроса на программистов, которые смогут обеспечить их взаимодействие с окружающим миром. А порог вхождения в JavaScript куда как ниже, чем в C или Assembler, тут не поспоришь!

Не всё так просто

Преимущества кроссплатформенной разработки в том, что можно один раз написать приложение или какую-либо его компоненту, используя, например, С++, и запускать его на различных платформах и устройствах. Логично, что и затрат это потребует меньше. Казалось бы - пиши и радуйся! Однако у такого подхода есть и ряд своих недостатков.

И все они имеют одну причину: все платформы разные .

Рассмотрим основные неудобства, с которыми придётся столкнуться, встав на путь кроссплатформенной разработки.

Негативный пользовательский опыт

Каждая платформа имеет свои стандарты: стандартные жесты и элементы управления, расположение элементов, внешний вид иконок… Например, вам хватит одного взгляда на экран, чтобы понять, iOS перед вами или Android. Разработав приложение, которое будет выглядеть одинаково на всех платформах, вы столкнётесь с тем, что пользователь не сможет использовать привычные ему методы управления и не увидит привычного дизайна, а значит, сочтёт ваше приложение менее удобным, чем нативное.

Этим, например, часто страдают игры, портированные на ПК с PlayStation: многие из них не поддерживают мышь и не позволяют настраивать комбинации клавиш, удобные для игрока, что делает их менее удобными, чем игры, разработанные специально для ПК. И если такие приложения, как Mortal Combat или Final Fantasy могут “выезжать” за счёт ностальгии, то разработчикам новых игр следует подумать, прежде чем лишать пользователей привычных им элементов управления.

Другой пример - Matlab, который на Mac использует не верхнее меню, а меню внутри окна, что типично для Windows и противоречит всем гайдлайнам iOS. Будучи монополистом, MatLab может себе это позволить, но если вы разрабатываете приложение, которое будет конкурировать с другими, стоит задуматься, не отдадут ли пользователи предпочтение привычному для них нативному интерфейсу.

Ещё один момент - все платформы отличаются внешне: шрифты, размер и форма кнопок, внешний вид календаря, чекбоксов, radio buttons… Даже если вы хотите, чтобы приложение просто выглядело похожим на нативное, придётся разрабатывать таблицы стилей для каждой платформы, что увеличивает как сроки, так и стоимость разработки.

Ограничения при разработке функциональности

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

Такое привычное всем действие, как drag and drop, принципиально отличается для Mac и для других платформ. Если на Windows или Linux это действие обрабатывается самим приложением, то на Mac в игру вступает непосредственно операционная система, а значит, разработчику потребуется создавать отдельное событие “открытие файла” для того, чтобы на Mac это действие работало корректно. А значит, придётся смириться или с ростом трудозатрат на разработку, или с тем, что привычный пользователям drag and drop на этой платформе просто не будет работать.

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

Кроссплатформенные приложения тормозят: миф или реальность?

Практически в любом споре, посвящённом преимуществам и недостаткам кроссплатформенной разработки, вы увидите аргумент о том, что кроссплатформенные приложения значительно медленнее своих нативных собратьев. Это и так, и не так. Например, код, написанный на С++ и запущенный на Android с помощью NDK, будет работать даже быстрее нативных приложений. С другой стороны, если вы используете, например, PhoneGap, приложение начинает работать по принципу “Дома, который построил Джек”: PhoneGap вызывает JS, который обращается к Java, которая запускается на Java-машине, которая работает уже на реальном телефоне. Разумеется, о быстродействии речи уже не идёт.

И что же выбрать?

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

Популярную головоломку 2048, например, лучше разрабатывать как кроссплатформенное приложение. Разработанная на веб-технологиях, она будет запускаться везде: вы можете использовать тот же PhoneGap, чтобы запустить её на мобильных платформах, Electron - для Windows, Linux и Mac, а для сайтов, приложений ВКонтакте и Facebook даже не придётся прикладывать усилий: приложение запустится напрямую. Всё, что вам нужно, - собрать программу при помощи разных упаковщиков и создать иконку для каждой платформы. Готово, приложение не отличить от нативного!

На противоположном конце шкалы находится, например, графический редактор Sketch, снискавший завидную популярность у UX и UI дизайнеров (мы в Noveo тоже его используем!). В настоящее время он существует только для OS X, и вопрос, когда же его выпустят для других платформ, задают настолько часто, что он был даже вынесен в FAQ.

“Is Sketch available for Windows or Linux?

Due to the technologies and frameworks exclusive to OS X that Sketch has been built upon, regrettably we will not be considering supporting Sketch on either of these platforms.”

(Есть ли версии для Windows или Linux?

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

Большинство приложений, конечно, лежат где-то между этими точками экстремума, так что для выбора одного из подходов потребуется тщательный анализ. Постарайтесь оценить: какой процент ваших пользователей отпугнёт, например, непривычный вид кнопок или неиспользвание верхнего меню на OS X? Будут ли это те пользователи, за счёт которых окупается ваше приложение? Много ли в приложении функциональных возможностей, которые потребуют значительных доработок для одной или нескольких платформ?

Конечно, точные результаты сможет дать только A/B тестирование, но даже поразмыслив над этим, вы много сделаете для выбора подхода к разработке.

Подведём итоги

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

Существует множество фреймворков и технологий кроссплатформенной разработки. Среди самых популярных можно назвать Ionic, Unity 3D, Xamarin, React Native, а также использование HTML + JavaScript.

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

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

Конечно, разобрать все тонкости и нюансы нативной и кроссплатформенной разработки в одной статье невозможно. Нашей целью было дать понятие об основных понятиях и сложностях, которые заключены в этом вопросе. Делитесь своим мнением и опытом в комментариях!

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

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

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

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

Родные

Если разработчики в процессе написания приложения пользуются принятым для конкретной платформы языком программирования, будь то 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 .

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

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

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