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

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

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

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

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

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

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

Тренд №1: кроссплатформенная разработка

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

1. При помощи веб-фреймворков, например: PhoneGap, Appcelerator Titanium.

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

2. На кроссплатформенном фреймворке, например Xamarin, Qt.

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

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

• Конечный продукт завязан на конкретную команду разработчиков. Если приложение написано на малоизвестном фреймворке, появятся очень большие трудности с сопровождением и развитием продукта. Носитель идеи может стать “заложником” команды разработчиков, которые будут диктовать свои условия, на которых они готовы продолжать сотрудничество.
• Крайняя медлительность и неповоротливость готового приложения. В первом случае (при использовании веб-фреймворков) это происходит из-за того, что решение наследует все минусы встроенного веб-браузера. А в случае с кроссплатформенными фреймфорками код сначала запускается под виртуальной машиной, которая тоже требует для запуска определенных ресурсов.
• Лишние действия и вызовы порождают ошибки. Фреймворк — это дополнительная прослойка, которая требует подгонки под конкретную платформу ввиду невозможности создания действительно универсального инструмента для всех систем разом. Это добавляет лишние действия и вызовы, что может порождать набор различных известных и неизвестных ошибок.
• Ограниченная в функциональность. Фреймворки предоставляют ограниченный набор функций, которые могут “воспроизводить”. Каждую новую функцию придется программировать с нуля и, кто знает, как она себя поведет под различными платформами. Таким образом, кроссплатформенная разработка не может использовать все возможности iOS, Android, Windows phone, иначе это была бы одна платформа.

Тренд №2: коробочная разработка

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

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

Если вы обратитесь к такому разработчику, то никогда не получите крутую концепцию приложения, оригинальный дизайн, эффекты и анимацию. Все будет стандартизировано, чтобы максимально удешевить разработку. Но местами коробочная разработка будет идти действительно быстрее за счет того, что разработчики “собаку съели” в реализации того или иного функционала.

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

Тренд №3: нативная разработка

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

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

Например, dynamics text kit только-только появился в iOS 7, но ни один фреймворк пока не поддерживает этот функционал. Оптимистичный прогноз, когда они научатся с ним работать, — полгода. Вы готовы столько ждать, если вам необходимо приложение, полностью адаптированное под iOS 7?

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

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

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

Автор статьи: Дарья Ахмерова,
Менеджер мобильных проектов
в Improve Digital

Понравилась статья? Поделитесь с коллегами и друзьями: