Нативная или кроссплатформенная разработка

Что такое нативное приложение, если объяснить простыми словами: это программа, которую написали на родном языке и родными инструментами конкретной операционной системы. Для iPhone таким языком служит Swift, для Android - Kotlin. Приложение работает напрямую с системой, без промежуточного слоя, и может использовать новые функции устройства в тот же день, когда они появляются в свежей версии ОС.

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

Что такое нативные мобильные приложения?

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

Главный признак натива - прямой доступ к API системы (API - набор функций, через которые программа обращается к камере, датчикам, файлам и сети). Кроссплатформенный код тоже умеет вызывать эти функции, но через мост или плагин. Если нужного плагина нет, его приходится писать на том же Swift или Kotlin.

Где чаще всего встречаются нативные приложения: банковские клиенты, камеры и фоторедакторы, навигаторы, фитнес-трекеры в связке с часами, игры на системных графических интерфейсах Metal и Vulkan. Все, что тесно завязано на железо телефона и на скорость отклика.

Что такое нативная программа?

Термин шире мобильной разработки. Нативной называют любую программу, скомпилированную под конкретную платформу и процессор: приложение для Windows на C++, утилиту для macOS на Swift, клиент для Linux. Такое программное обеспечение выполняется как машинный код и не требует браузера или виртуальной машины.

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

В мобильном мире граница размыта. Flutter компилирует код на Dart в машинный, но рисует интерфейс своим движком. React Native исполняет JavaScript, но показывает системные компоненты. Поэтому на практике приложение нативное, если и логика, и интерфейс написаны средствами самой платформы: Swift и SwiftUI на iOS, Kotlin и Jetpack Compose на Android.

Нативная разработка

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

• iOS: язык Swift (старые проекты еще на Objective-C), интерфейс на SwiftUI или UIKit, среда Xcode, которая работает только на macOS.
• Android: язык Kotlin (старые проекты на Java), интерфейс на Jetpack Compose или XML-разметке, среда Android Studio.

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

Есть промежуточный вариант - Kotlin Multiplatform. Общую логику пишут один раз на Kotlin, а интерфейс остается нативным на каждой платформе. Вариант удобен командам, у которых уже сильный Android-опыт и есть желание сохранить родной интерфейс на iPhone.

Плюсы нативной разработки

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

• Высокая производительность. Код компилируется под процессор напрямую, анимации и прокрутка идут без рывков даже на длинных списках и сложной графике.
• Полный доступ к функциям устройства. Камера, Bluetooth, NFC, биометрия, фоновая геолокация, виджеты, часы и системные платежи работают без посредников.
• Новые возможности ОС сразу. Когда выходит новая версия системы, нативный код получает новые API в день релиза. Кроссплатформенные фреймворки догоняют через обновления плагинов.
• Хороший пользовательский опыт. Системные компоненты ведут себя так, как привык владелец телефона, включая режимы доступности для людей с нарушениями зрения.
• Меньше зависимостей. Нет стороннего фреймворка, который может отстать от платформы или сменить курс развития.

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

Сравнение нативной разработки

Сравнение нативной разработки с альтернативами удобно вести по пяти вопросам: сколько кода, сколько стоит, как работает, что с доступом к железу и как приложение попадает к пользователю. Основных альтернатив две: кроссплатформенная разработка (Flutter, React Native, Kotlin Multiplatform) и веб-приложение, в том числе PWA. Решение, писать нативный или кроссплатформенный код, принимают по этим пунктам, а не по моде.

Flutter рисует интерфейс своим движком и дает одинаковую картинку на обеих платформах. React Native использует JavaScript и выводит системные компоненты, поэтому внешне ближе к нативу, но сильнее зависит от связки между JS и платформой. Оба варианта хорошо подходят для приложений с формами, каталогами, личными кабинетами и чатами. Если вам ближе один код на две платформы, посмотрите, как у нас устроена кроссплатформенная разработка.

Веб-приложение проще всего выпустить: его не нужно проводить через модерацию магазина приложений, а обновление видят все пользователи сразу. Цена за это - ограниченный доступ к устройству и отсутствие в App Store в привычном виде.

Опыт нативной разработки

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

• Трассер - демо логистического приложения для водителей и курьеров: фоновая геолокация, работа без сети, отправка точек маршрута при слабом сигнале. Здесь разумно использовать нативные средства хотя бы для модуля трекинга, потому что фоновая работа на iOS и Android устроена по-разному и жестко ограничена системой.
• Умникум - демо образовательной платформы: курсы, тесты, видео, личный кабинет. Экраны типовые, функции устройства почти не нужны. Такой продукт выгоднее собрать на Flutter и выпустить сразу на две платформы.
• Терапис - демо сервиса записи к психологу с видеосвязью. Видеозвонки есть в готовых SDK для обеих технологий, поэтому решают бюджет и планы. Для проверки спроса хватит кроссплатформы, а при росте нагрузки звонковый модуль можно переписать нативно.

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

Как сделать нативное приложение?

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

1. Описать задачу: кто пользователь, какие сценарии, какие функции устройства нужны. По этому списку сразу видно, нужен ли натив вообще.
2. Выбрать платформы. Если аудитория в основном на одной ОС, можно начать с нее. Версия только под iOS обычно стоит около 60 процентов от бюджета двух платформ, только под Android - 55-60 процентов.
3. Сделать дизайн с учетом правил платформы: Human Interface Guidelines для iOS и Material Design для Android.
4. Написать код: Swift и Xcode для iOS, Kotlin и Android Studio для Android. Параллельно разработать серверную часть, если приложение использует свой бэкенд.
5. Протестировать на реальных устройствах разных поколений и размеров экрана.
6. Опубликовать в магазинах приложений: App Store, RuStore и других. Каждый магазин проверяет сборку по своим правилам.
7. Поддерживать: обновлять под новые версии ОС, исправлять ошибки, выпускать новые функции.

Рыночный срок простого MVP (первой версии с минимальным набором функций) 3-4 месяца. При разработке нативных версий под две платформы он обычно дольше, чем для одной кроссплатформенной кодовой базы. Если нужен один продукт под iPhone, загляните на страницу разработка приложений для iOS. Прикинуть объем работ под свой набор функций можно в калькуляторе, точную оценку мы даем после брифа.