Миф о простоте: почему создание мобильного приложения сложнее, чем кажется

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

Привет, мы студия mrktng. bz, разрабатываем сайты, сервисы и приложения.

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

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

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

Так какой язык разработки выбрать? Мы попробуем максимально простыми словами без технических терминов объяснить существующие подходы, их плюсы и минусы, дать маяки которые помогут определиться с выбором.

Всех разработчиков и в принципе людей “в теме” просьба не обращать внимание на излишние упрощения объяснений или технические тонкости. Ведь цель статьи в именно в доступности материала.

Начать хотели бы с ключевой идеи:

Глобально, существуют нативные и кросс-платформенные приложения, каждое направление имеет свои преимущества которые мы рассмотрим далее.

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

Плюсы

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

Минусы

Дорогая разработка. Разработчики нативных приложений более узкоспециализированны, их меньше и спрос на них выше. Высокий спрос вызывает увеличение стоимости. Очень дорогая разработка. Чаще всего бизнесу нужно приложение на обе платформы: iOS и Android. Соответственно, нужно писать одно и то же приложение два раза: одно для iOS, другое для Android. Нужны две команды разработки.

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

Затем умножьте все проблемы еще на полтора, ведь вам нужно, чтобы два приложения разрабатывались примерно в одном темпе, вышли примерно в одно время, получали обновления примерно в одно время + имели одни и те же функции. Это долго. В принципе, это ясно из предыдущего пункта без дополнительных комментариев.

В остальных случаях вполне справедливо будет рассмотреть кросс-платформенные решения. О них поговорим далее.

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

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

Слово Native в названии технологии ― это некий маркетинговый ход. Ведь из описания выше мы знаем, что такое нативная разработка. И это явно не она. “Native” здесь присутствует, потому что, по итогу приложение действительно будет использовать нативные компоненты системы. Как мы договаривались ранее, в технические нюансы погружаться не будем.

Плюсы

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

Минусы

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

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

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

По большому счету, это то же самое, что и React Native, только универсальнее в части написания приложения. Если React Native создан только для React-разработчиков, то на NativeScript может писать практически любой толковый фронтендер.

Плюсы

Легко найти разработчика. Приложения выглядят и работают практически как нативные. Высокая скорость разработки.

Минусы

Могут быть проблемы с производительностью. Сложно сделать внешне одинаковое на обе платформы приложение. Большие приложения со сложной логикой и функционалом на NativeScript (да и на ReactNative) лучше не писать, потому что не все идеи можно реализовать.

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

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

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

Плюсы

Скорость работы приложений. Действительно, то, что написано на Flutter (если грамотно написано), будет работать очень быстро. Без нагрева телефона, без зависаний и вылетов приложения.

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

Стабильность. Такие приложения будут вести себя практически в 100% случаях предсказуемо.

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

Минусы

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

Это все же не натив. Даже отдельные нативные компоненты в основном не используются. Весь интерфейс Flutter “рисует” сам. Поэтому сделать приложение, которое бы выглядело как нативное (особенно в iOS), практически невозможно.

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

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

То есть все, что будет на экране пользователя: кнопки, окна, экраны — это все обычный веб-сайт. Он работает внутри нативного приложения, которое служит оберткой.

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

Плюсы

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

Моментальные обновления приложения. В классических приложениях, которые мы рассмотрели выше, обновление отправляется и рассматривается в AppStore и GooglePlay от 1 до 7 дней. Иногда обновление могут отклонить. С WebView подходом обновления будут прилетать пользователю моментально, ведь достаточно обновить сайт.

Идентичный вид сайта и мобильного приложения. Потому что по сути это одно и то же.

Минусы

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

Это очень далеко от натива. Даже самые неприхотливые пользователи на уровне ощущений будут понимать, что приложение “какое-то не такое”. Оно не будет работать и выглядеть как нативное, анимации не будут такими плавными, как в нативе.

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

Могут не пройти проверку в AppStore и GooglePlay. На практике такое бывает очень редко, но теоретически такое приложение не соответствует правилам этих площадок. Приложение могут не пропустить либо удалить из стора уже существующее.

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

Progressive Web Application. Последняя технология создания приложений которую мы рассмотрим в этом статье. Чем-то это похоже на WebView. Приложением здесь тоже становится веб-сайт, но иным способом.

В данном случае сайт не будет пытаться замаскироваться под натив. PWA ― существующая и поддерживаемая технология, при которой веб-приложение (сайт) с помощью определенных техник и подходов может получать доступ ко многим функциям операционной системы почти как нативное приложение. PWA могут использовать камеру, распознавание речи, запись звука, доступ к файлам, отправлять Push уведомления и делать бейджи количества уведомлений на своем значке. И много чего еще. И при этом стабильно и быстро работать. А еще приложение сможет работать без интернета.

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

Плюсы

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

Скорость. Любой уже существующий сайт можно превратить в PWA. Быстродействие и стабильность. При грамотном подходе (как и всегда), такие приложения работают быстро и предсказуемо.

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

Идентичный внешний вид и функционал в приложении и на сайте. Моментальные обновления (как и в WebView)

Можно не зависеть от AppStore и GooglePlay. PWA будет доступен для установки прямо с сайта как на iOS, так и на Android.

Может работать без интернета

Минусы

Никогда не будет работать и выглядеть как нативное

Не все функции можно реализовать. Список возможностей на iOS заметно короче, чем на Android

AppStore не принимает PWA. На данный момент, наверное, это самый очевидный и отталкивающий многих минус. Люди привыкли искать и устанавливать приложения в сторах. Особенно пользователи iOS, где альтернативных способов никогда не было. Части клиентов будет просто сложно донести, как установить приложение, а часть может подумать, что это какая-то “пиратская” установка, которая может навредить их устройству. Ведь Apple всегда заявляли, что установка приложений возможна только через AppStore.

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

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

Если вы хотите запустить приложение очень быстро и очень дешево, выбирайте PWA или WebView, но не забудьте оценить риски. Если вам крайне важно, чтобы приложение выглядело как нативное, но вы не располагаете бюджетом и временем на настоящую нативную разработку — ваш выбор ReactNative или NativeScript, но будьте готовы столкнуться с проблемами при разработке и его отладке, которые выведут бюджет за пределы планируемого.

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

#приложения, #разработка, #iOS, #Android

__________

Подписывайтесь на наш канал, здесь пишем о бизнесе, веб и AI-решениях

Остаемся на связи, mrktng.bz