Industry standard to avoid side jumping app

[eonist]

Now I have enough deep research. Here is the honest, well-sourced answer:

---

What the Community Actually Does About This

After studying the broader macOS ecosystem, here is the real picture. The situation is more nuanced than your current code treats it.

The Fundamental Truth: NSPopover Was Never Designed for Dynamic Resizing While Visible

Apple's own documentation states that NSPopover re-anchors any time contentSize changes while shown . This is not a bug — it is by design. The popover's position is entirely derived from its anchor rect + contentSize. Change one, and AppKit recomputes both X and Y from scratch using the status button's current screen coordinates, which due to coordinate system transforms ends up being wrong almost every time in a status bar context.

This means there is no safe, non-hacky way to resize an NSPopover while it is visible. Every approach you have tried — setFrameSize, contentSize writes, preferredContentSize KVO — all trigger this re-anchor. That's confirmed across dozens of Stack Overflow threads and open-source projects.

---

What Other Apps Actually Do (3 Proven Patterns)

Pattern 1 — Fix Size at Open, Let Content Scroll (Most Common)

The overwhelmingly dominant pattern in real-world status bar apps. The popover opens at a fixed or max-content-fitted size. All dynamic content uses ScrollView internally so the frame never needs to change. Apps like Lungo, Pockity, and virtually every Sindre Sorhus utility use this.

The main branch of runner-bar already does this correctly — fittingSize is read once before show(), height is clamped to maxHeight: 620, and ScrollView handles overflow. This works.

Pattern 2 — Abandon NSPopover: Use NSPanel Instead

A very significant chunk of serious macOS menu bar apps — including productivity tools like those described in and — fully abandon NSPopover in favour of a manually-positioned NSPanel. The reason:

"Every possible case for when the popover should be hidden needed to be manually listened for. Overall it felt like I was fighting against OSX way more than I should have."

With NSPanel, you position it yourself using the status button's screen coordinates, and you resize it freely with setFrame() — at any time, while visible, with zero re-anchor issues because NSPanel has no anchor concept at all.

// NSPanel approach — resize freely while visible, no jump ever
let buttonFrame = buttonWindow.convertToScreen(button.frame)
let x = buttonFrame.midX - panel.frame.width / 2
let y = buttonFrame.minY - panel.frame.height - 4
panel.setFrameOrigin(NSPoint(x: x, y: y))
// Later, while visible — SAFE:
panel.setFrame(NSRect(origin: panel.frame.origin, size: newSize), display: true, animate: false)

Pattern 3 — MenuBarExtra(.window) (macOS 13+)

Apple's native SwiftUI API since Ventura. Automatically handles anchoring, dismissal, and content sizing. Dynamic height just works because Apple owns the entire rendering pipeline. The caveat: limited customisation and known layout issues with ScrollView in some macOS versions.

---

What This Means for runner-bar

The current NSPopover architecture on main is correct for what NSPopover can reliably do: measure once at open, show at fixed height, scroll internally. The fix pushed in the last commit (restore nav state before measuring fittingSize) is also correct — it ensures Settings and detail views get their proper height at open time.

The only remaining gap is: if you need the popover to grow taller while open (e.g. "Load 10 more actions…" expands the list), you cannot do that with NSPopover without jumping. The choices are:

1. Accept the cap — maxHeight: 620 with internal scroll. This is what every single comparable app does.
2. Switch to NSPanel — gives you full resize freedom at the cost of implementing your own dismiss-on-outside-click, full-screen app support, and mission control handling.
3. Switch to MenuBarExtra(.window) — simplest, but loses the fine-grained AppKit control you've built.

The jump regression you keep hitting is not a code quality problem — it is the documented, intentional behaviour of NSPopover.contentSize. The only real fix is to never write to it while shown. Your main branch already does that correctly.

[eonist]

Good research gathered. Here's a thorough honest assessment based on what I've found across multiple sources:

What the research actually says about NSPopover side-jumps

The fundamental problem is AppKit's NSPopover re-anchoring behavior — documented across Stack Overflow, Apple Developer Forums, and real open-source app codebases. Here's the actual landscape:stackoverflow

The root cause (confirmed by multiple sources)

Any call to popover.contentSize while the popover is visible causes NSPopover to re-calculate its anchor position, which can shift it horizontally. This is hardcoded AppKit behavior. All the approaches that actually work avoid this entirely.stackoverflow

What proven apps actually do

Approach | How it avoids jump | Who uses it -- | -- | -- Fix size before show() | Never touch contentSize after shown | Most tutorials, nilcoalescing.com guide nilcoalescing Fixed frame(width:height:) on SwiftUI root | SwiftUI never asks for more space | nilcoalescing MenuBarExtra example nilcoalescing NSMenu with NSHostingView instead of NSPopover | No NSPopover at all = no re-anchor bug | VPN Peek dev post dev, many others MenuBarExtra(.window) scene | Apple's own modern API handles positioning | nilcoalescing.com guide nilcoalescing

The honest finding: your main branch approach is already correct

The pattern in main — read fittingSize once before show(), width is always fixed, navigate() is a pure rootView swap with zero sizing — is precisely what every real-world guide recommends. The side-jump you're still seeing is not caused by AppDelegate logic — it's something else changing contentSize while the popover is shown. Two likely culprits to check in the branch's SwiftUI views:stackoverflow

1. PopoverMainView or ScrollView — does it have any .onChange that triggers a frame/height change?

2. The live poll (RunnerStore.shared.onChange) — if this causes a SwiftUI state update that forces the hosting view to relayout and emit a new intrinsicContentSize, AppKit can pick that up and re-anchor even without explicit contentSizecalls

The real long-term fix

Multiple experienced devs have concluded NSPopover simply isn't the right tool for dynamic-content status bar apps. The side-jump-proof approaches are:dev

• MenuBarExtra with .menuBarExtraStyle(.window) — Apple's own modern API, introduced macOS 13, handles all anchor logic internallynilcoalescing

• NSMenu + NSHostingView — no NSPopover, no re-anchoring possible, instant dismiss behavior, feels like a native Mac appdev

The branch work is building a redesigned popover on the old NSPopover foundation. If the side-jump persists even with the stable main sizing pattern, the most durable fix is migrating to MenuBarExtra(.window) — which is exactly what modern SwiftUI-first status bar apps do and completely bypasses the NSPopover re-anchor bug. Should I look into what that migration would involve for runner-bar specifically?

Good research gathered. Here's a thorough honest assessment based on what I've found across multiple sources:

What the research actually says about NSPopover side-jumps

The fundamental problem is AppKit's NSPopover re-anchoring behavior — documented across Stack Overflow, Apple Developer Forums, and real open-source app codebases. Here's the actual landscape: [stackoverflow](https://stackoverflow.com/questions/14449945/resize-nspopover-after-it-is-shown)

The root cause (confirmed by multiple sources)

Any call to popover.contentSize while the popover is visible causes NSPopover to re-calculate its anchor position, which can shift it horizontally. This is hardcoded AppKit behavior. All the approaches that actually work avoid this entirely. [stackoverflow](https://stackoverflow.com/questions/14449945/resize-nspopover-after-it-is-shown)

What proven apps actually do

Approach	How it avoids jump	Who uses it
Fix size before show()	Never touch contentSize after shown	Most tutorials, nilcoalescing.com guide nilcoalescing
Fixed frame(width:height:) on SwiftUI root	SwiftUI never asks for more space	nilcoalescing MenuBarExtra example nilcoalescing
NSMenu with NSHostingView instead of NSPopover	No NSPopover at all = no re-anchor bug	VPN Peek dev post dev, many others
MenuBarExtra(.window) scene	Apple's own modern API handles positioning	nilcoalescing.com guide nilcoalescing

The honest finding: your main branch approach is already correct

The pattern in main — read fittingSize once before show(), width is always fixed, navigate() is a pure rootView swap with zero sizing — is precisely what every real-world guide recommends. The side-jump you're still seeing is not caused by AppDelegate logic — it's something else changing contentSize while the popover is shown. Two likely culprits to check in the branch's SwiftUI views: [stackoverflow](https://stackoverflow.com/questions/69877522/how-to-position-nspopover-in-status-bar-application-macos)

1. PopoverMainView or ScrollView — does it have any .onChange that triggers a frame/height change?
2. The live poll (RunnerStore.shared.onChange) — if this causes a SwiftUI state update that forces the hosting view to relayout and emit a new intrinsicContentSize, AppKit can pick that up and re-anchor even without explicit contentSize calls

The real long-term fix

Multiple experienced devs have concluded NSPopover simply isn't the right tool for dynamic-content status bar apps. The side-jump-proof approaches are: dev

• MenuBarExtra with .menuBarExtraStyle(.window) — Apple's own modern API, introduced macOS 13, handles all anchor logic internally [nilcoalescing](https://nilcoalescing.com/blog/BuildAMacOSMenuBarUtilityInSwiftUI)
• NSMenu + NSHostingView — no NSPopover, no re-anchoring possible, instant dismiss behavior, feels like a native Mac app [dev](https://dev.to/heocoi/what-i-learned-building-a-native-macos-menu-bar-app-4im6)

The branch work is building a redesigned popover on the old NSPopover foundation. If the side-jump persists even with the stable main sizing pattern, the most durable fix is migrating to MenuBarExtra(.window) — which is exactly what modern SwiftUI-first status bar apps do and completely bypasses the NSPopover re-anchor bug. Should I look into what that migration would involve for runner-bar specifically?

[eonist]

The MEMORY.md from the Just10 project — another macOS status bar SwiftUI app — is very instructive and contradicts the current approach. Here's a complete picture of what the research shows:github

What other apps actually do

The real root cause you're hitting

The Just10 project (another status bar SwiftUI app with the same exact bug history) documents the actual two-part fixclearly:github

Fix 1: hostingController.sizingOptions = [] — STOP using .preferredContentSize. It auto-propagates preferredContentSizeon every SwiftUI update and that is what makes the popover drift. The correct setting is empty [].

Fix 2: Fixed statusItem slot width via NSStatusItem.squareLength or a fixed pixel value — never variableLength. Any time the slot resizes, NSPopover re-anchors and shifts. Since RunnerBar already uses squareLength, this is fine.

This directly contradicts the approach taken in the last two commits. sizingOptions = .preferredContentSize was the source of the problem, not the solution. Every view content change causes the hosting controller to push a new preferredContentSize to NSPopover while it is shown — and NSPopover re-anchors on every receive.

What the vbat.dev article actually saysvbat

The article confirms: when preferredContentSize is larger than the popover's allowed size, it truncates in an unexpected dimension. The idealWidth: 420 trick is only needed because .preferredContentSize is being used. If you drop .preferredContentSizeentirely you don't need idealWidth on every view either.

The correct architecture (what stable apps use)

Concern | Correct approach -- | --

What needs to change

The last commit (eeac205d) set sizingOptions = .preferredContentSize — that must be reverted to [] (or simply removed, since []is the default). The idealWidth: 420 additions to JobDetailView, ActionDetailView, StepLogView can stay (they're harmless and correct for layout), but the core of the fix needs to go back to the pre-preferredContentSize model with one critical difference: remeasurePopover() must stay dead and height is set only once before show(). Detail views use maxHeight: .infinity to fill the existing frame height — no resize after show.

The simplest correct fix is:github

1. controller.sizingOptions = [] (revert the preferredContentSize change)

2. Keep remeasurePopover() deleted

3. Set contentSize only in openPopover() before show()

4. Accept that height doesn't live-update while shown — it updates on next open

Want me to push that revert now?

The MEMORY.md from the Just10 project — another macOS status bar SwiftUI app — is very instructive and contradicts the current approach. Here's a complete picture of what the research shows: [[github](https://github.com/zunguyen/Just10/blob/main/MEMORY.md)](https://github.com/zunguyen/Just10/blob/main/MEMORY.md)

What other apps actually do

The real root cause you're hitting

The Just10 project (another status bar SwiftUI app with the same exact bug history) documents the actual two-part fix clearly: [github](https://github.com/zunguyen/Just10/blob/main/MEMORY.md)

Fix 1: hostingController.sizingOptions = [] — STOP using .preferredContentSize. It auto-propagates preferredContentSize on every SwiftUI update and that is what makes the popover drift. The correct setting is empty [].

Fix 2: Fixed statusItem slot width via NSStatusItem.squareLength or a fixed pixel value — never variableLength. Any time the slot resizes, NSPopover re-anchors and shifts. Since RunnerBar already uses squareLength, this is fine.

This directly contradicts the approach taken in the last two commits. sizingOptions = .preferredContentSize was the source of the problem, not the solution. Every view content change causes the hosting controller to push a new preferredContentSize to NSPopover while it is shown — and NSPopover re-anchors on every receive.

What the vbat.dev article actually says vbat

The article confirms: when preferredContentSize is larger than the popover's allowed size, it truncates in an unexpected dimension. The idealWidth: 420 trick is only needed because .preferredContentSize is being used. If you drop .preferredContentSize entirely you don't need idealWidth on every view either.

The correct architecture (what stable apps use)

Concern	Correct approach
sizingOptions	[] — empty. Never .preferredContentSize.
Height on open	Read fittingSize.height once before show()
Height on navigate	Do nothing. Keep the height from openPopover(). Let content scroll.
Width	Always fixedWidth constant, never measured
statusItem length	NSStatusItem.squareLength (already correct)

What needs to change

The last commit (eeac205d) set sizingOptions = .preferredContentSize — that must be reverted to [] (or simply removed, since [] is the default). The idealWidth: 420 additions to JobDetailView, ActionDetailView, StepLogView can stay (they're harmless and correct for layout), but the core of the fix needs to go back to the pre-preferredContentSize model with one critical difference: remeasurePopover() must stay dead and height is set only once before show(). Detail views use maxHeight: .infinity to fill the existing frame height — no resize after show.

The simplest correct fix is: [github](https://github.com/zunguyen/Just10/blob/main/MEMORY.md)

1. controller.sizingOptions = [] (revert the preferredContentSize change)
2. Keep remeasurePopover() deleted
3. Set contentSize only in openPopover() before show()
4. Accept that height doesn't live-update while shown — it updates on next open

Want me to push that revert now?