What’s a Universal Windows Platform (UWP) app?

UWP is one of many ways to create client applications for Windows. UWP apps use WinRT APIs to provide powerful UI and advanced asynchronous features that are ideal for internet-connected devices.

To download the tools you need to start creating UWP apps, see Get set up, and then write your first app.

Where does UWP fit in the Microsoft development story?

UWP is one choice for creating apps that run on Windows 10 devices, and can be combined with other platforms. UWP apps can make use of Win32 APIs and .NET classes (see API Sets for UWP apps, Dlls for UWP apps, and .NET for UWP apps).

The Microsoft development story continues to evolve, and along with initiatives such as WinUI, MSIX, and Project Reunion, UWP is a powerful tool for creating client apps.

Features of a UWP app

• Secure: UWP apps declare which device resources and data they access. The user must authorize that access.
• Able to use a common API on all devices that run Windows 10.
• Able to use device specific capabilities and adapt the UI to different device screen sizes, resolutions, and DPI.
• Available from the Microsoft Store on all devices (or only those that you specify) that run on Windows 10. The Microsoft Store provides multiple ways to make money on your app.
• Able to be installed and uninstalled without risk to the machine or incurring «machine rot».
• Engaging: use live tiles, push notifications, and user activities that interact with Windows Timeline and Cortana’s Pick Up Where I Left Off, to engage users.
• Programmable in C#, C++, Visual Basic, and Javascript. For UI, use WinUI, XAML, HTML, or DirectX.

Let’s look at these in more detail.

Secure

UWP apps declare in their manifest the device capabilities they need such as access to the microphone, location, Webcam, USB devices, files, and so on. The user must acknowledge and authorize that access before the app is granted the capability.

A common API surface across all devices

WindowsВ 10 introduces the Universal Windows Platform (UWP), which provides a common app platform on every device that runs WindowsВ 10. The UWP core APIs are the same on all Windows devices. If your app only uses the core APIs, it will run on any WindowsВ 10 device no matter whether you are targeting a desktop PC, Xbox, Mixed-reality headset, and so on.

A UWP app written in C++ /WinRT or C++ /CX has access to the Win32 APIs that are part of the UWP. These Win32 APIs are implemented by all WindowsВ 10 devices.

Extension SDKs expose the unique capabilities of specific device types

If you target the universal APIs, then your app can run on all devices that run Windows 10. But if you want your UWP app to take advantage of device-specific APIs, then you can do that, too.

Extension SDKs let you call specialized APIs for different devices. For example, if your UWP app targets an IoT device, you can add the IoT extension SDK to your project to target features specific to IoT devices. For more information about adding extension SDKs, see the Extension SDKs section in Programming with extension SDKs.

You can write your app so that you expect it to run only on a particular type of device, and then limit its distribution from the Microsoft Store to just that type of device. Or, you can conditionally test for the presence of an API at runtime and adapt your app’s behavior accordingly. For more information, see the Writing code section in Programming with extension SDKs.

The following video provides a brief overview of device families and adaptive coding:

Adaptive controls and input

UI elements respond to the size and DPI of the screen the app is running on by adjusting their layout and scale. UWP apps work well with multiple types of input such as keyboard, mouse, touch, pen, and Xbox One controllers. If you need to further tailor your UI to a specific screen size or device, new layout panels and tooling help you design UI that can adapt to the different devices and form factors that your app may run on.

Windows helps you target your UI to multiple devices with the following features:

• Universal controls and layout panels help you to optimize your UI for the screen resolution of the device. For example, controls such as buttons and sliders automatically adapt to device screen size and DPI density. Layout panels help adjust the layout of content based on the size of the screen. Adaptive scaling adjusts to resolution and DPI differences across devices.
• Common input handling allows you to receive input through touch, a pen, a mouse, a keyboard, or a controller such as a Microsoft Xbox controller.
• Tooling that helps you to design UI that can adapt to different screen resolutions.

Some aspects of your app’s UI will automatically adapt across devices. Your app’s user-experience design, however, may need to adapt depending on the device the app is running on. For example, a photo app could adapt its UI when running on a small, handheld device to ensure that usage is ideal for single-handed use. When a photo app is running on a desktop computer, the UI should adapt to take advantage of the additional screen space.

There’s one store for all devices

A unified app store makes your app available on WindowsВ 10 devices such as PC, tablet, Xbox, HoloLens, Surface Hub, and Internet of Things (IoT) devices. You can submit your app to the store and make it available to all types of devices, or only those you choose. You submit and manage all your apps for Windows devices in one place. Have a C++ desktop app that you want to modernize with UWP features and sell in the Microsoft store? That’s okay, too.

UWP apps integrate with Application Insights for detailed telemetry and analytics—a crucial tool for understanding your users and improving your apps.

UWP apps can be packaged with MSIX and distributed via the Microsoft Store, or in other ways. MSIX allows apps to be updated no matter how they are distributed, see Update non-Store published app packages from your code.

Monetize your app

You can choose how you’ll monetize your app. There are a number of ways to make money with your app. All you need to do is choose the one that works best for you, for example:

• A paid download is the simplest option. Just name the price.
• Trials let users try your app before buying it, providing easier discoverability and conversion than the more traditional «freemium» options.
• Sale prices to incentivize users.
• In-app purchases.

Deliver relevant, real-time info to your users to keep them coming back

There are a variety of ways to keep users engaged with your UWP app:

• Live tiles and lock screen tiles that show contextually relevant and timely info from your app at a glance.
• Push notifications that bring real-time alerts to your user’s attention.
• User Activities allow users to pick up where they left off in your app, even across devices.
• The Action Center organizes notifications from your app.
• Background execution and triggers bring your app into action when the user needs it.
• Your app can use voice and Bluetooth LE devices to help users interact with the world around them.
• Integrate Cortana to add voice command capability to your app.

Use a language you already know

UWP apps use the Windows Runtime, the native API provided by the operating system. This API is implemented in C++ and is supported in C#, Visual Basic, C++, and JavaScript. Some options for writing UWP apps include:

• XAML UI and C#, VB, or C++
• DirectX UI and C++
• JavaScript and HTML
• WinUI

Links to help you get going

Get set up

Check out Get set up to download the tools you need to start creating apps, and then write your first app.

Design your app

The Microsoft design system is named Fluent. The Fluent Design System is a set of UWP features combined with best practices for creating apps that perform beautifully on all types of Windows-powered devices. Fluent experiences adapt and feel natural on devices from tablets to laptops, from PCs to televisions, and on virtual reality devices. See The Fluent Design System for UWP apps for an introduction to Fluent Design.

Good design is the process of deciding how users will interact with your app, in addition to how it will look and function. User experience plays a huge part in determining how happy people will be with your app, so don’t skimp on this step. Design basics introduces you to designing a Universal Windows app. See the Introduction to Universal Windows Platform (UWP) apps for designers for information on designing UWP apps that delight your users. Before you start coding, see the device primer to help you think through the interaction experience of using your app on all the different form factors you want to target.

In addition to interaction on different devices, plan your app to embrace the benefits of working across multiple devices. For example:

Design your workflow using Navigation design basics for UWP apps to accommodate mobile, small-screen, and large-screen devices. Lay out your user interface to respond to different screen sizes and resolutions.

Consider how you’ll accommodate multiple kinds of input. See the Guidelines for interactions to learn how users can interact with your app by using Cortana, Speech, Touch interactions, the Touch keyboard and more. Or, see the Guidelines for text and text input for more traditional interaction experiences.

Add services

• Use cloud services to sync across devices.
• Learn how to connect to web services to support your app experience.
• Include Push notifications and in-app purchases in your planning. These features should work across devices.

Submit your app to the Store

Partner Center lets you manage and submit all of your apps for Windows devices in one place. See Publish Windows apps and games to learn how to submit your apps for publication in the Microsoft Store.

New features simplify processes while giving you more control. You’ll also find detailed analytic reports combined payout details, ways to promote your app and engage with your customers, and much more.

More advanced topics

• Learn how to use User Activities so that user activity in your app appear in Windows Timeline and Cortana’s Pick Up Where I Left Off feature.
• Learn how to use Tiles, badges, and notifications for UWP apps.
• For the full list of Win32 APIs available to UWP apps, see API Sets for UWP apps and Dlls for UWP apps.
• See Universal Windows apps in .NET for an overview of writing .NET UWP apps.
• For a list of .NET types that you can use in a UWP app, see .NET for UWP apps
• Compiling apps with .NET Native
• Learn how to add modern experiences for Windows 10 users to your existing desktop app and distribute it in the Microsoft Store with the Desktop Bridge.

How the Universal Windows Platform relates to Windows Runtime APIs

If you’re building a Universal Windows Platform (UWP) app, then you can get a lot of mileage and convenience out of treating the terms «Universal Windows Platform (UWP)» and «Windows Runtime (WinRT)» as more or less synonymous. But it is possible to look under the covers of the technology, and determine just what the difference is between those ideas. If you’re curious about that, then this last section is for you.

The Windows Runtime, and WinRT APIs, are an evolution of Windows APIs. Originally, Windows was programmed via flat, C-style Win32 APIs. To those were added COM APIs (DirectX being a prominent example). Windows Forms, WPF, .NET, and managed languages brought their own way of writing Windows apps, and their own flavor of API technology. The Windows Runtime is, under the covers, the next stage of COM. At the actual application binary interface (ABI) layer, its roots in COM become visible. But the Windows Runtime was designed to be callable from a great range of different programming languages. And callable in a way that’s very natural to each of those languages. To this end, access to the Windows Runtime is made available via what are known as language projections. There is a Windows Runtime language projection into C#, into Visual Basic, into standard C++, into JavaScript, and so on. Furthermore, once packaged appropriately (see Desktop Bridge), you can call WinRT APIs from an app built in one of a great range of application models: Win32, .NET, WinForms, and WPF.

And, of course, you can call WinRT APIs from your UWP app. UWP is an application model built on top of the Windows Runtime. Technically, the UWP application model is based on CoreApplication, although that detail may be hidden from you, depending on your choice of programming language. As this topic has explained, from a value proposition point of view, the UWP lends itself to writing a single binary that can, should you choose, be published to the Microsoft Store and run on any one of a great range of device form factors. The device reach of your UWP app depends on the subset of Windows Runtime APIs that you limit your app to calling, or that you call conditionally.

Hopefully, this section has been successful in describing the difference between the technology underlying Windows Runtime APIs, and the mechanism and business value of the Universal Windows Platform.

Windows 10 SDK

The Windows 10 SDK (10.0.19041.0) for Windows 10, version 2004 provides the latest headers, libraries, metadata, and tools for building Windows 10 apps.

Use this SDK to build Universal Windows Platform (UWP) and Win32 applications for Windows 10, version 20H2 and previous Windows releases.

Windows 10, version 20H2 is a scoped set of features for select performance improvements and quality enhancements. Developers should be aware of this release, but no action is necessary at this time.

A new Windows SDK will not be issued to accompany this version of Windows because this release doesn’t introduce new APIs. That means there’s no need to modify your project files or target a new version of Windows, and you should continue to use the Windows 10 SDK for Windows 10, version 2004. When setting the target version for your Windows app, Windows 10 build 19041 is still the most recent target version.

Getting started

You can get the Windows 10 SDK in two ways: install it from this page by selecting the download link or by selecting “Windows 10 SDK (10.0.19041.0)” in the optional components of the Visual Studio 2019 Installer.

Before you install this SDK:

System requirements

The Windows SDK has the following minimum system requirements:

Supported operating systems

• Universal Windows Platform (UWP) app development
  • Windows 10 version 1507 or higher: Home, Professional, Education, and Enterprise (LTSB and S are not supported)
  • Windows Server 2019, Windows Server 2016 and Windows Server 2012 R2 (Command line only)

• Win32 app development
  • Windows 10 version 1507 or higher
  • Windows Server 2019, Windows Server 2016, and Windows Server 2012 R2 (Command line only)
  • Windows 8.1
  • Windows 7 SP1

(Not all tools are supported on earlier operating systems)

Hardware requirements

• 1.6 GHz or faster processor
• 1 GB of RAM
• 4 GB of available hard disk space

Additional SDK requirements

Installation on Windows 8.1 and earlier operating systems requires KB2999226. To install through Windows Update, make sure you install the latest recommended updates and patches from Microsoft Update before you install the Windows SDK.

What’s new

The Windows 10 SDK for Windows 10, version 2004 offers exciting new APIs and updated tools for developing your Windows applications. Learn more about the new features in Windows 10, version 2004.

To see the new APIs introduced with Windows 10, version 2004, see: What’s new in Windows 10 for developers, build 19041.

Removal of api-ms-win-net-isolation-l1-1-0.lib

In this release api-ms-win-net-isolation-l1-1-0.lib has been removed from the Windows SDK. Apps that were linking against api-ms-win-net-isolation-l1-1-0.lib can switch t OneCoreUAP.lib as a replacement.

Removal of irprops.lib

In this release irprops.lib has been removed from the Windows SDK. Apps that were linking against irprops.lib can switch to bthprops.lib as a drop-in replacement.

Removal of wuapicommon.h and wuapicommon.idl

In this release we have moved ENUM tagServerSelection from wuapicommon.h to wupai.h and removed the header. If you would like to use the ENUM tagServerSelection, you will need to include wuapi.h or wuapi.idl.

Windows 10 WinRT API Pack

The Windows 10 WinRT API Pack lets you add the latest Windows Runtime APIs support to your .NET Framework 4.5+ and .NET Core 3.0+ libraries and apps. To access the Windows 10 WinRT API Pack, see the Microsoft.Windows.SDK.Contracts nuget package.

Universal C Runtime (UCRT)

The printf family of functions now conforms with the IEEE 754 rounding rules when printing exactly representable floating-point numbers and will honor the rounding mode requested via calls to fesetround. Legacy behavior is available when linking with legacy_stdio_float_rounding.obj.

Tools

Windows App Certification Kit

In this release of the Windows SDK, several new APIs were added to the Supported APIs list in the App Certification Kit and Windows Store. If there are APIs in the supported list that appear greyed out or disabled in Visual Studio, you can make a small change to your source file, to access them. For more details, see this known issue.

In addition to adding APIs, the following changes have been made to the tests:

Updated tests:

• ValidateContentUriRules will be informational only. Test failures will be presented as warnings.

Removed tests

• WebView WinRT access test for web app
• PackageSizeCheck test for UWP apps
• SupportedApi test for Desktop Bridge apps
• AppContainerCheck test from BinScope for UWP apps
• ServiceWorker check for all app types

New tests

• High-DPI test. A new test for Desktop Bridge apps checks if the app uses DPI aware feature and warns if not specified. This test will encourage you to make your app per-monitor DPI aware. For details on DPI see High DPI Desktop Application Development on Windows.

Message Compiler (mc.exe)

Updates include:

• Now detects the Unicode byte order mark (BOM) in .mc files. If the .mc file starts with a UTF-8 BOM, it will be read as a UTF-8 file. Otherwise, if it starts with a UTF-16LE BOM, it will be read as a UTF-16LE file. If the -u parameter was specified, it will be read as a UTF-16LE file. Otherwise, it will be read using the current code page (CP_ACP).
• Now avoids one-definition-rule (ODR) problems in MC-generated C/C++ ETW helpers caused by conflicting configuration macros (e.g. when two .cpp files with conflicting definitions of MCGEN_EVENTWRITETRANSFER are linked into the same binary, the MC-generated ETW helpers will now respect the definition of MCGEN_EVENTWRITETRANSFER in each .cpp file instead of arbitrarily picking one or the other).

Windows Trace Preprocessor (tracewpp.exe)

Updates include:

• Now supports Unicode input (.ini, .tpl, and source code) files. Input files starting with a UTF-8 or UTF-16 byte order mark (BOM) will be read as Unicode. Input files that do not start with a BOM will be read using the current code page (CP_ACP). For backwards-compatibility, if the -UnicodeIgnore command-line parameter is specified, files starting with a UTF-16 BOM will be treated as empty.
• Now supports Unicode output (.tmh) files. By default, output files will be encoded using the current code page (CP_ACP). Use command-line parameters -cp:UTF-8 or -cp:UTF-16 to generate Unicode output files.
• Behavior change: tracewpp now converts all input text to Unicode, performs processing in Unicode, and converts output text to the specified output encoding. Earlier versions of tracewpp avoided Unicode conversions and performed text processing assuming a single-byte character set. This may lead to behavior changes in cases where the input files do not conform to the current code page. In cases where this is a problem, consider converting the input files to UTF-8 (with BOM) and/or using the -cp:UTF-8 command-line parameter to avoid encoding ambiguity.

TraceLoggingProvider.h

Updates include:

• Now avoids one-definition-rule (ODR) problems caused by conflicting configuration macros (e.g. when two .cpp files with conflicting definitions of TLG_EVENT_WRITE_TRANSFER are linked into the same binary, the TraceLoggingProvider.h helpers will now respect the definition of TLG_EVENT_WRITE_TRANSFER in each .cpp file instead of arbitrarily picking one or the other).
• In C++ code, the TraceLoggingWrite macro has been updated to enable better code sharing between similar events using variadic templates.

Signing your apps with Device Guard Signing

We are making it easier for you to sign your app. Device Guard signing is a Device Guard feature that is available in Microsoft Store for Business and Education. Signing allows enterprises to guarantee every app comes from a trusted source. Our goal is to make signing your MSIX package easier. See the documentation about Device Guard Signing.

Samples

Windows 10 app samples are now available through GitHub. You can browse the code on GitHub, clone a personal copy of the repository from Git, or download a zipped archive of all the samples. We welcome feedback, so feel free to open an issue within the repository if you have a problem or question. These samples are designed to run on desktop, mobile, and future devices that support the Universal Windows Platform (UWP).

Previous SDK versions

Previously released SDKs and emulators, including update details, can be found on the archive page.

API Light Up

When you use new APIs, consider writing your app to be adaptive so that it runs correctly on the widest array of Windows 10 devices. An adapative app «lights up» with new features wherever the devices and Windows version supports them, but otherwise offers only the functionality available on the detected platform version. For implementation details, see the Version adaptive code article.

Release notes & Known Issues

The Windows 10 SDK, Version 2004 SDK servicing update (released 12/16/2020) contains the following fixes. If you encounter these issues, we recommend that you update your version of the SDK as soon as possible to avoid them:

• Resolved unpredictable and hard to diagnose crashes when linking both umbrella libraries and native OS libraries (for example, onecoreuap.lib and kernel32.lib)
• Resolved issue that prevented AppVerifier from working
• Resolved issue that caused WACK to fail with “Task failed to enable HighVersionLie”

For known issues, see the winapi-sdk Q&A.

For new developer feature requests, submit through the Feedback Hub app under the category “Developer Platform/API.”

More resources

Downloads and tools

Get the latest editions of Visual Studio and Windows 10 development tools.

SDK archive

Find previous releases of the Window SDK and other tools.

Windows blog

Stay in touch with the latest SDK flights by subscribing to our blog.

Windows lifecycle fact sheet

Find the key dates for Windows release updates and end of support.