If you have looked up the iPhone Duo’s screen size more than once, you have probably been given more than one answer. The pixel figures are consistent everywhere, because Apple publishes them. The point figures are not, because Apple does not.
Here is the whole of it:
| Display | Published pixels | ÷ scale | Points |
|---|---|---|---|
| Inner (folding) | 1878 × 2670 | ÷ 3 | 626 × 890 |
| Outer (cover) | 1398 × 2034 | ÷ 3 | 466 × 678 |
Both divide exactly. No rounding, no judgement call, nothing to disagree about once you have decided the device is @3x.
How to check any source in ten seconds
A wrong point figure almost always travels next to the correct pixel figure, because the pixels get copied from Apple and the points get copied from somewhere else. That makes the error easy to catch: divide the pixel numbers the source itself gives you by three, and see whether you get the points it also gives you.
We have watched an AI assistant state the inner display as 669 × 951 points while quoting 1878 × 2670 pixels two sentences earlier. Those cannot both be true. 1878 ÷ 3 is 626, not 669. The answer contradicted itself and read perfectly fluently, which is exactly why this check is worth doing on anything you are about to hard-code.
Why Apple publishes pixels and not points
Apple’s technical specifications page is written for people buying a phone, and pixels and inches are what that audience compares. Points are a developer concern, and Apple’s developer material approaches the subject from the opposite direction: its written Preparing your app for iPhone Duo guide tells you not to lay out against fixed device dimensions at all.
That advice is right, and it is worth stating plainly even on a page about dimensions: you should not be hard-coding either number. Apple’s guidance is to size views relative to their container, calculate from your scene’s bounds rather than the screen’s, and adapt to size classes. A layout that needs to know it is 626 points wide is a layout that will break on the next device.
The numbers are still worth having for three things:
- Snapshot tests, where you render at a fixed size deliberately.
- Design handoff, where a canvas needs a size.
- Sanity-checking what you are seeing in the simulator.
What the numbers mean in practice
The inner display at 626 points wide reports a regular horizontal size
class, which is the detail that catches people out: iPhone Duo reports the phone
idiom with a regular-width display, so any layout gated on
userInterfaceIdiom == .pad never appears. See
idiom-based assumptions.
The outer display at 466 points is compact width. Note that it is wider than the 402 points of an iPhone 18 Pro — the outer display is not a small screen, it is a differently-shaped one. Layouts break on the inner display because of width, and on the outer display because of proportion.
In CSS pixels, for the web
CSS pixels correspond to points, so a page on the unfolded inner display gets a
viewport around 626 CSS pixels wide, and about 466 on the closed outer
display. The device pixel ratio is 3, so devicePixelRatio reports 3 and your
@3x assets are the right ones.
626 lands above most “tablet” breakpoints and below most “desktop” ones, which is its own problem — covered in websites on iPhone Duo. If you are writing a media query for this device, write it against a range rather than a device width: the viewport changes while the page is open, as the phone folds.
The aspect ratio is the real change
1878 × 2670 is an aspect ratio of about 1.42, against 2.17 on an iPhone 18 Pro. That is the number that actually breaks layouts, and it is the reason a full-screen 16:9 video letterboxes so heavily on the inner display.
Apple describes the two displays as sharing an aspect ratio, and for design purposes they effectively do: the published pixel dimensions put them about 2% apart, at 1.42 and 1.45. Lay out for a range rather than either number.
The reference
The full table, with physical sizes, PPI, reported size classes and the comparison against iPhone 18 Pro, lives on our iPhone Duo display reference. It now shows the division inline, so the arithmetic is on the page rather than in a footnote.
If you would rather not audit your own layout for hard-coded dimensions, that is the first thing our iPhone Duo audit looks for — it is usually the single largest source of visible breakage.