UWP defines 'device families', so an app targeting a device family X has access to all the APIs provided by X. You have 'Universal' (can't do much, but is on all devices) and inheriting from that e.g. desktop, xbox, iot etc. So if you want to target xbox, you select that device family and if the app also has to run on desktop, you need to do some extra work if the api you're using isn't available on the other device family. Depending on what language you use, if it's a .NET language, it is the same code running on both, if it's C++, you'll have multiple compilation targets (x86, arm etc.). All outputs are packaged into the same package, the device will pick the one it can run.
UWP offers some win32 api's, but that's a minor subset.
If you write an UWP app, you thus target the UWP api provided by the device family of choice. This means that if you want to ship it as a normal win32 app, you have to redo all code which utilizes UWP api's as UWP isn't a wrapper around win32, it's an 'alternative'. Also, if you have a win32 app and want to ship it as a UWP, you have to redo all code that utilizes Win32 APIs that are not available in the UWP api provided by the device family of choice.
In practice this means that a lot of code can be re-used (as it's general purpose code, e.g. in the context of games, the scene graph of the 3D engine, data structures libraries, game logic etc.) and some parts have to be re-done, like user interfaces, code that utilizes the device's screen / input etc, or in the context of games: render pipelines, rasterization, I/O etc.
So it's not 'build for UWP' and it runs everywhere. The marketing wants you to believe that, the small print tells otherwise.