Гибридное приложение что это
Разработка эффективного гибридного приложения
А помните ли вы свой первый мобильный телефон? Для меня это была Nokia 3310, неубиваемая «трубка», неустанно радовавшая меня скудным набором развлечений в виде игры в змейку, WAP и чудесных монофонических рингтонов. За последние тридцать лет индустрия шагнула далеко вперед. И это ещё мягко сказано: мобильные чипы приближаются по производительности к современным компьютерам, а две самые популярные на текущий момент системы — Android и iOS — предоставляют практически безграничные возможности для создания приложений на любой вкус.
Оплата по NFC, заказ такси буквально за пару свайпов, и даже тот же Instagram настолько плотно вошли в нашу жизнь, что необходимость создания мобильного клиента для своего бизнеса теперь уже не вызывает вопросов. Стандартом разработки в этом случае принято считать нативные приложения. Они работают плавно, имеют привычный пользователям UI и UX, а также доступ к разнообразным аппаратным возможностям смартфона и его операционной системы. Из основных недостатков этого подхода можно отметить необходимость иметь в штате выделенных iOS- и Android-разработчиков, возникновение сложностей в организации тестирования, и более длительный, по сравнению с web, релизный цикл. Нельзя забывать и про сегментацию: часть пользователей предпочитает оставаться на старых версиях приложения, старых версиях iOS и Android, обожают свои старые телефоны. Поэтому ненайденный в релизе баг, просочившись в сторы, напоминает землетрясение с долгим афтершоком.
Если у вас уже есть команда опытных мобильных разработчиков и налажен CI, то кажется, что выбор очевиден. Но зачастую бывают ситуации, когда время запуска функциональности в прод играет решающую роль, а постоянные обновления не идут на пользу репутации приложения. Хотя бы раз в жизни, каждый из нас брал кредит, или, по крайней мере, всерьез задумывался об этом. Обычно этот процесс включает в себя заполнение анкеты. Представим, что такая анкета есть у вас на сайте и в мобильном приложении. И вот банк решил освободить зарплатных клиентов от половины полей — это, безусловно, прекрасно, но влечет за собой изменения на сайте, а также в iOS- и Android-приложениях. Учитывая нашу асинхронность релизных циклов, а также возможность появления багов при обновлении, возникает риск получить три разные анкеты на неопределенный срок. А если подобные изменения нужно вносить часто?
Очевидное решение — гибрид. Существует множество фреймворков, позволяющих писать код сразу под обе платформы: Flutter, React Native, Ionic, однако их внедрение в существующий проект может стоить значительного времени и трудозатрат. Есть способ проще: помещая часть функциональности в WebView, мы можем быстро и относительно дешево переиспользовать часть уже реализованной на сайте логики. Контент, загружаемый из сети, в связке с нативными компонентами подчас абсолютно неотличим от нативного экрана. Так пользователи получат доступ к новым фичам одновременно с веб-версией, а мобильная команда сможет проработать полноценный нативный процесс в менее жестких временных рамках.
Если вы пошли по пути «гибрида», то важно понимать, когда это решение временное, а когда постоянное. Экран в WebView, как и любой другой, является частью экосистемы приложения. Запуская функциональность с объемной бизнес-логикой, придется закладывать значительное время и ресурсы на её поддержку. Но почему, если всё уже давно свёрстано и прекрасно работает?
50 оттенков сервисов
Тестирование под разные браузеры и разрешения — обычное дело при разработке фронта. Теперь этот чеклист пополнит ещё и мобильное приложение. Всё дело в WebKit-е, свободном движке для отображения веб-страниц, на котором работают все самые популярные браузеры. Он отвечает за единообразный разбор HTML, построение DOM, создание объектов window и document, работу с CSS, а также построение макетов и позиционирование UI-элементов. Однако при всём видимом удобстве, он насчитывает немалое количество версий, или, как их ещё называют, — «портов».
От одной версии к другой могут различаться подходы к управлению рендерингом, декодированию изображений и работе с видео; меняется поддержка кодеков, сетевой слой, а также используются разные JS-движки. Также WebKit позволяет включать или выключать любую функциональность на этапе компиляции при помощи compile-time feature flags, и даже в рантайме, при передаче параметров в командной строке или конфигурации. Прибавьте ко всему этому факторы, зависящие от «железа», и становится очевидно: браузер на телефоне точно будет отличаться от своего одноименного десктопного собрата.
Таким образом, встраивая в приложение «браузер на минималках» перед выкаткой в прод всё равно стоит закладывать дополнительное время на тестирование экрана, а лучше всего процесса.
WebView ≠ адаптив
Если пользователи привыкли менять вкладки при помощи свайпов, то на экране с WebView они будут ожидать поддержки такого же поведения. То же самое касается нативной навигации между экранами и UI-элементов (кнопок, полей ввода, контекстных меню и т.п.).
С точки зрения UX и дизайна, процесс работы с приложением должен оставаться согласованным, а руководящие принципы разработки пользовательских интерфейсов платформ должны быть учтены. Можете считать, что создание отдельной верстки под WebView это неизбежная плата за возможность мгновенного обновления функциональности без привязки к мобильным релизам. Чтобы поддержка функциональности в WebView не причиняла вам боль, с самого начала тратьте время на создание базы UI-компонентов со стилями, использованными в приложении.
Бесшовный процесс
Важно учесть, что экран в WebView не должен уводить пользователя на другие страницы сайта. Многие приложения хранят личные данные клиентов, а следовательно, требуют аутентификации. И все, кто однажды вошел в свой личный кабинет, будут ожидать, что они останутся авторизованными и на экране в WebView. Используя механизм перехвата ссылок, вы можете направить пользователя в нативный процесс логина или регистрации, и таким образом избежать незапланированных ветвлений сценария в браузере.
На протяжении пользовательского пути зачастую возникает необходимость сохранить прогресс и полученную информацию. Открывая гибридный экран, не будет лишним передать в параметрах ссылки всё, что необходимо для продолжения работы. Что касается обмена данными в реальном времени, то его легко организовать, используя коллбэки. Например, с их помощью WebView может передать информацию о пунктах, которые должны отображаться в контекстном меню, а нативное меню, в свою очередь, вернёт пункт, на который нажал пользователь, и браузер загрузит нужную страницу.
Хотите встроить экран в существующий процесс? Без проблем. Но при этом логика работы приложения должна оставаться согласованной, а данные — консистентными. Библиотека WebKit в связке со средствами JS, реализованными интерфейсами на стороне Android и message handler со стороны iOS способны обеспечить глубокую интеграцию WebView-экрана и нативного кода. Вы сможете добавлять нативные виджеты поверх страниц, управлять их UI, добавлять требуемое поведение и настраивать видимость.
Тёмная сторона WebView
Начиная с Android 10 и iOS 13 появилась функциональность, называемая «тёмной темой». Это альтернативная цветовая схема UI, предназначенная для заботы о ваших глазах во время использования телефона в ночное время. Библиотека WebKit позволяет выставить настройки, согласно которым загруженная страница будет отображаться в соответствии с темой, установленной в текущий момент на телефоне (рекомендуемый режим), всегда в тёмном или светлом виде. Обратите внимание, что добавление поддержки тёмной темы в CSS веб-страницы строчкой @media (prefers-color-scheme: dark) не даст нужного результата, так эта настройка влияет только на контролы — панель прокрутки, кнопки приближения и отдаления и т.д., но не на стиль контента, отображаемого внутри WebView.
Если в вашем приложении заданы стили для тёмной темы, это уже отлично, но и экран в WebView тогда обязан выглядеть соответствующе.
Разделяй и властвуй
Одними из важнейших показателей стабильности мобильных приложений являются доля crash-free users и отзывы в сторах. И если раньше все данные об ошибках, логи и пользовательские метрики можно было найти в Firebase или любом другом любимом вами сервисе, то теперь отладка и сбор аналитики станут несколько сложнее. В то же время оценки пользователей всё так же будут отражать их отношение к продукту целиком, вне зависимости от того, в какой части работы с гибридом у них возникли затруднения. Разбор каждого такого случая теперь будет начинаться с выявления источника: ошибка в нативе или вебе, или всё же в интеграции. Решением может стать сегментирование отзывов пользователей по тегам и перенос аналитики в единый кроссплатформенный сервис.
Один из популярных сервисов мониторинга активности приложений в App Store и Google Play — AppFollow. Он предоставляет автоматическую разметку отзывов пользователей. Для этого нужно прописать правила, согласно которым будут проставляться теги. Например, к жалобам на баги можно отнести отзывы с наличием в тексте слов «баг», «ошибка» или «не работает», а также с оценкой меньше 3.
А для сбора аналитики отлично подойдет ClickHouse — open source СУБД российской разработки, предназначенная для работы с большими объёмами данных. Она способна эффективно обрабатывать запросы в реальном времени, при этом их синтаксис максимально приближен к классическому SQL. Помимо быстродействия и низкого порога вхождения для пользователей стоит также отметить отлично реализованное сжатие данных и отсутствие проблем с подключением — у сервиса активное сообщество, на текущий момент есть готовые коннекторы под большинство популярных языков программирования. А если мне до сих пор не удалось вас убедить, то посмотрите руководство, знакомство с функциональностью займёт буквально пару часов, а тестовые данные идут в комплекте.
Подводя итог, становится понятно, что «быстро и относительно дёшево запуститься в WebView» — задача нетривиальная, если говорить о крупных и хорошо оттестированных фичах. Но зато этот подход отлично применим для кратковременного промо, раздела со справочной информацией, динамических форм обратной связи — иными словами, для экранов с часто изменяемой информацией, не завязанных на основные сценарии приложения.
Выбирая между запуском MVP в нативе и WebView, важно понимать, что лучшее решение принимается только в контексте задачи. Нативные SDK позволяют эффективно контролировать объём памяти, используемой приложением, загружать файлы в фоне, хранить локально большие объёмы данных, а также использовать все аппаратные преимущества современных смартфонов и систем iOS и Android. Требуется минимальный Time To Market? Гибридное решение позволяет запускать новую функциональность синхронно с сайтом, фиксить баги быстро и одновременно на всех устройствах. Однако при его некачественном исполнении пользовательский опыт может серьёзно пострадать.
Так где же золотая середина? WebView может неплохо себя показать в качестве заглушки, однако, как известно, нет ничего более постоянного, чем временное. Отличным вариантом будет начать разработку нативной версии одновременно со страницей гибрида. Мобильные разработчики смогут быстро погрузиться в контекст, фронты — корректно доработать вёрстку, пользователи получат фичу в самые короткие сроки, а через релиз экран уже станет нативным. Выбирайте мудро, используйте инструменты правильно, и результат не заставит себя долго ждать.
Нативные, гибридные или веб-приложения?
Навигация по ландшафту разработки мобильных приложений
Вы продолжаете слышать о пользовательских тенденциях к мобильным устройствам; Ваш 10-летний подросток знает ваш iPad лучше, чем вы, и поэтому вы полагаете, что ваш бизнес также должен принять участие и иметь собственное мобильное приложение. Конечно, если ваша компания в основном взаимодействует с нишей аудиторией, в основном, в автономном режиме, вполне возможно, что вам не нужно мобильное приложение. Если вы сделаете колпачки для тюбиков с зубной пастой, я не уверен, что приложение сделает все для вас.
По мере того, как все больше и больше людей начинают пользоваться Интернетом со своих мобильных устройств, многие компании считают, что наличие мобильного приложения — отличный способ связать их со своей аудиторией.
Показательный пример — когда я делаю заказ в моем любимом ресторане, я проверяю их номер и звоню? Нет, я запрыгиваю на их мобильное приложение, вижу, сколько времени доступно, и забронирую свой столик. Я также могу видеть, сколько людей у них в списке ожидания. Теперь, если бы только приложение позволяло мне предварительно заказать стакан Мерло, чтобы быть готовым для меня, когда я туда попал!
Поскольку бизнес рассматривает возможность найма компании для создания мобильного приложения, ситуация может быть запутанной, а иногда даже пугающей — это часто может означать огромные затраты времени и денег. Вы слышите разговоры об iOS, Android, Symbian, webOS, и люди спрашивают вас, хотите ли вы использовать нативную версию или использовать веб-приложение. Собираетесь родные? Нет, это не означает носить набедренную повязку, лицевую краску и копье … это скорее означает фундаментальное решение о том, в каком направлении следует развивать ваше мобильное приложение. И нет правильного ответа — скорее плюсы и минусы для каждого пути, который вам нужно будет сравнить с вашими конкретными потребностями бизнеса.
Позволь мне сосчитать пути …
Часто предполагается, что существует два способа создания мобильных устройств: веб-приложения или нативные приложения. На самом деле их больше как четыре:
Родные приложения
Нативный относится к созданию приложения на родном языке программирования устройства. Для iOS-устройств это означает Objective-C, а для Android — Java. Нативные приложения обычно бывают быстрыми, надежными и могут получить доступ ко всем аппаратным средствам устройства (камера, акселерометр, компас и т. Д.). Из-за этой повышенной производительности мобильные игры обычно создаются как собственные приложения. Это также означает, что ваше приложение привязано к платформе, для которой оно создано. Например, приложение iOS не будет работать на устройстве Android без предварительной перекодировки всего приложения в Java.
Веб-приложения
Веб-приложение — это веб-сайт, к которому вы получаете доступ через браузер вашего устройства, но этот сайт создан для того, чтобы напоминать приложение, а не традиционный веб-сайт. Его назначение также более функционально — оно предлагает утилиту или услугу, а не простой веб-сайт, который часто является более информативным. Доступ к веб-приложению может быть получен с любого мобильного устройства с браузером. Хотя это основано на браузере, типично, что не все аппаратные функции устройства могут быть задействованы. Для создания более увлекательного и интерактивного опыта. HTML5, CSS3 и JavaScript все чаще используются для использования преимуществ расширенных функций, предлагаемых этой новой спецификацией.
Веб-приложение для конкретной платформы
Это веб-приложение, специально разработанное для определенных мобильных устройств, таких как смартфоны под управлением iOS или Android. Меньше внимания уделяется тому, как приложение выглядит на всех мобильных устройствах, а упор делается на то, чтобы сделать веб-приложение максимально похожим на нативное приложение.
Гибридное приложение
Некоторые утверждают, что гибридное приложение является нативным, но важно проводить различие. Гибридное приложение создается с использованием веб-технологий, а затем помещается в оболочку для конкретной платформы, которая позволяет устанавливать его точно так же, как и нативное приложение. Таким образом, он продается / доступен через магазин приложений устройства.
PhoneGap — это пример инфраструктуры, которая позволяет вам взять веб-приложение и превратить его в собственное приложение для iOS, Android, BlackBerry, Windows 7, WebOS, Symbian и других. Гибридные платформы обычно имеют также API-интерфейсы, которые позволяют получить доступ к аппаратному обеспечению и функциям устройства, которые заблокированы в браузере.
А без мозгов?
На первый взгляд вы можете подумать, что гибрид — это путь. В конце концов, он предлагает лучшее из обоих миров или, по крайней мере, лучший компромисс между затратами на разработку и распространением; единая базовая кодовая база на нескольких платформах. Увы, не все так просто. Давайте разберем некоторые плюсы и минусы нативных, веб-и гибридных приложений, чтобы помочь вам сделать правильный выбор. Направление, которое вы выберете, должно быть больше о соответствии технологии требованиям вашего бизнеса.
Родной — Когда скорость имеет значение
Плюсы:
Минусы:
Веб — пиши один раз, беги везде
Плюсы:
Минусы:
Гибрид — полностью загружен с лучшей экономией топлива
Плюсы:
Минусы:
Информированное решение
Как вы можете видеть из приведенного выше списка плюсов и минусов, решение о том, какую технологию использовать, часто зависит от того, что вашему приложению нужно будет делать. Выясните, каковы ваши бизнес-цели, и посмотрите, какой метод лучше всего им подходит. Прямо сейчас, учитывая состояние производительности веб-приложения, если вы создаете игру с причудливой графикой, вам, вероятно, придется перейти к нативной. Если ваше приложение более простое, например, приложение, которое напоминает людям об их годовщине (и ругает вас, если вы забудете), то, возможно, вам нужно веб-приложение.
Назад в будущее
Создание веб-приложений не так просто. Это все еще требует большого знания HTML, CSS и Javascript. Javascript — это очень надежный, эффективный и способный язык, который выполняет большую часть тяжелой работы в веб-приложениях (например, логика кода, анимация, интеграция с базой данных, интерактивность и т. Д.). И чтобы упростить разработку сложных веб-приложений, в последнее время появилось несколько сред Javascript, некоторые из которых даже используют архитектуру MVC (модель-представление-контроллер), чтобы вы действительно почувствовали себя инженером-программистом.
Мобильные приложения для всех!
Это захватывающее время для мобильных и веб-разработчиков. Хотя я не предполагаю, что нативные приложения будут полностью заменены веб-приложениями, я полагаю, что мы по-прежнему увидим, как все больше компаний обращаются к веб-приложениям за более дешевым и эффективным по времени решением при разработке мобильных приложений. И кто знает, может быть, ваша компания-производитель колпачков для зубной пасты могла бы использовать мобильное приложение в конце концов!
Нативные, гибридные и web-приложения в сравнении
Dec 24, 2020 · 9 min read
Итак, вы решили разработать для своего бизнеса приложение. Каков в этом случае следующий шаг?
Что ж, выбор типа создаваемого приложения во мн о гом зависит от того, на каких пользователей вы нацеливаетесь. Здесь вам нужно определить, какой из этих видов ваша целевая аудитория предпочтет использовать, как долго они будут задерживаться в нем, сколько раз в месяц они будут к нему обращаться и т.д.
Но повода для волнения здесь нет, так как мы собрали статистику и ряд фактов, которые помогут вам лучше понять и сознательно выбрать наиболее подходящий вашему бизнесу тип приложения.
Статистика и факты по загрузкам и использованию
В качестве обобщения этих статистических данных можно уверенно сказать, что индустрия мобильных приложений процветает и с каждым годом достигает все новых вершин своего развития. Поэтому давайте предположим, что вы уверено настроены на создание приложения, но, прежде чем приступить к этому процессу и принять окончательное решение, вам нужно взвесить ряд факторов. С технической точки зрения важнейшими факторам являются нужды самого бизнеса, требования пользователей, варианты дизайна UX/UI приложения, выбор подходящего брэнда, а также вывод продукта на рынок. Все эти факторы так или иначе определяют успешность всего процесса.
Тем не менее многих из вас интересует вопрос, почему для успеха бизнеса необходимо выбирать именно конкретный тип приложения, когда вся эта индустрия имеет очень высокие темпы развития в целом. Причины тому следующие:
Выбор приложения, которое сможет обеспечить вашему бизнесу длительный устойчивый успех, оказывается достаточно сложной задачей. В связи с этим мы подготовили список пунктов, имеющих важнейшее значение при выборе типа приложения.
Для начала давайте сформируем базовое понимание каждого из их видов.
1.Знакомство с типами приложений
Обзор
Нативные приложения: отличная производительность в обмен на высокую стоимость
Нативные приложения создаются для конкретной платформы, нацеливаясь на пользователей либо Android, либо iOS. Если вы хотите сфокусировать внимание на пользователях обеих платформ, тогда будьте готовы к разработке двух отдельных приложений, одно для Google Play Store, а второе для Apple App Store. Поскольку каждая из этих платформ имеет совершенно различные стандарты, для их соблюдения использовались разные языки программирования.
Гибридные приложения: пишутся один раз и запускаются на всех устройствах
Многие относят гибридные приложения к кроссплатформенным, но общее между ними лишь то, что они имеют одну базу кода. Тем не менее кроссплатформенный подход отлично работает для малобюджетных приложений с безопасными, стабильными и легко обслуживаемыми функциями.
С другой стороны, гибридные приложения — это профессиональное решение для развивающихся стартапов и бутстрэпперов, так как они обеспечивают высокую скорость разработки и позволяют создавать идеальные решения для бизнеса. Если UX и производительность не стоят в качестве приоритетов, тогда гибридное приложение окажется превосходным решением. Среди основных инструментов для их разработки можно назвать Flutter, Ionic, React Native, Visual Studio и др.
web-приложения: одно приложение для всех типов экранов и платформ
Такие приложения предоставляет вам околонативный опыт и возможность выполнения во всех браузерах и устройствах, включая ноутбуки, планшеты, смартфоны, умные часы и даже ТВ. Единственным требованием является наличие на устройстве браузера. В этом случае вместо разработки отдельных приложений для каждой платформы можно нацелиться на все сразу, создав всего одно.
2. Производительность
Обзор
Производительность приложения — это одна из важнейших его составляющих, определяющая продолжительность использования этого приложения пользователями. В ходе опроса выяснилось, что наиболее распространенными причинами удаления приложений являются следующие: 59% пользователей назвали низкую скорость, 76% назвали фризы экрана, а 71% сбои в работе. Когда доходит до оценки типов приложений в отношении их производительности, нативные варианты могут обеспечить несопоставимые с другими показатели.
Нативные приложения
Этот вид может гарантировать высокую производительность, поскольку они имеют прямой доступ к функциональности и элементам устройства, обеспечивая повышенную скорость отклика. Более того, эти приложения разрабатываются при помощи продвинутого набора возможностей (включая USB вход, сложное сетевое взаимодействие, управление памятью и др.), благодаря чему могут предоставить уникальный пользовательский интерфейс.
Гибридные приложения
С другой стороны, гибридные приложения работают на платформе, загружая данные с сервера, и имеют ограниченный доступ к возможностям устройства. Именно поэтому несколько снижается их производительность по сравнению с нативными приложениями.
Web-приложения
Производительность этих приложений зависит от интернет-соединения и производительности браузера, в связи с чем этот показатель по отношению к нативным версиям снижается.
3. Канал дистрибуции
Обзор
Поскольку, согласно прогнозам, количество скачиваний приложений к 2023 году достигнет 258,2 миллиарда становится очевидно, что более обширный охват аудитории приведет к мгновенному приросту его скачиваний. Нативные и гибридные приложения размещаются в онлайн-магазинах, в то время как web-приложения доступны непосредственно в интернете.
Нативные приложения
Поскольку создаются они под конкретную платформу, приложения Android и iOS размещаются в соответствующих этим платформам магазинах. Это позволяет им задействовать возможности устройств и пользоваться системой рейтинга магазинов.
Гибридные приложения
Они спроектированы для работы на нескольких платформах и обычно размещаются в нескольких магазинах приложений и имеют возможность как задействовать возможности устройств, так и участвовать в системе рейтинга.
Web-приложения
Эти приложения выполняются в браузерах. Они не размещаются в магазинах, но пользователи могут найти их непосредственно в интернете.
4. Целевая аудитория и пользовательский опыт
Обзор
Удержание пользователей в мобильных приложениях на семьдесят процентов зависит от предоставляемого этими приложениями пользовательского опыта (UX) и интерфейса (UI). Тем не менее ведущая компания-разработчик может обеспечить вам 100% удержание с минимумом багов и сбоев UX, в то же время применив последние веяния в дизайне UI. Качество же пользовательского опыта напрямую зависит от выбранной вами аудитории. Взяв за основу ее предпочтения и интересы, вы сможете создать максимально соответствующее им приложение.
Нативные приложения
Нативные приложения для Android скачиваются бесплатно, в то время как приложения iOS являются платными, поэтому вам следует определиться для какой категории пользователей вы создаете продукт. При этом важно помнить, что нативные приложения для поддержания высококачественного пользовательского опыта требуют частых обновлений.
Гибридные приложения
Выбор в пользу этого типа приложений стоит делать, когда вас интересует максимальный охват аудитории по нескольким платформам с минимальной потребностью в обновлениях. Кроме того, если ваши пользователи будут скачивать приложение и пользоваться им офлайн, тогда нативные и гибридные варианты будут идеальным решением.
Web-приложения
Эти приложения предоставляют бесплатный доступ для любых устройств и браузеров, позволяя вам охватить более широкую аудиторию. К тому же web-приложения легче обслуживать, так как они в отличие от нативных не требуют частого обновления.
5. Стоимость разработки
Обзор
Так как стоимость разработки является одним из наиболее острых вопросов для бизнеса, важно отчетливо понять доступный вам бюджет до того, как начать разработку определенного вида приложения. В случае создания нативных приложений вам потребуется нанять разносторонние команды разработчиков, владеющих разными навыками, в связи с чем итоговая стоимость такого проекта значительно превысит стоимость создания гибридных или web-приложений.
Нативные приложения
Гибридные приложения
Web-приложения
Заключение
Надеюсь, что вы ясно представили себе различия между этими тремя типами приложений. Для завершения этой статьи будет не лишним отметить, что каждый тип приложения имеет как достоинства, так и недостатки. Еще раз повторю, что выбор направления разработки приложения будет существенно изменяться в зависимости от целевой аудитории, ее предпочтений и доступного вам бюджета.
Тем не менее не столь важно, какой тип приложения вы в итоге выберите, так как его успех во многом будет зависеть от навыков работающей над ним команды и выбранного способа подстройки приложения под нужды конечных пользователей.