How do I convert points to pixels in iOS?

The formula is px = pt × scale, where scale is the device's @1x, @2x or @3x factor. Most current iPhones are @3x, so 44pt × 3 = 132px. Pick a scale (or choose a device) above and type into the pt field — the converter multiplies instantly and shows both fields at once.

How do I convert pixels to points in iOS?

Divide instead of multiplying: pt = px ÷ scale. On an @2x screen, 828px ÷ 2 = 414pt. Type into the px field above and the pt value updates instantly — useful when a bug report or screenshot gives you a pixel measurement and you need the point value that produced it.

What is 1pt in pixels on an iPhone?

It depends on the device's scale factor, which is the entire reason iOS uses points instead of pixels. 1pt is 1px on the original non-Retina iPhone and iPad mini (long discontinued), 2px on an @2x device (iPhone SE, iPhone 11/XR, most iPads), and 3px on an @3x device (most current iPhones). There is no single answer to "how many pixels is 1pt" without naming a device or scale factor first.

What do @2x and @3x mean?

They're the device's scale factor — how many physical pixels back one point in each direction. At @2x, 1pt covers a 2×2 grid of pixels (4 physical pixels total); at @3x, a 3×3 grid (9 pixels total). Apple introduced @2x with the first Retina iPhone 4 in 2010 and @3x with the iPhone 6 Plus in 2014. Asset catalogs use the same suffix convention: icon.png (@1x), icon@2x.png, icon@3x.png.

Is an iOS point the same as a CSS pt?

No — despite sharing a name, they're unrelated units. A CSS or print pt is a fixed physical unit: 1pt = 1/72 inch, which browsers render as 1.3333px at the reference 96dpi. An iOS point has no fixed physical size at all — it's purely device pixels ÷ scale factor, and the same 44pt button measures a different number of millimeters on an iPhone SE versus an iPhone 16 Pro Max. A generic "pt to px" converter that assumes the CSS definition will give you the wrong number for any iOS work — use a scale factor (@1x/@2x/@3x), never 1.3333, for anything UIKit or SwiftUI related.

How many pixels is 44pt?

44pt — Apple's minimum recommended tappable control size — is 44px at @1x (no modern device), 88px at @2x, and 132px at @3x. Since most current iPhones are @3x and most iPads are @2x, expect 132px on an iPhone and 88px on an iPad for the same 44pt control.

Which iPhones are @3x and which are @2x?

Every current iPhone (12 through 17, all variants) is @3x, as are the iPhone X through 11 Pro and the Plus-suffixed 6/6s/7/8 models. The two @2x outliers are the iPhone 11 and iPhone XR — Apple used a lower-density LCD panel on those two models — plus the older iPhone SE (1st–3rd gen), iPhone 8, iPhone 7 and earlier Retina devices. The device picker above lists the scale factor next to every model.

What is the iPhone 17 Pro Max resolution in points?

440×956pt at @3x, which renders to a native 1320×2868px panel. Select "iPhone 17 Pro Max" in the device picker above to see the same numbers plotted against whatever pt or px value you're converting.

Should I design in points or pixels in Figma?

Design at @1x, in points — set your frame to the device's logical size (e.g. 402×874 for an iPhone 17) rather than its native pixel resolution (1206×2622). Figma operates at 1x regardless of your display, so typing point values directly matches what a developer will read off the design and hand to SwiftUI or UIKit. Export image assets at @2x and @3x afterwards; don't design the frame at 3x size.

How do I export @2x and @3x assets?

In an Xcode asset catalog, provide three files named name.png, name@2x.png and name@3x.png, sized at exactly 1×, 2× and 3× your base point dimensions — Xcode picks the right one for the running device automatically. Enter your base size in the converter above and the all-scales table gives you all three pixel sizes at once. For app icons specifically, skip this entirely: Xcode 14 and later use a single 1024×1024px source image instead (see below).

Is a point a fixed physical size on iOS?

No — and this is the biggest difference from Android's dp, which is deliberately fixed at 1/160 inch on every device. An iOS point is only ever pixels ÷ scale factor; its physical size drifts with each device's actual pixel density, landing anywhere from roughly 1/163 inch on an iPhone to roughly 1/132 inch on some iPads. Apple prioritizes a consistent logical layout grid per device family over a fixed physical measurement.

How do I get the screen scale in SwiftUI?

Read the displayScale environment value: @Environment(\.displayScale) var displayScale, then multiply — let pixels = points * displayScale. This is the modern replacement for UIScreen.main.scale and correctly reflects the scale of whichever screen the view is actually rendered on (relevant for external displays and Stage Manager).

Why is UIScreen.main.scale deprecated, and what replaces it?

UIScreen.main assumes a single, global screen, which breaks down on iPad with Stage Manager, external displays, and multiple scenes — there's no longer one canonical "main" screen. The replacement is view.traitCollection.displayScale in UIKit, or the displayScale environment value in SwiftUI — both read the scale of the specific screen a view is actually on, rather than guessing from a global singleton.

What is nativeScale, and why is the iPhone 8 Plus different?

nativeScale is the scale factor of the device's actual physical pixel grid, as opposed to scale, which is the factor an app renders at. They're almost always identical — except on the Plus-sized iPhones (6, 6s, 7, 8 Plus), which render UI at @3x into a 1242×2208 virtual canvas and then downsample it to a physical 1080×1920 panel. Their nativeScale is roughly 2.608 (1080 ÷ 414), not a clean integer, which is why that generation is the one real exception to "scale is always 1, 2 or 3."

Is an iOS point the same as an Android dp?

Conceptually yes — both are density-independent layout units so a control looks the same physical size across devices in the same OS. Mechanically they differ: Android's dp is defined against a fixed 160dpi baseline (px = dp × dpi/160), giving it a genuinely fixed physical size. iOS's point has no such baseline — it's simply pixels ÷ integer scale factor, and that physical size varies slightly by device. See the dp to px converter for the Android side of the same problem.

Do points change with Display Zoom or Dynamic Type?

Display Zoom changes the logical resolution itself — turning it on for an iPhone 12 Pro Max makes iOS report the smaller iPhone 11 Pro's 375×812pt instead of its native 428×926pt, uniformly enlarging everything. Dynamic Type is different: it only changes the point size of text styles (Body, Title, etc.) that opt into it — it never changes the scale factor, and non-text UI stays exactly the same size unless you explicitly scale it too.

What size should an iOS app icon be in points and pixels?

As of Xcode 14, provide a single 1024×1024px PNG in your asset catalog with "Single Size" enabled, and Xcode generates every smaller variant automatically at build time — there's no point value to convert. The older 20/29/40/60/76/83.5pt × @1x/@2x/@3x set is legacy: those were the point sizes Apple required before Xcode 14, and you'll still see them referenced in older tutorials and some third-party icon generators, but current projects don't need to think in points for icons at all.

What is the default text size on iOS in points?

17pt is Body text at the default Dynamic Type setting ("Large", which is the middle of iOS's range) — the most common baseline for reading text in an app. iOS 18 supports 12 Dynamic Type steps in total: 7 standard sizes (xSmall through xxxLarge) plus 5 larger accessibility sizes (AX1–AX5), and body text can scale to roughly 310% of its base size at the largest AX5 setting.

Does macOS use points like iOS?

Yes, the same concept, but not the same mechanics. macOS also converts px = pt × scale, but scale is only ever 1 or 2 — there is no @3x Mac. macOS also has a "Scaled resolution" display mode, on by default on most Macs, where the system renders at 2× a non-native "looks like" resolution and resamples it to the panel — the kind of downsampling that's a rare exception on iOS (the Plus-model iPhones) but the everyday case on Mac. There's also no fixed device catalog the way iPhone and iPad have one, since Macs support arbitrary external displays and multiple selectable scaled options per built-in screen.

What is NSScreen.backingScaleFactor?

It's the macOS equivalent of iOS's displayScale — a property on NSScreen that returns the number of physical pixels per point, either 1 (non-Retina) or 2 (Retina). Unlike iOS's UIScreen.scale, it's never 3. Apple's own guidance is to avoid reading it directly where possible and instead let AppKit's backing-store conversion methods (or SwiftUI's displayScale environment value) handle the conversion, since the raw factor doesn't reflect anything as concrete as physical pixel density.

Mobile

iOS Points to Pixels Converter — pt to px & px to pt

Free iOS points to pixels converter (and px to pt): convert at @1x, @2x and @3x with a device picker for every iPhone and iPad, HIG reference values, and SwiftUI & UIKit code snippets. 100% in your browser.

Updated Aug 26, 2026

Scale factor

Or pick a device

Points (pt)

Pixels (px)

44 × 2 = 88 px

dp to px →sp to px →

44pt at every scale factor
Scale	px
@1x	44
@2x	88
@3x	132

iOS doesn't round to whole device pixels the way Android does — the system renders sub-pixel content and lets the display antialias it.

Common pt values at @2x
pt	px	Reference
11pt	22px	Label Small (smallest recommended text)
17pt	34px	Body text — default Dynamic Type size
20pt	40px	Callout / list row default
28pt	56px	Title 1
34pt	68px	Large Title
44pt	88px	Minimum tappable control size

Use this value in code

// SwiftUI
.frame(width: 44, height: 44)

// SwiftUI — read the screen scale
@Environment(\.displayScale) var displayScale
let pixels = 44 * displayScale

// UIKit
let pixels = 44 * view.traitCollection.displayScale

What is a point in iOS, and why doesn’t Apple use pixels?

A point (pt) is iOS’s device-independent layout unit — the number you type into .frame(width:) in SwiftUI or a constraint constant in UIKit. It exists because Apple ships dozens of physical screen resolutions across iPhone and iPad, and a fixed pixel count would mean a button sized correctly on one device looking wrong-sized on every other. Points let you write layout code once; the system multiplies by each device’s scale factor to land on real pixels.

This is the same problem Android solves with dp — see the dp to px converter for that side — but the mechanics differ, which is the point of this page.

The pt to px formula (and the reverse)

Both directions reduce to one multiplication, because iOS’s scale factor is always a small integer:

pt → px: px = pt × scale
px → pt: pt = px ÷ scale

scale is 1, 2 or 3 — the device’s @1x, @2x or @3x factor. A 44pt button on an @3x iPhone is 44 × 3 = 132px. Measure 828px on an @2x screen and it’s 828 ÷ 2 = 414pt. Pick a scale or a device above and type into either field — the converter does the multiplication both ways.

@1x, @2x, @3x — what the scale factors actually mean

The scale factor is how many physical pixels back one point per direction, so the total pixel count grows with the square:

@1x: 1pt = 1px. The original iPhone and iPad mini, long discontinued.
@2x: 1pt covers a 2×2 grid — 4 physical pixels. Introduced with the Retina iPhone 4 in 2010; still used by the iPhone SE, the iPhone 11 and XR, and every iPad.
@3x: 1pt covers a 3×3 grid — 9 physical pixels. Introduced with the iPhone 6 Plus in 2014; used by essentially every current iPhone.

The iPhone 11 and XR are the one modern exception — Apple used a lower-density LCD panel on those two models, so they stayed at @2x while every other iPhone released around them moved to @3x.

iOS pt is not CSS pt (or print pt)

The single most common mistake in this space: a generic “pt to px” converter almost always means the CSS or print point, a completely different, fixed-physical-size unit.

Context	1pt equals	Basis
iOS (UIKit / SwiftUI)	1, 2 or 3 px	The device’s `@Nx` scale factor — no fixed physical size
CSS	1.3333px	`1/72 inch`, rendered at a 96dpi reference
Print / typography	`1/72 inch`	A fixed physical measurement

If you plug an iOS point value into a CSS pt→px calculator, you’ll get × 1.3333 instead of × 2 or × 3 — a wrong answer that’s neither obviously wrong nor close to right. Always reach for a scale factor (@1x/@2x/@3x), never 1.3333, for anything UIKit- or SwiftUI-related.

Every iPhone’s points, scale and pixel resolution

Device	Points (portrait)	Scale	Pixels (native)
iPhone 17 Pro Max / 16 Pro Max	440 × 956	@3x	1320 × 2868
iPhone 16 Plus / 15 Pro Max / 15 Plus / 14 Pro Max	430 × 932	@3x	1290 × 2796
iPhone Air	420 × 912	@3x	1260 × 2736
iPhone 17 / 17 Pro / 16 Pro	402 × 874	@3x	1206 × 2622
iPhone 16 / 15 / 15 Pro / 14 Pro	393 × 852	@3x	1179 × 2556
iPhone 16e / 14 / 13 / 13 Pro / 12	390 × 844	@3x	1170 × 2532
iPhone 11 Pro / XS / X / 13 mini / 12 mini	375 × 812	@3x	1125 × 2436
iPhone 11 / XR	414 × 896	@2x	828 × 1792
iPhone 8 Plus / 7 Plus / 6s Plus	414 × 736	@3x*	1242 × 2208 (*downsampled to a 1080×1920 panel)
iPhone SE (3rd/2nd gen) / 8 / 7	375 × 667	@2x	750 × 1334
iPhone SE (1st gen)	320 × 568	@2x	640 × 1136

Pick any of these in the device picker above to see both resolutions plotted against your own value.

iPad points and pixel resolutions

Every current iPad is @2x — there’s no @3x iPad:

Device	Points (portrait)	Pixels (native)
iPad Pro 13“ / Air 13“ / Pro 12.9“	1024 × 1366	2048 × 2732
iPad Pro 11“	834 × 1194	1668 × 2388
iPad Air 11“ / 10.9“	820 × 1180	1640 × 2360
iPad 10.2“ / 10.9“	810 × 1080	1620 × 2160
iPad mini	744 × 1133	1488 × 2266

Exporting @1x / @2x / @3x assets from Figma or Sketch

Design frames at @1x, in points — set a frame to a device’s logical size (e.g. 402×874 for an iPhone 17), not its native pixel resolution. Figma and Sketch both operate at 1x internally regardless of your monitor, so the numbers you type match exactly what a developer reads off the design.

Export image assets afterwards at all three scales, named for an Xcode asset catalog:

icon.png       (@1x — base size)
icon@2x.png    (@2x — 2× the base pixel dimensions)
icon@3x.png    (@3x — 3× the base pixel dimensions)

Enter your base size in the converter above and the all-scales table gives you the pixel dimensions for all three files at once.

Common iOS point values from the Human Interface Guidelines

Two values are worth memorizing because they recur everywhere in iOS layout:

44 × 44pt — Apple’s minimum recommended tappable control size. At @3x that’s 132×132px; at @2x, 88×88px.
17pt — the default Body text size at the standard Dynamic Type setting (see below).

Chrome metrics like the navigation bar (typically 44pt) and tab bar (typically 49pt) are not fixed constants — they vary slightly by device and are taller on iPad — so read the actual value from safeAreaInsets or the view’s frame at runtime rather than hardcoding them.

App icons: forget point sizes entirely (Xcode 14+)

The legacy requirement was a full set of point-sized icons — 20, 29, 40, 60, 76 and 83.5pt, each at @1x/@2x/@3x, more than a dozen files total. That’s no longer necessary. Since Xcode 14, asset catalogs support Single Size: provide one 1024×1024px PNG (not pt — this one asset is always specified in raw pixels) and Xcode generates every device variant automatically at build time. If you’re following a guide that lists point sizes for icons, it’s describing the pre-2022 workflow.

Half-points, hairlines and pixel alignment

A point value that doesn’t divide evenly into whole pixels at your scale factor renders blurred — the system has to split it across two physical pixels and antialias the edge. A classic case: a 0.5pt hairline separator is a crisp 1px line at @2x but a blurry 1.5px line at @3x. The fix is to compute the thinnest crisp line for the current scale as 1 / displayScale rather than hardcoding 0.5.

Points to pixels in SwiftUI

Read the screen’s scale from the environment, then multiply:

@Environment(\.displayScale) var displayScale
let pixels = points * displayScale

This is the SwiftUI-native replacement for UIScreen.main.scale (see below) and correctly reflects the scale of whichever screen a view is actually rendered on.

Points to pixels in UIKit

let pixels = points * view.traitCollection.displayScale

UIScreen.main.scale still works today but is being phased out — it assumes one global “main” screen, which breaks down with external displays, multiple scenes, and iPad Stage Manager. traitCollection (UIKit) and the displayScale environment value (SwiftUI) both read the scale of the specific screen a view is actually on.

The Plus-model exception: nativeScale and downsampling

nativeScale is the scale of the device’s actual physical pixel grid; scale is the factor your app renders at. They’re identical on every device except the Plus-sized iPhones — the 6, 6s, 7 and 8 Plus. Those models render UI into a @3x, 1242×2208 virtual canvas, then the system downsamples that to a physical 1080×1920 panel. Their nativeScale works out to roughly 2.608 (1080 ÷ 414) — not a clean integer, which makes that generation the one real exception to “scale is always 1, 2 or 3.”

iOS points vs Android dp vs React Native units

Both platforms solve the same problem — a layout unit that looks the same physical size regardless of pixel density — with different mechanics. Android’s dp is pinned to a fixed 160dpi reference (px = dp × dpi/160), giving it a genuinely constant physical size across every device. iOS’s point has no such reference: it’s simply pixels ÷ integer scale factor, so its physical size drifts slightly between an iPhone and an iPad. See the dp to px converter and sp to px converter for the Android side of this exact problem, including how Android layers a user font-scale on top for text.

React Native’s unitless layout numbers map directly onto whichever platform they run on — dp on Android, pt on iOS — with PixelRatio.get() exposing the current scale factor when you need to drop to raw pixels.

Does macOS use points too?

Yes — same concept, different mechanics. macOS uses the identical px = pt × scale formula, but with two differences that matter if you’re building a cross-platform Apple app:

scale is only ever 1 or 2 — never 3. NSScreen.backingScaleFactor is macOS’s equivalent of iOS’s displayScale, and it returns 1 on a non-Retina display or 2 on a Retina one. There is no @3x Mac.
Non-integer downsampling is the everyday case, not an exception. macOS’s “Scaled resolution” display mode — on by default on most Macs — renders the interface at 2× a “looks like” logical resolution that often isn’t an integer factor of the panel’s native pixel count, then resamples the result down to the physical screen. On iOS, this kind of downsampling only ever happened on the Plus-model iPhones (see above); on Mac, it’s how the majority of displays run.

One consequence: there’s no fixed device-and-resolution catalog for macOS the way there is for iPhone and iPad. Macs support arbitrary external displays, and each built-in screen typically offers several selectable “looks like” scaled options — so unlike the device table above, macOS point-to-pixel math is situational rather than a lookup.

Display Zoom, Dynamic Type — what does and doesn’t change points

Display Zoom changes the logical resolution itself: turning it on for an iPhone 12 Pro Max makes iOS report the smaller iPhone 11 Pro’s 375×812pt instead of its native 428×926pt, uniformly enlarging every point value at once — a blunt, whole-screen zoom.

Dynamic Type is different and much more common to design around: it only changes the point size of text styles (Body, Title, Caption, …) that explicitly opt in, via Apple’s typography guidelines. Non-text UI — icons, spacing, images — stays exactly the same point size unless you deliberately scale it too, which is why fixed-height containers around Dynamic Type text are a common accessibility bug: the text grows, the container doesn’t, and content clips.

When you actually need this conversion

Asset export. Turning a point-based design spec into the exact @1x/@2x/@3x pixel files an asset catalog needs.
QA and bug reports. A tester or a screenshot measurement tool reports a gap or offset in pixels; you need the point value in your layout code that’s actually responsible.
Design handoff. A Figma or Sketch spec at @1x hands off point values directly, but verifying a build against a pixel-based mockup means converting back the other way.
Canvas and Core Graphics drawing. Custom drawing code that needs to reason in device pixels rather than the point-based coordinate system UIKit and SwiftUI otherwise handle for you.
Cross-platform specs. A design system shared between iOS and Android needs the equivalent value on each platform — the dp/sp tools above cover the Android half.

Building the Android side of the same app? The dp to px converter and sp to px converter solve the identical scaling problem for Android layout and text. Shipping the app icon too? The App Icon Generator produces the full native size set for iOS, Android and more from one source image — including the single 1024×1024px file Xcode 14+ needs.

Everything runs 100% client-side — nothing you type ever leaves your device.

Frequently asked questions

How do I convert points to pixels in iOS?
The formula is px = pt × scale, where scale is the device's @1x, @2x or @3x factor. Most current iPhones are @3x, so 44pt × 3 = 132px. Pick a scale (or choose a device) above and type into the pt field — the converter multiplies instantly and shows both fields at once.
How do I convert pixels to points in iOS?
Divide instead of multiplying: pt = px ÷ scale. On an @2x screen, 828px ÷ 2 = 414pt. Type into the px field above and the pt value updates instantly — useful when a bug report or screenshot gives you a pixel measurement and you need the point value that produced it.
What is 1pt in pixels on an iPhone?
It depends on the device's scale factor, which is the entire reason iOS uses points instead of pixels. 1pt is 1px on the original non-Retina iPhone and iPad mini (long discontinued), 2px on an @2x device (iPhone SE, iPhone 11/XR, most iPads), and 3px on an @3x device (most current iPhones). There is no single answer to "how many pixels is 1pt" without naming a device or scale factor first.
What do @2x and @3x mean?
They're the device's scale factor — how many physical pixels back one point in each direction. At @2x, 1pt covers a 2×2 grid of pixels (4 physical pixels total); at @3x, a 3×3 grid (9 pixels total). Apple introduced @2x with the first Retina iPhone 4 in 2010 and @3x with the iPhone 6 Plus in 2014. Asset catalogs use the same suffix convention: icon.png (@1x), icon@2x.png, icon@3x.png.
Is an iOS point the same as a CSS pt?
No — despite sharing a name, they're unrelated units. A CSS or print pt is a fixed physical unit: 1pt = 1/72 inch, which browsers render as 1.3333px at the reference 96dpi. An iOS point has no fixed physical size at all — it's purely device pixels ÷ scale factor, and the same 44pt button measures a different number of millimeters on an iPhone SE versus an iPhone 16 Pro Max. A generic "pt to px" converter that assumes the CSS definition will give you the wrong number for any iOS work — use a scale factor (@1x/@2x/@3x), never 1.3333, for anything UIKit or SwiftUI related.
How many pixels is 44pt?
44pt — Apple's minimum recommended tappable control size — is 44px at @1x (no modern device), 88px at @2x, and 132px at @3x. Since most current iPhones are @3x and most iPads are @2x, expect 132px on an iPhone and 88px on an iPad for the same 44pt control.
Which iPhones are @3x and which are @2x?
Every current iPhone (12 through 17, all variants) is @3x, as are the iPhone X through 11 Pro and the Plus-suffixed 6/6s/7/8 models. The two @2x outliers are the iPhone 11 and iPhone XR — Apple used a lower-density LCD panel on those two models — plus the older iPhone SE (1st–3rd gen), iPhone 8, iPhone 7 and earlier Retina devices. The device picker above lists the scale factor next to every model.
What is the iPhone 17 Pro Max resolution in points?
440×956pt at @3x, which renders to a native 1320×2868px panel. Select "iPhone 17 Pro Max" in the device picker above to see the same numbers plotted against whatever pt or px value you're converting.
Should I design in points or pixels in Figma?
Design at @1x, in points — set your frame to the device's logical size (e.g. 402×874 for an iPhone 17) rather than its native pixel resolution (1206×2622). Figma operates at 1x regardless of your display, so typing point values directly matches what a developer will read off the design and hand to SwiftUI or UIKit. Export image assets at @2x and @3x afterwards; don't design the frame at 3x size.
How do I export @2x and @3x assets?
In an Xcode asset catalog, provide three files named name.png, name@2x.png and name@3x.png, sized at exactly 1×, 2× and 3× your base point dimensions — Xcode picks the right one for the running device automatically. Enter your base size in the converter above and the all-scales table gives you all three pixel sizes at once. For app icons specifically, skip this entirely: Xcode 14 and later use a single 1024×1024px source image instead (see below).
Is a point a fixed physical size on iOS?
No — and this is the biggest difference from Android's dp, which is deliberately fixed at 1/160 inch on every device. An iOS point is only ever pixels ÷ scale factor; its physical size drifts with each device's actual pixel density, landing anywhere from roughly 1/163 inch on an iPhone to roughly 1/132 inch on some iPads. Apple prioritizes a consistent logical layout grid per device family over a fixed physical measurement.
How do I get the screen scale in SwiftUI?
Read the displayScale environment value: @Environment(\.displayScale) var displayScale, then multiply — let pixels = points * displayScale. This is the modern replacement for UIScreen.main.scale and correctly reflects the scale of whichever screen the view is actually rendered on (relevant for external displays and Stage Manager).
Why is UIScreen.main.scale deprecated, and what replaces it?
UIScreen.main assumes a single, global screen, which breaks down on iPad with Stage Manager, external displays, and multiple scenes — there's no longer one canonical "main" screen. The replacement is view.traitCollection.displayScale in UIKit, or the displayScale environment value in SwiftUI — both read the scale of the specific screen a view is actually on, rather than guessing from a global singleton.
What is nativeScale, and why is the iPhone 8 Plus different?
nativeScale is the scale factor of the device's actual physical pixel grid, as opposed to scale, which is the factor an app renders at. They're almost always identical — except on the Plus-sized iPhones (6, 6s, 7, 8 Plus), which render UI at @3x into a 1242×2208 virtual canvas and then downsample it to a physical 1080×1920 panel. Their nativeScale is roughly 2.608 (1080 ÷ 414), not a clean integer, which is why that generation is the one real exception to "scale is always 1, 2 or 3."
Is an iOS point the same as an Android dp?
Conceptually yes — both are density-independent layout units so a control looks the same physical size across devices in the same OS. Mechanically they differ: Android's dp is defined against a fixed 160dpi baseline (px = dp × dpi/160), giving it a genuinely fixed physical size. iOS's point has no such baseline — it's simply pixels ÷ integer scale factor, and that physical size varies slightly by device. See the dp to px converter for the Android side of the same problem.
Do points change with Display Zoom or Dynamic Type?
Display Zoom changes the logical resolution itself — turning it on for an iPhone 12 Pro Max makes iOS report the smaller iPhone 11 Pro's 375×812pt instead of its native 428×926pt, uniformly enlarging everything. Dynamic Type is different: it only changes the point size of text styles (Body, Title, etc.) that opt into it — it never changes the scale factor, and non-text UI stays exactly the same size unless you explicitly scale it too.
What size should an iOS app icon be in points and pixels?
As of Xcode 14, provide a single 1024×1024px PNG in your asset catalog with "Single Size" enabled, and Xcode generates every smaller variant automatically at build time — there's no point value to convert. The older 20/29/40/60/76/83.5pt × @1x/@2x/@3x set is legacy: those were the point sizes Apple required before Xcode 14, and you'll still see them referenced in older tutorials and some third-party icon generators, but current projects don't need to think in points for icons at all.
What is the default text size on iOS in points?
17pt is Body text at the default Dynamic Type setting ("Large", which is the middle of iOS's range) — the most common baseline for reading text in an app. iOS 18 supports 12 Dynamic Type steps in total: 7 standard sizes (xSmall through xxxLarge) plus 5 larger accessibility sizes (AX1–AX5), and body text can scale to roughly 310% of its base size at the largest AX5 setting.
Does macOS use points like iOS?
Yes, the same concept, but not the same mechanics. macOS also converts px = pt × scale, but scale is only ever 1 or 2 — there is no @3x Mac. macOS also has a "Scaled resolution" display mode, on by default on most Macs, where the system renders at 2× a non-native "looks like" resolution and resamples it to the panel — the kind of downsampling that's a rare exception on iOS (the Plus-model iPhones) but the everyday case on Mac. There's also no fixed device catalog the way iPhone and iPad have one, since Macs support arbitrary external displays and multiple selectable scaled options per built-in screen.
What is NSScreen.backingScaleFactor?
It's the macOS equivalent of iOS's displayScale — a property on NSScreen that returns the number of physical pixels per point, either 1 (non-Retina) or 2 (Retina). Unlike iOS's UIScreen.scale, it's never 3. Apple's own guidance is to avoid reading it directly where possible and instead let AppKit's backing-store conversion methods (or SwiftUI's displayScale environment value) handle the conversion, since the raw factor doesn't reflect anything as concrete as physical pixel density.