In my apps, I have a requirement to display an image of the application icon is certain circumstances. This is fairly straightforward for iOS/iPadOS and it used to be straightforward for macCatalyst. For MacCatalyst, this is no longer true (at least since macOS 26). This is because the app icon is now stored as an .icns file and (in the case of using an IconComposer icon), the `'png' in the Asset Catalog now has an unknown name. So the following code no longer works: public extension Bundle { var icon: UIImage? { #if targetEnvironment(macCatalyst) guard let iconName = infoDictionary?["CFBundleIconName"] as? String else { return nil } return UIImage(named: iconName, in: self, compatibleWith: nil) #else guard let icons = infoDictionary?["CFBundleIcons"] as? [String : Any] else { return nil } guard let primaryIcon = icons["CFBundlePrimaryIcon"] as? [String : Any] else { return nil } guard let iconFiles = primaryIcon["CFBundleIconFiles"] as? [String] else { return nil } guard let file = iconFiles.last else { return nil } return UIImage(named: file, in: self, compatibleWith: nil) #endif } The obvious solution is to place an Image in the Asset Catalog which I can access, but this is a maintenance headache. What I would actually like to do is either create a UIImage directly from the .icns file, or access the .png file in the Asset Catalog (which has a name beginning with the icon file name, but has additional characters in its name that I don't know). Can you help?

Hello everyone, I have a question regarding the Place Card API I'm using .mapFeatureSelectionAccessory(.automatic) to get information about a POI on the Map The trouble I have is that it forces me to use Apple Maps for directions, which isn't ideal for my use case For example, I support commercial navigation, including large units such as trucks, and I have my own routing engine for this Is there a way to handle the directions via my routing engine instead? Is there a modifier I'm missing, or should I suggest this as an enhancement? Thanks, great work MapKit team

I am seeing a weird crash from Xcode 27 Beta 3 when building a variadic type DynamicProperty that also needs SwiftUI.State. This does not crash from Xcode 26. Here is a repro: import SwiftUI struct Repeater<each Input>: DynamicProperty { @State private var storage = Storage() private var input: (repeat each Input) init(_ input: repeat each Input) { self.input = (repeat each input) } } extension Repeater { final class Storage { } } @main struct CrashDemoApp: App { private var repeater = Repeater(1) var body: some Scene { WindowGroup { EmptyView() } } } Here is the crash: Thread 1 Queue : com.apple.main-thread (serial) #0 0x000000019a93aec0 in swift::TargetMetadata<swift::InProcess>::isCanonicalStaticallySpecializedGenericMetadata () #1 0x000000019a946b38 in performOnMetadataCache<swift::MetadataResponse, swift_checkMetadataState::CheckStateCallbacks> () #2 0x000000019a8c85f0 in swift_checkMetadataState () #3 0x00000001004a2c78 in type metadata completion function for Repeater () #4 0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize () #5 0x000000019a94c870 in swift::MetadataCacheEntryBase<swift::GenericCacheEntry, void const*>::doInitialization () #6 0x000000019a94f820 in swift::LockingConcurrentMap<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage<swift::GenericCacheEntry, (unsigned short)14>>::getOrInsert<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor<swift::InProcess> const*&, void const* const*&> () #7 0x000000019a93c714 in _swift_getGenericMetadata () #8 0x00000001004a4190 in __swift_instantiateGenericMetadata () #9 0x00000001004a2a5c in type metadata accessor for Repeater () #10 0x00000001004a5094 in type metadata accessor for Repeater<Pack{Int}> () #11 0x00000001004a4fcc in type metadata completion function for CrashDemoApp () #12 0x000000019a9543bc in swift::MetadataCacheEntryBase<(anonymous namespace)::SingletonMetadataCacheEntry, int>::doInitialization () #13 0x000000019a8d2ae0 in swift_getSingletonMetadata () #14 0x00000001004a479c in type metadata accessor for CrashDemoApp () #15 0x00000001004a473c in static CrashDemoApp.$main() () #16 0x00000001004a4a34 in main () #17 0x0000000186e47e00 in start () Here is a repo to demo: https://github.com/vanvoorden/2026-07-17 Please let me know if you have any ideas about that. Thanks!

Hello， We’re seeing an iPad-specific Launch Screen issue related to multitasking window sizes. Environment Device: iPad (iPadOS 26) Device orientation: Landscape App is launched in a small window where the app window is portrait-shaped (width < height) Issue When the iPad is in landscape but the app is launched as a portrait-shaped small window, the LaunchScreen.storyboard appears to be rendered/layouted as landscape, not matching the actual window geometry. As a result, the Launch Screen content is clipped / partially missing (we see blank/empty area at the bottom during launch). After the app finishes launching, our first view controller uses the correct window size and the UI looks fine — the problem is mainly during the Launch Screen phase. What we checked LaunchScreen.storyboard uses Auto Layout and is expected to adapt to screen/window size. This only reproduces when the device orientation and the app window aspect ratio don’t match (landscape device + portrait-shaped app window, or vice versa). When device orientation and window shape are aligned, the Launch Screen displays correctly. Question Is it expected that iPadOS renders LaunchScreen.storyboard based on the interface orientation / size class rather than the actual window bounds in multitasking scenarios? If not expected, what is the recommended way to ensure the Launch Screen matches the app’s actual window size/aspect ratio at launch (without using code, since Launch Screen is static)? Are there any additional diagnostics or recommended steps to help us investigate and confirm the root cause (e.g., specific logs, APIs/values to capture at launch such as UIWindowScene bounds, interfaceOrientation, size classes, or any guidance on how Launch Screen snapshots are chosen/cached in multitasking)? Thank you.

macOS 27 developer beta 5 introduces a bug where an NSTrackingSeparatorToolbarItem in a toolbar causes a bar to appear under the toolbar, overlaying the content. I have a blog post about this at: https://www.virtualsanity.com/202608/nstrackingseparatortoolbaritem-causes-white-bar-over-top-of-content-in-macos-27-developer-beta-5/ I reported this as FB24266969. A sample project and a screenshot are included in both the blog post and the feedback report.

Feedback ID: FB23086400 On iOS 27 beta 1, .scrollEdgeEffectStyle(.soft, for: .top) on a List underneath a custom .safeAreaBar(edge: .top) no longer renders the progressive fade-blur. The top edge is fully transparent — scrolled rows pass under the bar with no visual treatment at all, as if scrollEdgeEffectDisabled() had been applied. What I've verified so far: .hard renders correctly in the exact same hierarchy; only .soft is affected. The same binary works correctly on iOS 26.x Xcode preview. I'm building with Xcode 26.3 (iOS 26 SDK). Minimal reproduction: import SwiftUI struct EdgeEffectRepro: View { enum Style: String, CaseIterable, Identifiable { case automatic, soft, hard var id: Self { self } var value: ScrollEdgeEffectStyle { switch self { case .automatic: .automatic case .soft: .soft case .hard: .hard } } } @State private var style: Style = .soft @State private var useSystemBarOnly = false var body: some View { NavigationStack { List(0..<60, id: \.self) { i in Text("Row \(i)") .frame(maxWidth: .infinity, alignment: .leading) .listRowBackground( i.isMultiple(of: 2) ? Color.orange.opacity(0.45) : Color.teal.opacity(0.45) ) } .scrollIndicators(.hidden) .scrollEdgeEffectStyle(style.value, for: .top) .safeAreaBar(edge: .top) { if !useSystemBarOnly { VStack(spacing: 8) { HStack { Text("Custom Top Bar") .font(.system(size: 28, weight: .bold)) Spacer() } HStack { Text("Second row (e.g. date range picker)") .font(.caption) .foregroundStyle(.secondary) Spacer() } } .padding(.horizontal) } } .safeAreaInset(edge: .bottom) { VStack(spacing: 8) { Picker("Edge effect style", selection: $style) { ForEach(Style.allCases) { Text($0.rawValue).tag($0) } } .pickerStyle(.segmented) Toggle("System bar only (control group)", isOn: $useSystemBarOnly) .font(.caption) } .padding() .background(.regularMaterial) } .navigationTitle("EdgeEffect Repro") .navigationBarTitleDisplayMode(.inline) } } } Steps: run on iOS 27 beta 1, set the picker to soft, scroll rows under the bar. Expected: fade-blur as on iOS 26. Actual: fully transparent. Switch to hard: renders fine.

Any view that is content for the tabViewBottomAccessory API fails to retain its state as of the last couple of 26.1 betas (and RC). The loss of state happens (at least) when the currently selected tab is switched (filed as FB20901325). Here's code to reproduce the issue: struct ContentView: View { @State private var selectedTab = TabSelection.one enum TabSelection: Hashable { case one, two } var body: some View { TabView(selection: $selectedTab) { Tab("One", systemImage: "1.circle", value: .one) { BugExplanationView() } Tab("Two", systemImage: "2.circle", value: .two) { BugExplanationView() } } .tabViewBottomAccessory { AccessoryView() } } } struct AccessoryView: View { @State private var counter = 0 // This guy's state gets lost (as of iOS 26.1) var body: some View { Stepper("Counter: \(counter)", value: $counter) .padding(.horizontal) } } struct BugExplanationView: View { var body: some View { ScrollView { VStack(alignment: .leading, spacing: 16) { Text("(1) Manipulate the counter state") Text("(2) Then switch tabs") Text("BUG: The counter state gets unexpectedly reset!") } .multilineTextAlignment(.leading) } } }

We are experiencing issues during extended automated test executions on iOS devices. During long-duration test runs that involve a high volume of interactions with the device under test, the socket connection is unexpectedly terminated. When this occurs, the automation session is disrupted and the test run fails. We would like to better understand the root cause of this behavior and determine whether it is related to the automation framework, the underlying iOS platform, or another system-level constraint. We have the following questions: Are there any iOS security mechanisms or system protections that may be triggered after a high number of automated interactions, resulting in the termination of an active socket connection? Does iOS impose any runtime limitations, session timeouts, resource restrictions, or inactivity thresholds that could impact long-running automation sessions? Are there any known conditions under which iOS may terminate or reset socket connections during extended periods of intensive device interaction? Any guidance on troubleshooting steps, relevant system logs, or known platform limitations would be greatly appreciated.

Hi everyone, We're experiencing a bug on iOS 26 that only occurs when the user has Reduce Transparency enabled in Accessibility settings. App structure: Our app uses a TabView with a standard tab bar. Inside each tab, we use a NavigationStack. The tab bar is visible on root-level screens, and hidden on all pushed destinations using: .toolbar(.hidden, for: .tabBar) The problem: On iOS 26 with Reduce Transparency off (Liquid Glass active) — everything works correctly. The tab bar hides as expected. On iOS 26 with Reduce Transparency on — a white bar appears at the bottom of the screen in every place where the tab bar is hidden. This white bar: Overlaps content at the bottom of the screen. Blocks scroll, tap, and all user interactions in that area. We also tried: .toolbarBackground(.hidden, for: .tabBar) Removing all custom UITabBarAppearance configuration The only workaround we found is setting UIDesignRequiresCompatibility = YES in Info.plist, which reverts the entire app to the pre-iOS 26 design — not a viable long-term solution. What can we do? Thanks in advance.

I’m seeing a layout regression in SwiftUI on iPadOS 26.4 involving NavigationSplitView inside a TabView. When a NavigationSplitView is embedded in a TabView, the sidebar toolbar appears to reserve too much vertical space. There is a large vertical gap between the top edge of the sidebar and the sidebar collapse/toggle icon. It looks as if the sidebar toolbar itself has become much taller than expected. The same NavigationSplitView layout is rendered correctly when it is shown directly without being embedded in a TabView. Environment: iPadOS 26.4 or later SwiftUI iPad TabView NavigationSplitView inside one tab Expected behavior The sidebar toolbar should use its normal height, as it does when the same NavigationSplitView is shown without a surrounding TabView. The sidebar collapse/toggle icon should appear close to the top of the sidebar, without a large empty gap above it. Actual behavior When the NavigationSplitView is hosted inside a TabView, the sidebar toolbar area becomes excessively tall. A large empty space appears above the sidebar collapse/toggle icon. This only happens in the TabView setup. Rendering the same NavigationSplitView directly does not show the issue. Feedback I also filed this as Feedback Assistant report: FB22645938 Has anyone else seen this behavior since iPadOS 26.4? Is this an intentional layout change, or is there a supported way to avoid this additional top inset when using NavigationSplitView inside TabView? Reproduction import SwiftUI struct ContentView: View { enum AppTab { case first case second } @State private var selectedTab: AppTab = .first var body: some View { TabView(selection: $selectedTab) { Tab("First", systemImage: "sidebar.leading", value: .first) { NavigationSplitView { List { Section("Sidebar Content") { ForEach(1...20, id: \.self) { index in Text("Item \(index)") } } } .navigationTitle("Sidebar") .toolbar { ToolbarItem(placement: .topBarLeading) { Button { // action } label: { Image(systemName: "plus") } } } } detail: { Text("Detail") } } Tab("Second", systemImage: "doc", value: .second) { Text("Second tab") } } } }

I need to display verse so that if a line exceeds the right margin, it is continued on the next line but indented. In UIKit this is easy by using NSParagraphStyle and headIndent and firstLineHeadIndent. But none of this is available on SwiftUI on the Apple Watch, which marks a big step back compared to WatchKit. Is there any way to display text indented in this way? I attach two screenshots, one with the indentation and one without. The one with indentation is far more readable!

Did VisionOS get the LazyVGrid Performance Updates that other platforms received? I’m observing that a LazyVGrid that works well on iPhone, iPad, and Mac appears to hitch and jitter as cells exit and renter the lazyVGrid on VisionOS. It really feels like it did not get the same behavior changes as the other platforms. I observe the scrollbar expands as cells leave the top of the grid, and each “exit” of a row seems to cause a hitch. I’ve got rigidly defined cell frames, rigidly defined columns. I don’t think any cells frames are being invalidated during scroll… (there’s no way to check this with instruments, right?) I‘ve made several analysis passes myself and threw the Xcode Agent with Codex at it just to scan for stuff, but it’s starting to just guess at things. Any known issues with VisionOS?

I’ve hit a strange SwiftUI preview crash that happens on macOS previews when using a view inside a List’s ForEach, resulting in the error Fatal Error in TableViewListCore_Mac2.swift. Only crashes macOS preview - iPhone/iPad preview doesn't crash. Doesn't crash when actually running the app. Here’s a minimal reproducible example, causing the preview to crash. XCode: Version 26.0.1 (17A400) MacOS: 26.0.1 (25A362) import SwiftUI struct Item: Identifiable { let id = UUID() let name: String } struct ItemRow: View { let item: Item var body: some View { HStack { Button(action: {}) { Image(systemName: "play") } Text(item.name) Spacer() ProgressView() } } } struct ContentView: View { @State private var items = [ Item(name: "Item A"), Item(name: "Item B"), ] var body: some View { List { ForEach(items) { item in ItemRow(item: item) } } } } #Preview("Content view") { ContentView() } #Preview("Item row") { ItemRow(item: Item(name: "Item A")) } If I wrap the row in a container, like this: ForEach(items) { item in ZStack { ItemRow(item: item) } } the crash seems to disappear. Has anyone else seen this behavior? What might I be doing wrong? Any ideas about what could be causing this?

Hello, I found a difference in application lifecycle behavior between iPadOS 26.5 and iPadOS 27 beta when the app is running in the foreground and the iPad top button is pressed to put the device into sleep. Test condition Device: iPad App state: app is running in foreground (active) Action: press the top button once to put the device to sleep Observed via UIApplicationDelegate lifecycle callbacks Observed behavior iPadOS 26.5 The following callbacks are called in this order: applicationWillResignActive applicationDidEnterBackground iPadOS 27 beta The following callbacks are called in this order: applicationWillResignActive applicationDidBecomeActive applicationWillResignActive applicationDidEnterBackground Expected behavior I expected the lifecycle sequence on iPadOS 27 beta to be the same as, or at least consistent with, iPadOS 26.5 when the device is put to sleep from the foreground app state. In particular, I did not expect applicationDidBecomeActive to be called during the transition to sleep/background. Question Is this changed behavior expected in iPadOS 27 beta, or could this be a bug in the beta? If this is expected, could you clarify the intended lifecycle behavior when the top button is pressed and the device transitions to sleep? Thank you.

I am trying to use an NSSearchToolbarItem using AppKit directly in Objective-C. If I perform a search and then click the cancel icon, my target/action is called while the NSSearchField still contains the search text (not yet cleared) and the delegate has not yet received the ending search invocation. In other words, it looks exactly the same as if the user had submitted the same search twice. Google's AI suggested using the controlTextDidChange method, but that was deprecated long ago. My current solution is to ignore searches that appear redundant (although they may not be, if the data being searched changes). This is on macOS 26.6.

Collapsing a NavigationSplitView sidebar from the toolbar button terminates the process in a right-to-left window — but only when the detail column's content carries a padding modifier. Remove the padding and it never crashes. Switch the window to left-to-right and it never crashes. AppKit raises an uncaught exception from -[NSWindow _postWindowNeedsUpdateConstraints] (the window is asked to update its constraints more times than it has views) while a SwiftUI NSHostingView re-invalidates its layout without ever settling. Environment: macOS 27.0 beta (26A5388g), MacBook Pro with Apple M5; Xcode 27.0 (27A5228h); Swift 6.4. Complete reproducer This is the whole app — no dependencies, no model, no table, no timer, no toolbar items of my own. @main struct PaddedDetailCrashApp: App { @State private var columns: NavigationSplitViewVisibility = .all var body: some Scene { Window(Text(verbatim: "Padded Detail"), id: "main") { NavigationSplitView(columnVisibility: $columns) { List { Text(verbatim: "Projects") Text(verbatim: "Archived") Text(verbatim: "Trash") } } detail: { Color.gray .padding(40) // <-- remove this and the crash goes with it } .environment(\.layoutDirection, .rightToLeft) } .defaultSize(width: 900, height: 600) } } Steps to reproduce: 1 - Build and run the code above, launched with the arguments that mirror the window itself: -AppleTextDirection YES -NSForceRightToLeftWritingDirection YES 2 - Click the toolbar's sidebar toggle repeatedly and quickly — roughly four clicks a second. 3 - The process terminates, in my measurements after about 8 toggles. The timing is essential. Each click has to land while the previous collapse is still animating. Clicking slowly, or scripting it so each click completes before the next begins, never reproduces it. Driving the toggle from the View menu (which changes the same state without animating) also never reproduces it.

I've found a repeatable difference in input-to-display latency on macOS depending only on how an application is launched. Launching an application normally: open -n /Applications/App.app consistently produces higher latency than directly running the exact same bundled executable: /Applications/App.app/Contents/MacOS/App I've reproduced this with a minimal Qt QPlainTextEdit application as well as Koi, Xcode, BBEdit, Sublime Text, and Zed. It reproduces across: Mac mini M2 Pro, macOS Sequoia 15.7.9 MacBook Air M4, macOS Tahoe 26.6.1 Minimal reproduction The Qt application is essentially just: import sys from PyQt6.QtWidgets import QApplication, QPlainTextEdit app = QApplication(sys.argv) editor = QPlainTextEdit() editor.resize(1200, 800) editor.show() sys.exit(app.exec()) I package this as a normal .app and compare: open -n dist/QtLaunchTest.app with: dist/QtLaunchTest.app/Contents/MacOS/QtLaunchTest Input-to-display latency is measured externally from generated keyboard input through to the corresponding visible pixel change on the display, with 200 measurements per run. Results (Launch method, avg, p95, p99) At 60 Hz: Open normally, 29.676 ms, 37.742 ms, 43.080 ms Direct Mach-O, 16.404 ms, 20.500 ms, 24.882 ms The p95 difference is 17.242 ms, compared with a 60 Hz frame interval of 16.667 ms. At 100 Hz: Open normally, 24.687 ms, 31.182 ms, 33.797 ms Direct Mach-O, 16.295 ms, 20.623 ms, 23.286 ms The p95 difference is 10.559 ms, compared with a 100 Hz frame interval of 10.000 ms. That relationship is what makes me suspect this is related to presentation/frame scheduling rather than application processing. This also happens with Xcode The same effect occurs when comparing normal and direct launches of Xcode. (Launch method avg p95 p99) On macOS Sequoia 15.7.9: Open normally, 23.433 ms, 29.886 ms, 31.877 ms Direct Mach-O, 15.787 ms, 19.494 ms, 20.480 ms On macOS Tahoe 26.6.1 on an M4 MacBook Air: Open normally, 35.830 ms, 40.122 ms, 53.996 ms Direct Mach-O, 23.639 ms, 27.233 ms, 37.855 ms Koi, BBEdit, Sublime Text, and Zed show the same direction of effect. Things I’ve ruled out so far The difference does not appear to be caused by Terminal. Direct execution remains fast after detaching the process, and using open on the Mach-O itself is also fast. Different LaunchServices forms (open -n, open -na, open -nb, open -b) all produce the slower behavior. I've also compared process QoS and final AppKit activation state, which are the same. Most importantly, application-side instrumentation does not show the additional latency. Input processing and painting complete quickly in both cases. The difference appears only when measuring through to the actual pixel change on the display. Question Is there some presentation, WindowServer, Core Animation, RunningBoard, or application-lifecycle state established when an application is launched through LaunchServices that could affect when completed rendering reaches the display? The refresh-rate result makes it look as though the normally launched application is reaching the display approximately one presentation opportunity later: Direct: input → update → paint → presentation N Normal: input → update → paint → presentation N+1 That's only a model based on the measurements. I haven’t directly observed the presentation sequence. I'm particularly interested in what APIs or Instruments traces could expose the difference between these two processes after they’ve reached the same active AppKit state. I've documented the full investigation, including additional measurements and tests, here: https://hackerman.ai/research/investigating-macos-input-to-display-latency/ Any pointers on what to instrument next would be appreciated.

Hello. Some users of my app experience crashes that mention PDFKit. I managed to find out what specific PDF file caused the crash and created a sample that demonstrates the issue and created a bug report in Feedback Assistant (FB22409977). Unfortunately I didn't get any answer for over a month, hence I'm writing it here so others can see that this is a known issue. The crash repro sample is very simple, it's just a PDFView that opens a bundled PDF file upon application lanunch. To cause the crash it is only needed to zoom-in and move around the page that has a table. The crash happens when the system tries to do some sort of OCR. The original crash report came from iPhone 11 user running iOS 26.3.1. Recently another user with iPhone 16 Pro Max running 26.5 experienced the same crash. Thread 12 Queue : PDFKWit.PDFDocument.formFillingQueue (serial) #0 0x000000018d320bd8 in PageLayout::GetBoundsForRangeWithinLine () #1 0x000000018d320c88 in PageLayout::GetBoundsForTextRange () #2 0x000000018d393028 in CGPDFTaggedNodeCreateCopyWithStringRange () #3 0x000000018d316630 in invocation function for block in TaggedParser::InsertLinkAnnotationsIntoStructureTree(CGPDFTaggedNode*, CGPDFPage*, PageLayout&) () #4 0x000000018d104f00 in CGPDFPageEnumerateAnnotations () #5 0x000000018d106968 in CGPDFPageCopyRootTaggedNode () #6 0x000000018d106710 in CGPDFPageInsertTableDescriptions () #7 0x00000001957a65b8 in +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] () #8 0x00000001957a3030 in +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] () #9 0x000000019584c018 in __31-[PDFView visiblePagesChanged:]_block_invoke () When CG_PDF_VERBOSE env variable is set, "New text range needs to be within the original node's text range." warning is printed to console several times before the crash happens.

For GNU Taler, we defined a custom URL scheme: "taler://". We want to have a SwiftUI PasteButton in our app which is only active/enabled when the user copied a talerURI, but not for other URIs (such as https:// or mailto://). Currently we use PasteButton(supportedContentTypes: [.url]) { providers in which works, but is also enabled when the copied text is some other URI, not only for "taler://". Can we define a UTType ".taler" for PasteButton to check whether the pasteBoard has indeed a talerURI? How?

I've got a single-window app whose main ContentView is a table of records. It has some menu commands, defined in my App file, that allow record-level operations (add, delete, process, etc). It also uses some framework-provided editing views (i.e. TextFieldView) for individual fields on each record. I'm having a lot of trouble implementing undo/redo. The menu commands don't have access to the Environment to obtain the undoManager there. The undoManager is nil during onAppear of the ContentView, so I can't set it into my view model before running some user-initiated action on the view itself. If I wire up custom Undo/Redo menu items with my own UndoManager, the TextFieldView undo no longer works. I even tried getting at the underlying NSWindowDelegate to provide my own UndoManager in windowWillReturnUndoManager, but that never gets called. What's the correct pattern to use here?