Skip to main content

What exactly IS a Universal Windows Platform (UWP) app?

Writing about technology is often a balancing act. Some people want general tech news, while others want deep dives. When it comes to software and OS development, as a non-programmer I often find myself in over my head. That's why UWP is such a steamy mess to talk about for the "prosumer."

Today, I'm going to chip away at this monolith of a topic.

Who is UWP even for?

Before I try to explain what Microsoft's software development platform is for Windows 10, let's just get this out of the way: The term "UWP" is not a consumer-facing one, it's for developers.

At no point should a customer walk into Best Buy and inquire with the sales clerk about what UWP apps a PC can run. In fact, a rule of thumb in technology is if you must explain something to someone the product probably already failed.

On Windows Central, however, we jump back and forth between consumer news and how-tos and more informative articles discussing Microsoft's technology, OS development, and general computing trends. In our reporting, we must talk about UWP to understand Windows 10. For non-pro consumers, however, it should be simpler.

'Universal' does not mean run-everywhere

On a technical level, UWP is Microsoft's extension of the Windows Runtime platform that leverages the C++, C#, VB.NET, and XAML coding languages. There are a few main ideas behind UWP, which include:

  • Universal API toolkit.
  • Responsive design and scaling in apps.
  • Universal controls, styles, input, and interactions.
  • Cloud, A.I., and cognitive services.
  • Single Store for distribution.
  • One Software Development Kit (SDK).

The confusing bit for our audience is the "universal" in "Universal Windows Platform." While the goal for UWP is to let developers share code between apps and utilize a broad swath of APIs, it does not necessarily mean that a UWP app is supposed to "run everywhere," such as on phones, PCs, Xbox, HoloLens, IoT devices.

Ideally, an app developer will write a native UWP app that just works across all Windows 10 devices, but sometimes that just doesn't make sense. For example, certain phone-only apps have little value on the desktop. Some UWP games could be too resource intensive for a phone, or the benefit of running a map app on your Xbox may not be self-evident (even if it is available, it's likely not used often).

The "universal" in UWP refers to the shared APIs and resources that developers have access to when writing an app, not the app's hardware destination. I can't stress this enough. Just because an app is only available on Xbox or can only be installed on Windows 10 Mobile does not mean it's not UWP or even "true UWP," which has no technical definition.

Windows Bridge apps are UWP too

To add to the confusion, Microsoft introduced Windows Bridges a few years back during its Build developer conference.

All you need to know is that an app that takes advantage of Windows Desktop Bridge (a.k.a. Project Centennial), Progressive Web Apps (Project Westminster) like LinkedIn, or Windows iOS Bridge (a.k.a. Project Islandwood) is a UWP app too.

Getting more technical, a Windows Bridge app is best thought of as a hybrid app. For instance, Adobe Photoshop Elements 15 and the new Spotify apps are classic Win32 desktop apps literally wrapped in a UWP appx file container.

If you're not a developer this is probably confusing.

If you're not a developer this is probably confusing.

It's not just the wrapper or installer that makes it UWP, but rather it is how a Desktop Bridge app can leverage Windows 10-only features like:

  • Cortana.
  • Live tiles.
  • Action and Notification Center.
  • Share targets.
  • UWP background tasks.
  • UWP XAML user experience.
  • UWP app services e.g. cloud, A.I., and cognitive.
  • Automatic updates, licensing, in-app purchases and all Windows Store features.

Therefore, desktop bridge apps are really hybrid-UWP ones. To the OS, however, they're just UWP since it is those features that are most prominent.

Those Desktop Bridge apps also behave like non-hybrid "native" UWP apps. They do not modify the system registry and are essentially sandboxed from the OS to ensure one-click uninstallation with no orphaned DLL files in the Windows System directory.

It might be easier to think of it as a slider. On the left, you have Win32 apps that use one or two UWP APIs, and on the right, you have apps that use only UWP APIs. An app that only uses UWP APIs are "true UWP" apps can run across different versions of Windows 10 with only one codebase.

An app that uses one or two UWP APIs is likely a Win32 app that taps into UWP features and functions. A developer is able to slowly convert its app to a true UWP app over time if it wants, slowly moving from left to right on that imaginary "UWP" slider.

The curious case of Spotify and UWPness

When talking about Microsoft's UWP, the Spotify example is a great one to highlight the weird choices that companies can make with its apps.

There are technically four Windows-type Spotify apps:

  • Spotify Win32 .exe installer.
  • Spotify for Windows Phone 8.1.
  • Spotify for Windows 10 (UWP).
  • Spotify for Xbox One (UWP).

The last two are the newest and are UWP even though they are vastly different. The Spotify app for Windows 10 is just the Win32 .exe desktop version repackaged using the Desktop Bridge. However, as noted above, bridge apps are still considered UWP.

The new Xbox One Spotify app is also UWP. Some have taken umbrage with the term since that app is not available for Windows 10 PCs or Mobile (although, technically, you could side-load it if it were signed).

Spotify on Xbox One is very different from everything else but still UWP.

Spotify on Xbox One is very different from everything else but still UWP.

So why did Spotify create so many apps instead of just one "native" UWP app that could run on Mobile, PC, and Xbox?

I have no idea.

But it doesn't matter. The UWP platform and its bridges are all about giving developers various routes to one place: the Windows Store. How they get there, or how many versions of the app exist, is inconsequential. Microsoft would prefer developers just to use the same code with a single app, but the company does not dictate such practice. In the end, it is up to developers to choose the best route.

For now, Spotify deemed a desktop bridge app for Windows 10 PCs as the best way to the Windows Store while a separate Xbox One app is the top solution for that platform.

UWP is a work in progress

The UWP is not finalized, nor will it ever be for developers. UWP is the future of Windows 10 app development that – someday – will supplant Win32. Nonetheless, Win32 has been around for 20 years, and you cannot recreate a developer platform in a year.

Some UWP games in the Windows Store.

Some UWP games in the Windows Store.

The point here is that UWP as is is far from perfect or feature complete. Thousands of APIs are needed to bridge Win32 app calls and features to the world of native UWP. Microsoft is prioritizing where it can, but it's like a wartime hospital where triaging the patients is necessary.

One reason some companies do not put their apps in the Windows Store – even with the desktop bridge – is today's tools do not make it possible. If your app uses a custom API or makes a weird system call that UWP does not yet support, well, the desktop bridge does not work.

Anything in the Windows Store is UWP

For now, the only definition that Microsoft and Windows watchers need for UWP is this: If the app is in the Windows Store it is technically UWP. If you want to get specific (opens in new tab):

Windows 10 introduces UWP, which provides a common app platform available on every device that runs Windows 10. The UWP provides a guaranteed core API across devices. This means you can create a single app package that can be installed onto a wide range of devices. And, with that single app package, the Windows Store provides a unified distribution channel to reach all the device types your app can run on. Apps that target the UWP can call not only the WinRT APIs that are common to all devices but also APIs (including Win32 and .NET APIs) that are specific to the class of device that the app is running on.

While Microsoft's intent is for a UWP to run across types of devices it's not all there just yet, nor is Microsoft forcing companies down that path.

If the app or game is in here it's UWP.

If the app or game is in here it's UWP.

The confusion here is also due to Microsoft, which has a lousy history of naming schemes. Many developers and even people at Microsoft have a tough time defining what UWP is and is not.

I can also add the caveat that websites can technically host UWP appx files, which would still make them UWP even if not in the Store. Although rare, these and apps that only target Windows Phone 8.x are the exceptions to the Windows Store rule.

Regular consumers have no idea what UWP is or is supposed to mean, nor should they. The customer experience is intended to be simple. Turn on a Windows 10 device, go to Windows Store, search, find, and install the app. How the app got there, or whether it's technically an Electron app or React Native or it leverages the UWP JavaScript container, is entirely inconsequential.

Microsoft is trying hard to make the Windows Store and the apps therein device-universal, but it's not quite there yet. UWP is a journey for Microsoft and it is just starting but all paths eventually lead to one destination: the Windows Store.

Further reading about UWP

Here are a few more deep dives and discussion articles about Windows 10, UWP, and the future of the platform:

Daniel Rubino
Executive Editor

Daniel Rubino is the Executive Editor of Windows Central, head reviewer, podcast co-host, and analyst. He has been covering Microsoft here since 2007, back when this site was called WMExperts (and later Windows Phone Central). His interests include Windows, Microsoft Surface, laptops, next-gen computing, and arguing with people on the internet.

  • This one of those articles that I've been sitting on for awhile. In truth, I could have doubled the length as I glossed over a lot of technical details, side discussions and more. I may revisit some of those topics later and if you folks have some ideas, or other areas related to UWP that could use some Dan'splaning, let me know. Also, it would be greatly appreciated if you can share/reference this article anytime a UWP-debate pops up on comments, forums, Twitter, etc. My goal here is to help educate and explain some technical stuff for folks like you who may not be devs, but are still interested in the ins and outs of Windows 10. The more we get the right info out there the more I can focus on covering other topics ;)
  • Dansplaining... Epic!
  • Rescinded
  • So, you're just wrong then by Microsoft's own writings going back to 2015 and what developers understand. Your argument literally boils down to: I don't want to believe this, I have my own definition. That's not how this works and you don't get to do that. You can't even be bothered to argue on a technical level, it's just conjecture.
    "None of your readers here believe this."
    You do not represent the readers here, so don't speak for them in an attempt to make your fallacious position look stronger. It doesn't work. As far as you first point i.e. motivation I write editorials here every Friday and the motivation was from the Spotify app on Xbox and a lively discussion I had with the developers, Microsoft, and the community on Twitter last week. Translation: you're wrong on everything today, two for two.
  • Its just the run everywhere part.
    I understand for instance that some UWP apps can only run on one form factor.
    But this decision should be taken under condition that it could and can run but simply disabled.
    Like DVD regions, any player can read all discs but those the publisher hasn't authorised. If Microsoft didn't communicate this, then its either they've changed their strategy and are now trying to take all of us for a ride or its their way of denying failure.
  • Bridge Apps are not UWP. They are "Store Apps". UWP means that the base code can be run everywhere, the developer chooses the target platform, whether that is one device platform or 3. Maybe for the consumer, the difference may be meaningless if the only target device is the desktop anyway, but bridge apps are NOT considered UWP.
  • " but bridge apps are NOT considered UWP."
    Read Microsoft's own documentation, which I link to. Quoting Microsoft:
    "At Build 2016 we announced the Desktop App Converter, enabling developers to bring their existing desktop apps and games over to the Universal Windows Platform (UWP) and then extend it with UWP functionality."
    Again, it's about the APIs that make it UWP, not the "base code can be run everywhere", that is just part of it.
  • ACF1 is correct: bridge apps are NOT UWP apps. The bridge for Win32 apps leaves the apps themselves unchanged. The bridge changes how the app is distributed: instead of using an exe or msi file, it will be an appx file. That appx file is what allows the app to be distributed via the store and is what will give you the guarantee that upon uninstallation your registry and filesystem will be perfectly clean. The Microsoft documention is just another sign they are their own worst enemy when it comes to naming things. It's subtle, but notice the descripion says that it "brings apps and games over to the platform" which just a way of saying it's allows for the app to be in distributed via the store and that it comes with the advantages of appx (clean uninstall). The text does not say that the bridge changes the app into a UWP app. Daniel is right in that it's about APIs and that's exactly why bridge apps are not UWP: because the bridge will not change any APIs. For such a thing to happen, MS would need access to the source code of the app. And that's not how the bridge works. The bridge starts with original exe/msi with the fully finished and compiled app in it, analyses what it does to your PC upon installation, and then uses that to wrap the whole thing into a appx file. The bridge does not touch the original Win32 app. And so Spotify in the store on PC is still the same old Win32 app. And that's also why this version can only work on PCs. It simply cannot run on Xbox or Mobile. It's impossible. Whereas with a real UWP app its a choice: even though they can run everywhere, developers decide which types of devices (PC/Mobile/Hub/Xbox) they want to support. It's only when Spotify decides to start adding UWP specific features such as live tiles, that it will become a hybrid app. And only when Spotify has totaly rewritten the app to use ONLY WinRT/UWP APIs will it become a true UWP app and will it be able to run on other types of Windows 10 devices besides PCs. A full rewrite of course takes a lot of work, and won't happen overnight (if ever) and that's why there's now another more simple app for Xbox.
  • Is clean uninstall inside APPX really possible when win32 replaces files everywhere from c: windows to program files to common files.
  • It's not Win32 that will do that, it's the installer (exe/msi file) that will put the files in those locations. The question is not whether APPX will always give you a clean uninstall (it should), but whether the bridge will be able to convert the original exe/msi and turn it into an appx. I have no experience with this myself, but I can imagine that the bridge will do the necessary checks and throw up an error if it detects that files are being put into locations they don't belong during the installation. Meaning that MS will probably only allow apps that are already "well-behaved" to be turned into an appx and submitted to the store.
  • I thought so too on the well-behaved.
    Otherwise the APPX would have to carry its own system folders and .net files.
  • Yes and no.
    The Desktop Bridge includes filesystem and registry virtualization, which means the system can trap access to some keys and folders at runtime and redirect them to app-specific folders. This typically includes any directory the app stores files into during install, which is it's own program files subfolders, and optionally the common files and system32 folders. However it doesn't have to enable this virtualization for any directory besides its installation directory. So an app could, at runtime, modify the system32 or other program files folders. Same for the registry, it will typically isolate the key used by the app for its own settings, but not every other key the app can access and modify at runtime. A clean uninstall of a desktop bridge app can only be performed if the app has been designed to avoid modifying registry keys and filesystem directories outside of its virtualized ones.
  • Microsoft has backtracked on a lot of things the last two years.
  • There is no backtracking here just ignorance.
  • I think the problem to begin with is that there is no real problem with saying a Desktop Bridge App is not UWP. Technically it is, but in it's soul it isn't. For the consumers, UWP is that great look and feel that it is an app built for Windows 10. There is no need to try to explain them out of that thinking, because they wont have to deal with any more than that anyways, if they are not Devs. I am a developer and I have no problem if people say that Spotify isn't UWP, because they are actually right (even if technically, they arent). It's just a 90's car disguised like a 2016 Camaro SS, but inside it's still an old car. By the way, even if the word True-UWP isnt anything official, Hybrid-UWP isnt either (at least not that I know of). And I wouldnt wonder, if you can find an example for both somewhere hidden in Microsofts Documents, because not even Microsoft knows what UWP is nowadays.
  • On point!
  • Hey Daniel I'm disappointed with this article because on the most important point, which has unnecessarily caused the most confusion, you are still plain and simply WRONG! I've really tried to see your point of view and I'm really trying to understand how you've come to the conclusion that "if the app is in the Windows Store it is technically UWP". You are apparently convinced that this paragraph validates that claim:
    Windows 10 introduces UWP, which provides a common app platform available on every device that runs Windows 10. The UWP provides a guaranteed core API across devices. This means you can create a single app package that can be installed onto a wide range of devices. And, with that single app package, the Windows Store provides a unified distribution channel to reach all the device types your app can run on. Apps that target the UWP can call not only the WinRT APIs that are common to all devices but also APIs (including Win32 and .NET APIs) that are specific to the class of device that the app is running on.
    IT DOES NOT! This is one of the places you are in over your head. An app being in the store does not make it an UWP app. Nothing in the above paragraph states otherwise. Since I'm unable to understand where you're getting this misconception from, it's hard for me to help correct it. The store is a distribution channel. That's all. The distribution channel doesn't define what OS services an app can use, how it runs, or its security model. Those things are defined by the APIs an app uses: Uses WinRT/UWP API exclusively = It's a UWP app (you are correct that this doesn't automatically make it universal) Uses Win32 API exclusively = It's a Win32 app, even if it was wrapped in an appx wrapper using the desktop bridge and is distributed through the Windows Store. Uses both the Win32 and UWP APIs = This is the hybrid app you speak of. A Win32 app can't use live tiles, continuum, or anything else related specifically to the UWP. This is just pure Win32 software. Using the desktop bridge allows Win32 software to be distributed through the Windows Store, but if that's all the developer does, then it's still pure Win32 software. Nothing more. However, using the desktop bridge does give the developer an additional option. The developer can now also call UWP APs from the Win32 app. If the developer actually does that, then that is when it becomes a hybrid app. A hybrid between UWP and Win32 software! For such a hybrid app it is still notoriously difficult to use some UWP features. Something like continuum requires such a different UI setup that gaining that capability requires soemthing close to a complete rewrite. However, the ability to call both Win32 and UWP APIs from the same app allows developers to work towards that step by step, likely over years. At some point, hopefully, the entire code base will have been shifted to UWP and nothing that interacted with legacy Win32 will remain. ONLY NOW is this a UWP app! Only at this point is the app based only on the APIs that are universally available on all form factors, and only with that does it gain the ability to potentially be universal. Anyone telling you it is a UWP app before this point is technically incorrect. Any engineer at MS would tell you the same thing. If MS is telling you something else you're just being fed malarkey by their marketing department. If you're basing your opinion on the paragraph you quoted (and I requoted above) then you're just not understanding that paragraph. It doesn't say what you think it says.
  • You're an idiot. Your argument clearly puts you in the non technical audience of this  site.
  • I didn't know we had titles
  • One the thing the detractors like to do is to is to hilight the supposed "app gap" and exploit the division between old Win32 apps and UWP apps. The only difference is the programming model, and as you describe here even that is not as strictly segmented as hey like to proclaim. Win32 apps can call to the UWP layer, and vice versa. To the user, it makes no difference. They get more and more apps, more they can do with their computer, more options, more enjoyment. In the past, a user didn't care - or even know - if their program data was stored in the system registry or in a text file buried deep in some App Data folder. Likewise, people today don't care If their window was created by calling CreateWindow or Windows.UI.Xaml.Controls.Page. They just want to do things with that desktop, game console, tablet, 2 in 1, or Rotherham form factor. And currently (and for the foreseeable future) Windows offers far more solutions to do that than either Apple or Android could ever offer.
  • A true challenge Dan, would be explaining the varioius renames and versions of .Net......
  • lol, not touching .NET
  • C'mon Dan, .NET is easy. The UWP is native code.  .NET languages are supported through a feature called 'language projections' where the UWP APIs are exposed to the .NET languages. This was explained in 2011.
  • I'll be honest with you, I was one of those under the misconception that UWP really did mean universal=run everywhere...or, at least, on every type of Windows device.  Personally, I really do with they would ditch the word 'universal' for that very reason.  If the complaint that the biggest contributor to the downfall of Windows phones was lack of apps, and something like UWP isn't/wasn't a way for devs to literally write-once-deploy-anywhere, then there was never, ever a chance for Windows phones to succeed.  And THIS, more than anything, makes me believe that Windows On Arm is equally doomed to fail. I had a lengthy discussion with a 17 yr old friend of mine who has been through Android, Windows Phone (Lumia 1020) and is now an iPhone user.  He also is an avid Xbox One fan, but has grown disenchanted with it.  He is a gamer, versus me, a media consumer, so what he expects from the ecosystem is different.  He lamented the ups and downs of MS jacking with the dashboard, which features work or don't, which features are easily accessible versus nested...the system has never been fast, contrary to Microsoft's constant promises.  Now he's realizing what many of us in the Windows phone world have complained about.  Microsoft never really has had the heart to create something completely awesome -- and meeting their own hype -- from the start, and has routinely relied on reboot after reboot that, in the end, requires us to buy NEW more POWERFUL hardware.  Their bloated, convoluted systems never seem to meet expectations on current hardware and efforts to improve it quickly spell the end of support for otherwise good hardware.  The latest versions of the Xbox will apparently be amazingly agile...on the Xbox One X.  So, it's not so much Microsoft is setting things up to succeed, whether that's UWP, phones, mobile, or gaming, it's that they just punt to the next advance in hardware.  That's no impressive.
  • WoA isn't a mobile platform. It just means classic Windows form factors, laptops and desktops, can be created using ARM chips while fully supporting legacy software. WoA isn't for phones. It cannot really fail, it just widens hardware choices for manufacturers creating devices using full Windows. Joe Belfiore made this clear with his statements a couple weeks ago. They supposedly have some new platform for phones coming. It isn't WoA.
  • Scubadog,  You and Me both.  And MS duped us into believing that.  I watched the windows 10 release with great interest.  They were going on about UWP apps and how one app will run on phone/box/computer and how dev's will be able to just take their IOS/Android code,  fire it into "some software" and spit out said UNIVERSAL APP.  They said that on stage.   Why would we think its something else?  Dan hindsight is 20/20 and of course we know NOW that universal apps are not universal.   However,  when they got up on stage pounding their chests about was to make us think they were UNIVERSAL!
  • fangirl downvotes...keep it up *******!
  • "I was one of those under the misconception that UWP really did mean universal=run everywhere...or, at least, on every type of Windows device.  Personally, I really do with they would ditch the word 'universal' for that very reason." This is why it is called the "Universal Windows Platform", and apps are "UWP apps", but not "Universal Windows Apps".
    It means the platform the app run on is universal across devices, but the app isn't necessarily.
  • Yes, yes, yes, we understand that NOW.  My point is that clearly a LOT of us, probably even many devs, were left to believe differently.  And, as consumers, we're now left with the realization there never was a real effort to maintain a Windows experience on PHONES.  I already have a Surface Pro 3.  I don't need another "mobile" device that ISN'T a phone.  I, as many others did, EMBRACED Windows on phones.  Windows On Arm no longer appears to be an inroad to hold onto if we want Windows smartphones.  I'd like to have a successful develope come on here and convince us that the who UWP, Windows On Arm, C-shell thing in any makes it EASY and ENTICING for him/her to develop apps for Windows.  I don't think there are any.  There's only one developer I was ever aware of who was a genuine enthusiast (Rudy Huyn), and I've not seen anything from him in a year.  I doubt anyone cares if the platform is "universal" if the apps have to be different for every device/form factor.
  • you are 100% correct.  No matter what UWP "IS" does not matter at this point.   It "WAS" what microsoft made us beleive it was that is important.  and At the w10 event,  UWP was SAID TO BE an app platform that is used on every device running windows 10.  Simple.  NOW that it's not....the backpedaling is in full swing!  green mushroom for you scuba dog!  (1 up)!
  • You sir, are a gentleman and a scholar :)   One thing I'd like to see added to this discussion (though I kinda wish they'd just go away already, but I still use a few) is how the Windows 8.x (not Phone) apps fit in. Unless things have changed I think those would be an exception to the "everything in the store is UWP" as they aren't or weren't delivered in "UWP wrappers"?  This can start to get into irrevelant terrirotry, but interesting non the less. Also, just semi-related but I used to avoid apps that would say they work on Windows 8 and above (and think you've mentioned the same) as that meant you'd be getting an old Win8 app.  But more recenlty it seems that might not be the case now and could indicate there is an Win8 app but also a "native" Win10 app as well.  Have you seen this?  
  • The store supports multiple packages for a single app. So there could be a single APPX that supports several devices families, or there could be APPX specific to devices families or even to Windows 10 versions. When selecting an app that supports several families and versions, you don't know precisely what you're getting, the store automatically picks the newest available package that fits both requirements.
    For example, a developer could have an Xbox-specific APPX, a Creators Update APPX that supports both Desktop and Mobile, a fallback APPX that supports any device running the original first release of Windows 10, and a Windows 8 or WP version for users still not running Windows 10.
    This would all be seen by the user as a single app with a unique AppID.