Разработчик Джей Мейстрих сравнил десктопные приложения с историей чата на AppKit, React Native и SwiftUI: в появлении первого контента React Native оказался близок к AppKit и заметно обошёл SwiftUI.
Это не доказывает, что React Native подходит для любых задач, но ставит под сомнение правило «нативное значит быстрое». Практический вывод: измеряйте ключевые пользовательские сценарии, а не выбирайте стек по ярлыку.
Разработчик Джей Мейстрих решил проверить это на практике: реализовал одно и то же десктопное приложение на девяти фреймворках и сравнил результаты. По его словам, AppKit оказался немного быстрее и экономнее React Native, а React Native заметно обошёл SwiftUI. Результатами он поделился в треде в X 14 октября 2026 года. [1]
Это не доказательство того, что React Native подходит для любых задач лучше нативных инструментов. Но хороший повод перестать выбирать стек по принципу «нативное значит быстрое».
Что именно сравнивал автор
В треде опубликованы результаты нескольких проверок: время до появления первого содержимого в приложении с историей чата, переход к началу истории, потребление памяти, размер приложения и время до первого содержимого в минимальном Hello World. Автор также дал ссылку на открытые исходники приложений, код бенчмарка и данные измерений.
Ниже — пять оригинальных графиков Мейстриха. Подписи внутри изображений оставлены на английском; пояснения к ним — на русском.
Важная оговорка: это опубликованные автором результаты, а не независимо воспроизведённый нами эксперимент. При интерпретации нужно учитывать оборудование, конфигурацию сборки, данные и особенности каждой реализации.
Первый контент: React Native между AppKit и SwiftUI
Первый график показывает время до появления содержимого в приложении с историей чата. Именно к этому сценарию относится вывод автора о том, что React Native близок к AppKit и опережает SwiftUI.
Здесь важно не превращать отдельную метрику в общую оценку приложения. Появление первого контента, готовность к взаимодействию и скорость последующих действий — разные характеристики. Успех в одной проверке не гарантирует такой же результат в остальных.
Скорость работы: отдельный сценарий — отдельный результат
Следующая проверка — переход к началу истории чата. Она относится уже к работе с интерфейсом, а не к первому показу содержимого.
Для продуктовой команды такой подход полезнее абстрактного вопроса «какой фреймворк быстрее». Пользователь не взаимодействует с фреймворком напрямую: он открывает переписку, ищет сообщение, редактирует запись или переключает экран. Измерять стоит именно эти действия.
Память и размер приложения — не одно и то же
Мейстрих отдельно опубликовал потребление памяти. В сопровождающем посте он отметил, что React Native оказался близок к AppKit, а SwiftUI потреблял больше памяти.
Размер самого приложения вынесен в другой график. Его не следует путать с оперативной памятью: объём файлов на диске и ресурсы работающего процесса отвечают на разные вопросы.
Приложение может быть компактным, но неэкономным в работе — или наоборот. Поэтому одного числа недостаточно, чтобы назвать реализацию «лёгкой».
Зачем в сравнении нужен Hello World
Дополнительно автор собрал минимальное приложение на каждом фреймворке. Этот тест стоит рассматривать отдельно от приложения с историей чата: здесь существенно меньше прикладной логики и интерфейсной работы.
Минимальный пример полезен как отправная точка, но не заменяет проверку реального продукта. Если вы разрабатываете редактор или интерфейс с большой таблицей, пустое окно не покажет, где возникнут основные задержки.
Почему ярлык «нативное» мало что объясняет
AppKit и SwiftUI обычно относят к одной стороне спора — нативной разработке. Но в эксперименте Мейстриха они показали разные результаты относительно React Native. Уже поэтому деление на «нативное» и «кроссплатформенное» слишком грубое для прогноза производительности.
Полезнее разбираться в том, что делает конкретная реализация: какие изменения состояния вызывают обновления, сколько элементов приходится обрабатывать и где выполняется тяжёлая работа.
Документация React Native, например, разделяет производительность JavaScript-потока и UI-потока. Тяжёлые вычисления в JavaScript могут задерживать обработку взаимодействий и управляемые им анимации, тогда как некоторые нативные операции прокрутки и переходов способны продолжать работу независимо.
Эта документация в основном описывает мобильные сценарии. Она помогает понять, почему важны детали исполнения, но сама по себе не подтверждает результаты десктопного бенчмарка.
Есть и ещё одна тонкость: «React Native для десктопа» — не исчерпывающее описание стека. Официальная документация перечисляет отдельные партнёрские реализации для macOS и Windows, а также проекты сообщества. Поэтому в сравнении нужно указывать целевую платформу, реализацию и её версию.
Как проверить стек для своего проекта
Вместо поиска универсального победителя соберите небольшой, но показательный фрагмент будущего приложения. Для рабочего инструмента это могут быть загрузка большого набора данных, прокрутка списка, поиск, редактирование и переключение экранов.
Чтобы сравнение помогло принять решение:
- Сравнивайте одинаковые возможности и данные. Если реализации отличаются, явно зафиксируйте различия.
- Используйте релизные сборки. Документация React Native предупреждает, что режим разработки заметно снижает производительность JavaScript-потока, и рекомендует оценивать скорость в release-сборках.
- Опишите условия. Укажите оборудование, ОС, версии фреймворков, зависимости и параметры сборки.
- Определите метрики заранее. Появление окна, первый контент и готовность к вводу — разные события.
- Повторяйте измерения. Разделяйте холодный и повторный запуск, учитывайте разброс и редкие задержки.
- Ищите причину, а не виноватого. Узкое место может находиться в прикладной логике, работе с данными, отрисовке или интеграции с системой.
- Сохраняйте воспроизводимость. Исходники и понятная процедура проверки полезнее одного эффектного скриншота.
И не ограничивайтесь скоростью. При выборе стека также важны доступность интерфейса, интеграция с ОС, поддержка библиотек, стоимость сопровождения и опыт команды.
Вывод: измеряйте продукт, а не репутацию технологии
Эксперимент Мейстриха ставит под сомнение категоричное утверждение, что нативное десктопное приложение обязательно намного быстрее React Native. Но он не делает React Native универсальным победителем: речь идёт о конкретных реализациях и сценариях, а опубликованные измерения не были независимо воспроизведены для этой статьи.
Для команды практический вывод прост: сначала проверьте самый сложный экран и ключевые пользовательские действия на подходящем оборудовании. Затем сопоставьте результаты с требованиями продукта.
Производительность — это характеристика, которую нужно измерять, а не преимущество, автоматически прилагающееся к названию фреймворка.
Источник
Материал подготовлен по треду Джея Мейстриха в X. Все пять графиков взяты из оригинальных публикаций автора. В заключительном посте треда он разместил ссылку на исходники приложений, бенчмарк и данные измерений.