I saw this issue persisting through macOS 27 beta 1.

In macOS 26 and macOS 27 beta 1.

@DTS Engineer @Developer Tools Engineer I'm back and I filed a feedback about it: FB22039672 Hoping this would be useful.

Thank you for replying, Albert. I'm focusing on developing a macOS app using non-SwiftUI app lifecycle. I would need some SwiftUI-AppKit bridging in this project, and I might want to use Xcode Previews also on AppKit view controllers. I'm encountering the problem described in the first post, meaning that I can't experience both Xcode Previews and Storyboard well as expected. That popup window can be moved away, but it reappears back at the initial position every time I write source code. I created the first post a bit prematurely. Sorry for that. I noticed that it's nothing about the entry point. Instead, it's about making any instance of window controller from storyboards — instantiateInitialController() I used before, and other instantiate… methods. Just make a window controller from a storyboard and show its window (e.g. in applicationDidFinishLaunching(_:)). Only NSStoryboard trigger the problem, while NSNib don't. I also noticed that the mechanism behind the problem also works when the Xcode window is not full-screen. Those windows are just "hidden" in the background so we're not interrupted as in full-screen. From my conclusion I think this is a bug or technical limitation. I'll prepare the demo later if you're interested. If you intend to use SwiftUI, I would suggest sticking to that framework. Thanks for your suggestion. SwiftUI is better in most cases, but SwiftUI app lifecycle for macOS isn't powerful enough for me.

Sorry I just forgot about copying the NSImage instance. I didn't see performance issue loading about 50 resized images into menus in my workspace. Solved. let nsImage = { let returnValue = icon.copy() as! NSImage nsImage.size = CGSize(width: 16, height: 16) return nsImage }() Image(nsImage: nsImage)

It's been troubling me too. We might never achieve lower latency unless using UIUpdateLink (WWDC24 What’s new in UIKit). However, I failed to trigger that low-latency mode. I think low-latency rendering on iOS seems designed for drawing apps.

Oh perhaps this is just because Stage Manager's 3D mode (Show Recent Apps) works terribly in Metal 4? That 3D animation is expected to consume much less GPU and power.

The behavior of UIUpdateLink is kind of weird. _ UIUpdateLink.isEnabled: By default, the value of this property is true. No. I must explicitly write updateLink.isEnabled = true for all cases. _ @MainActor var wantsImmediatePresentation: Bool { get set } Hmm, yes and no. Setting this property DOESN'T WORK. I wonder if this intended why there's even isImmediatePresentationExpected.

Days passed and I've been accustomed to use open with environment variables. Well, a plist key for MTL_HUD_ELEMENTS would be trivial for me… But I rely on Metal HUD pretty much. With this I could easily tell when my XDR display went into bad mood. (Game graphics stuttering during brightness change in XDR displays)

Also some games may capture input, making configuration panel (Metal HUD > Show Configuration Panel) particularly hard to use.

I did't fully read the documentation and misunderstood this API. Scene.windowIdealSize(_:) is for zooming in macOS. (The command "Window" > "Zoom" can trigger it.) This also explains why there exists WindowIdealSize.maximum, I think. For my needs, I used Scene.defaultSize and people would see my designed window size on first-time window presentation. WindowGroup { Color.accentColor.opacity(1/4) .frame(minWidth: 500, minHeight: 500) .frame(idealWidth: 800, idealHeight: 800) } // For window zooming (a macOS feature), // which can be accessed via double-clicking the window title bar (see Settings). .windowIdealSize(.fitToContent) // For window size on first presentation .defaultSize(width: 640, height: 640) In this example, people will see 640640 window for the first time. Also, when people zoom this window, it expands to 800800, not as large as it can.

Problems gone 16.4 beta (16F1t). Seems working fine on all macOS.

Problem persists and behaves in the same way in a fresh macOS 15.5 beta (24F5042g). I used UTM as a Virtualization environment. bringing approximately 2 watts of power load to my Mac I'm new to Apple silicon therefore I wrongly measured the power consumption. It seems to be 0.15W ~ 0.2W on M4 and 6W on virtualized M4.