Same issue here with a Flutter app running as "Designed for iPad" on Apple Silicon (macOS 26), so this is not specific to SwiftUI: it sits in the UIKit lifecycle layer that every framework relies on.
Reproduction (reliable for us, but not on every attempt)
Run the app in a normal window (not full screen).
Switch to another app that is in full screen.
Lock the Mac and close the lid, wait a few minutes.
Wake the Mac and go back to the app window.
What we logged
On lock, the app receives UIApplication.didEnterBackgroundNotification (and the scene didEnterBackground), as expected.
On wake, the window is visible again but no willEnterForeground / didBecomeActive is ever delivered. UIApplication.shared.applicationState stays .background (2) while the user is looking at the window and clicking in it.
Touch/pointer events are still delivered to the app, but because the app believes it is in the background, the renderer stays stopped, so nothing redraws.
Switching the window to full screen makes macOS send the foreground notifications and everything works again; going back to windowed sends didEnterBackground again and the app freezes again.
Workaround
Since a click or hover can only reach a window that is visible, we treat pointer input received while applicationState == .background as proof the window is in the foreground, and, only when ProcessInfo.processInfo.isiOSAppOnMac is true, we post the notifications macOS should have sent:
NotificationCenter.default.post(name: UIApplication.willEnterForegroundNotification, object: UIApplication.shared)
NotificationCenter.default.post(name: UIApplication.didBecomeActiveNotification, object: UIApplication.shared)
This restores rendering immediately (just moving the mouse over the window is enough). applicationState itself still reports .background afterwards, so code that reads it directly is not fixed by this.
