Reported twice. The first answer only moved the menu twenty points, because I was looking at the menu — and the space was not going there.
The margin was being charged for twice
tvOS insets the whole scene by 80pt horizontally. Every screen in the app then adds its own tvSafeHorizontal inside that. Both exist for exactly the same reason — a television that crops the edges of the picture — and stacked, they put the first poster 285pt into a 1920pt screen. The Android app, which draws edge to edge and keeps a single 48dp margin of its own, puts it at 96.
So the shell takes the horizontal safe area over itself, and the app's own token is the only margin left. Same for the pushed screens, which had the same double-count one level up and a 176pt indent.
Vertical is left alone — nothing was stacking there, and the top title and the bottom rail both want the room.
Measured, not judged by eye
| before | after | |
|---|---|---|
| menu pills | 98pt | 60pt |
| first poster | 285pt | 247pt |
| right edge of a settings card | 176pt from the edge | 96pt |
60pt for the pills is a deliberate step inside Apple's 80pt horizontal recommendation: it is the number Apple itself uses for the top and bottom edges, and it clears the 2.5% overscan a set that still crops would take. If anything is ever clipped on an older television, railLeadingPadding is the one number to raise.
And what the grey band actually was
Home and Settings were both scanned line by line for a tone step. There is none, and there never was one on the flat screens — the band was the Home backdrop stopping where the menu column stopped, which 1.0.10 fixed. If you were still seeing it, that release is the one to check against: the screenshot in the report is running 1.0.8.
164 unit tests, 8 UI tests.
The IPA is unsigned — sideload it with your own signing.