На тлі загального розгубленості корпорацій щодо застосування штучного інтелекту (ШІ), Microsoft має план, який використовує ШІ для створення більшої кількості нативних додатків WinUI для Microsoft Store.
Компанія опублікувала новий посібник для швидкого старту, який допомагає будь-кому, починаючи з порожньої папки, створити та опублікувати додаток WinUI, використовуючи ШІ, VS Code та власну утиліту winapp CLI. 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 agent має спеціалізовані навички для дизайну WinUI, перевірки коду, тестування інтерфейсу користувача, пакування та міграції фреймворку.
Microsoft також рекомендує підключати агента до свого сервера Learn MCP, щоб він отримував актуальну документацію API WinUI під час запиту. З огляду на нижчу популярність WinUI 3, можна припустити, що моделі ШІ мають багаторічний матеріал для навчання на WPF та UWP.
Посібник з міграції WPF не вдає, що це проста заміна. System.Windows.* стає Microsoft.UI.Xaml.*, і Microsoft надає агенту ШІ повну таблицю заміни, що охоплює елементи керування, потоки, керування вікнами, обробку DPI та прив’язку даних, а також початковий запит, який вказує, що слід позначати.
Посібник Microsoft з міграції з 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 та збільшити участь у відкритому коді. Фактично, WinUI тепер є повністю відкритим кодом.
Це не тільки для розробки додатків. Компанія замінює частини інтерфейсу Windows 11 на WinUI 3, найновіші приклади — AutoPlay, Print Management, і багато іншого в розробці. Несправедливо вимагати від розробників використовувати стек, який сама Microsoft не використовує.
Однак, Microsoft потребує цих посібників більше, ніж ми
Пропозиція Microsoft щодо нативних додатків полягає не в тому, що WebView2 або Electron є поганими технологіями, хоча автор з цим не погоджується. Документація компанії розглядає WebView2 як легітимний спосіб створення гібридних додатків і стверджує, що використання ресурсів залежить від того, наскільки добре розробник оптимізує свій веб-контент.
Досить кумедно, що додаток погоди Windows 11, створений на WebView2, використовує 1,2 ГБ оперативної пам’яті в режимі простою, що приблизно в п’ять разів більше, ніж використовує нативний додаток погоди macOS від Apple, маючи дев’ять підпроцесів Chromium.
Незважаючи на орієнтацію на корпоративний сегмент, Microsoft Teams додав режим Ефективності лише після кількох років скарг.
Популярні сторонні додатки, такі як Windows-версія WhatsApp, мали проблеми з часом завантаження, одночасно споживаючи багато оперативної пам’яті. Discord визнав, що його додаток для Windows був «ненажерливим» щодо ресурсів, і тестував його автоматичне перезавантаження, коли використання оперативної пам’яті перевищує 4 ГБ.
Microsoft закликає сторонніх розробників створювати більш легкі нативні додатки, тоді як деякі її власні додатки та інтерфейс Windows базуються на WebView2.
Чи є код, згенерований ШІ для додатків Windows, хорошим чи поганим?
Девід Фоулер, провідний інженер Microsoft, який працює над Aspire, нещодавно заявив, що ручне введення коду — це минуле. Так, інструментарій WinUI має агентів, які генерують код, розуміють проєкт, запускають тести та виправляють помилки, замість того, щоб людина писала кожен рядок.
Однак, те, що ШІ робить виробництво коду дешевшим, не означає, що він робить його якісним. Microsoft це теж розуміє, тому WinUI agent має спеціальні навички для перевірки коду та тестування інтерфейсу користувача.
Якщо Microsoft хоче, щоб ШІ генерував більше програмного забезпечення для Windows, це програмне забезпечення все одно повинно бути ефективним, інакше полегшення створення нативних додатків призведе лише до появи більшої кількості погано оптимізованих нативних додатків.
Microsoft перебудовує екосистему розробників Windows навколо ШІ
Автор заглибився в спроби розшифрувати план Microsoft щодо збільшення кількості нативних додатків у Windows 11. Якщо багато років тому Стів Балмер вигукував «розробники, розробники, розробники» на сцені, то зараз ситуація змінилася: багато розробників надають перевагу середовищам Linux, а велика група розробників додатків на основі ШІ обирає MacBook через їх потужне обладнання.
Редмонд намагається зберегти свої позиції трьома способами:
- Microsoft створює повний конвеєр: WinUI, агент для кодування за допомогою ШІ, інструменти міграції, автоматизоване тестування, пакування та шлях до Store.
- Подвоює зусилля щодо WSL, дозволяючи агентам кодування працювати в середовищах Linux з повним доступом до GPU, щоб розробники не залишали Windows.
- Просуває робочі станції з високою пропускною здатністю пам’яті, такі як машини Nvidia RTX Spark, наприклад, Surface RTX Spark Dev box, разом з нещодавно анонсованим Project Zenith, що надає ПК щонайменше 64 ГБ оперативної пам’яті та пропускну здатність 250 ГБ/с для локального запуску моделей з понад 30 мільярдами параметрів.
Microsoft намагається зробити розробку для Windows можливою всередині середовища Windows, розробленого навколо агентів ШІ. Якщо це спрацює, Windows може отримати більше нативних додатків без необхідності ручного переписування всього розробниками. Але Microsoft ще належить довести, що додатки WinUI, створені за допомогою ШІ, будуть швидшими та легшими за веб-додатки, які вона хоче замінити.
Підтримайте оригінальну журналістику.
Windows Latest залежить від читачів, таких як ви. Зробіть нас вашим Пріоритетним джерелом у Google Discover та Google Search, і допоможіть нашим незалежним репортажам охопити більше людей.
Follow us on DiscoverFollow us on GoogleAsk a question (Forum) Home Comments Share Newsletter