Introduction

You do not handle every iPhone resolution by writing special-case code for every model. On iOS, the correct strategy is to think in points instead of raw pixels, provide properly scaled assets, and let Auto Layout and asset catalogs choose the right resource for the device. Once you adopt that model, image scaling across iPhone screens becomes much more manageable.

Think in Points, Not Device Pixels

iOS layout is based on points. The device converts those points into physical pixels using a scale factor such as 2x or 3x.

That means these are different concepts:

• layout size in points
• image asset scale such as 1x, 2x, or 3x
• physical screen resolution in pixels

If you hardcode for a specific pixel size, your layout becomes brittle. If you size views in points and provide matching assets, UIKit handles most of the scaling for you.

Use Asset Catalogs for 1x, 2x, and 3x

The standard iOS answer is to place images in an asset catalog and provide the appropriate variants. If your base image name is avatar, Xcode and UIKit automatically resolve the correct version from the asset set.

For raster images, that usually means:

• 'avatar.png'
• '[email protected]'
• '[email protected]'

Then load it normally:

let imageView = UIImageView(image: UIImage(named: "avatar"))
imageView.contentMode = .scaleAspectFit

UIKit picks the correct underlying asset for the current screen scale. You do not need device-specific if statements for each iPhone model.

Let Auto Layout Control the Display Size

The image asset and the image view size are separate concerns. The asset catalog decides image resolution. Auto Layout decides how large the image view appears in the interface.

Example:

1let imageView = UIImageView(image: UIImage(named: "hero"))
2imageView.translatesAutoresizingMaskIntoConstraints = false
3imageView.contentMode = .scaleAspectFill
4imageView.clipsToBounds = true
5
6view.addSubview(imageView)
7
8NSLayoutConstraint.activate([
9    imageView.leadingAnchor.constraint(equalTo: view.leadingAnchor),
10    imageView.trailingAnchor.constraint(equalTo: view.trailingAnchor),
11    imageView.topAnchor.constraint(equalTo: view.safeAreaLayoutGuide.topAnchor),
12    imageView.heightAnchor.constraint(equalToConstant: 220)
13])

This code sizes the image in points. The screen density and chosen asset resolution determine how sharp it looks.

Choose the Right contentMode

A lot of image-scaling bugs are really image-view configuration bugs.

The most useful content modes are:

• '.scaleAspectFit to show the full image without distortion'
• '.scaleAspectFill to fill the view while preserving aspect ratio, possibly cropping'
• '.scaleToFill to stretch the image, usually not what you want for photos'
• '.center when you do not want scaling at all'

If an image looks wrong on some phones, check contentMode before assuming the asset resolution is the problem.

Prefer Vector or PDF Assets for Simple Artwork

For icons, logos, and simple illustrations, vector-style assets are often better than shipping multiple large raster files. Xcode can handle single-scale PDF assets for many UI graphics.

That approach helps when the art is simple and should stay crisp at different sizes. For photos or detailed bitmaps, you still want raster images with appropriate 2x and 3x variants.

Avoid Device-by-Device Image Logic

A common mistake is writing code such as:

• if iPhone SE, use one image
• if iPhone 14 Pro Max, use another image
• otherwise, guess

That approach does not scale well as Apple adds more screen sizes. A better strategy is:

• let Auto Layout respond to size classes and safe areas
• let the asset catalog handle scale resolution
• use constraints and content modes to define how the image should behave

This keeps the app adaptable instead of model-specific.

Support Different Cropping Needs, Not Just Different Resolutions

Sometimes the real issue is not pixel density but composition. A banner image that looks good on a narrow phone may crop badly on a taller or wider one.

If the art direction matters, solve that at the layout level:

• use a different aspect ratio constraint
• choose a different crop for compact versus regular layouts
• break one giant image into background and foreground layers

This is different from simple scale handling, but developers often mix the two problems together.

Test with Real Layout Variation

When checking image behavior, test more than one screen shape. Even though UIKit handles scale factors well, visual problems still appear when:

• the view is too short for the chosen crop
• the safe area changes the visible image area
• text expansion pushes the image into a smaller frame
• the wrong content mode causes distortion

So test both density and layout shape, not just one modern device.

Common Pitfalls

One common mistake is thinking in pixels instead of points. That leads to brittle device-specific layout code.

Another mistake is providing only one raster asset and expecting it to look sharp everywhere. High-density screens need appropriate source resolution.

Developers also often misuse .scaleToFill, which stretches the image and creates distortion that looks like a scaling problem when it is really a view configuration issue.

Finally, avoid hardcoding specific iPhone models just to manage images. Asset catalogs, Auto Layout, and content modes are the tools iOS expects you to use.

Summary

• Design image layout in points, not raw device pixels.
• Use asset catalogs with the appropriate 1x, 2x, and 3x resources.
• Let Auto Layout control view size and let UIKit choose the correct asset scale.
• Set the right contentMode so the image behaves as intended.
• Solve device differences with responsive layout rules, not with per-model image hacks.