Сегодня мобильный телефон — неотъемлемая часть жизни практически каждого человека. Миллиарды смартфонов по всему миру работают на базе iOS или Android, и для каждой из этих платформ существуют миллионы приложений в App Store и Google Play. Эти приложения, от простых утилит до сложных игр и социальных сетей, создаются разработчиками. Логично предположить, что спрос на специалистов, способных создавать такие программы, должен быть колоссальным и постоянно растущим. Однако в последние годы мы наблюдаем тенденцию, которая ставит под сомнение будущее традиционной, нативной мобильной разработки. Похоже, что эпоха безраздельного доминирования Swift для iOS и Kotlin для Android подходит к концу.

Обозначение проблемы: Золотой век и скрытые трещины нативной разработки

Вспомним ситуацию примерно 10-15 лет назад. С появлением App Store и Google Play (в его ранней форме) начался настоящий бум мобильных приложений. Компании всех мастей стремились заиметь собственное нативное приложение. Почему именно нативное? Считалось, что такие приложения обеспечивают лучшую производительность, более плавный пользовательский интерфейс и полный доступ к возможностям устройства.

В те времена спрос на разработчиков Objective-C (предшественник Swift для iOS) и Java (основной язык для Android до Kotlin) был огромен. Эти специалисты высоко ценились на рынке, их зарплаты зачастую превышали доходы веб-разработчиков. Особенно востребованными были iOS-разработчики, так как аудитория Apple считалась более платежеспособной. Android-разработка также процветала благодаря огромному количеству устройств и широкому охвату пользователей. Казалось, это золотой век нативной разработки.

Однако у этой идиллии были свои проблемы. Objective-C многие считали довольно громоздким и не самым удобным языком. Работа с ним требовала специфических знаний и подходов. Java, хоть и была популярна, имела свои сложности, в частности, из-за юридических споров между Google и Oracle (владельцем прав на Java), что создавало определенную напряженность вокруг ее использования в Android. Google нуждалась в современном языке, который был бы совместим с существующей экосистемой Java и виртуальной машиной JVM, но при этом решал бы ее проблемы.

Ответом на эти вызовы стали Swift, представленный Apple в 2014 году (хотя разработка началась раньше), и Kotlin, который Google официально назвала предпочтительным языком для Android-разработки в 2017 году. Swift был призван модернизировать разработку под iOS, сделать ее проще и привлекательнее. Kotlin предложил элегантное решение для Android, обеспечивая полную совместимость с Java-библиотеками и предлагая современный синтаксис и возможности. Казалось, что с появлением этих новых, мощных языков нативная разработка получит второе дыхание и ее позиции станут незыблемы. Но параллельно развивалась другая технология, которая кардинально изменила ландшафт.

Решение (или причина упадка нативной разработки?): Восход кроссплатформенных технологий

Примерно в 2010-2011 годах начали набирать популярность решения, позволяющие создавать мобильные приложения с использованием веб-технологий (HTML, CSS, JavaScript). Одним из пионеров был PhoneGap (позже ставший Apache Cordova). Идея была проста: упаковать веб-приложение в нативную "обертку", которая дает доступ к некоторым функциям телефона (камера, геолокация и т.д.). Это позволяло веб-разработчикам создавать мобильные приложения без изучения Swift/Objective-C или Kotlin/Java.

Однако у ранних кроссплатформенных решений, таких как PhoneGap/Cordova, были существенные недостатки. Главный из них – производительность. Приложения часто ощущались "тормозными", интерфейс был не таким отзывчивым, как у нативных аналогов. Часто было заметно, что под видом приложения скрывается обычный веб-сайт.

Настоящий перелом произошел с появлением фреймворков нового поколения, таких как React Native от Facebook (ныне Meta*). Используя популярную библиотеку React и JavaScript, React Native позволял создавать приложения, которые компилировались в нативный код или использовали нативные компоненты интерфейса. Это обеспечивало значительно лучшую производительность по сравнению с PhoneGap и приближало пользовательский опыт к нативному.

Ключевые преимущества React Native и схожих технологий (таких как Vue Native, NativeScript, а позже и Flutter от Google, использующий язык Dart) стали очевидны:

  • Единая кодовая база: Разработчики могут писать код один раз и запускать его как на iOS, так и на Android (а иногда и на других платформах). Это значительно сокращает время и стоимость разработки и поддержки.
  • Доступность разработчиков: JavaScript – один из самых популярных языков программирования в мире. Огромное количество веб-разработчиков смогли относительно легко перейти к созданию мобильных приложений с помощью React Native.
  • Скорость разработки: Возможность использовать готовые компоненты, обширную экосистему JavaScript и инструменты вроде "горячей перезагрузки" (hot reloading) ускоряют процесс разработки.
  • "Достаточно хорошая" производительность: Для подавляющего большинства мобильных приложений производительности, предлагаемой современными кроссплатформенными фреймворками, вполне достаточно.
  • Давайте будем честны: большинство мобильных приложений не являются сверхсложными с точки зрения технологий. Основные задачи – получить данные из API, красиво отобразить их пользователю, обеспечить навигацию и взаимодействие. Это могут быть приложения интернет-магазинов, банков, сервисов доставки, социальных сетей, новостных порталов. Для таких задач не всегда требуются уникальные возможности нативной разработки или выжимание максимума производительности из устройства. Игры, приложения с интенсивной графикой, сложной анимацией или требующие глубокой интеграции с аппаратными возможностями (например, обработка сигналов в реальном времени) – это отдельная категория, где нативная разработка все еще часто является предпочтительной или единственно возможной.

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

Последствия для нативной разработки

Эта смена парадигмы не могла не сказаться на спросе на "чистых" Swift- и Kotlin-разработчиков. Конечно, они все еще нужны, особенно в крупных компаниях, разрабатывающих сложные флагманские продукты или поддерживающих существующие нативные приложения. Но для стартапов и среднего бизнеса, стремящихся быстро вывести продукт на рынок и охватить обе платформы, кроссплатформа часто выглядит привлекательнее.

Появляются даже кроссплатформенные фреймворки на других языках, например, на Go или с использованием .NET MAUI от Microsoft. Это еще больше размывает границы и уменьшает уникальную нишу Swift и Kotlin. Наблюдается тенденция к снижению позиций этих языков в некоторых рейтингах популярности, где они когда-то занимали высокие места именно благодаря мобильной разработке.

Можно ли говорить о "смерти" нативной разработки? Вероятно, это слишком сильное заявление. Нативные приложения никуда не денутся. Они по-прежнему будут эталоном производительности и возможностей. Apple и Google продолжат развивать свои платформы и языки, предлагая уникальные функции, доступные только через нативные SDK. Однако роль нативной разработки меняется. Из мейнстрима для всех типов приложений она смещается в сторону ниши для сложных и требовательных продуктов, а также для компаний, готовых инвестировать в максимальное качество и производительность для каждой платформы отдельно.

Вывод

Ландшафт мобильной разработки претерпел значительные изменения. Если 10-15 лет назад нативная разработка была практически безальтернативным выбором, то сегодня кроссплатформенные технологии, особенно React Native и Flutter, захватили огромную долю рынка. Это произошло благодаря их способности предлагать более быструю и дешевую разработку для большинства типичных приложений, не сильно уступая в качестве для конечного пользователя.

Нативная разработка на Swift и Kotlin не умерла, но ее доминирование подорвано. Она остается важной и необходимой для определенных задач, но перестала быть универсальным решением. Будущее, вероятно, за гибридным подходом: компании будут выбирать технологию (нативную или кроссплатформенную) исходя из конкретных требований проекта, бюджета и сроков. Разработчикам же стоит быть гибкими и, возможно, осваивать как нативные, так и кроссплатформенные инструменты, чтобы оставаться востребованными на меняющемся рынке труда. Эпоха безальтернативного выбора прошла, наступило время прагматичных решений.