Understanding Native Image Sizing in Xamarin Forms Apps

This post is about probably my least favorite part of mobile app development – figuring out and assembling all of the various images needed to build an application and publish it into the stores. Each platform has its own requirements for this, and often you will need to provide multiple resolution versions within each platform in order to handle varying pixel density ratios. Xamarin supports all of the necessary resource types of course, but it is still up to us as developers to include the right images in our projects.

For very simply apps this isn’t quite as big of a problem – but it becomes a huge headache for medium-size and large-size apps. To help make my life easier, I like to use a spreadsheet to identify all of the images needed along with the final image resolutions and preferred file names. This works great because I can give this spreadsheet to the UX designer and have them provide all of the assets – already sized and named appropriately so that I can just drop them right into my project. So let’s cover all of the various image types that an app might need – including both the minimum required images as well as optional ones. I will also separate this list into artwork that is needed for the app itself versus artwork needed for the store entries for publication.

Common Rules

Untitled-1Generally, images should be in PNG format, and you should provide a version of each image that most closely matches the target device form factor and pixel density. The device will compensate for mismatched images, but the visual quality will not be great and your app will potentially consume far more memory and CPU resources.

Use standard alpha channel transparency when necessary.

To avoid problems with the native platform resource resolution, you should avoid spaces and dashes in filenames . I also suggest using all lowercase names.

What’s this about Pixel Density?

The term “pixel density” refers to the relative number of individual points/pixels in a given area of a device’s screen. Newer and more advanced devices tend to support higher densities, because this provides a more crisp and detailed visual experience. Both iOS and Android support multiple variations in pixel density, and while they will do their best to upscale/downscale images on demand as needed, this process can consume quite a bit of processing resources and usually produces sub-optimal visual quality.

In iOS, the pixel density of the original iPhone display is considered to be the baseline. The original iPhone had a display resolution of 320×480 and a screen size of 3.5 inches (diagonal). This yields a density of about 164 DPI (dots per inch).

Note: to compute the DPI, you can just use Pythagorean’s theorem to take the square root of the sum of the squares of the width and height (in pixels) and then divide by the diagonal screen size (in inches).

iPhone 4 through 6 have a density of 326 DPI, and the iPhone 6+ has a density of 401 DPI. These various density levels are sometimes referred to as Standard, Retina, and Retina HD. Generally speaking, Retina has twice the number of rendered pixels on each side, and Retina HD has triple. So a 100×100 image on a Standard display is the same physical size as a 200×200 image on Retina, and 300×300 on Retina HD. The larger formats are just sharper.

In Android, there are more density levels. These are known as “low dpi” (about 120 DPI), “medium dpi” (about 160 DPI), “high dpi” (about 240 DPI), “extra-high dpi” (about 320 DPI), “extra-extra high” (about 480 DPI) and so on. In Android parlance, these are called “ldpi”, “mdpi”, “hdpi”, “xhdpi”, and “xxhdpi”. The “mdpi” density is considered to be the baseline.

iPhone Standard Retina *Retina HD
Android ldpi mdpi hdpi xhdpi xxhdpi xxxhdpi
~120 dpi X
~160 dpi X
~240 dpi X
~320 dpi X
~480 dpi X
~640 dpi X

DPI Chart

As you can see in the above chart, we can often interchange image resources between iOS Standard /Android MDPI, iOS Retina / Android XHDPI, and iOS Retina HD / Android XXHDPI. At a bare minimum though, we want to supply images at Retina / XHDPI (320 dpi) for our applications, and also Standard / MDPI if we are supporting slightly older devices.

image

It should be noted that we rarely need to worry about actual screen pixel size in Xamarin Forms when dealing with general layouts. We work in density-independent units while laying out a UI. At runtime the actual pixels are computed and used (the density-independent size is scaled by the pixel density ratio), and the appropriate artwork files are loaded. So for all practical purposes, we pretend that our devices are 320 points wide and either 470 points tall (Android) or 480 points tall (iPhone prior to iPhone 5) or 568 points tall (iPhone 5 and 6).

DPI Multipliers

Now that we know the various pixel densities, let’s cover how to apply that knowledge. We know that we need to supply larger images for higher density formats, and luckily that is an easy thing to do assuming that we are working from a 320 pixel-wide baseline layout.

First, figure out the image size needed for a particular graphic element based on that fundamental screen size of 320×470 (or 480 or 568). Say for example you need an icon that is 1/6 the width of the screen after accounting for a 10 point margin. That would be (320 – 10 – 10) / 6 = 50. So a 50×50 image is needed for Standard iOS and MDPI Android. To compute the other sizes needed for this image, you can just rely on the simply multiplication factors for each:

  • LDPI: 0.75 x base size
  • MDPI / Standard: 1.0 x base size
  • HDPI: 1.5 x base size
  • XHDPI / Retina: 2.0 x base size
  • XXHDPI / Retina HD*: 3.0 x base size
  • XXXHDPI: 4.0 x base size

So now that we know how to size our images, let’s quickly cover where to put them and how to name those files.

iOS Resources

iOS projects place all of their images into a single Resources folder. Filenames must not contain spaces, and you identify the different pixel densities by appending the “@2x” or “@3x” suffix to higher density versions. For example an image resource named “my_image.png”

One special case with iOS artwork is that if you wish to use custom icons for the various built-in button types (navigation bar buttons, tab bar buttons, or toolbar buttons) then your images should be single-color using an alpha transparency mask. It doesn’t matter what color you use – although Apple officially suggests white – because iOS will color it in using whatever the current operating system theme default is, and whether the button is highlighted or not. More detail can be found here on creating custom icons: iOS Human Interface Guidelines – Bar Button Icons

Android Resources

Android projects are structured differently. Instead of using suffixes to designate DPI variations, Android instead uses separate subfolders using a naming convention based on resource qualifier tags. For example, the “/drawables” folder contains default image resources, while the “/drawables-hdpi” folder contains HDPI variants. Android will first search the current device density folder and then fallback to others if it cannot find a resource in the most ideal location. You can find further details of how this works here: Android API Guide – Supporting Multiple Screens

Launcher Icons

Launcher / App Icons are handled slightly differently from the other compiled artwork resources. They are still placed within the Resources folder of each project type (or “/Resources/drawables[-dpi]” for Android), but in iOS they have specific set sizes depending upon targeted devices:

  • iOS 5 & 6: 57×57
  • iOS 5 & 6, iPhone 4 and later: 114×114
  • iOS 7 and up: 120×120

In Android you simply match your Launcher Icon with the target device DPI:

  • ldpi: 36×36
  • mdpi: 48×48
  • hdpi: 72×72
  • xhdpi: 96×96
  • xxhdpi: 144×144
  • xxxhdpi: 192×192

In iOS you should not round the corners of your App Icons – Apple will do that for you, and it might change from one version of iOS to the next.

In Android this icon will also be used (in a smaller version) at the top left of the navigation bar within your app, unless you have taken steps to hide the icon there.

Additional (Optional) Icons for iOS

There are some additional icons you may need to provide to iOS if you are using certain features of the platform. These should all usually be based on your main App Icon.

  • Spotlight Search: 80×80 (and 120×120 if supporting iPhone+)
  • Settings: 58×58 (and 87×87 if supporting iPhone+)
  • Toolbar / Nav Bar: 44×44 (and 66×66 if supporting iPhone+)
  • Tab Bar: 50×50 (and 75×75 if supporting iPhone+)

As mentioned above, don’t forget about the coloring rules for Toolbar / Navigation Bar / Tab Bar icons if you are including those.

App Store Artwork

The final thing left before we can publish an app into one of the App stores is the artwork for the listing itself. In both platforms, there are some required images that you need to provide.

iOS App Store

The iOS App Store requires a large version of your App Icon. A 1024×1024 resolution image is required.

It is highly recommended that you also provide up to five screenshots and a video preview (where applicable) for each of the supported screen sizes:

  • iPhone 2, 3, 4: 3.5″
  • iPhone 5: 4″
  • iPhone 6: 4.7″
  • iPhone 6+: 5.5″
  • iPad

Google Play Store

The Google Play Store requires a large version of your App Icon (512×512) as well as a 1024×500 image to be used as a “feature graphic”.

Screenshots for multiple display formats are also required – a minimum of two total screenshots, and as many as up to eight for each screen size that is supported.

Additional Resources

Lastly, I’d like to leave a few links here with some extra resources that you might find useful when dealing with all of the various image resources needed for a mobile app as well as the variations thereof:

  • App Icon Template – Nice Photoshop templates to help you (or your designer) create awesome app icons
  • Android Asset Studio – Generates multiple resolutions of your icons and other artwork images for the various dpi targets

Need Xamarin Help?

Xamarin Consulting  Xamarin Training

Stay Informed

Sign up for the latest blogs, events, and insights.

We deliver solutions that accelerate the value of Azure.
Ready to experience the full power of Microsoft Azure?

Atmosera is thrilled to announce that we have been named GitHub AI Partner of the Year.

X