Кроссплатформенные приложения дешевле, работают сразу на двух платформах, а дизайн и разработка занимают меньше времени.
Нативные приложения дороже, зато обеспечивают лучший пользовательский опыт и подходят для крупных и долгосрочных проектов.
В статье разберем две модели разработки и расскажем, какую из них выбрать, чтобы приложение решало бизнес-задачи и нравилось пользователям.
Как устроены кроссплатформенные приложения
Разработчики кроссплатформенных приложений пишут один код сразу для iOS и Android. Для этого они используют программные платформы — кроссплатформенные фреймворки. Два самых популярных фреймворка — React Native и Flutter.
Кроме общей кодовой базы у кроссплатформенных приложений общий интерфейс. Это значит, что дизайнерам не нужно придерживаться двух разных гайдлайнов — Google Material Design System и Apple Human Interface Guidelines — а все элементы и компоненты интерфейсов будут выглядеть идентично на Android и iOS.
Например, кроссплатформенные приложения разработали eBay, Google Ads и AliExpress. А в России — сеть магазинов «Дикси» и аптека «Ригла». Разработчики написали единый код, протестировали, а затем опубликовали приложения в Google Play и App Store.
✅ Разработка кроссплатформенного приложения дешевле и быстрее
«Общая кодовая база и единый интерфейс сокращают сроки разработки и удешевляют проект. Кроссплатформенное приложение обойдется заказчику на 20-30% дешевле, чем нативное»
Анастасия Овсянникова Аккаунт-менеджер Heads and Hands
Например, у клиента своя служба доставки. Компания хочет оптимизировать и оцифровать работу курьеров: чтобы они отмечали смены, принимали и собирали заказы в приложении. Сотрудники пользуются смартфонами как на iOS, так и на Android, а разрабатывать приложение для двух платформ исключительно для внутреннего пользования — дорого.
Кроссплатформенный подход решит эти задачи. Компании не нужно нанимать две отдельные команды дизайнеров и разработчиков под каждую платформу, чтобы отрисовать интерфейсы и спроектировать приложения. Поддержка приложения минимальна — его не надо будет дорабатывать и добавлять сложную функциональность.
✅ Кроссплатформенные приложения подходят для стартапов и корпоративных проектов
«Если нужно быстро выпустить MVP и проверить гипотезу — тогда стоит выбрать кроссплатформу. Также кроссплатформа подойдет, когда дизайн и скорость работы не важны. Например, для корпоративных приложений. Но и в этом случае надо понимать, что рано или поздно дешевле будет сделать натив».
Антон Максимов СТО Heads and Hands
Например, Ozon разработал на Flutter приложение для пунктов выдачи заказов. С его помощью сотрудники ПВЗ выдают посылки, ищут заказы по номеру или штрихкоду, перемещают товары на полках, принимают возвраты.
Ozon выбрал кроссплатформу, потому что Flutter производительный фреймворк, с открытым исходным кодом, его можно использовать сразу на двух платформах и при необходимости интегрировать нативные элементы. Разработчики выпустили MVP c минимальной функциональностью и протестировали гипотезы. Но проект быстро вырос из стартапа с документооборотом. Тогда Ozon, чтобы продолжить его развивать, перешел на нативную разработку.
❌ Кроссплатформенные приложения сложно поддерживать
Кроссплатформенные фреймворки поддерживают большинство стандартной функциональности iOS и Android. Но Apple и Google постоянно обновляют свои операционные системы. Нативный разработчик использует обновления сразу после релиза. Кроссплатформенный разработчик ждет, пока фреймворк добавит поддержку новых функций, либо пишет часть кода нативно и тратит больше времени.
Например, сервис бронирования Airbnb в 2016 году перешел на кроссплатформенную разработку. Но привычные для нативной разработки функции было сложно реализовать в React Native. А решение проблемы могло занять несколько дней. Кроме того, компании было сложно интегрировать нативную и кроссплатформенную часть приложений и пришлось самостоятельно создавать большую часть инфраструктуры. В результате два года спустя команда вернулась на нативный код.
❌ Кроссплатформенные приложения предлагают пользователям непривычный интерфейс
Разработчики и дизайнеры создают интерфейсы на основе гайдлайнов Apple и Google. Если интерфейс не соответствует гайдлайнам, то он может не пройти модерацию в сторах. Поэтому каждый элемент управления или иконка имеют стандартный вид и расположение на экране.
Например, у Android есть встроенная панель навигации, а в iOS нет стандартного навигационного меню. У Android есть кнопка «Назад», а iOS рекомендует использовать жестовое управление. У Android кнопки с острыми углами, а у iPhone — со скругленными. Пользователь привык, что все элементы интерфейса выглядят и работают одинаково.
Кроссплатформенный фреймворк эмулирует интерфейс и элементы iOS и Android. Но они не всегда работают корректно.
«C точки зрения стандартных элементов или стандартного поведения все работает также, как и в нативе. Но Flutter — программный продукт и в нем бывают баги. Поэтому поведение элементов в некоторых нюансах может отличаться от нативных».
Александр Фоминов Веб-разработчик Heads and Hands
Например, приложение «Дикси» на iOS не поддерживает навигационные жесты. Пользователь не может использовать свайп, чтобы пролистывать карточки и убирать уведомления.
❌ Приложение работает медленнее
Скорость анимации и отзывчивость приложения на кроссплатформе ниже, чем в нативном приложении. Например, экраны работают медленнее, а списки прокручиваются с задержкой.
Как устроены нативные приложения
Нативные приложения пишут отдельно под каждую операционную систему: iOS-приложения разрабатывают на языке Swift, Android — на Kotlin. Для каждой платформы нужна своя команда разработчиков, чтобы приложение корректно работало, воспроизводило логику и навигацию операционной системы.
Дизайнеры мобильных приложений используют гайдлайны Apple и Google. Это набор рекомендованных параметров, которые помогают делать интерфейсы в едином ключе. Руководства по оформлению экономят время дизайнеров — в гайдлайнах прописаны рекомендации по цветам, верстке и анимации. Приложения, соответствующие гайдлайнам, быстрее проходят модерацию в сторах. Стандартный интерфейс и навигация интуитивно понятны пользователю, который привык к определенной платформе.
Нативно разработано большинство популярных приложений: стриминговые сервисы, банковские приложения, маркетплейсы, сервисы доставки.
✅ Приложения напрямую используют программное обеспечение смартфона
Нативные приложения напрямую используют программное обеспечение смартфона: камеру, геолокацию, микрофон, список контактов. Например, приложению Shazam нужен доступ к микрофону, чтобы распознавать музыку. А приложению «Сбербанк Онлайн» доступ к адресной книге, чтобы пользователь мог переводить деньги людям из списка контактов.
В кроссплатформенных приложениях эту опцию должен поддерживать фреймворк, либо программисту нужно отдельно прописать нативный кусок кода и встроить его в приложение, чтобы все работало корректно.
✅ Привычный и удобный интерфейс
Нативное приложение спроектировано под привычные паттерны пользователей. Например, у Android есть стандартное навигационное меню — Android Navigation Bar. У iOS его нет, поэтому нижняя часть приложения совпадает с кромкой смартфона.
У Android основная панель вкладок располагается в верхней части экрана, у iOS — в нижней. Android использует меню-гамбургер, iOS рекомендует дизайнерам использовать жестовое управление.
В iOS ключевые кнопки должны располагаться вверху страницы: действия ― в правом углу, а отмены ― в левом углу. В Android основная кнопка действия страницы отображается в правом нижнем углу либо плавает. Если есть другие важные действия, то их надо расположить в верхней части экрана.
Отличается шрифт и иконки. Например, у Android системный шрифт Roboto или Noto. У iOS — гротеск San Francisco или New York. У Android иконка должна быть квадратной с прямыми углами и без подложек. У Apple у иконок скругленные углы и непрозрачный фон.
✅ Можно интегрировать сложные технологии
Дополненную или виртуальную реальность на кроссплатформе можно реализовать только на базовом уровне. А на нативной доступна вся функциональность.
✅ Подходит для крупных и долгосрочных проектов
Большинство крупных и долгосрочных проектов создаются с помощью нативной разработки. Банковские приложения и супераппы сделаны нативно, например, СберБанк Онлайн.
❌ Дороже
Если приложение должно работать на двух ОС, то компании потребуется нанимать отдельные команды разработчиков: под iOS и под Android. Соответственно, стоимость проекта будет дороже, потому что понадобится разрабатывать две кодовые базы.
❌ Дольше разрабатывать
Программистам нужно создать два разных приложения, а дизайнерам — отрисовать два разных интерфейса под каждую операционную систему. Поэтому прототипирование, разработка и дизайн займут больше времени.
Какую разработку выбрать
Быстро разработать MVP и протестировать гипотезу можно как нативе, так и на кроссплатформе. В приложение нужно интегрировать сложные технологии: например, дополненную реальность или AI, тогда подойдет только натив. Нужен прямой доступ к программному обеспечению смартфона — тоже натив. Если стоит цель оптимизировать бюджет, то возможна как кроссплатформа, так и натив.
Какой вид разработки выбрать зависит от бизнес-задачи. Мы в Heads and Hands создаем сервисы, которые решают задачи бизнеса и помогают компаниям конкурировать за внимание пользователей. Расскажите нам о своей задаче на сайте, мы проанализируем ваш проект и подскажем оптимальное решение.
