что такое uwp приложения

Приступая к работе с приложениями для Windows 10

Создавайте приложения, которые работают на всех устройствах с Windows 10, или улучшайте существующие приложения с помощью новых и обновленных функций.

Сведения о приложениях для Windows 10.

Windows 10 и универсальная платформа Windows позволяют создавать приложения, которые прекрасно работают и выглядят на всех типах устройств с Windows, или обновлять существующие приложения с помощью современных функций.

Подготовка

Visual Studio Community и пакет SDK для Windows 10 содержат все необходимые инструменты для разработки превосходных приложений, причем это абсолютно бесплатно!

Начало разработки

Независимо от того, являетесь ли вы опытным разработчиком или просто создаете свое первое приложение, вы можете получить помощь по платформе Windows 10 и доступ к учебной документации.

Учебники

Вам нужно пройти пошаговое обучение с практическими примерами? Эти руководства помогут вам.

Примеры

Научитесь на личном опыте работать с платформой Windows 10 и оцените возможности интерфейсов API в действии.

Новые возможности

Расширьте свои возможности и изучите последние изменения в Windows 10.

Источник

О приложениях UWP для разработчиков WPF

Хотел бы закодировать разработчиков WPF от боязни чего-то нового, рассказав про отличия, которые ожидают их при разработке приложений под универсальную платформу Windows. Так что ставьте банки перед монитором, я начинаю давать установку.

Какие-то изменения в языках программирования и платформах происходят постоянно. Представьте себе на минуту, что выйдет C# версии 10 и все. Это последняя версия. Представили? Я представил. И в моем представлении если это и случится когда-нибудь, то эта последняя версия языка будет регулярно обновляться.

Были «чудесные» времена, когда у меня немного разбегались глаза от различий в коде (даже в коде XAML): WPF, Silverlight, Windows Phone, потом WinRT, а теперь еще и UWP. Сколько разработчиков никогда не путаются? Я думаю, что большинство разработчиков не держат все в памяти. Достаточно держать в памяти основные концепты работы. Когда дело касается кодирования, то используются вспомогательные инструменты вроде IntelliSense, Blend и т.п. Никуда не уйти и от использования сниппетов.

По каким причинам происходят изменения:

1. Где-то сидит вредный дядя, который ждет момента, когда все привыкнут к платформе/среде разработки. И тогда он что-то меняет.
2. Усовершенствования/новый функционал.
3. Отзывы пользователей или разработчиков (не понравилось и все тут). Исправление ошибок.
4. Аппаратная часть совершенствуется. Акцент на энергосбережение, на производительность или же на красивые эффекты.
5. Что-то глобальное. Например, последнее объединение платформ в UWP или что-то вроде «Мы хотим чтобы на C# писали под все платформы сразу, минуя Xamarin, поэтому добавили вам новые аналогичные другим платформам контролы». Кто знает, может через несколько лет будет и такое.
6. Ваш вариант напишите в комментариях.

Так что вполне можно начать знакомиться с новой платформой. Давайте я сделаю небольшой экскурс, описав некоторые отличия.

Начну с того, что приложения UWP обладают кое-чем, чего нет у классических приложений Windows – у них есть App Model. Что такое App Model? Это своеобразный регламент. Описание всех возможностей приложения — его прав доступа, способа установки, обновления, хранения информации и т.п.

У приложений Windows Store, точно так же как и у приложений UWP есть файл манифеста, в котором описаны все возможности и права приложения. Это файл Package.appxmanifest. Его можно редактировать как в графическом редакторе, так и в виде кода XML. Скриншот графического редактора смотрите ниже.

Элементы управления

Если вы помните, то совсем недавно у Windows 8 и 8.1 была Charm panel – волшебная панелька:

Сейчас же вместо нее используются более привычные для WPF разработчиков контролы:

Здесь новым контролом является ContentDialog, который блокирует приложение, примерно так же, как блокирует его MessageBox.
Кроме того в UWP более привычная для разработчиков WP навигация:

Что может показаться интересным, так это то, что некоторые элементы управления могут иметь различный внешний вид при отображении на различных устройствах. Простыми словами, контрол может выглядеть немного иначе, например, при отображении на десктопе и на мобильном устройстве.

В целом, я так полагаю, среднестатистический разработчик уже давно привык большому разнообразию контролов. Освоение новых трудностей вызвать не должно.

Разработка под различные устройства

Постараюсь разобрать то, что для WPF разработчика будет необычным. Например, это то, что при разработке приложений Windows 8.1 можно было в одном решении разрабатывать одновременно и под телефон и под десктоп.

В таком случае создавалось 3 проекта. В приложениях WP и WinRT хранился xaml код «вьюшек» и какой-то особый код под устройства, а в общем проекте хранился общий код xaml и общий для двух проектов код C#.

Сейчас же, так как платформа UWP универсальная, то для каждого типа устройств можно создать папку, в которую можно поместить «вьюшку» — т.е. xaml файл с дизайном под параметры устройства.

Жизненный цикл

Есть старая шутку про формулу-1: «У Ральфа Шумахера два положения педали – включено и выключено. Остальными положениями можно пренебречь».

Триггеры и фоновые задания

Что касается приложений 8.x и UWP, то они могут содержать в себе фоновые задания. Фоновые задания это некоторое подобие сервиса. То есть приложение может не работать, но в системе будет выполняться какая-то задача. Кроме того фоновая задача может «отлавливать» какие-то события в работе системы триггером.

Один из самых популярных триггеров это SystemTrigger. С помощью него приложение может выполнить какой-либо код при наступлении таких событий как: появление или пропажа интернета, изменение состояния сети, подключение или отключение пользователя, получение смс, изменение часовой зоны и т.п.

Также довольно популярны TimeTrigger и MaintenanceTrigger. Оба триггера выполняют какой-либо код с периодичностью в определенный промежуток времени. Промежуток времени должен быть не менее 15 минут. Отличие в то, что TimeTrigger требует регистрации приложения на экране блокировки, а MaintenanceTrigger-у требуется чтобы устройство работало не от батареи, а от сети.

В UWP появилось много новых триггеров. Взять, например такой вот интересный триггер как MediaProcessingTrigger, который позволяет приложению перекодировать мультимедиа в рамках фоновой задачи.

Использование библиотек

Если в классических приложениях вы использовали библиотеки DLL, то в приложениях 8.x и UWP вы сможете использовать как PCL, так и компонент среды выполнения WinMD. В чем отличие?

WinMD может быть использован только под 8.x или UWP. Вне зависимости от языка, на котором написаны приложения, они могут работать с WinMD. Но сам WinMD в случае если он содержит в себе сложные вычисления лучше писать на C++ для достижения наилучшей производительности.

Впрочем, при разработке под UWP вы можете создать и библиотеку классов (DLL).

Работа с данными

В чем еще заключается отличие приложений UWP, так это в том, что они не работают с базами данных напрямую. То есть такие базы данных, как, скажем SQL Server или Oracle, расположенные на сервере организации, будут вам недоступны. Впрочем, это было бы странно, если бы пользователь скачивал из Store приложение, и приложение начинало бы работать с базой SQL Server-а, расположенной на сервере в локальной сети. Но вы сможете работать с данными, используя веб-сервисы. Есть возможность использовать для баз MySQL оракловский Connector/Net, но он на данный момент не поддерживает SSL и потому не особо интересен. Так что лучше не отклоняться от концепта использования сервисов для доступа к данным.

Для хранения информации внутри приложения вы можете использовать SQLite.

Хранения параметров приложения и работа с файлами

Хранение параметров приложения возможно не только на устройстве, но и в облаке. Таким образом, если запускать приложение на различных устройствах, то настройки везде будут одинаковыми.

Следующий небольшой сниппет сохраняет количество вызова кода в облаке:

Если заменить Windows.Storage.ApplicationData.Current.RoamingSettings на Windows.Storage.ApplicationData.Current.LocalSettings, то параметр будет сохранен локально на устройстве.

Настройки могут быть скомпонованы как в составные параметры, так и в контейнеры. Файлы точно так же как и настройки можно хранить как на устройстве в локальной папке, так и в облаке. Но кроме этого есть возможность хранить файлы во временной папке, которая при необходимости может быть очищена системой — ApplicationData.TemporaryFolder.

Кроме того можно получить доступ к папке, которая содержится в приложении с помощью
Windows.ApplicationModel.Package.Current.InstalledLocation

Доступ к файлам, хранящимся на дисках, тоже организован по особой модели. Содержимое папок документов, фотографий, видео и подобных может быть получено с помощью класса KnownFolders, но в таком случае необходима установка разрешений в манифесте. Доступ к какой-либо другой папке возможен только в случае, если пользователь выберет папку сам в процессе работы с приложением. Посещенные папки можно сохранять, дабы при повторном запуске приложения не заставлять пользователя делать лишние действия

Получить после этого последнюю сохраненную папку можно так:

Привязки данных

Как в приложениях WPF, так и в приложениях UWP, а также при разработке под 8.x можно использовать привязки данных – . Но в UWP появились еще и компилируемые привязки – В чем отличие? Компилируемые работаю гораздо быстрее, а формируются/проверяются они во время компиляции а не во время запуска приложения. Также они строго типизированные.

Эффективные пиксели

Создавая приложение UWP, вы ведете разработку в эффективных пикселях, а не физических. Особый алгоритм масштабирования позволяет добиться того, что шрифт размера в 24 пикселя будет одинаково читаемым и на большом экране PC и на экране телефона.

Таким образом, получается, что разработчик может не заботится о плотности пикселей на различных устройствах или дистанции просмотра. Но он должен позаботиться о том, чтобы на устройствах с высоким разрешением изображения смотрелись качественно. Давайте рассмотрим папку Assets стандартного только что созданного универсального приложения:

Пример: если вы заходите создать вариант изображения для устройств с коэффициентом масштабирования 150, то вам нужно создать изображение размера 66×66 и назвать его Square44x44Logo.scale-150.png.

Это касается не только изображений, используемых в описании приложения, но и изображений, которые вы используете в UI.

Источник

Что такое приложение UWP?

UWP — это один из многих способов создания клиентских приложений для Windows. Приложения UWP используют API WinRT для предоставления мощных пользовательских интерфейсов и расширенных асинхронных функций, которые идеально подходят для устройств, подключенных к Интернету.

Чтобы скачать средства, требуемые для создания приложений UWP, ознакомьтесь со сведениями о подготовке, а затем напишите свое первое приложение.

Какое место принадлежит UWP в истории разработки Майкрософт?

История разработки Майкрософт получила логическое развитие с реализацией UWP — мощного средства для создания клиентских приложений, используемого наряду с такими инициативами, как WinUI, MSIX и Project Reunion.

Возможности приложения UWP

Основные достоинства приложения UWP.

Рассмотрим все это более подробно.

Безопасность

В манифестах приложений UWP объявляются возможности устройства, необходимые приложению, — например, доступ к микрофону, геоданным, веб-камере, USB-устройствам, файлам и т. д. Прежде чем приложение получит доступ к возможности, пользователь должен подтвердить и разрешить такой доступ.

Общая поверхность API для всех устройств

В Windows 10 впервые появилась универсальная платформа Windows (UWP), которая предоставляет общую платформу приложений на любом устройстве, работающем под управлением Windows 10. Основные API UWP одинаковы на всех устройствах Windows. Если ваше приложение использует только основные API, оно будет работать на любом устройстве под управлением Windows 10, независимо от того, под какое устройство оно разрабатывалось — ПК, Xbox, гарнитуру смешанной реальности и т. п.

Приложение UWP, написанное на C++ /WinRT или C++ /CX, имеет доступ к API-интерфейсам Win32, которые входят в состав UWP. Эти API Win32 реализуются всеми устройствами с Windows 10.

Пакеты SDK расширений предоставляют уникальные возможности для конкретных типов устройств

Если вы разрабатываете приложение для универсальных API, такое приложение сможет работать на всех устройствах под управлением Windows 10. Но если вы хотите, чтобы ваше приложение UWP могло пользоваться преимуществами API конкретных устройств, это также возможно.

Пакеты SDK расширений позволяют вызывать специализированные API для различных устройств. Например, если ваше приложение UWP предназначено для устройства Интернета вещей, вы можете добавить в свой проект пакет SDK расширения для Интернета вещей, чтобы реализовать функции, характерные для устройств Интернета вещей. См. сведения в разделе Пакеты SDK расширений статьи Программирование с помощью пакетов SDK расширений.

Вы можете написать приложение так, чтобы оно было предназначено для запуска только на устройствах определенного типа, а затем ограничить его распространение в Microsoft Store только этим типом устройств. Или же вы можете реализовать условную проверку на наличие того или иного API во время выполнения и соответствующим образом адаптировать поведение своего приложения. См. сведения в разделе Написание кода статьи Программирование с помощью пакетов SDK расширений.

Следующее видео представляет собой краткий обзор семейств устройств и написания адаптивного кода:

Адаптивные элементы управления и ввод

Элементы пользовательского интерфейса реагируют на размер и плотность точек экрана, на котором выполняется приложение, и выбирают подходящий масштаб и макет. Кроме того, приложения UWP отлично работают с различными средствами ввода, такими как клавиатура, мышь, сенсорные устройства, перо и устройства управления Xbox One. Если нужно дополнительно настроить пользовательский интерфейс в соответствии с определенным размером экрана или типом устройства, новые панели макета и инструменты помогут вам разработать интерфейс, способный адаптироваться к различным устройствам и форм-факторам, на которых может работать ваше приложение.

Windows позволяет ориентировать пользовательский интерфейс на множество устройств с помощью следующих функций:

Некоторые характеристики пользовательского интерфейса приложения автоматически корректируются под разные устройства. Однако при проектировании пользовательского интерфейса приложения могут потребоваться некоторые изменения в поведении приложения в зависимости от устройства, на котором оно работает. Например, приложению для фотографирования при работе на маленьком наладонном устройстве следует адаптировать свой интерфейс так, чтобы с ним удобно было работать одной рукой. Когда это же приложение для фотографирования запускается на настольном компьютере, пользовательский интерфейс должен адаптироваться так, чтобы использовать дополнительное пространство экрана.

Один магазин для всех устройств.

Благодаря единому магазину ваше приложение будет доступно на различных устройствах с Windows 10 — ПК, планшетах, HoloLens, Surface Hub, а также устройствах для Интернета вещей. Вы можете отправить приложение в магазин и сделать его доступным для всех типов устройств или только некоторых из них. Вы отправляете все свои приложения для устройств с ОС Windows и управляете ими централизованно. У вас есть классическое приложение на C++, которое вы хотите модернизировать за счет возможностей UWP и продавать в Microsoft Store? Это тоже возможно.

Приложения UWP интегрируются с Application Insights для получения подробной телеметрии и аналитики, что поможет вам понять предпочтения своих пользователей и усовершенствовать приложения.

Приложения UWP можно упаковывать с использованием MSIX и распространять через Microsoft Store или другими способами. MSIX позволяет обновлять приложения независимо от способа их распространения (см. статью Обновление пакетов приложений, опубликованных не в Store, из кода).

Монетизация приложения

Вы можете выбрать способ монетизации своего приложения. Существует целый ряд способов заработать на своем приложении. Вам нужно только выбрать наиболее подходящий (примеры способов приведены ниже).

Актуальная информация в реальном времени, которая побуждает пользователей вновь и вновь обращаться к приложению

Есть множество способов поддерживать интерес пользователей к приложению UWP.

Использование уже знакомого языка

Приложения UWP могут использовать среду выполнения Windows, то есть собственный API, встроенный в операционную систему. Этот API реализован на языке C++ и поддерживается в C#, Visual Basic, C++ и JavaScript. Некоторые из языков и технологий, пригодных для написания приложений UWP:

Ссылки, которые помогут вам приступить к работе

Подготовка

Скачайте средства, необходимые для создания приложений, на странице Get set up (Подготовка), а затем создайте свое первое приложение.

Проектирование приложения

Корпорация Майкрософт предоставляет систему проектирования под названием Fluent. Fluent Design — это набор функций UWP в сочетании с рекомендациями по созданию приложений, которые будут прекрасно смотреться на всех типах устройств под управлением Windows. Разработанные с помощью Fluent приложения адаптируются к самым разным устройствам — от планшетов и ноутбуков до ПК и телевизоров, и даже к устройствам виртуальной реальности — и выглядят на них совершенно естественно. Вводные сведения о системе Fluent см. в статье The Fluent Design System for Windows app creators (Система проектирования Fluent для разработчиков приложений Windows).

Хорошее проектирование подразумевает принятие решений о том, как пользователи будут взаимодействовать с приложением, а также как оно будет выглядеть и функционировать. Взаимодействие с пользователем очень сильно повлияет на то, насколько люди будут довольны вашим приложением, так что не пренебрегайте этим шагом. Из статьи Проектирование и разработка приложений для Windows вы узнаете, с чего начинать проектирование универсального приложения для Windows. Сведения о проектировании приложений UWP, которыми будут довольны все пользователи, см. в руководстве по приложениям универсальной платформы Windows (UWP) для разработчиков. Прежде чем приступить к написанию кода, изучите вводную информацию об устройствах. Это поможет вам продумать взаимодействие с пользователем в приложении на устройствах любых форм-факторов, на которые вы ориентируетесь.

Помимо взаимодействия на разных устройствах, проектируйте приложение так, чтобы использовать все преимущества работы на разных устройствах. Например:

При разработке рабочего процесса учитывайте основы проектирования навигации для приложений UWP, чтобы поддерживать мобильные устройства, большие и маленькие экраны. Продумайте макет пользовательского интерфейса, который изменяется в соответствии с размером и разрешением экрана.

Подумайте, как вы реализуете прием нескольких типов ввода. Ознакомьтесь с руководством по взаимодействию, чтобы узнать, как пользователи могут взаимодействовать с вашим приложением с помощью Кортаны, службы «Речь», распознавания сенсорного ввода, сенсорной клавиатуры и других возможностей. Или ознакомьтесь с руководством по тексту и текстовому вводу, чтобы узнать больше о традиционных способах взаимодействия.

Добавление служб

Отправьте приложение в Store.

Центр партнеров позволяет централизованно управлять всеми приложениями и держать в одном месте все приложения для устройств Windows. См. статью Публикация приложений и игр для Windows, чтобы узнать, как отправлять приложения в Microsoft Store для публикации.

Новые возможности упрощают процессы, обеспечивая больший контроль с вашей стороны. Вы также найдете здесь подробные аналитические отчеты вместе с сведениями о выплатах, способами продвижения вашего приложения среди пользователей и многие другие сведения.

Подробные вводные сведения см. в статье Windows 10 — An Introduction to Building Windows Apps for Windows 10 Devices (Вводные сведения о создании приложений для Windows для устройств с Windows 10).

Более сложные темы

Сопоставление универсальной платформы Windows (UWP) и API времени выполнения Windows

Если вы разрабатываете приложение для универсальной платформы Windows (UWP), вам будет намного проще и удобнее считать термины «Универсальная платформа Windows» и «Среда выполнения Windows (WinRT)» почти синонимами. Но у вас есть возможность заглянуть «под капот» этих технологий и определить различия между концепциями. Если вам это интересно, то этот последний раздел написан именно для вас.

И, само собой, API-интерфейсы WinRT можно вызвать из приложения UWP. Модель приложения UWP создана на основе среды выполнения Windows. С технической точки зрения модель приложения UWP основана на CoreApplication, но некоторые подробности могут быть недоступны в зависимости от выбора языка программирования. Как описано в этом разделе, с точки зрения ценности платформа UWP предназначена для создания единого двоичного файла, который вы сможете при желании опубликовать в Microsoft Store и запустить на любых устройствах самых разных форм-факторов. Охват устройств для приложений UWP зависит от API среды выполнения Windows, которые может вызывать приложение или которые вы можете вызывать условно.

Мы надеемся, что смогли описать в этом разделе разницу между базовыми технологиями API среды выполнения Windows и механизмом и ценностью универсальной платформы Windows.

Источник

WPF, UWP, WinUI, MAUI, Windows App SDK

Вот уже года 3 Microsoft проводит «рефакторинг» в своём «королевстве». Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.

Windows API и Windows Runtime

Прежде чем начать разбираться с UI-фреймворками стоит сначала опуститься на уровень ниже, впрочем, без особых подробностей. В современной винде 2 основных API для работы приложений. Windows API (обычно сокращается до Win32) и Windows Runtime (WinRT). При разработке первый был ориентирован на язык С, и активно развивался вплоть до выхода Windows 8. Я не имею в виду, что этот API объявлен устаревшим, но все новые функции системы уже разрабатывются для WinRT. Хотя некоторые так же бекпортируются и в Win32. Приложения, которые работают через Win32 и используют его модель приложений и сервисов Microsoft называет классическими.

Ключевое: есть объектно-ориентированные метаданные, которые описывают публичный интерфейс библиотеки: поддерживаются базовые классы (числа, строки), асинхронность (async/await), события. Начиная с Windows 8 весь новый API — это COM, с которым можно взаимодействовать через данный протокол. Любой язык, который реализует языковую проекцию в WinRT (C++/WinRT, Rust/WinRT, Python/WinRT, С#/WinRT) может взаимодействовать с этим API, будто это нативная для языка библиотека. Компоненты WinRT могут быть написаны на любом их этих языков. Сам виндовый API написан при этом на C++.

Помимо объектно-ориентированности, новый API имеет версионирование, больший контроль доступа к вызовам. Некоторые системные вызовы могут делать только приложения определённых разработчиков, некоторые доступны по специальному ключу. Некоторые сокрыты весьма условно: если приложение попало на комп, оно может ими пользоваться. Но вот в Microsoft Store могут и не пустить.

Application Models

Два вышеописанных системных API в данный момент подразумевают две разных модели жизненного цикла приложений. Классическая модель — приложению можно почти всё, оно может залезть почти куда угодно, читать что угодно, прятать окна и свою деятельность. С одной стороны — это позволяет делать различные удобные штуки вроде Punto Switcher, или сворачивание в трей по закрытию окна (вопреки ожиданиям, это не стандартное поведение в Windows). С другой стороны, это развязывает руки любым троянам.

И это было одной из причин, почему для приложений, работающих с WinRT, за основу была взята модель из мобильных платформ — изолированные приложения с контролируемым системой жизненным циклом. Другой из озвученных причин является большая энергоэффективность мобильного подхода. Всё же значительное количество ПК — ноутбуки. Вылилось это в повсеместные ограничения, привязку времени жизни приложения и времени жизни его основного окна (пока-пока сворачивание в трей). А также сильные ограничения работы в фоновом режиме. На размен давались различные фоновые задачи, контролируемые системой, и легальные способы интеграции в систему (системные контракты, такие как Share UI). В Microsoft посчитали, что за неполные 9 лет за счет таких интеграций появилось около 40 возможных точек входа в приложение. В какой-то момент даже появилась возможность делать консольные приложения, работающие поверх WinRT.

Стоит так же отметить, что эти две модели не изолируют Win32 и WinRT API друг от друга. В UWP приложения всё так же можно подключать Win32-библотеки, пока это не открывает путь за пределы песочницы. Из Win32 можно дергать WinRT API, но для большей его части надо получить AppIdentity, до недавнего времени это означало, что приложение придётся запаковать и оно станет чуть более изолированным.

И, пожалуй, именно тут надо вспомнить про UWP (Universal Windows Platform). Технически это название для реализации Windows Runtime в Windows 10+. Дело в том, что Windows Runtime в телефонах и Windows Runtime в Windows 8 отличались настолько, что для них нужно было делать отдельные сборки приложений (даже для одной архитектуры процессора). С появлением Windows 10, ОС и рантайм допилили до того состояния, когда 1 сборка приложения может запускаться и на телефоне (тогда они ещё были), и на ПК. Так же к этому списку добавились XBox, IoT, Hololens и Teams (большая интерактивная «маркерная доска»)

На практике, под сокращением UWP часто понимают именно UWP-приложения.

UI-фреймворки

Наконец можно поговорить про UI-фреймворки. С Windows Forms и WPF многие знакомы. UI, работающий поверх Win32 API. Отличаются способом верстки UI (дизайнер или XAML) и способом отрисовки (GDI или DirectX). С появлением WinRT, эти фреймворки особо не развиваются, но из-за огромного количества легаси приложений, Microsoft вынуждена поддерживать их. Например, в последних выпусках десятки значительно улучшена поддержка HDPI для WinForms.

WinUI

WinUI достоин отдельного упоминания, так как он един в двух лицах.

WinUI 2.x — UI-библиотека для UWP-приложений, содержащая в себе новые, в том числе экспериментальные, контролы. А также, обеспечивающая совместимость со старыми версиями Windows 10 (аналог AndroidX)

WinUI 3.x — часть Windows App SDK. Фактически это и есть UI-фреймворк для UWP, только оторванный от жизненного цикла UWP-приложений.

Обе версии сейчас развиваются параллельно.

Project Reunion он же Windows App SDK

Собственно, посмотрев на это обилие фреймворков (ещё и ввязавшись зачем-то в ReactNative), и выслушав жалобы разработчиков, в мае 2020 Microsoft анонсировала объединение подходов. Разработчики Windows Forms и WPF хотят писать стильные/модные/молодёжные приложения, получить доступ к новому API (в том числе различным системным триггерам, которые бывают довольно удобны). UWP-разработчики хотят получить больший доступ к системе и более простые способы распространения приложения, так как сейчас мимо стора распространять приложение не просто.

Собственно, WinUI 3.x является частью решения. Берём графический фреймворк от UWP-приложений, насаживаем его на жизненный цикл классических приложений. И все счастливы.

На самом деле, все конечно сложнее. И что за монстр Франкенштейна в итоге получится мы узнаем уже в конце года. Впрочем начать знакомиться можно уже сегодня.

Так жив ли больной?

UWP, как подсистема винды, никуда не денется в ближайшее время. Это всё ещё основной вектор развития API системы. Для UWP-приложений, которые нацелены только на десктоп, уже настало время планировать портирование на Windows App SDK. Недавно выпущенная версия 0.8 уже допускается в Microsoft Store. Если же приложение должно работать и на других платформах (Xbox, Hololens и т. д.), то тут придется ждать следующего года. Но рано или поздно, таки придется переехать на Windows App SDK.

Касательно классических приложений, покуда вам не нужны новые фичи платформы (пуши, возможность поделиться в ваше приложение, новый богатый UI и т. п.), то делать в общем-то тоже ничего не надо.

Если писать новое приложение, то стоит оценить Windows App SDK в текущем его состоянии. И возможно писать на нём.

А как же MAUI?

MAUI — абстракция над нативными UI-фреймворками.

Собственно, на винде это будет абстракцией над WinUI. У Xamarin.Forms есть поддерживаемая сообществом реализация поверх WPF.

Аналогичным образом ReactNative for Windows так же является абстракцией поверх WinUI. На нем, кстати, написан магазин на Xbox.

Подытожим

UWP — название подмножества API Windows, но часто используется как сокращение для изолированных приложений, работающих на этом API.

WinUI — современный графический фреймворк для Windows

Windows App SDK — в перспективе, единый набор SDK для любых приложений на Windows, вне зависимости от языка, и с возможностью переключения между различными жизненными циклами приложений

Источник