В то время как многие считают, что корпорации не знают, что делать с ИИ, у Microsoft есть план: с помощью ИИ добавить в Microsoft Store больше нативных приложений WinUI.
Компания опубликовала новое руководство для быстрого старта, которое помогает любому пройти путь от пустой папки до опубликованного приложения WinUI 3 с помощью ИИ, VS Code и CLI winapp. В Microsoft утверждают, что весь процесс занимает около 30 минут, не требует Visual Studio и работает на бесплатных инструментах, включая бесплатный тариф GitHub Copilot.
Выглядит заманчиво. Простое 30-минутное руководство по сути служит приманкой для начинающих разработчиков: оно позволяет создавать приложения для Windows 11 без “тяжёлой работы” по написанию кода. Редакция поддерживает такой подход, потому что в Microsoft Store не помешают приложения WinUI.
Теперь любой может создать новое приложение WinUI с помощью ИИ, поручить агенту добавить функции, протестировать результат, упаковать его в MSIX и отправить в Microsoft Store, и всё это бесплатно и с минимальными усилиями. Но больше внимания привлекают прилагаемые руководства по миграции существующих приложений WPF и UWP с использованием ИИ.
Это и есть ответ Microsoft на давнюю проблему нативных приложений в Windows: сделать WinUI-приложения проще в разработке, упростить перенос старых приложений и отдать ИИ рутинную работу в обоих случаях.
Microsoft упрощает создание и миграцию WinUI-приложений с помощью ИИ
Новый рабочий процесс создания приложений работает на VS Code, .NET 10, Windows App Development CLI от Microsoft, шаблонах проектов WinUI, GitHub Copilot и плагине WinUI Agent.
Это не нужно путать с тем, как компания продвигала свой универсальный чат-бот Copilot. WinUI-агент поставляется со специализированными навыками для проектирования WinUI, проверки кода, тестирования интерфейса, упаковки и миграции на другой фреймворк.
Microsoft также рекомендует подключить агента к своему Learn MCP-серверу, чтобы он подгружал актуальную документацию по WinUI API в момент запроса. Учитывая меньшую популярность WinUI 3, можно предположить, что у ИИ-моделей накоплено на годы больше обучающих материалов по WPF и UWP.
Руководство по миграции WPF не пытается выдать миграцию за простую замену. Пространство имён System.Windows. заменяется на Microsoft.UI.Xaml., а Microsoft передаёт ИИ-агенту полную таблицу подстановок, охватывающую элементы управления, потоки, управление окнами, работу с DPI и привязку данных, плюс стартовую подсказку, в которой указано, на что обращать внимание.
Руководство по миграции UWP на WinUI 3 начинается с заявления, что UWP больше не находится в активной разработке, а её наследниками стали WinUI 3 и Windows App SDK. Примечательно, что в руководстве предупреждают: ИИ-модели, обученные на годах примеров UWP, продолжат воспроизводить эти шаблоны, если навык миграции не даст им явные замены.
По сути, Microsoft пытается снизить затраты на перенос огромной существующей библиотеки программ WPF и UWP на новый нативный фреймворк.
Microsoft также хочет, чтобы WinUI пришёл на смену беспорядку из веб-приложений
Windows продолжает получать веб-приложения вместо нативных, потому что кросс-платформенные веб-фреймворки дешевле в разработке: они позволяют разработчикам переиспользовать код на разных платформах, а не писать под Windows-фреймворк, который в будущем может измениться, как это уже не раз происходило.
На конференции Build 2026 Microsoft твёрдо пообещала изменить это восприятие: компания назвала WinUI “продакшен-платформой для Windows-приложений” и убрала “3” из названия, чтобы показать сообществу разработчиков, что замены фреймворка больше не будет.
Microsoft также пообещала снизить потребление памяти, добавить поддержку DataGrid и диаграмм, улучшить взаимодействие с WPF и активнее участвовать в open source. Фактически WinUI теперь полностью открыт.
Это касается не только разработки приложений. Компания уже заменяет части устаревшего интерфейса Windows 11 на WinUI 3, в числе последних примеров AutoPlay, Print Management и другие изменения на подходе. Было бы несправедливо просить разработчиков переходить на стек, который сама Microsoft не использует.
Однако эти руководства нужны в первую очередь самой Microsoft
Microsoft не называет WebView2 или Electron плохими технологиями, хотя с этим можно поспорить. В документации компании WebView2 описывается как легитимный способ создания гибридных приложений, а потребление ресурсов, по её словам, зависит от того, насколько хорошо разработчик оптимизирует веб-контент.
Забавно, но приложение “Погода” для Windows 11, построенное на WebView2, использует 1,2 ГБ ОЗУ в простое, примерно в пять раз больше, чем нативное приложение “Погода” в macOS от Apple, и запускает девять подпроцессов Chromium.
Несмотря на подход, ориентированный в первую очередь на корпоративных пользователей, в Microsoft Teams режим эффективности появился только после многих лет жалоб.
Популярные сторонние приложения, например приложение WhatsApp для Windows страдает от долгой загрузки, одновременно расходуя много оперативной памяти. Команда Discord признала, что её приложение для Windows потребляет слишком много ресурсов и тестировала автоматический перезапуск, когда потребление ОЗУ превышает 4 ГБ.
Microsoft призывает сторонних разработчиков создавать более лёгкие нативные приложения, тогда как часть её собственных приложений и интерфейса Windows построена на WebView2.
Насколько хорош код для Windows-приложений, созданный ИИ
Дэвид Фаулер, заслуженный инженер Microsoft, работающий над Aspire, недавно заявил, что набор кода вручную полностью ушёл в прошлое. Да, в этом инструментарии WinUI агенты генерируют код, понимают проект, запускают тесты и исправляют ошибки, вместо того чтобы человек набирал каждую строку вручную.
Однако то, что ИИ удешевляет производство кода, не означает, что он делает его качественным. Microsoft это понимает, поэтому WinUI-агент и оснащён отдельными навыками проверки кода и тестирования интерфейса.
Если Microsoft хочет, чтобы ИИ генерировал больше программ для Windows, такое ПО всё равно должно быть эффективным. Иначе упрощение создания нативных приложений просто приведёт к появлению большего количества плохо оптимизированных нативных приложений.
Microsoft перестраивает экосистему разработки для Windows вокруг ИИ
Разобраться в плане Microsoft по увеличению числа нативных приложений для Windows 11 оказалось непросто. Если несколько лет назад компании требовался Стив Балмер, скандировавший на сцене “developers, developers, developers”, то теперь правила игры изменились: многие разработчики предпочитают окружение Linux, а значительная часть ИИ-разработчиков выбирает MacBook из-за мощного оборудования.
Редмонд пытается удержать позиции тремя способами:
- Microsoft строит полный конвейер: WinUI, ИИ-агент для написания кода, инструменты миграции, автоматическое тестирование, упаковку и путь до магазина.
- Усиливает WSL, позволяя агентам для написания кода работать внутри Linux-окружений с полным доступом к GPU, чтобы разработчики не отказывались от Windows.
- Продвигает рабочие станции с высокой пропускной способностью памяти, такие как машины Nvidia RTX Spark, включая Surface RTX Spark Dev box и недавно анонсированный Project Zenith, которые дают ПК не менее 64 ГБ ОЗУ и пропускную способность 250 ГБ/с для локального запуска моделей с 30 млрд параметров и больше.
Microsoft пытается сделать так, чтобы разработка под Windows происходила в среде Windows, спроектированной вокруг ИИ-агентов. Если этот подход сработает, Windows сможет получать больше нативных приложений без необходимости переписывать всё вручную. Но Microsoft ещё предстоит доказать, что созданные ИИ WinUI-приложения будут быстрее и легче веб-приложений, которые они должны заменить.
Пока нет комментариев. Будьте первым!