Several years ago, when Windows Phone appeared, we were all targeting 480×800 resolution. We had exactly 480 pixels of width and 800 pixels of height for our user interface. Then with Windows Phone 8 we got three more resolutions, but in practice – we had only two. The “old” one, and one slightly taller. So we were all designing our apps for 480×800, having in mind that some phones may have 53 pixels more in height, so we had to allow some element on the screen to use that extra height if necessary. Everything else was fixed automatically by scaling.

In Windows Phone 8.1 WinRT apps (not Silverlight) we had a smallest width of 384 pixels, so we had to multiply our sizes from Windows Phone Silverlight app markup by 0.8. Not all phones had that width, that was only the smallest one possible, to we had to have an element (or two) that will fill the space up to 600 pixels in width. That’s almost twice as much!

On Windows 10 smallest view resolution is even lower – it’s 320 x 533 pixels, so you’ll need to start with that and be prepared to scale and grow in both directions. The old default will have a scale of 150, so if you’re converting an old Windows Phone Silverlight app, just divide everything with 1.5.

Scale and the actual resolution depend on many different factors, and I won’t go into details here (read more on MSDN if interested). The important thing is – actual resolution is the one you use in XAML. Physical resolution is the one that will be displayed on screen. Since there are no phones with physical resolution of 320 x 533, that means that your UI will always be scaled, at least 150%. Any image you include at 100% scale will be blurry and ugly. So the least you can do is to prepare bitmap images in higher resolution (for example 2x bigger than size values you use in XAML). If you want to do more – prepare your images in multiple resolutions, but for the best results – simply use vectors (fonts or XAML). And vote here so Microsoft adds support for SVG elements inside XAML. We really need that.