Что выбрать, нативное или кроссплатформенное приложение

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

Особенности разработки нативных приложений

Что это вообще такое?

Нативное приложение делают отдельно под каждую платформу. Если вы хотите иметь нативные приложения для iOS и Android, нужно разрабатывать два отдельных приложения на разных языках, например, для iOS Swift, а для Android — Kotlin. 

Что хорошего в нативе?

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

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

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

Быстрое обновление. Если функционал iOS и Android обновляется, сразу же обновляются и нативные приложения. С кроссплатформенным приложением придется ждать обновления фреймворка. И никто не скажет, на сколько это затянется.

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

Для приложений, чей UI/UX основан на стандартных паттернах пользователей, это может быть критичным. 

Особенности кроссплатформенной разработки

Что такое кроссплатформа?

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

Что хорошего в кроссплатформенной разработке?

Стоит меньше и делается быстрее. Кроссплатформенная разработка, как правило, экономит ресурсы, поскольку код пишется одновременно для iOS и Android. Экономия составляет до 50% времени. 

На Flutter, например, писать код быстрее, чем на натив. И, соответственно, дешевле.

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

Единый UI. Логика работы у iOS и Android разная, поэтому нативные приложения в них выглядят по-разному. Кроссплатформенное приложение одинаково на всех платформах.

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

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

Самые неприятные ограничения кроссплатформенных фреймворков

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

Дело вот в чем: верстка для кроссплатформы делается по той же технологии, что и для адаптивных сайтов, а при переносе макетов в код нативных приложений соблюдается сетка iOS и Android. Сетки у iOS и Android разные, плюс у них разные размеры и форматы иконок для экрана приложения. Именно поэтому нативная интеграция лучше отображается на разных мобильных устройствах. Даже если это один из тысяч смартфонов на Android и модель с нестандартным экраном. У нестандартного экрана все равно будет стандартная сетка, так что макет со стандартизированными колонками нормально интегрируется в приложении. Кроссплатформенная верстка на нестандартный экран может не встать ни на Андроиде, ни на iOS. Отсюда и баги, которые крайне сложно находить и устранять. У нас был случай, когда в приложении отображалась ошибка с нажатием одной из кнопок. Ошибка воспроизводилась только на одной модели Xiaomi Redmi Note. Мы тестировали приложение на пяти других моделях Xiaomi, искали ошибку на симуляторах, но проблема не воспроизводилась. Пришлось купить именно ту модель Xiaomi Redmi Note, на которой не срабатывала кнопка, и только тогда мы отыскали причину бага.

Мария Орлова, CEO ТехноФабрики

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

Рано или поздно наступает момент, когда каждая правка такого приложения превращается в ад, муки и дорогие часы техподдержки.

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

Мария Орлова, CEO ТехноФабрики

Привередливость операционных систем. У платформ множество различий и все их нужно учитывать в кроссплатформенном фрейме. Например, macOS управляет оперативной памятью, а Windows — нет. 

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

Apple предпочитает нативный код. В политике Apple кроссплатформенные решения не в почете: иногда компания выпускает запрещающий список кроссплатформ, которые больше не смогут публиковаться в App Store. 

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

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

Как выбрать платформу разработки

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

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

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

Каждом продукту — свой инструмент. Каждому бизнесу — свое решение.