Edit

Windows App Development Frequently Asked Questions

This FAQ provides answers to common questions about Windows application development, including guidance on choosing the right framework for your projects. Topics covered include:

  • Getting started and the Windows app development landscape.
  • Native Windows-only app development with WinUI 3, Windows Presentation Foundation (WPF), and Windows Forms (WinForms).
  • Windows Software Development Kit (SDK) and Windows App SDK.
  • Targeting Windows as part of your cross-platform development strategy.
  • Hybrid and web app development with .NET MAUI, Blazor, and ASP.NET Core.
  • How to choose an approach while understanding Microsoft's investments.

Windows app development landscape

Where can I find a straightforward overview of Windows development technologies?

For an overview of today's options for Windows developers, watch the Windows Dev Chat episode Choosing your ideal dev platform, which discusses WinUI 3, .NET MAUI, React Native, Blazor, and Progressive Web Apps (PWAs). You can find other episodes in the Windows Dev Chat playlist.

You can also refer to the overview of app development options for Windows developers.

Why is client app development still crucial for modern digital transformation in the era of cloud services?

In the age of cloud services, client app development remains important for delivering responsive, meaningful interactions on user devices.

Here's why client apps matter:

  • Device reach: Client apps let you bring your application directly to users on their devices of choice.
  • Gateway to Intelligent Services: Client apps are often the first interaction users have with your services. They offer a rich, interactive interface that allows you to showcase intelligent features and differentiate your product from others.
  • Scalability with Cloud Integration: A well-integrated client app can sync effortlessly with backend cloud services, enabling real-time data access and seamless scalability as your user base grows.
  • Enhanced Productivity and User Loyalty: A thoughtfully designed app can enhance productivity and keep users engaged with your product or service over time.

Native Windows-only app development

What is the Windows App SDK?

The Windows App SDK provides independently serviced components for Windows desktop apps, including WinUI 3, app lifecycle, windowing, notifications, resources, and text APIs. It supports apps that run on Windows 10, version 1809 and later, subject to the support lifecycle of the Windows release and Windows App SDK version.

What's the difference between the Windows App SDK and the Windows SDK?

Both are software development kits (SDKs) that let you build Windows apps.

The Windows App SDK provides components that ship independently from Windows and work across supported Windows releases down to Windows 10, version 1809. It includes WinUI 3 and APIs for app lifecycle, windowing, notifications, resources, text, and other capabilities.

The Windows SDK provides headers, libraries, metadata, and tools for operating-system APIs such as Win32, WinRT, COM, DirectX, devices, and shell capabilities.

The Windows App SDK doesn't replace the Windows SDK. Apps that adopt the Windows App SDK can continue to use Windows SDK APIs, and WinUI 3 apps commonly use both.

I'm building a new team to develop a Windows-only app. Why should I choose to develop with a native Windows framework like WinUI 3, WPF, or WinForms?

Here are some reasons to choose a native Windows framework for your Windows-only app:

  • Performance: Native Windows frameworks are optimized to leverage modern Windows hardware, providing fast and responsive user experiences.
  • Integration: Windows ships with a wide variety of APIs that enable sophisticated experiences only available on Windows. Native frameworks provide deep integration with these features and APIs.
  • Native user experience: Native frameworks provide a consistent experience across Windows devices, ensuring that your app looks and works great everywhere.
  • Offline support: Native frameworks support offline scenarios, allowing apps to function even without internet connectivity.
  • Support and tooling: Microsoft maintains the native frameworks and provides current SDKs, documentation, debugging tools, and samples.
Which framework should I use to leverage Microsoft's latest investments in Windows app development?

If you're building a new general-purpose Windows desktop app, we recommend using WinUI 3. WinUI 3 is the native UI framework delivered with the Windows App SDK. It supports Windows desktop apps and provides access to current Fluent controls and Windows platform capabilities.

Can I use Windows App SDK / WinUI 3 in my existing Windows app?

Note that WinUI 3 (a UI framework) ships with the Windows App SDK (a Windows platform development framework).

You can migrate an app's UI to WinUI 3, or use WinUI XAML Islands to host Windows App SDK controls in a supported existing desktop host. Legacy system XAML Islands host UWP XAML controls and use different APIs.

Elements of the Windows App SDK can often be used in desktop apps, depending on how the existing app was built. UWP apps are not supported by Windows App SDK.

This means WPF/MFC/WinForms apps can use Windows App SDK APIs that are unrelated to WinUI 3. Examples include app lifecycle, windowing, and app notifications.

See Use the Windows App SDK in an existing project for more info.

Do I need to use Visual Studio to build WinUI 3 apps?

No. WinUI 3 XAML builds use MSBuild, but you can build with the .NET SDK and current WinUI 3 templates from the command line in another editor. See the command-line quickstart.

Visual Studio 2026 provides the richest integrated editing, debugging, profiling, and XAML Hot Reload experience. Use the workflow that matches your tooling requirements.

I get an "Unable to load DLL 'Microsoft.ui.xaml.dll'" error when running my app. How do I fix it?

This error usually occurs in unpackaged app scenarios where the Windows App SDK runtime hasn't been installed on the machine. Try the following:

  • If you're running a packaged app (the recommended default), ensure you're launching via Visual Studio with the MsixPackage launch profile selected (not the plain executable profile). The MSIX packaging step installs the required runtime components.
  • If you're running a framework-dependent unpackaged app, install the matching Windows App SDK runtime. A self-contained deployment includes its Windows App SDK dependencies.
  • Confirm that your project matches your deployment model. For a normal .NET unpackaged app, setting <WindowsPackageType>None</WindowsPackageType> enables Windows App SDK runtime auto-initialization. Use the bootstrapper API directly only when you need explicit control over dynamic dependency initialization.

See Deploy apps that use the Windows App SDK for more details on deployment requirements.

What is the difference between WinUI 3 and WinUI 2 for UWP?

WinUI 3 is Microsoft's current native UI framework for Windows desktop apps and is delivered as part of the Windows App SDK.

WinUI 2, also called WinUI for UWP, is a control and styling library for UWP apps. WinUI 2 and WinUI 3 use different XAML namespaces and aren't binary-compatible.

When I build an app using Windows App SDK and WinUI 3, am I building a "WinUI app"?

Yes. WinUI 3 app is the clearest term for an app whose UI uses WinUI 3 and the Windows App SDK. WinUI app is also commonly used when the context is unambiguous.

Can I incrementally update my UWP app with WinUI for UWP controls to WinUI 3 by gradually replacing the controls?

No. Windows App SDK can't be used in UWP apps, and WinUI for UWP can't be mixed with WinUI 3. See Migrate from UWP to the Windows App SDK.

How hard is it to migrate a UWP app to WinUI 3?

UWP and WinUI 3 share many XAML concepts, but migration isn't a direct namespace change. The cost depends primarily on:

  1. Project file and MSBuild customization: Migration effort varies depending on advanced MSBuild usage.
  2. .NET API migration: UWP apps using .NET Native can move to a currently supported .NET release with Native AOT. This modernization is separate from migrating the UI to WinUI 3.
  3. UI component libraries: Libraries must have versions targeting WinUI 3.
  4. Windowing and application-model APIs: UWP APIs tied to concepts such as CoreWindow, ApplicationView, or GetForCurrentView require Windows App SDK replacements or another desktop approach.
  5. C++ language projection: If the UWP app uses the superseded C++/CX projection, port that code to C++/WinRT.

For more info, see Migrate from UWP to the Windows App SDK and the UWP to Windows App SDK API mapping.

If I have an existing UWP app in the Store, can I publish a new packaged WinUI 3 app using the same identifiers?

Yes, upgraded apps can be published without updating the application identity. Users of the old version will be updated to the new version. This applies to desktop apps only. Xbox, HoloLens, and standard Surface Hub apps cannot migrate to WinUI 3.

How do I package or distribute my WinUI 3 app?

See Deployment overview.

Where can I find Windows App SDK migration guidance?

See Migrate from UWP to the Windows App SDK.

Do I need to use XAML markup if I want to use WinUI 3?

No. UI controls can be created in code. However, representing the UI in declarative XAML markup provides many benefits, including an improved developer experience.

  • Migrating from UWP to WinUI 3: Many XAML and UI concepts carry over, but the namespaces, project model, and some APIs differ.
  • Migrating from WPF to WinUI 3: Many concepts carry over, but the control set and APIs differ.
Does Visual Studio have a design surface or UI designer for WinUI 3?

Not currently. Use XAML Hot Reload, Live Visual Tree, Live Property Explorer, and related runtime tools to inspect and update XAML while the app runs.

For a complete walkthrough of the runtime design tools available for WinUI 3, see XAML runtime design tools for WinUI 3.

Does Windows App SDK include WinUI 3?

Yes. WinUI 3 ships as part of the Windows App SDK.

Does Windows App SDK include WinUI for UWP?

No. WinUI for UWP is part of the UWP platform.

Are WinUI for UWP and WinUI 3 built on the same technology?

Not quite. Although WinUI 3 started from the WinUI for UWP codebase, they are distinct technologies. Both are XAML-based UI frameworks that work across .NET and C++, but WinUI for UWP and WinUI 3 aren't compatible with each other.

Can I use WinUI 3 without using Windows App SDK?

No. WinUI 3 ships as part of the Windows App SDK.

Can I use WinUI 3 in an unpackaged app?

Yes. WinUI 3 and many Windows App SDK APIs work in unpackaged apps. However, some Windows capabilities require package identity, and framework-dependent unpackaged apps must initialize the Windows App SDK runtime. Compare the options in Packaging overview and Features that require package identity.

What's the difference between XAML Islands and WinUI 3?

WinUI 3 is the UI framework included in the Windows App SDK. XAML Islands are a hosting technique that lets an existing desktop app place XAML content alongside UI from another framework.

The term can refer to legacy system XAML Islands that host UWP XAML controls, or to WinUI XAML Islands that host Windows App SDK controls in supported desktop hosts. The APIs, namespaces, and host requirements differ.

If I create a WinUI 3 app, will it look modern on both Windows 11 and Windows 10?

WinUI 3 controls use Fluent styling on supported versions of Windows 10 and Windows 11, in both packaged and unpackaged apps. Some operating-system effects and behaviors differ by Windows version. For example, Mica is available on Windows 11 and falls back to a solid color on Windows 10.

Can I use Mica or Acrylic backgrounds in apps built with Windows App SDK?

Yes. Desktop Acrylic is supported on Windows 10, version 1809 and later. Mica requires Windows 11 and falls back to a solid theme color on Windows 10. Call MicaController.IsSupported or DesktopAcrylicController.IsSupported at run time before applying a backdrop. See Apply Mica or Acrylic materials in desktop apps for Windows 11.

Where can I find WinUI 3 samples?

See Sample and resources. Some notable repositories:

If I have already invested heavily in WPF, should I continue to use WPF or consider migrating to WinUI 3?

If you've already invested heavily in WPF, you can continue using it for existing apps. WPF is a mature, stable framework widely used to build Windows desktop apps.

Use GitHub Copilot upgrade to assess and upgrade a .NET Framework WPF app to modern .NET. Review the generated plan and validate each change in your app.

If I build a new WPF app, will it look dated compared to other new Windows apps?

When developing a WPF application with .NET 9 or later, you can ensure your app matches the sleek, modern look of Windows 11. The new Fluent theme for WPF introduces a contemporary Windows 11 aesthetic, with integrated Light/Dark mode and system accent color support. This modernizes your app’s appearance and delivers a polished, cohesive user experience.

My team is comfortable building WinForms apps, and it suits our needs. Should we consider migrating to WinUI 3 or another framework?

If WinForms meets your needs and your team is comfortable with it, you can continue using WinForms for existing apps. WinForms is a mature and stable framework widely used for Windows desktop development.

The WinForms team continues to invest in the platform. Recent and ongoing work includes:

  • Asynchronous form and dialog APIs
  • Dark mode and visual-style support
  • Accessibility, high-DPI, layout, and designer improvements
  • Clipboard and DataObject modernization

Cross-platform native development

What are some reasons for building cross-platform, native apps that target Windows?

If you're targeting users across multiple OS platforms, building cross-platform apps with .NET MAUI or React Native can offer several benefits:

  • Reach: Cross-platform apps reach a larger audience across different devices and operating systems.
  • Code reuse: Reusing code across platforms reduces development time and cost. Building separate apps for Windows, Android, iOS, and macOS can be prohibitively expensive.
  • Consistent user experience: Cross-platform frameworks help provide a consistent look and feel across platforms.
  • Integration: Cross-platform apps can still integrate with platform-specific services to deliver a comprehensive experience.
Can I be confident that .NET MAUI apps will run well on Windows?

When you build a .NET MAUI app for Windows, the output uses WinUI 3. During development, .NET MAUI offers a single .NET experience across platforms, but it generates platform-specific code under the hood.

How can .NET MAUI provide native device APIs across every platform?

.NET MAUI provides a unified .NET experience across Windows, iOS, Android, and macOS. It offers cross-platform APIs for common capabilities such as storage, networking, and device sensors. You can also call platform-specific APIs or provide specialized implementations for each platform.

Can I start with WinUI 3, and later integrate .NET MAUI if I eventually want to target cross-platform scenarios?

Not at this time. Although .NET MAUI uses WinUI 3 when running on Windows, teams expecting to target multiple platforms should start with .NET MAUI or React Native for Desktop.

Our team has strong web front-end development skills. Should we consider using React Native for Desktop?

Teams with strong web development experience may want to consider React Native for Desktop. It includes React Native for Windows and macOS. With the “Learn once, write anywhere” approach, existing JavaScript, TypeScript, and React skills can be used to build native Windows and macOS apps.

React Native for Desktop renders UI directly to native primitives, delivering native performance and platform capabilities.

See the React Native for Desktop documentation to get started.

Are any other Windows devices supported by React Native for Desktop?

React Native for Windows supports the Windows versions listed in its compatibility documentation. Verify device-family support for the React Native for Windows version you target rather than assuming that every Windows device is supported.

What should I use if I want to build apps that work on Windows and Xbox?

For an Xbox app, use UWP and account for the Xbox-specific UWP limitations. For game development, use the Microsoft Game Development Kit.

What should I use if I want to build apps that work on Windows and Surface Hub?

For a Surface Hub running the standard Teams Rooms or Surface Hub environment, use a UWP app that meets the Surface Hub app requirements. A Surface Hub 3 configured with Windows 11 Pro or Enterprise can run supported desktop app technologies, so UWP isn't the only option in that configuration.

Hybrid and web development

What are hybrid apps, and why should I consider building one?

Hybrid apps blend the best of web and native app development. Their core is built using web technologies like HTML, CSS, and JavaScript, and wrapped in a native container that gives access to certain native platform features and hardware. They can also be distributed through app stores.

The main advantage is that hybrid apps allow you to build a single app that can run on multiple native platforms and on the web, reducing development time and cost. Examples of hybrid app development platforms include:

  • Electron for desktop apps
  • Ionic for mobile apps
  • .NET MAUI Blazor Hybrid for cross-platform apps
How do I build native-feeling progressive web apps (PWAs) on Windows?

See Web development on Windows and Overview of Progressive Web Apps.

What is a .NET MAUI Blazor hybrid app?

With .NET MAUI, Blazor apps can run natively on Windows, iOS, Android, and macOS. This allows you to create hybrid client apps that combine Blazor and .NET MAUI components in a single native client app, with full access to native platform capabilities.

Learn more at ASP.NET Core Blazor Hybrid.

Do the web components of a .NET MAUI hybrid app need to be created with Blazor?

No. Starting with .NET 9, .NET MAUI includes a HybridWebView control that allows hosting other JavaScript-based UIs inside a native app.

This allows you to host Angular, React, Vue, or other HTML/JavaScript apps inside a .NET MAUI app. The hybrid control provides interop between C# and JavaScript, so C# code can call JavaScript functions and vice versa.

Can any other native app types host Blazor hybrid components?

Yes. WPF and WinForms apps can also host Blazor hybrid components, enabling the addition of modern web UI to existing apps. This is not supported for WPF or WinForms apps built on .NET Framework.

Does my entire app need to be a hybrid app, or can I mix and match native and hybrid components?

Native and hybrid components can be mixed within an app. For example, the core of an app may be built with .NET MAUI components while hybrid components provide additional functionality. This allows combining the performance and capabilities of native components with the flexibility and cost efficiency of hybrid components.

What are my choices for building .NET-based web apps that look great on modern browsers on Windows?

Web apps offer the broadest reach of any client app platform. Options for creating beautiful .NET web apps include:

  • ASP.NET Core apps with Razor Pages
  • ASP.NET Core MVC apps
  • ASP.NET Core Blazor apps, with hosting model options:
    • Blazor WebAssembly
    • Blazor Server

Blazor hosting models can now be configured at the component level, enabling scenarios like hosting a Blazor WebAssembly component within a Blazor Server app.

See the ASP.NET Core documentation for more details.

Choose an approach and understand Microsoft's investments

There are so many framework options for building apps that target Windows! How do I decide?

Windows is an open platform that supports many technologies. Here are some criteria that can help you choose a platform:

  • Are you building Windows-first or cross-platform?
  • What languages or skills do you already have — .NET, JavaScript, something else?
  • Do you need access to Windows-specific APIs?
  • Which framework’s capabilities best match your app’s requirements?
  • See this table for additional comparison factors.

For many business apps, teams often choose based on existing skills and what the team is most comfortable using.

How do I choose the best development approach for my web app?

Consider the following when choosing a development approach for your web app:

  • Blazor is recommended for building front-end web apps with .NET. It lets you build both the front-end and back-end using .NET, saving time and cost, and it’s especially good for enterprise apps.
  • JavaScript web apps still make sense if you want to leverage existing JavaScript skills or need to integrate with established JS libraries or frameworks.
  • Existing apps using older frameworks like Web Forms, MVC, or Razor Pages remain supported and can continue to be developed and maintained.
Who is building apps with WinUI 3 today?

Microsoft Photos is one documented example. The app migrated from UWP to the Windows App SDK and continues to use WinUI 3. For details about the architecture and migration, see Microsoft Photos: Migrating from UWP to Windows App SDK.

Who is building .NET MAUI apps today?

Organizations use .NET MAUI to build cross-platform apps for Android, iOS, macOS, and Windows. See examples in the .NET customer showcase.

Who is building WPF apps today?

Most of the Microsoft Visual Studio UI is built with WPF. The Visual Studio IDE itself is a major example of a complex, high-performance WPF app.

Who is building Blazor apps today?

GE Digital’s FlightPulse airline system uses Blazor for the backend configuration of everything pilots see, bringing sensor data and analytics directly to pilots to improve safety and efficiency.

See more Blazor customer stories on the .NET site.

Language choice (.NET vs C++)

Should I use C# or C++ for my Windows app?

Use C# (.NET) in most cases. C# offers faster development, memory safety, rich libraries, and excellent tooling. Most Windows apps — including WinUI 3, WPF, WinForms, and .NET MAUI apps — are best built with C#.

Use C++ when you need direct hardware access, minimal runtime overhead, or interop with existing C++ codebases. Common C++ scenarios include game engines (DirectX), drivers, system-level utilities, and performance-critical components.

Factor C# (.NET) C++
Development speed ✅ Faster — managed memory, rich ecosystem ⚠️ Slower — manual resource management
Runtime performance ✅ Excellent with modern .NET (AOT, Span<T>) ✅ Best possible — no GC pauses
Memory safety ✅ Garbage-collected ⚠️ Manual — risk of leaks and vulnerabilities
Windows API access ✅ Via C#/WinRT projection ✅ Via C++/WinRT projection
WinUI 3 support ✅ Full support ✅ Full support via C++/WinRT
Cross-platform ✅ .NET runs on Windows, Linux, macOS ✅ With platform-specific code
Best for Business apps, CRUD, services, UI-heavy apps Games, drivers, system tools, low-latency

You can also mix both: build your app in C# and call performance-critical native code via P/Invoke (CsWin32) or a C++/WinRT component.

How do I call Win32 APIs from C#?

Use CsWin32, a source generator that creates type-safe P/Invoke signatures at build time. You add the Microsoft.Windows.CsWin32 NuGet package, list the APIs you need in a NativeMethods.txt file, and call them through a generated PInvoke class.

CsWin32 replaces hand-written [DllImport] declarations and works in any C# project, including WinUI 3, WPF, WinForms, and console apps. See Call Win32 APIs from a C# Windows app (CsWin32) for a step-by-step walkthrough.

What is C++/WinRT and when should I use it?

C++/WinRT is a standard C++17 language projection for Windows Runtime APIs. Use it when building Windows apps in C++ that consume or author WinRT APIs. It replaces C++/CX and the Windows Runtime C++ Template Library (WRL).

Choose C++/WinRT when:

  • You're building a C++ WinUI 3 app
  • You need to author Windows Runtime components consumed by other languages
  • You're porting from C++/CX
What is C#/WinRT and when do I need it?

C#/WinRT provides WinRT projection support for C#. In most cases you don't interact with it directly — .NET apps targeting Windows automatically get access to WinRT APIs through target framework monikers (TFMs). You need C#/WinRT explicitly when authoring Windows Runtime components in C# or when generating interop assemblies for third-party WinRT components.

Packaging, deployment, and updates

What's the difference between apps that are packaged, unpackaged, and packaged with external location?

A packaged app contains its files, identity, and deployment information in a package such as MSIX. An unpackaged app uses an installer or deployment process outside the Windows package system and doesn't have package identity by default. An app packaged with external location uses a small identity package while retaining externally located binaries and its existing installer and update process.

See Packaging overview for requirements and tradeoffs.

Do I need package identity?

It depends on the Windows features your app uses. Package identity is required for scenarios such as packaged background tasks, share targets, startup tasks, custom context-menu package extensions, manifest-based file-type and protocol associations, and many Windows AI APIs. Windows App SDK push notifications support limited foreground scenarios without identity, but background delivery and COM activation require identity. WinUI 3 and local app notifications can work without package identity.

See Features that require package identity. If you need identity but must retain an existing installer, consider packaging with external location.

What's the difference between framework-dependent and self-contained deployment?

A framework-dependent app uses Windows App SDK runtime packages installed separately on the device. This reduces the app's deployment size and lets the installed framework receive servicing updates. A self-contained app carries its Windows App SDK dependencies with it, which increases deployment size and makes the app publisher responsible for distributing Windows App SDK servicing updates with new app versions.

APIs that depend on additional MSIX packages, such as the Singleton package, can require separate deployment or runtime support checks even in a self-contained app. Packaging and runtime deployment are separate decisions. See Windows App SDK deployment overview.

Will my WinUI 3 app automatically update for end-users?

A WinUI 3 app can be delivered through the Microsoft Store, an .appinstaller file, or an MSI or setup executable. Store packages can be updated through Microsoft Store servicing, subject to Store and organizational settings. An .appinstaller deployment supports automatic updates only when its UpdateSettings configure launch-time or background checks. MSI and setup deployments must provide or integrate their own update mechanism.

Can I use Windows App SDK without using MSBuild?

Yes, for some scenarios. WinUI 3 XAML projects currently require MSBuild, although Visual Studio isn't required and dotnet build can invoke MSBuild from the command line. You can use non-XAML Windows App SDK APIs from C++ and CMake projects through the preview Windows App Development CLI, or integrate the runtime manually.

Windows AI

How do I choose between Windows AI APIs, Foundry Local, and Windows ML?

The first three technologies are part of Microsoft Foundry on Windows. You can combine them with each other and with cloud models in the same app:

  • Use Windows AI APIs for ready-to-use capabilities whose models and hardware acceleration Windows manages.
  • Use Foundry Local to discover, download, and run supported open-source language and speech models locally.
  • Use Windows ML to run your own ONNX models with execution providers for available CPU, GPU, and NPU hardware.
  • Use Microsoft Foundry, a separate cloud AI platform, when you need cloud-hosted models, retrieval, centralized governance, or capabilities that aren't available on the target device.

Compare the options in Choose your Windows AI solution. Consider model capability, privacy, connectivity, latency, hardware coverage, deployment size, and operating cost.

Do Windows AI features require a Copilot+ PC?

Not all of them. Many Windows AI APIs require a Copilot+ PC, but some APIs also support specific GPUs or CPUs. Foundry Local and Windows ML support broader hardware configurations, subject to their current operating-system, model, runtime, and execution-provider requirements.

Check the Windows AI API hardware table and the requirements for the specific API or model. Detect support and model readiness at run time, and provide a non-AI, local-model, or cloud fallback when the feature is unavailable.

Can Windows AI features run locally and offline?

Yes. Windows AI APIs, Foundry Local, and Windows ML can run inference on the user's device, which can reduce latency and keep input data local. Some models or execution providers must first be downloaded or provisioned and can require an internet connection during setup or servicing. Cloud AI services require connectivity and send data to the service according to its data-handling terms.

Tell users when a model download is required and when data leaves the device. Don't describe a feature as offline-capable until you've tested its complete first-run, update, and fallback experience.

Can AI tools help me build or modernize a Windows app?

Yes. AI coding agents can help scaffold projects, explain APIs, migrate code, generate tests, and diagnose build problems. Use the AI-assisted Windows development guidance for GitHub Copilot, the WinUI agent plugin, the Microsoft Learn MCP Server, migration workflows, and AI-assisted testing.

Review and test generated code as you would any other contribution. In particular, verify API names and versions, package capabilities, security-sensitive code, accessibility, and any UWP-to-WinUI 3 substitutions.

What should I consider before shipping an AI-assisted feature?

Define the feature's intended use and limitations, evaluate quality and safety with representative data, disclose AI behavior where appropriate, protect user data, and provide a fallback when the model or required hardware isn't available. Keep secrets and privileged service credentials out of client apps, and require user confirmation before consequential or irreversible actions. See Responsible generative AI development on Windows and Security and responsible AI for Windows development.

Performance and optimization

What can I do to make my Windows app feel great to end-users?

See Windows application development - Best practices and Windows app performance and fundamentals overview.

Compatibility

Will my users ever have to update Windows to use my WinUI 3 app?

The Windows App SDK has a minimum compatible OS of Windows 10, version 1809, build 17763. Microsoft support requires a supported Windows App SDK release with its latest servicing update and a Windows edition, version, and servicing channel that is still supported. Individual APIs can require a newer Windows version or specific hardware. See Windows App SDK support and Release channels.

Can I target Arm64 with my WinUI 3 app?

Yes. Build a native Arm64 app for the best performance and efficiency. For a large C++ codebase with x64 dependencies, Arm64EC lets you migrate modules incrementally. Windows 11 on Arm can also run many existing x86 and x64 apps through Prism emulation, but you should test performance and compatibility on representative Arm devices.

Deprecations and migrations

Are UWP / WinUI for UWP deprecated?

UWP and WinUI 2 aren't formally deprecated. Visual Studio 2026 supports UWP with modern .NET and Native AOT, while WinUI 2.8 remains the latest stable WinUI release for UWP. However, Microsoft recommends WinUI 3 and the Windows App SDK for new general-purpose Windows desktop apps.

UWP support for modern .NET with Native AOT is generally available and is the default C# UWP project type in Visual Studio 2026. Moving an existing UWP app from .NET Native to modern .NET is a separate modernization step from migrating its UI to WinUI 3. See Modernize your UWP app with .NET and Native AOT.

When should I migrate a UWP / WinUI for UWP app to WinUI 3?

UWP developers should not feel pressured to migrate if they are satisfied with UWP and its feature set — for many apps, the right choice may be to stay on UWP.

Apps that want to benefit from the latest Windows platform and .NET investments should consider moving to WinUI 3 and the Windows App SDK. See Migrate from UWP to the Windows App SDK.

When should I *not* migrate a UWP + WinUI for UWP app to WinUI 3?

Continue using UWP when your target device or app model requires it, such as Xbox apps, HoloLens 2D apps, or apps for the standard Surface Hub environment. Windows IoT Enterprise supports desktop app technologies, including the Windows App SDK, so an IoT target isn't by itself a reason to use UWP.

Is WPF deprecated?

No. WPF is supported and continues to receive feature, performance, accessibility, and Fluent-style improvements in modern .NET. It remains a good choice for existing WPF apps and for new apps whose requirements fit WPF. For new general-purpose Windows desktop apps, Microsoft's primary recommendation is WinUI 3 with the Windows App SDK. See the WPF roadmap on GitHub.

Is WinForms deprecated?

No. WinForms is supported and continues to receive feature updates. See the Windows Forms Roadmap on GitHub.

Is the Windows Runtime (WinRT) deprecated?

No. WinRT is an application binary interface (ABI) that enables interop across multiple languages. WinRT is the evolution of COM, and the Windows App SDK provides most of its functionality through WinRT APIs.

Release notes

Where can I find release notes for Windows App SDK?

See the Windows App SDK release notes for stable, preview, and experimental releases. The What's new for Windows developers page summarizes the latest Windows SDK, Windows App SDK, WinUI 3, tooling, and platform updates.

Related content

  • Last updated on