Нативный интерфейс. Нативная vs кроссплатформенная разработка: преимущества и недостатки подходов

» Александр Кузнецов написал для VC колонку об отличиях нативных приложений от кроссплатформенных, в которой объяснил, какой тип разработки будет предпочтительным в тех или иных обстоятельствах.

Время приложений

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

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

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

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

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

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

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

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

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

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

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

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

Гибридные приложения

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

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

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

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

Сравнение подходов

Рынок предложений растёт. Статистика продаж мобильных приложений показывает, что год от года пользователи гаджетов всё чаще меняют стандартные сервисы на альтернативные. Так, родной менеджер задач заменяется на Wunderlist, почтовый клиент - на приложение Mailbox, Evernote оказывается предпочтительнее стандартных заметок.

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

Зависимость от платформы

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

Дизайн интерфейса

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

Языковая среда, в которой разрабатываются нативные приложения, обладает необходимыми инструментами для создания привычного пользователю интерфейса. Другая ситуация с веб-технологиями: чтобы сделать кроссплатформенное приложение похожим на нативное, придётся приложить немало усилий. Разные кроссплатформенные фреймворки (Framework 7, Sencha Touch, Kendo UI, Ionic и другие) помогают с той или иной степенью достоверности имитировать нативный интерфейс, но чаще всего отзывчивость, скорость анимации, эффекты и дизайн будут другими. Этому и посвящен следующий пункт.

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

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

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

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

Ограничения

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

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

Безопасность

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

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

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

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

Быстрая и дешёвая кроссплатформенная разработка - миф или реальность

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

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

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

Справедливым будет вопрос: «Как так - полтора? Почему не один?» Увы, на практике кроссплатформенное приложение, хорошо работающее на iOS, будет плохо работать на Android - у всех браузерных движков своя специфика, и как следствие, оптимизацию под Android может уйти ещё половина человеко-месяца.

Исходя из вышесказанного, был произведен расчёт стоимости мобильной разработки в случае нативного и кроссплатформенного подходов, представленный в двух таблицах. Результаты в таблице 1 отталкиваются от средней почасовой ставки фрилансеров из баз freelansim.ru и fl.ru в рублях, в таблице 2 - средней почасовой ставки фрилансеров и студий из международной базы upwork.com в долларах.

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

Но есть нюанс

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

Резюме

К нативной разработке стоит прибегать, если:

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

Ваш вариант - кроссплатформенная разработка, если:

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

К выбору той или иной стратегии всегда приводят индивидуальные обстоятельства, ни одна статья не даёт универсального ответа.

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

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

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

В настоящее время 9 из 10 потенциальных клиентов обращаются с запросом разработки приложения сразу под 2 платформы - iOS и Android. Это вполне логично, ведь упомянутые платформы в сумме занимают более 95% рынка, и экономически целесообразно разрабатывать мобильное приложение именно под эти платформы.

Во время общения с заказчиками техническому директору компании Mauris Владимиру Бондаренко часто приходится объяснять, в чем разница разработки под каждую из платформ и почему это два абсолютно разных продукта. Многие считают, что программисты разрабатывают одно приложение, которое потом регистрируют в маркетах App Store и Google Play. В некоторых случаях это действительно так, но далеко не всегда. Владимир рассказал об основных подходах к разработке мобильных приложений.

Их всего четыре:

Конструктор приложений - готовый сервис, который позволяет за 30 минут собрать мобильное приложение.

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

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

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

• Скорость работы. Интерфейс кроссплатформенных приложений отзывчив.
• Время разработки. За счет единого решения под 2 платформы время разработки существенно сокращается.
• Техническая поддержка платформ.

Недостатки:

Недостатки:

• Ограниченный API. Хоть React Native и поддерживает огромное количество API-интерфейсов, все еще существует потребность в использовании других API через встроенные модули.
• Различия платформ Android и iOS.
• Относительно низкая производительность. Если вы планируете разрабатывать сложное приложение, React Native вам не подойдет.

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

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

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

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

Недостатки:

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

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

Существует еще ряд менее популярных технологий для реализации приложений, но все они вписываются в градацию, описанную выше.

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

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

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

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

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

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

Приложение разрабатывается на “родном” языке для каждой платформы: 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 Обращение к “нейтиву”

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

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

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

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

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

Следующее высказывание с легкостью может прозвучать от того, кто только что начал изучать Titanium:

JavaScript?! Как Phonegap? Не, я лучше сделаю нативное приложение.

Titanium !== HTML

Приложения на Titanium – это не сайты, которые чудесным образом обернуты в приложения.

Что ты имеешь в виду под «Нативной» разработкой?

А что делает приложение нативным?

• Разработчик использует предоставленные Apple, Google и Microsoft инструменты?
• Разработчик использует стандартный для платформы язык?
• Приложение использует строительные блоки (API), которые предоставляет платформа?
• Приложение работает так, как ожидает пользователь на этой платформе?

Что такое хороший User Experience?

Выглядит и ведет себя ожидаемо

Единство API там, где это возможно, платформо-зависимые API – там, где нет. Всегда с уважением к целевой платформе.

Чувствуется ожидаемо

Как достичь классного UX?

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

Кросс-платформенные фреймворки PhoneGap, Xamarin, Unity, Qt и Appcelerator Titanium, Telerik Platform на сегодняшний день занимают 80% рынка кросс-платформенной разработки для мобильных устройств.

В таблице ниже представлены основные характеристики для каждого фреймворка:

PhoneGap

PhoneGap Build позволяет делать сборки для iOS, Android и Windows Phone одновременно, без необходимости устанавливать какие-либо SDK tools (конечно, в этом есть доля лукавства – при разработке всё равно лучше делать сборку локально, хотя бы на Android, перед отправкой на тестирование). Но что более важно, этот сервис позволяет делать сборки для iOS в облаке без наличия Mac.

Установка PhoneGap требует неимоверных усилий, потому советую освободить пол дня… Шутка. Установка для XCode заняла минуты 3 - заключалась в скачивании архива, распаковке и установке. Вот собственно и все.

PhoneGap представляет возможность использовать нативные функции мобильного устройства по работе с:

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

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

• PhoneGap имеет простое API, что позволит легко начать разработку, для тех кто сталкивался с HTML, CSS и JavaScript.
• Возможность использования любых существующих JavaScript библиотек (JQuery, Prototype, Sencha Touch)
• Поддержка всех мобильных платформ

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

Xamarin

Функционально платформа Xamarin представляет ряд субплатформ. Эти субплатформы играют большую роль - через них приложения могут направлять запросы к прикладным интерфейсам на устройствах. Определяется визуальный интерфейс, привязывается логика на C#, и все это будет работать на Android, iOS и Windows Phone. Видео с разработкой приложения на Xamarin.

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

• Большое и развивающееся сообщество.
• Разработчики могут использовать TestCloud для тестирования приложений автоматически.
• Если вы уже знакомы с C# и.NET то вам не нужно будет тратить много времени на изучение нескольких новых фреймворков.
• Можно повторно использовать уже написанный код.
• Приложения под разными системами будут выглядеть очень похоже.
• Динамическая верстка для iOS в бесконечное число раз проще, чем использование constraints вручную.
• За счет CustomRenderer‘ов стандартные контролы легко дополняются произвольными свойствами (например, сделать градиентную заливку кнопок - дело пары минут, хотя «из коробки» это не работает).

Недостатки:

• Некоторые интерфейсные паттерны тяжело реализовать на monodroid и очень тяжело на monotouch, так как решения по умолчанию для той или иной фитчи опираются на костыли платформы, которые могут попросту не работать в Xamarin.
• Возникают проблемы со стороны платформы mono, monotouch и monodroid. Ваше приложение должно удовлетворять особенным требованиям стабильности.
• Android страницы невозможно расположить как часть уже существующего Activity/Fragment.
• Реализованы не все контролы.

Telerik AppBuilder

Возможность создавать iOS приложения работая на Windows или Linux еще одно преимущество.

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

• Telerik предоставляет плагины Visual Studio и Sublime Text для AppBuilder.
• AppBuilder предлагает быстрый способ импорта плагинов Cordova.
• Полноценная онлайн IDE.
• Легок в использовании и изучении

Недостатки:

• Небольшое сообщество

Unity

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

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

Недостатки:

• UI и сложность в использовании для новичков
• Исходный код недоступен
• Компиляторы Unity не оптимизированы для ARM процессоров на некоторых мобильных устройствах.

• Qt имеет множество хороших инструментов которые помогут в разработке, например: IDE QT Creator, Qt Designer и code profiling.
• Он имеет библиотеки, содержащие интуитивно понятные API интерфейсы для элементов, таких как сети, анимации и многое другое.

Недостатки:

• Qt сложен для начинающих

Appcelerator Titanium

Вы можете создавать современные, а главное - нативные приложения, используя любую популярную на сегодняшний день операционную систему: Windows, GNU/Linux или MacOS X.

Приложения созданные с помощью данного SDK будут действительно нативными. Контроллер навигации на Андроиде будет выглядеть привычно и не так как на iOs. Причем не только вид, но и сам код приложения будет тоже нативный. Это кстати не мешает вам создавать и классический WebView и наполнить его желаемым web контентом.

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

• JavaScript позволяет легко разрабатывать приложения без использования языков платформы.
• Appcelerator позволяет делать аналитику в режиме реального времени
• Использование native API даст более высокую производительность для приложений, которые не очень велики.

Недостатки:

• Есть задержки при запуске приложения из-за загрузки библиотеки
• Трудно создавать сложные приложения, так как использование JavaScript отрицательно сказывается на производительности приложений.

React Native

Технология очень перспективная, но молодая, поэтому платформа кое-где еще сырая. Версия для Android появилась позже, поэтому для iOS-приложений пока есть больше компонентов. Также стоит учитывать, что при разворачивании приложения на устройство пользователя попадет весь JS, поэтому на уровне презентации не стоит держать секретную бизнес-логику. Можно сказать, что сейчас React Native можно использовать для быстрого прототипирования мобильных версий ваших веб приложений. Причем если веб приложение уже написано на ReactJS, то скорость переноса возрастает в разы. Пример разработки на React Native.

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

• Единый воркфлоу и инструменты: неважно, работаете ли вы на Android- или iOS-версией - все равно используете одни инструменты.
• По этой причине - скорость и простота разработки.
• Обвязка унаследованного приложения в JS API и гибридные приложения: допустим, у вас уже есть готовое приложение для iOS, и вы хотите перейти на React Native. Тогда можно обернуть нативные компоненты так, чтобы они были доступны в React Native. Так вы можете постепенно переходить на React, и получается гибридное приложение - половина его нативная, а половина - в React, и несколько унаследованных компонентов - в JS API.