Disclaimer

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

Мы уже писали и не устанем повторять: перед тем как инвестировать в разработку мобильного продукта, будьте на 100% уверены, что он вам необходим и органично вписывается в бизнес-процессы.

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

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

Нативное приложение разрабатывается с нуля специально под конкретную платформу. От выбора платформы (iOS, Android) зависит набор иснтрументов и язык, на котором приложение будет написано (Objective C для iOS, Java для Andriod).
Гибрид предполагает наличие уже готового html шаблона, к которому добавляется интерфейс, позволяющий открывать его как мобильное приложение.
Кроссплатформенная разработка стремится сделать большую часть кода приложения не зависящей от дальнейшего выбора платформы.

Native (англ. «родной») — в переносном смысле естественный для данной среды. Например, политкорректное обращение к индейцам: Native Americans.

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

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

Насколько важны интерактивные элементы интерфейса?

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

На каких платформах/типах устройств должно работать?

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

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

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

Если для Google Play правила не так строги, то быстро пройти модерацию в App Store почти искусство. Тут и заранее нужно знать, каким нормам должно соответствовать приложение, как оно работает с личными данными (влияет даже то, насколько очевиден и легкодоступен для пользователя значок лицензионного соглашения; политика Apple строга — человек должен точно знать, как будет использована его личная информация). Как следствие, процедура согласования может затягиваться и даже потребовать изменений в интерфейсе уже готового приложения. Решений несколько: идти в агентство, которое уже умеет общаться с модераторами маркетов, или, если нет острой необходимости и желания работать с такими сложностями, отказаться от идеи публикации приложения в магазине (а значит автоматически выбрать мобильную веб-версию сервиса).

Будем продавать контент через приложение?

Здесь мы снова возвращаемся к тому, что все ключевые решения по архитектуре и виду вашего приложения закладываются уже на этапе разработки бизнес-модели и схемы монетизации. У Apple достаточно жесткие ограничения относительно того, что может продаваться внутри приложения; так называемые real good (продукты питания, мебель) под запретом. Реализовать функцию корзины и оплаты покупки можно в практически любом приложении, но с позиции технологий будут существенные различия: для гибридных и кроссплатформенных приложений придётся использовать сторонние инструменты + адаптировать их под свои задачи, что не гарантирует надежности и безопасности транзакций. Нативные приложения могут использовать сертифицированные инструменты для соответствующей платформы (опять же важно помнить про ограничения на тип продаваемых товаров и внимательно изучить требования платформы).

Необходим ли доступ к доп.функциям и датчикам устройства?

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

Нужен ли оффлайн режим?

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

Планируется ли выпуск новых версий?

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

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

Какой бюджет?

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

Александр Чернышев,
директор производства Improve Digital:

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

Инвестиции в нативное приложение 100% оправданы в случае:

Если нужно выпустить приложение только под одну платформу.
Если необходимо внедрить функционал специфичный для платформы, например, in app. Может начаться пляска с костылями, которая потратить огромное кол-во времени и сил.
Если нужно постоянно обновлять приложение относительно платформы (новый iOS или Android - сразу новое приложение). Часто обновления движков запаздывают по отношению к обновлению платформ.
Если обновление платформы содержит что-то, что полностью несовместимо с движком.

Наше мнение субъективно и может не совпадать с мнением других игроков на рынке, и это нормально — во-первых, каждой задаче свои инструменты, во-вторых, лучше работать с тем, что больше всего нравится тебе и в чем ты гарантированно разбираешься лучше других. You have been warned

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

Резюме

Best design is transparent. Следуя этой логике, конечному пользователю глубоко безразлично, что внутри у приложения, если оно решает его задачу быстро и без проблем. Выбор подхода зависит от того, как вы хотите организовать процесс «за кулисами», в конце концов вам и вашим разработчикам жить с этим. Лично нам ближе всего нативная разработка. В ней мы видим больше всего плюсов: нет проблем с совместимостью, простота и легкость поддержки и обновления, наконец, минимум сторонних решений, а значит и причин для конфликтов, сбоев и непредвиденных проблем.

Светлое завтра.

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