Неудобное будущее кроссплатформенных фреймворков для iOS/Android в эпоху ИИ
На этой странице
Кроссплатформенная иллюзия: инженерия, бюрократия и эпоха ИИ
Больше десяти лет я работал в нескольких крупнейших интернет-компаниях материкового Китая. Позже переехал за границу и присоединился к глобальной технологической компании, которая работала по всему миру, но не в материковом Китае. После этого я основал за рубежом собственную компанию.
Этот опыт позволил мне иначе взглянуть на инженерную культуру и технические решения, с которыми я сталкивался в Китае.
Мои сомнения в кроссплатформенных фреймворках возникли в 2024 году.
Тогда в свободное время я разрабатывал мобильное приложение для ASR/TTS. Вместо облачных вычислений я хотел использовать вычислительные ресурсы самого устройства, поскольку и iOS, и Android уже поддерживали всё более мощные API машинного обучения.
Я также начал использовать Cursor для разработки с помощью ИИ.
Изучая кроссплатформенные решения для своего приложения, я пришёл к выводу: в эпоху ИИ кроссплатформенные фреймворки для iOS/Android будут становиться всё менее значимыми.
И, возможно, их ценность была переоценена ещё до появления ИИ.
Недавно я наткнулся на инженерную статью Shopify Нативная разработка теперь определяет будущее мобильных приложений Shopify, в которой описывается решение компании перейти с React Native обратно на нативную разработку.
Она напомнила мне о сомнениях в кроссплатформенных фреймворках, возникших у меня ещё в 2024 году, и вдохновила наконец записать собственные мысли.
Shopify утверждает, что React Native был правильным выбором в 2020 году. Я в этом не так уверен.
Сама Shopify признаёт, что потратила значительное время и ресурсы на оптимизацию производительности, улучшение фреймворка и обслуживание зависимостей. Но это лишь часть затрат на кроссплатформенную разработку. А как насчёт скрытых затрат на поддержание экосистемы разработчиков, организационных накладных расходов и упущенных бизнес-возможностей?
Подсчитала ли Shopify когда-нибудь в полном объёме истинную экономическую стоимость того решения? Я в этом сильно сомневаюсь.
За моим выводом стоят несколько причин:
- ИИ-агенты для программирования резко снижают стоимость разработки и сопровождения нативных приложений.
- ИИ на устройстве делает нативную разработку привлекательнее, тогда как кроссплатформенные фреймворки часто отстают от новых возможностей платформ.
- Скрытые затраты, включая сопровождение фреймворка, внутренние экосистемы разработчиков, координацию между командами и организационную политику, часто недооценивают.
- Новая холодная война и гонка вооружений в области ИИ: Мы живём в условиях новой холодной войны, и ИИ стал одним из её важнейших стратегических направлений, подобно Стратегической оборонной инициативе («Звёздным войнам») во время предыдущей холодной войны. По мере обострения конкуренции скорость выхода на рынок и пользовательский опыт становятся всё важнее относительно затрат на разработку.
Но прежде чем говорить об ИИ, я хочу поделиться некоторыми наблюдениями о китайской интернет-индустрии.
Написать один раз, запускать везде?
В нескольких крупных китайских интернет-компаниях, где я работал, кроссплатформенные фреймворки часто продвигали как способ сократить затраты на разработку.
Но их амбиции выходили далеко за пределы общего кода для iOS и Android.
Компании хотели написать код один раз и запускать его везде: на iOS, Android, H5, в мини-программах WeChat, мини-программах Alipay, а иногда и на ещё большем числе платформ.
Аргумент звучал просто: написать один раз, запускать везде.
Но реальность была гораздо сложнее.
- Написать один раз? Не обязательно. Иногда разработчикам в итоге приходилось писать код трижды: для iOS, для Android и для кроссплатформенного фреймворка. Поддержка веба или платформ мини-программ могла добавлять ещё больше работы.
- Производительность и пользовательский опыт. Чтобы приблизиться к нативной производительности, часто требовались значительные инженерные усилия, а некоторые ограничения нельзя было устранить полностью.
- Отставание в поддержке API платформ. Новые возможности iOS и Android не всегда сразу становились доступны через кроссплатформенные фреймворки.
- Издержки координации. Кроссплатформенная разработка создавала дополнительные зависимости между бизнес-командами, командами фреймворка и командами нативных платформ.
- Организационная политика. Некоторые инженерные проекты, казалось, были больше нацелены на технические достижения, расширение команд и повышения, чем на реальную пользу для бизнеса.
- Ненужные итерации. Действительно ли бизнесу требовалось так часто менять приложение? Или некоторые проекты были просто работой, придуманной ради работы?
И каждый дополнительный слой сложности имеет свою цену.
Даже если фреймворк сокращает время разработки, как измерить производительность, пользовательский опыт и бизнес-возможности, которыми пришлось пожертвовать?
Скрытая стоимость: внутренняя экосистема разработчиков
Одна из самых недооценённых статей расходов при создании кроссплатформенного фреймворка — сопровождение его экосистемы разработчиков.
Apple и Google вкладывают огромные средства в свои экосистемы разработчиков, потому что те напрямую укрепляют их платформы и бизнес.
Но когда интернет-компания создаёт собственный кроссплатформенный фреймворк, она фактически создаёт внутри себя ещё одну платформу для разработчиков.
Ей приходится поддерживать мосты к нативным API, UI-компоненты, средства сборки, инструменты отладки, тестовую инфраструктуру, документацию, интеграции SDK и обратную совместимость.
И эта внутренняя экосистема должна постоянно следовать за развитием iOS, Android, а иногда ещё веба, мини-программ и HarmonyOS.
Компания уже не просто разрабатывает приложение. Она сопровождает платформу внутри платформы.
Использование зрелого фреймворка, такого как React Native, может уменьшить эту нагрузку, поскольку Meta и сообщество открытого ПО поддерживают значительную часть его экосистемы. Но крупные компании всё равно часто выстраивают вокруг него обширную внутреннюю инфраструктуру.
Так сколько денег эта экосистема действительно экономит с учётом собственных затрат на разработку и сопровождение?
И создаётся ли она потому, что нужна бизнесу, или потому, что инженерной организации нужно что-то создавать?
Горячие обновления и искусственно созданный спрос
Есть ещё одна причина популярности кроссплатформенных и динамических фреймворков в китайской интернет-индустрии: горячие обновления.
Многие компании хотели обновлять приложения, не проходя каждый раз традиционный процесс проверки и публикации в магазинах приложений.
Это было особенно привлекательно для компаний с бесконечными маркетинговыми кампаниями, рекламными акциями и частыми продуктовыми экспериментами.
Но, оглядываясь назад, я задаюсь вопросом.
Действительно ли пользователям требовалось столько изменений?
Действительно ли эти кампании и непрерывные итерации создавали достаточно пользы для бизнеса, чтобы оправдать затраты?
Или некоторые из них просто порождались крупными организациями, которым требовалось больше проектов, больше активности и больше достижений?
Фреймворк, который ускоряет ненужную разработку, не обязательно делает компанию эффективнее.
Возможно, он лишь помогает компании лучше производить ненужную работу.
И какой бы совершенной ни становилась инженерная инфраструктура, компания не может решить фундаментальные бизнес-проблемы выпуском всё новых функций.
Инженерная эффективность не обязательно превращается в эффективность бизнеса.
Инженерия в духе экзаменов и искусственно созданная сложность
В китайской интернет-индустрии я наблюдал ещё одну проблему: инженерную культуру, ориентированную на экзамены.
Китайская система образования, сосредоточенная на экзаменах, учит людей решать трудные задачи, но редко побуждает задуматься, должны ли эти задачи вообще существовать.
Такое мышление может переноситься в инженерные организации.
Некоторые инженеры прекрасно решают сложные технические проблемы, но редко задаются вопросом, нужно ли эти проблемы решать.
Иногда они даже создают проблемы там, где их нет.
В программной инженерии нет идеальной архитектуры, идеального фреймворка или универсально правильного решения. Почти любое техническое решение можно обосновать достаточным количеством аргументов, бенчмарков и тщательно отобранных компромиссов.
Это оставляет много пространства для организационной политики.
Если предложение звучит технически разумно и устраивает нужных людей, инженерная команда может оправдать почти что угодно.
Создать новый фреймворк. Переписать существующую систему. Ввести ещё один слой абстракции. Разработать новый технический стандарт.
А затем использовать сложность проекта, число задействованных инженеров и его предполагаемые технические достижения, чтобы получить повышение.
Цель уже не в том, чтобы решать проблемы. Цель — производить проблемы, за которые можно получить повышение.
А поскольку идеальной архитектуры не существует, всегда найдётся ещё одна проблема, которую можно решить, ещё один фреймворк, который можно создать, и ещё одна причина занять организацию работой.
Настоящий вопрос — создаёт ли всё это достаточно ценности, чтобы оправдать затраты, — зачастую предпочитают не замечать.
Когда инженерная сложность становится путём к повышению, простота становится угрозой.
Когда абстракция порождает новые абстракции
Вот почти абсурдный пример.
В одной китайской интернет-компании одновременно существовало несколько кроссплатформенных фреймворков.
В конце концов разработали ещё один фреймворк, чтобы сделать эти существующие фреймворки совместимыми друг с другом.
Вдумайтесь.
Мы создавали абстракции, чтобы уменьшить сложность, а затем создали ещё одну абстракцию, чтобы управлять сложностью, порождённой этими абстракциями.
Нелепость.
И это происходило ещё до того, как ИИ-агенты для программирования начали менять экономику разработки ПО.
Экономика кроссплатформенной разработки
Всё это можно рассмотреть с помощью простой формулы.
Определим переменные:
— Чистая экономическая ценность внедрения кроссплатформенного фреймворка.
— Фактически сэкономленные затраты на разработку и сопровождение благодаря повторному использованию кода между платформами.
— Дополнительные затраты на абстракции, проблемы совместимости, отладку и оптимизацию производительности.
— Затраты на сопровождение инструментов разработчика, SDK, тестовой инфраструктуры и совместимости с API платформ.
— Дополнительные затраты на координацию, бюрократию, организационную политику и проекты ради повышения.
— Альтернативные издержки из-за задержек выхода на рынок, отставания в поддержке API, худшего пользовательского опыта и утраты платформенных отличий.
Формула выглядит так:
Кроссплатформенный фреймворк создаёт положительную экономическую ценность только тогда, когда фактическая экономия превышает дополнительные затраты, которые он привносит.
И этим вопросом стоило задаваться ещё до ИИ.
Экономика кроссплатформенной разработки в эпоху ИИ
Теперь посмотрим, как ИИ меняет это уравнение.
Во-первых, ИИ-агенты для программирования резко снижают стоимость нативной разработки.
В результате сокращаются те затраты на разработку, ради экономии которых изначально создавались кроссплатформенные фреймворки.
Во-вторых, новая холодная война и гонка вооружений в области ИИ делают нативные возможности платформ всё более ценными.
ИИ на устройстве, или периферийный ИИ, неизбежно станет важнейшей частью iOS, Android и других вычислительных платформ.
Нативная разработка обеспечивает более быстрый доступ к новым API, лучшую производительность, более простую интеграцию и более прямой доступ к аппаратным и программным возможностям конкретной платформы.
Но стоит задать ещё один вопрос.
Почему приложения для iOS и Android вообще должны быть одинаковыми?
Приложения для Windows и Linux не обязательно одинаково выглядят и работают. Почему мобильные приложения должны?
У разных платформ разное оборудование, операционные системы, возможности ИИ и ожидания пользователей.
В ближайшие годы Apple и Google продолжат развивать собственные возможности ИИ на устройстве, модели, аппаратное ускорение, механизмы конфиденциальности и интеграции на уровне системы.
Почему продукт должен ограничиваться общим подмножеством этих возможностей?
В эпоху острой технологической конкуренции платформенные различия могут стать конкурентными преимуществами, а не проблемами, которые нужно устранять.
А когда компании конкурируют в производительности, пользовательском опыте и скорости инноваций, затраты на разработку имеют относительно меньший вес.
Это увеличивает альтернативные издержки зависимости от кроссплатформенных фреймворков.
В-третьих, ИИ не устраняет сложность, которую привносят кроссплатформенные фреймворки.
ИИ-агенты для программирования могут помогать разработчикам быстрее создавать нативные модули, адаптировать новые API и сопровождать кроссплатформенные фреймворки.
Но написание кода — лишь часть проблемы.
Кроссплатформенный фреймворк по-прежнему добавляет слои среды выполнения, границы интеграции, требования совместимости и сложность отладки.
Когда что-то идёт не так, разработчикам может потребоваться выяснить, где источник проблемы: в операционной системе, нативной реализации, фреймворке или интеграции между ними.
ИИ может уменьшить стоимость решения этих проблем, но не способен заставить архитектурную сложность исчезнуть.
При этом ИИ удешевляет нативную разработку без необходимости в этих дополнительных слоях абстракции.
ИИ снижает стоимость реализации абстракций, но не устраняет сложность, которую эти абстракции привносят.
Следовательно:
Экономическая ценность кроссплатформенных фреймворков сжимается с двух сторон.
Нативная реализация становится дешевле, а специфические возможности платформ — ценнее.
Переиспользовать ядро, а не обязательно всё приложение
Когда в 2024 году я разрабатывал своё ASR/TTS-приложение, то в итоге решил не использовать кроссплатформенный фреймворк приложений.
Я хотел работать непосредственно с нативными возможностями, включая Core ML и экосистему инференса на C/C++ вокруг Whisper.
Интересно, что whisper.cpp сам по себе является кроссплатформенным проектом.
Но это принципиально другой вид повторного использования кода.
Разделять C/C++-движок инференса между операционными системами — не то же самое, что пропускать всё приложение через общий UI-фреймворк, среду выполнения и экосистему разработчиков.
Нативное iOS-приложение может использовать SwiftUI и Core ML. Нативное Android-приложение — Kotlin и специфическое для Android ускорение. При этом оба могут переиспользовать подходящие части одного и того же ядра инференса.
Кроссплатформенное повторное использование кода — не то же самое, что кроссплатформенный фреймворк приложений.
Я не выступаю против общего кода. Я выступаю против предположения, что общая реализация всего приложения всегда экономически выгодна.
И ИИ делает это различие всё более важным.
Неудобное положение посередине
Почему бы для простых приложений, продуктов, ориентированных на контент, и часто обновляемых страниц просто не использовать веб-технологии?
Веб уже предлагает зрелую, широко поддерживаемую платформу с огромной экосистемой разработчиков.
Почему бы для функционально насыщенных приложений, особенно глубоко интегрированных с ИИ на устройстве, аппаратным ускорением и возможностями операционной системы, не выбрать нативную разработку?
Кроссплатформенные фреймворки приложений всё чаще оказываются зажаты посередине.
Конечно, в определённых ситуациях они всё ещё полезны. Небольшая команда, которая создаёт приложение умеренной сложности с ограниченными требованиями к специфическим возможностям платформ, может значительно выиграть от React Native или Flutter.
Но эту пользу нужно доказывать, а не принимать как данность.
И нам стоит перестать считать повторное использование кода бесспорной инженерной добродетелью.
Десятилетия назад Java популяризировала идею «написать один раз, запускать везде». Значительная часть современной программной инженерии двигалась в том же направлении: вводить абстракции, чтобы снизить стоимость поддержки разных платформ.
ИИ меняет экономику, лежащую в основе этого решения.
Возможно, мы снова будем создавать отдельные реализации для разных платформ — не потому, что забыли уроки прошлого, а потому, что изменилась стоимость самой реализации.
Возможно, будущее не в устранении различий между платформами.
Возможно, оно в том, чтобы принять эти различия и одновременно радикально удешевить их реализацию.
Переиспользуйте ядро. Автоматизируйте реализацию. Сохраняйте платформу.
