SwiftUi - Filling a wide-aspect screen

Question

TL;DR:

I can't draw an image exactly onto the full screen on wide-aspect (13:6) phones. If I observe the safe area, the error is (predictably) underscan. Using .edgesIgnoringSafeArea() goes (unexpectedly) too far in the other direction.

Update

Apple DTS have suggested this is a bug, refunded me one support incident, and invited me to submit a bug report. It is in the pipeline at https://feedbackassistant.apple.com/feedback/8192204

Caveat Lector

My presumptions about .scaledToFill might be wrong. I address that at the end.

Code

So elementary I can put it here and it won't even slow you down

struct ContentView: View {
    var body: some View {
        Image("testImage").resizable().scaledToFill()
//        .edgesIgnoringSafeArea(.all)
    }
}

Test Image

The Test Image is a landscape rectangle, proportioned at 13:6, like the wide phone. (E.g. the 812:375 proportion of the original iPhone X.) The gray periphery is not part of the image.

It has its sub-frames marked, that correspond to the narrow (older) phones (16:9) and pads (4:3).

Runtime Results

The Xcode project settings are explicitly landscape-only, for both pads and phones.

For narrow phones and all pads, the code above, observing safe areas, renders the Test Image like I expect:

But on wide phones, I can't get the red rect to coincide with the screen edges.

Wide Phones

With no call to .edgesIgnoringSafeArea(), that is we are observing safe area. Naturally, our image is mapped to a subset of the full screen.

With the call to .edgesIgnoringSafeArea(). I expected this to exactly fill the screen but it overscans:

Here is the Xcode view-hierarchy debugger's perspective on the previous: the image is being mapped to a rect larger than the full screen. Why?

Order of Events

If I reverse the order of modifiers, and call .edgesIgnoringSafeArea() before .scaledToFill(), I get aspect ratio distortion, which .scaledToFill() is supposed to prevent. (See circle become ellipse in screen shot.) An explanation of how these operations compose, and why they do not commute, might go a long way to answering my primary questions.

Workaround

I think the above should work, and I don't see why not. What does work — on wide phones — is to eliminate the .scaledToFill modifier. Then you get this. But it only works because the test image is already the exact aspect ratio as the display — not a very general solution.

Scale to Fill

In the restricted domain of landscape images and displays, I expect the operation of scale-to-fill on the 13:6 test image to be equivalent to (to have the semantics of):

1. Center the test image in the destination (container) rect, sized to fit entirely in the container.

• I have been expecting that ignoring safe areas means the "destination" will be the full screen, but that may be where I err.

2. Expand the test image, maintaining proportion and center, until one pair of sides coincides with those of the container.

• For narrower displays, the left and right edges will meet first, and the top and bottom will be inside the destination rect.

3. But don’t stop now. That would be scale to fit, or letterboxing.
4. Expand until your top and bottom coincide with those of the container.

• For narrower displays this means there will be content cropped on both sides
• For 13:6 displays all four image edges will to coincide with the display edges at the same time.

Estis

Answer 1

I do not know why .edgesIgnoringSafeArea() does not work as it should but here is a workaround that should help you.

    GeometryReader { geo in
       Image("testImage")
          .resizable()
          .scaledToFill()
          .frame(width: geo.size.width, height: geo.size.height)
    }
    .edgesIgnoringSafeArea(.all)

Update: Here is another way to do the same thing without GeometryReader:

Image("testImage")
    .resizable()
    .scaledToFill()
    .frame(minWidth: 0, maxWidth: .infinity, minHeight: 0, maxHeight: .infinity)
    .edgesIgnoringSafeArea(.all)

Jibheaded

Thank you, both your workarounds do work on the wide (13:6) phones, and on the pads, except for the 11-inch one, which stubbornly displays like my next-to-last (Order of Events) screenshot above. I see this bug/misfeature almost every day, since my apps use full-screen bg images that have to match pixel-for-pixel with foreground objects. I opened a Support Incident with Apple on 6 June, and have heard nothing but machine acks, and with WWDC probably nothing until July. So far you are the points-winner. – Estis

Well the aspect ratio of 11 inch iPad is 10:7, so the given aspect ratios can not fit even in theory. – Jibheaded

Aha, I had overlooked that. You are right, 1194/834 ≈ 10/7 (more like 63/44 but whatevs), not 4/3. This explains the lateral "underscan" on 11" pad -- it's not a bug. Thanks! Those numbers were staring me in the face, and I looked but did not read. – Estis

Apple DTS have suggested I file a bug report on this. Time to re-take all those screen shots with a higher-res test image. – Estis