PDFView left-anchors to window edge instead of centering between sidebar and inspector (macOS Tahoe)

Question

Created Mar ’26

Replies 1

Boosts 0

Participants 2

I'm building a document viewer on macOS Tahoe with a 3-column NSSplitViewController (sidebar | detail | inspector), trying to replicate how Preview displays PDFs with the page centered in the visible gap between the panels, with content bleeding under them when panning or zooming.

I'm using the approach from Build an AppKit app with the new design (WWDC25):

detailItem.automaticallyAdjustsSafeAreaInsets = true

safeAreaInsets reports the correct values (e.g. left: 208, right: 240), and the frame does extend under both panels. But PDFView with autoScales = true anchors the page to the left edge of the window instead of centering it in the visible gap between the sidebar and inspector.

I can get the page to center correctly by constraining PDFView to view.safeAreaLayoutGuide, but then content no longer extends under the panels when panning or zooming, which defeats the whole purpose.

What's the correct way to center PDFView content within the visible gap while keeping the frame full-width so content bleeds under the panels?

I've attached pictures of how Preview does it. Skärmavbild 2026-03-31 kl. 01.49.52.png

Skärmavbild 2026-03-31 kl. 01.49.58.png

Answered by DTS Engineer in 888077022

Thanks for the clear writeup and screenshots — they made this easy to reproduce. With a 3-column NSSplitViewController + PDFView in macOS 26, I confirmed exactly what you're seeing. With detailItem.automaticallyAdjustsSafeAreaInsets = true, the detail view's frame extends under the panels and safeAreaInsets reports correct values — but PDFView's autoScales math positions and scales the page based on the full bounds, ignoring the safe-area region. The page anchors at the left of the bounds, partly under the sidebar, regardless of where the visible gap is.

I tested the workarounds that look like they should help, and none of them work:

Setting pdfView.additionalSafeAreaInsets to mirror the safe area — PDFView's scaling math doesn't read it.
Setting contentInsets on the internal scroll view (pdfView.documentView?.enclosingScrollView) with automaticallyAdjustsContentInsets = false — works for one layout pass, then autoScales recomputes against the full bounds on resize and reverts.
Disabling autoScales and computing scaleFactor manually from a safe-area-clipped width — the page still anchors against the full bounds, and you lose the fit-to-window behavior autoScales gives you on resize.

This is a real framework gap rather than something tunable from outside PDFView. The view's layout doesn't yet respect the safe-area pattern that the WWDC25 session "Build an AppKit app with the new design" documents, even though that's the recommended way to express "content extends under translucent panels." Please file a Feedback Report asking for PDFView to honor safeAreaInsets (or additionalSafeAreaInsets) when computing autoScales positioning and centering. If you post the FB number back here, we can track it.

For now, your fallback of constraining PDFView to view.safeAreaLayoutGuide is the most robust option, even though it gives up the bleed-under-panels effect — I know that's not what you were hoping for.

(Preview's behavior in your screenshots looks like custom layout rather than stock PDFView — I wouldn't expect the public API to match it pixel-for-pixel right now.)

Boost

Answer 1

DTS Engineer OP

Apple

20h

Recommended

Thanks for the clear writeup and screenshots — they made this easy to reproduce. With a 3-column NSSplitViewController + PDFView in macOS 26, I confirmed exactly what you're seeing. With detailItem.automaticallyAdjustsSafeAreaInsets = true, the detail view's frame extends under the panels and safeAreaInsets reports correct values — but PDFView's autoScales math positions and scales the page based on the full bounds, ignoring the safe-area region. The page anchors at the left of the bounds, partly under the sidebar, regardless of where the visible gap is.

I tested the workarounds that look like they should help, and none of them work:

Setting pdfView.additionalSafeAreaInsets to mirror the safe area — PDFView's scaling math doesn't read it.
Setting contentInsets on the internal scroll view (pdfView.documentView?.enclosingScrollView) with automaticallyAdjustsContentInsets = false — works for one layout pass, then autoScales recomputes against the full bounds on resize and reverts.
Disabling autoScales and computing scaleFactor manually from a safe-area-clipped width — the page still anchors against the full bounds, and you lose the fit-to-window behavior autoScales gives you on resize.

This is a real framework gap rather than something tunable from outside PDFView. The view's layout doesn't yet respect the safe-area pattern that the WWDC25 session "Build an AppKit app with the new design" documents, even though that's the recommended way to express "content extends under translucent panels." Please file a Feedback Report asking for PDFView to honor safeAreaInsets (or additionalSafeAreaInsets) when computing autoScales positioning and centering. If you post the FB number back here, we can track it.

For now, your fallback of constraining PDFView to view.safeAreaLayoutGuide is the most robust option, even though it gives up the bleed-under-panels effect — I know that's not what you were hoping for.

(Preview's behavior in your screenshots looks like custom layout rather than stock PDFView — I wouldn't expect the public API to match it pixel-for-pixel right now.)

0