Мобильная разработка - родная VS Cross Platform VS JavaScript

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

Мы будем стремиться в первую очередь к iOS и Android, вторичным для Windows-Mobile и BlackBerry.

Кандидаты:

После проведения некоторых фоновых исследований я нашел следующие возможные кандидаты:

Родной. Просто, но кропотливо разрабатывайте для каждой платформы свои собственные инструменты и язык.
HTML5, CSS и JavaScript. Может быть веб-служба, запущенная в браузере устройства (веб-сайт) или приложение, которое инкапсулирует такой код в WebKit.
Rho mobile. Сделано Google, поэтому оно должно быть хорошим - тем не менее, основано на Ruby (что нам неудобно) и имеет сложную и довольно хрупкую среду разработки.
PhoneGap. Это кажется легким и в основном основанным на Javascript. Это открытый исходный код, но в последнее время приобретенный adobe - (не хороший знак).
Appcelerator. Все, что связано с Javascript на PHP и на python, имеет хороший набор API Access, но мы слышали много историй об отказе (от Apple) и несовместимости при использовании сложного кода в разные платформы.
И больше похоже на MoSync, Sencha, Appmobi и Corona (не проверял их из первых рук).

Некоторые ориентиры:

Мы не планируем разрабатывать игры, приложения, которые мы планируем развивать, входят в сферу бизнес-приложений и информационных инструментов.
Приложения не зависят от чрезмерного использования API-интерфейсов устройств (но они нуждаются в незначительном базовом доступе)
Компания, уже разработанная для iOS, и у нас есть небольшая команда разработчиков iOS (Objective-C geeks)
Мы хотели бы быть уверены, что можем продолжить разработку наших приложений в этой функции, не нарушая их из-за новой ОС или API.
Будет полезно убедиться, что приложение не будет отклонено из-за кода кросс-платформы (в основном AppStore)
Как и любая компания, мы хотели бы быть такими же экономичными, как мы можем, - с другой стороны, мы настаиваем на высококачественных продуктах и опыте работы с Top-of-the-line.

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

Ответ 1

На рынках приложений есть 500k + приложения, и конкуренция жесткая. Крайне важно иметь отличный UX и графику.

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

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

Но, если вы серьезно относитесь к рынку мобильных приложений, тогда единственный способ - стать родным. И вам нужен парень UX и дизайнер (кто знает мобильную разработку) в команде полный рабочий день. Вы будете тратить более 50% времени на внешний вид. Проект, в котором я сейчас участвую, тратит 80% + времени на внешний вид (графика, анимация, UX, юзабилити-тестирование).

Предложение: потратьте разумное количество времени (= дней), используя ваши приложения-конкуренты. Также проводите время с 50 приложениями на каждом рынке. У вас будет ощущение, насколько высок бар. Затем проверьте приложения, сделанные с помощью кросс-платформенных инструментов (вы можете найти ссылки на своих сайтах) и сравните.

Ответ 2

Пока я полностью согласен с @Peter Knego, я бы добавил несколько второстепенных баллов для команд, которые хотят поддерживать несколько платформ:

Как отмечает Питер, UX огромен, а кросс-платформенный UX является наименее распространенным знаменателем UX. Это достаточно сложно, чтобы заставить этот материал быть всем, что нужно, чтобы не завязать руку за спиной. Действительно фантастические веб-приложения оцениваются по их способности приблизиться к родному опыту, а не наоборот.
Есть много частей продукта, которые не являются UX. Стоит тщательно изучить, какое повторное использование вы можете получить там. Например, я часто советовал командам, у которых SQL-базы данных уже работают на Android, чтобы не использовать Core Data на iPhone. Нет причин повторно изобретать ваши модели объектов и данных.
Это не общее предложение о том, что вы пишете свое ядро на С++. Если у вас обширное существующее С++ ядро, я сделал предложения до о том, как его повторно использовать. Но я вообще не рекомендую его для нового кода. Лучше использовать в большинстве случаев лучшие функциональные возможности платформы платформы.
Разработка сетевых протоколов, которые хорошо работают на всех платформах, довольно проста и должна выполняться. Ваш лучший выбор здесь почти в каждом случае - REST и JSON. Держите его простым, особенно для iPhone, который ненавидит такие вещи, как SOAP и синтаксический анализ сложного XML.
Некоторые сложные проблемы с компоновкой проще в HTML + CSS, чем с помощью собственных элементов управления. Это особенно верно, если у вас есть сложные таблицы с несколькими столбцами (особенно для тех, которые вам нужны colspan и rowspan for). У меня было довольно удачное воплощение отдельных UIWebView штук в других приложениях, даже если переносимость вообще не является соображением. Здесь может быть какое-то целесообразное повторное использование. Просто помните, что вы не хотите тратить много усилий и усилий, пытаясь сделать ваш браузер браузером нейтральным. На iPhone используйте расширения WebKit везде, где они делают ваше приложение лучше для пользователя.

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

Очень кросс-платформенные подходы - это дешевый способ получить "что-то", если вам все равно, что "что-то". Это очень дорогой способ получить что-то отличное.

Ответ 3

Я работаю в AppMobi, и я просто сделаю несколько комментариев.

Приложение не должно быть отклонено за кросс-платформу, используя собственный веб-просмотр. У нас не было использования Apple в приложениях, представленных в AppMobi.
Rhombile не "Сделано Google". На самом деле, это даже не часть Motorola, которую купил Google, это их бизнес-подразделение. Они продвигаются к HTML5/Javascript, но в настоящее время Ruby.
Appcelerator начал поддерживать веб-просмотр, а затем вернулся. Они просто подняли тонну денег, чтобы вернуться в веб-просмотр.

Что касается людей, говорящих "Нет" для кросс-платформенных приложений. Facebook и некоторые другие крупные компании продвигаются к приложениям на базе HTML5 для мобильных устройств.