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.

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.

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.

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.

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 is the Editor-in-chief of Windows Central, head reviewer, podcast co-host, and analyst. He has been covering Microsoft since 2007 when this site was called WMExperts (and later Windows Phone Central). His interests include Windows, laptops, next-gen computing, and for some reason, watches. Before all this tech stuff, he worked on a Ph.D. in linguistics, watched people sleep (for medical purposes!), and ran the projectors at movie theaters because it was fun.

112 Comments

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 it....it 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.
I respectfully disagree with you, and I wrote a blog post about it, which is a bit lengthier though, so I wouldn't like to copy all of it over here.
Please take a look at it, I'd appreciate your feedback: What UWP really, REALLY is?
A much needed article. Too many people do not understand what UWP is and expect everything to run on w10 mobile. I really do believe that UWP is the future and the store will be the center of app downloads in the future (I know a lot of people will disagree) but we can clearly see that it is still in its early stages and has a long way to go before it can replace win32
How long until Microsoft abandons UWP? They don't seem to be supporting it that heavily even with their first party apps.
Full Office is now in the Store. What would they replace UWP with, Win32? You question makes no sense.
Why do they have to replace UWP? Your comment echoed my point. Microsoft didn't create "true" UWP Office apps. If Microsoft was serious about UWP, they would support UWP across the board. There are multiple examples of apps released by Microsoft lately that don't leverage the true capabilities of UWP. If Microsoft doesn't believe in UWP, why would anyone else? Why wouldn't we believe that Microsoft would drop UWP?
The great thing about the office guys is they always do they're own thing.
They won't replace the ribbon interface for a hamburger
The issue is you assume a development platform for the modern era can be built up and match Win32 in a year or two. It can't. UWP will take years to grow, improve, get APIs, expand SDK. That is common to all software platforms. It has zero to do with being "serious" it's a lot of work and development too. It's like asking Apple "Why iOS 11 took 10 years...like why didn't they have iOS 11 out in 2007, it would have been so much easier to make and get apps" It makes no sense. Moreover, Win32 is not built for the mobile era. Microsoft needs a flexible, mobile platform. It's UWP and nothing else.
Windows 8 and the app store was released this month, 5 years ago. They had been working on it longer than that I am sure. Several years isn't long enough for Microsoft to get this done? To show they are serious? You really think they won't abandon UWP for some new savior? Isn't that Microsoft's modus operandi? It certainly isn't a crazy question to ask.
Something is definitely wrong with UWP because developers avoid using it in favour of some old tools. Improving UWP APIs over time doesn't solve the main problem. As the result, we have no a good development technology for Windows at all. If it would be possible, I'd like to return to WinForms/WPF times and reinvent the whole WinRT concept from scratch. Combining .NET Core flexibility with DirectX/OpenGL performance maybe the key to a flexible high-performance cross-platform development technology similar to Qt. Unfortunately, this is impossible for Microsoft because they invested too much in UWP and Windows Store (it works well only for consumer devices like phones or Xbox).
We don't know if UWP is inferior to Win16/32/64.
(I think it is until Autodesk show me they can port one of the big programs) Creating a new platform for Windows basically levels the playing field for Microsoft competitors because it erases 30 years of the gains they've made.
Many developers during that time code for Windows not because they liked it but because they had no choice.
Given a choice, they'd go somewhere else.
UWP gives them that choice finally and finally chipping away at the monopoly.
Microsoft doesn't even know what UWP is.
Spotify didn't make a single UWP app because it would not be available on the majority of devices. Not making "true" UWP apps backwards compatible with Windows 7 and 8 was a mistake.
You don't get it.
Thanks for the explanation then. You really do get it. What is there to get? The majority of Windows machines run Windows 7. Not targeting them is a mistake for anyone. A true UWP doesn't target Windows 7.
How well does the Windows 10 store run on WIndows 7 machines?
It doesn't at all obviously. That is the problem. The great Microsoft can't make that happen?
They couldn't even do it for 8.1
So you're saying they need to supply all the APIs etc. back to Win7, a system that they no longer update, simply so users can run the Win10 store?
Do they want UWP to succeed?
BonzeUK. The other day i started Windows 10 in safe mode, when i returned to normal mode it broke.
The store apps wouldn't run and the start menu only had the app list with no tiles.
Basically i had Windows7.
Its very clear that the store apps part is separate of the base Windows.
Also Windows 8 had access to the store and it's still supported.
This API is just another incompetent decision taken.
Err, no you had Win10 where the store apps wouldn't run - because you broke it.
Its funny though, UWP is so safe it can't run in safe mode.
I bet Microsoft will say you tried to run the very safe 'UWP' in safe mode and the system self-destruct for security reasons.
I had that same issue on SurfaceRT, Hiswona. The problem there, is that only the standard MS video driver is loaded in safe mode, and UWP (or in my case, the Windows Runtime), required hardware acceleration and a minimum screen size, > 800x600. Boot with the proper driver and a decent resolution and BAM!, problem solved.
How did you fix it.
UWP refused to work even after i returned to normal mode where full drivers with resolution loaded.
I eventually reinstall Windows. Edit: I see you running RT so you only have win 8 apps
Search how to fix windows 10 apps in powershell. remove-appxpackage -name *store* | add-appxpackage That's not the right syntax, but it is possible to reinstall the store (as Administrator), using PowerShell.
So basically any app that's an APPX is a UWP because being an APPX gives you App Identity, which is needed to be put in the store and use UWP APIs (whether the developer wants to or not)? The way I think about it is the people who say "Desktop Bridge apps aren't UWP apps because they don't use any UWP APIs" are wrong because Desktop Bridge apps are just UWP apps that leverage the RunFullTrust capability, which is the same thing the Settings app uses and no one argues the Settings app isn't a UWP app.
Technically true about being APPX/APPX container; thing is, Microsoft could change APPX name/structure, but still maintain UWP; for now, yeah that explanation is accurate.
Dan are you teasing some internal knowledge about Microsoft will change the APPX name/structure?
Nah, but someone at Microsoft joked that they could and not to make a UWP definition hinge upon pure APPX.
ah, I think thats because APPX is used by enterprises for their apps for another purpose not directly related to UWP.
One caveat. If it's an APPX package for Windows 8 (8.1) it's a Modern, aka Windows Runtime app. If it's AppX for windows 10, then yes, it's a UWP. UWP is the evolution of the Windows Runtime, focusing on enhancing the API surface over Win32, while creating a common model to develop for the multiple form factors.
It's the very clever plan that MS because they know the future.
Do you ever see MS dropping Win32 support? I mean long term, 10-25 years from now? I work for a couple of large hospital networks in a major city, the bulk of computers at both run XP & windows 7... Hardware isn't generally replaced until it dies. Can MS continue to support both win32 and UWP indefinitely? How could they convince major enterprise to upgrade and replace billions of dollars of hardware & software in the coming years? Just curious on your take.
Do you ever see MS dropping Win32 support? I mean long term, 10-25 years from now?
Sure, or at least depreciating it. So it will still be there, still work, but the world by then, in theory, will be on UWP. Depends on when they think they can make the leap and not strand hospitals/enterprise.
Let's be realistic, if Microsoft will ever mention the end of Win32 support over the next 10 years, I think we'll have World War III. Everyone has lost their minds with Paint. Except desktop, there is not enough market for developers to choose UWP. At this point, Windows = desktop, so developers should choose between Win32 that covers 100% of the Windows desktop or UWP covering about 28% (not to mention that there are a lot of APIs missing, controls for complex interface, stability, and so on). If they do not find a solution to pack UWP for Windows 7 (which I think they can not) then they will have to wait until Windows 7 dies. There are not enough reasons to choose UWP - and they know that.
With the investment their partners and customers did in Win32, I really don't see them dropping Win32 support even within 25 years. Phasing it out and not improving it anymore, sure, but dropping support for it, no. It might go into sustainability mode in 25 years and get dropped in 40-50 years.
Also remember many features of UWP are internally built on top of Win32, not directly running on the NT kernel. DirectX is a huge part of both games and XAML-based apps, and would probably need to be highly modified to run directly on top of NT to remove the Win32 layer underneath it.
It seems this is likely going to be the case, we like it or not, Win32 apps will really stretch its existence for longer. We still get new Win32 apps these days using different app platforms and containers. For example, Electron just to name a few. The only way they can really drop Win32 support is when the OS itself doesn't rely on it and about 98% of apps are pure UWP only. This is not impossible, but this will sure take a lot of time. To accelerate the progress, Microsoft really have to put so much focus to improve UWP and promote it, but the main thing to push it really is to have a strong mobile presence that will benefit the most; smartphones, small tablets, and any devices form factor where Win32 cannot work on several factors. There is another thing that seems to counter the progress of UWP adoption, cloud-powered apps and platform. It seems like other Win32 apps instead of moving to UWP, are likely just going straight to cloud platform. This is beneficial in many cases since it doesn't necessarily rely to the OS itself, so it doesn't matter if you are using WIndows, macOS, or any Linux distros. Not all apps may be suited only to move to the cloud, but numbers will. This still depends on what will be the trend in the near future and other factors in the industry. AR computing like HoloLens may be going to be really a next big thing, only without a shock but a slow transition. This where UWP have a fresh start for Microsoft. Now that all depends on how they will successfully execute it, especially that other strong competitors will not just sit back and watch.
Dan, extremely helpful. Thank you putting in the time needed to create this overview, which greatly improved my understanding of UWP.
Reading this reminds me of the last Build keynotes, and what they spoke about makes a lot more sense now, of how the desktop bridge works, even how win32 runs on Win10 ARM. They're undertaking a herculean task of introducing APIs for so many legacy softwares (hah, I still call them softwares and not apps), this will probably take a lot of time to get right, and a lot of persuasion from Microsoft to get companies and developers on board.. I'm guessing most developers are interested, but they don't have enough resources. More important than ever for the Microsoft Store to succeed. Also, wishful thinking: Assuming people get on board and apps start being written in fully modern code, may be it will ease us into the era of Mixed Reality and HoloLens smoothly
Microsoft has a huge communication problem. Even people that like to keep updated on tech news get confused by Microsofts definitions. A lot of people thought UWP apps would run everywhere. A lot of people thought Windows 10 would be a final "windows" that would run everywhere with the same code (including Windows 10 mobile). A lot of people thought Windows Mixed Reality headsets where going to be Mixed Reality Thats why so many people think Microsoft do not deliver what they promise.
Microsoft themselves do not seem to know what they are doing. How can they communicate something they don't even have a grasp of?
Because basically they (MS) get their developers and engineers to do the communicating. The worse instruction manuals ever written for any kind of a device, from a heater to a fridge to cars. Are almost uniformly written by those engineers or devlopers.
As a Windows developer who has written both WPF and UWP apps I can offer up my opinion that Daniels article is spot on and has no major technical errors. Additionally, I've just gotten back from VS Live in Redmond where we had sessions both on UWP (the platform) and XAML (the underlying markup language of both WPF and UWP, among other things). WPF (Windows Presentation Foundation) introduced XAML (eXtensible Application Markup Language), which is a very clean and functional markup language much like HTML. However, WPF was developed using managed code; it was written in languages like C# as opposed to C or C++. This makes it much easier to develop, quicker to rev, but also less performant. In Windows 10 Microsoft wanted to take the dog-fooding principle to heart and write all of the OS dialogs in XAML. This is why the new Settings looks so different from the traditional Control Panel. However, this was a non-starter on the WPF platform as it simply wasn't performant enough. The strict performance requirements around OS dialogs led them to re-write and exend XAML using the more complex but more performant C and C++ (unmanaged) languages. UWP means an application written using this new flavor of XAML. It allows but does not require applications to support multiple platforms, screen sizes, and orientations. A Bridge app is a UWP app, the Bridge system is a set of tools to aid in updating existing applications to UWP. HTH, cc
You're explaing how its achieved.
You not saying why we should not assume it runs the everywhere.
It's called Universal Windows Platform, not Guaranteed to Run Everywhere Platform. You should never assume, that's always dangerous.
Ambiguous names that requires assumptions to understand isn't the problem?
You are not explaining why it should not run everywhere.
There i removed assume. UWP means scalability..
Scalability means elements can fit any screen size without deformity UWP can run everywhere.
This has huge potential is just needs to be steered carefully. I think alot of Microsoft's future hangs on something like this.
as a developer that makes UWP apps. let me just place this here @dan https://developer.microsoft.com/en-us/windows/bridges/desktop more specifically microsoft own description. "Using the Desktop Bridge, you can gradually migrate your code to the Universal Windows Platform (UWP) to reach every Windows 10 device, including phones, Xbox One, and HoloLens. " This is how microsoft has described it to me and my team. so while you can publish desktop (wind32 apps) via the desktop bridge. in microsoft's definition they have explained here on your site and to use developers. an unchanged win32 app through desktop bridge does make it uwp. but rather a desktop app that has been converted and adds one feature like live tiles will qualify it us a uwp app. put simply.. win32 app -> desktop bridge = universal windows package (uwp) win32app -> desktop bridge + enchancments ( live tiles, notification etc) = universal windows platform App also UWP the real problem is microsoft uses 2 definition for uwp uwp = Universal Windows Platform as well as Universal Windows Package. all you have defined above is a Universal Windows Package. not a Universal Windows platform app. Again this is because microsoft uses these terms interchangably.
Oh I agree, which is why I point out that Bridge apps are basically hybrids, but the language you use is more precise. Microsoft is all over the map here. In Ch9 talks and their own dev blog posts they talk about "porting your Win32 app to the UWP using desktop bridge"; it's fast and loose, but agree, which is why you have some saying "true" or "native" UWP vs. hybrid UWP.
right. the other bigger problem here is with UW(p). because in half the dev documentation especially dealing with win32. microsoft calls P . Package. Then in uwp Api and moving to windows 10 store apps( which is what they keep trying to get people to say) P stands for platform. Basically the way i see it and how we talk about this internally. if your app using xaml and uses uwp api from the Windowsapp.lib. we consider them uwp apps. if you app uses any win32 com libraries then we consider it legacy. Or to say it in another way.. the fact that you have hyper-v enabled on your machine and can run linux apps in a windowless screen the app will still be considered a linux app, no matter what the boundaries are. this is effectively what microsoft has done with the bridge is to inspect all referenced dll's to see if there is a version referenced in the uwp api. if all references are compatible in the test run, it remaps and adds the windowsapp.dll to the application bundle and packages it as an appx file. no matter how microsoft tries to change our minds about this, we have not touched any uwp api's and our compiled code is still targeted at .net framework 4.5. all we are doing is packaging on creating a windows store app. But agina this is more along the lines of what a dev will like to differentiate. as far as consumers care. a store app is a store app regardless of the tech.
@Daniel Rubino I disagree. MS is not all over the place. It's more likely that you're understanding of what they write is all over the place, although I can understand how that happens as it's hard to explain developer related technologies to non-developers. "Porting your Win32 app to the UWP using desktop bridge " does not imply that the ported Win32 app becomes a UWP app. Nowhere does MS say that. You're just misunderstanding it in that way. However, that porting process does make it possible for the Win32 app to call UWP APIs. That is what MS means. If the developer actually makes use of that ability then the Win32 app becomes a hybrid app. As you correctly say, UWP is a developer-facing term. If being in the store is all that is required for software to be called UWP software, without that software having to actually call a single UWP API (which is what developers actually care about), then it's a completely worthless term that we might as well ignore. It then means nothing. It's also very counter intuitive. The correct terminology is also the easiest terminology: Store app = any app distributed through the store, irrespective of the API's used UWP app = any app that uses the UWP API exclusively, thereby gainig the ability to at least potentially be universal (can run on any system that hosts the universal windows platform). Hybrid app = any app that uses multiple APIs (like WIn32 + UWP), and which is therefore not even potentially universal
Great job doing the tight rope between developers and front facing geeks.
Is this real life or is it just fantasy?
Caught in a landslide....No escape from reality.....OPEN YOUR EYES...LOOK UP TO THE SKY and SEE!!!!!!....
Fanpanzy downvote...keep it up crybaby!
"If the app is in the Windows Store it is technically UWP." - That is not totally correct, because some apps in the store (a number of mine included) were written for Windows Phone 7 and Windows 8.x before UWP came into existence, but they still run on Windows 10.
I really should learn about all of this new tech, but for the past 10+ years of writing in C++ / .Net, program sthat interface with the back end of the proprietary CMS program we own, there is no need to. Business is SLOW to adopt. I push workplace to the limits but even new installations of software require us to run 2008 on NEW INSTALLATIONS. I have another 20 or so years which is extremely possible I am staying where I am. Fingers crossed....
Why Spotify wrote different UWP apps for PC, XBox and phone is because they wanted to optimise the user experience for the different device types. For them, they may also want to implement particular business rules for particular device classes such as enabling full mobile control for Premium subscribers. The phone app would be worked on for a handheld user experience while the XBox version would be worked on for the classic "lean-back" user experience associated with a large-screen TV and the PC satisfying a "lean-forward" user experience associated with that device class. The idea of writing different software for different device classes could allow the developer to provide a user experience targeted to these classes and UWP still can support that approach. OTOH, UWP can support software writers who are gradually targeting the different device classes without reinventing the wheel each time they want to, for example, have it run on the XBox with the 10-foot "lean-back" user experience..
While the article does a good job of explaining the concepts to general users, it contains some lasting misconceptions about UWP. "a Desktop Bridge app can leverage Windows 10-only features like Cortana, Live tiles, (...)"
Wrong. A Desktop Bridge app can only use Win32.
A single APPX container however can include both Desktop Bridge and UWP pieces, making it possible, by communicating between the two sides, to add UWP-only features.
Even Microsoft points out that if the goal of gradually moving the app to UWP, at the end the app will not use the Desktop Bridge at all anymore. "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."
Not completely true. While the runtime environment isolates the app's installation directory and its registry subtree (think App-V), the app can still permanently modify other registry keys and other directories.
Once installed, a Desktop Bridge app can permanently modify the registry and filesystem just like a standard Win32 app, except for the registry keys and folders that were part of the installation itself. "So why did Spotify create so many apps instead of just one "native" UWP app"
UWP makes it possible to share code, as the API platform is part of UWP.
If the user-interface requires a lot of differences between devices families, a single UI codebase would include a lot of device-specific code with huge branching depending on runtime device.
It is then more efficient to just share the code used behind the scene, for example DLLs shared between projects, but built separate apps, optimized for each platform family.
In this case, each app will be in a separate APPX package, flagged as supporting only specific devices families. These will however contain a lot of shared UWP code, but not the UI code that isn't necessary for that device. "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."
Wrong. Even dynamically loading a DLL, getting a function pointer, and calling it, works.
This means even functions exposed by private dlls or internal OS functions not declared in the SDK can be used. "If the app is in the Windows Store it is technically UWP.", "The UWP provides a guaranteed core API across devices."
These two contradict themselves, either Desktop Bridge are Win32 apps in APPX container, but not UWP as the API they use isn't available across devices,
either they are UWP, and you consider Win32 as part of UWP, but then UWP does not guarantee the API across devices. You really shouldn't try to mix the UWP with the Store distribution system.
UWP is a development platform, which can be used for sideloaded apps as well, while the store is a distribution platform, which, while biased for UWP, isn't limited to UWP.
Pure Desktop Bridge apps are not UWP, but they are Store apps, while sideloaded APPX are UWP, but not Store apps.
I've been saying for ages MS should design UWP to allow for 'origami' style apps (not to be confused with codename for the mobile hardware initiative of a good number of years ago). What I mean is, allowing devs to create, as single applications, apps that scale or 'fold back' screen estate and resources according to the device they're installed on. Maybe this is not the best example but its a start. Say you create a weather app. On the full desktop there's detailed data and graphs, on the phone just local weather forecasts and on the IoT device, maybe just a temperature readout on a temperature sensor/controller. Or on a photo app - just a basic picture frame on a camera, all the way up to a full blown photoshop on the desktop. Beyond this I think 3D is best rendered on a separate device until the hardware can properly merge, and MS should focus efforts on a great 2D surface (no pun intended) including CShell, because actually after many years, Windows is starting to look really good again against x-OS/iOS.
WinRT is core to UWP. Win32 is currently more feature rich than WinRT. But the main thing is Is WinRT more powerful than iOS or Android which have all app development currently going on and have higher quality apps than windows store?
Speaking of UWP, why doesn't Windows Central come clean and tell us what the hell is going on with the broken WC app Leaking avators and Preventing comment posts for both mobile and pc?!!! When shall we expect an update fixing these flaws? It's been over a month!
Microsoft will get right on that Netmann! Seems they are doing the development....
Oh, please. Everyone knows UWP = it runs on everything except Windows 10 Mobile.
Great article, Daniel! I will happily share it whenever I see someone in need of 'Dan'splaning' :P I am surprised (and shocked) to see how many users here is arguing the truth of this, because they are having such a hard time to, (I am guessing), re-wire their understanding of UWP.
It hard to "rewire" your understanding of UWP when The HORSE has been CLAIMING all along that they were INDEED apps that would run on ANY windows 10 device. You can understand the confusion when WC comes out and states otherwise.
I do not know enough facts for certain to comment correctly on that :)
Well...they did, way back when windows 10 was announced, and they made all kinds of claims that proved to be untrue...like ALL DENIM PHONES WILL RECEIVE windows 10 mobile, or, like, UWP apps will work on ANY windows device including PC/Tablet/mobile-phone/XBOX etc. Also, there will be two "projects" islandwood and astoria to EASILY port android and IOS apps to UWP and have them work on ANY windows deivce with hardly any extra coding involved....ALL LIES! All shitcanned and all the reason windows 10/mobile/UWP is in the GINORMOUS MESS it is in right now! Poor management who was more worried about cloud services than their bread and butter OS. SIMPLE.
Fanpanzy truth downvotes...keep up babies!
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 I put my Win32 program in the Store then MSFT would take a 30% cut of sales. My curent reseller only takes around 6% of sales. The Store is a nonstarter. If MSFT lowered their cut to, say, 10% then I would consider it. Of course, the main problem with that is the lack of Windows 7 support in the Store -- so I would have to create two versions of my Win32 programs for distribution. More versions == more support == more expensive to maintain. MSFT doesn't get it. Any way I look at it, supporting their UWP/WinRT/Store system is more expensive to me as a developer. They learned nothing from the OS/2 disaster decades ago.
As a developer, I think that UWP can never replace Win32, for one big reason - restriction. There are a lot of API's that won't be added, just because they are at the system level. There are lots of directories that not at the user level. App specific data is hidden away from different apps. Drivers cannot be built on managed code. I can't explain how many times a particular application would have an issue and a third party application fixed it - just because it was able to access the registry, the application directory or application data directory and fixed the issue. That's just one example. Let's put it that way - innovation did not thrive on restriction. UWP causes restriction.
One of the major problems with UWP is the U part. It creates an expectation or series of expectations just based on the name, no matter what explanations or provisos are attached to the software descriptions. You do us a real service by just explaining that UWP is a developer standard not a consumer feature.
Great article and explanation.
lol nice try, Daniel! But, no UWP is exactly what Microsoft first intended and told everyone. A scalable, responsive application written with the UWP API running across every device and every form factor and screen resolution that supports Windows 10 (any SKU). I understand the subliminal shift in message that Microsoft and Fan sites like WindowsCentral are trying to send, because Microsoft obviously failed - overpromised and underdelivered once again, but no, don't try to delude people. We all know exactly what is UWP. (Also I am a developer) "Universal' does not mean run-everywhere" That's EXACTLY what means, and what Microsoft wanted to mean!
That's actaully true. I have been developing for Windows since Windows Phone 7.5 and when UWP (after shared assets gimmick) was released that was the selling point. They were selling it heavily on WORA. I watched numerous videos on channel9 and mva and all of them were touting it to be WORA and all of them were actually saying its called universal well because it is "universal". That's partially true now. If you just use core UWP APIs it will run everywhere without much issue. But definitely there are more platform dependent APIs and approaches now than they originally had imagined. After that their startegies kept changing, with heavy change in mobile startegy and windows startegy as well and probably the original defnition doesn't fit in current vision. Now, they have gone into sort of damage control mode and thus such articles.
"After that their startegies kept changing, with heavy change in mobile startegy and windows startegy as well and probably the original defnition doesn't fit in current vision." Let's use the real words - failure.
I can't find any modern books on UWP, for example, in Amazon. Also, nothing about UWP certification exams: 70-354, 70-355. At the same time, you can find a number of books, for example, on Azure or .NET Core.
Here's the official Microsoft topic on what UWP is and isn't: https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp Disclosure: I helped write this topic, and I currently own it, so if you have comments feel free to leave them right there on the topic's own discussion area.
so in this article Daniel claims Win32 apps that are brought to the store with the bridge are also UWP. That makes no sense to me since it's just Win32 apps with a wrapper so you can install them through the store and have their files/registry virutalized. Those apps don't have to use Win10 APIs and can never run on any other platform. Having access to the UWP APIs so you can "light up" your app if it's running on Windows 10 is not the same as creating an app with the actual platform. Right now it seems Microsoft is fine with this confusion (I can't really blame Daniel for that, but it doesn't help that his clarification post just amplifies this mess). I guess it will let Microsoft claim a larger number of UWP apps. Apps that would never come to any other platform than the one they were already available for, full Windows. So, maybe it's a bit misleading by design. Maybe it doesn't really matter because Windows Phone is pretty much dead, Xbox is a small market and HoloLens is far away as a consumer product. Maybe the name UWP is irrelevant as it's now just another way to build apps that pretty much only have one target, PCs. Still, it would be great if Microsoft cleared that up so when someone comes to me and asks me to build them a UWP app from their Win32 code they're not dissapointed when they find out it would still only run on PCs

Show more comments