I finally found the answer: "Optimize Interface for Mac" Had the same problem: "maximizing" the UIWindow made it about 1/3 too small using UIScreen.main.bounds, and about 50% too large with UIScreen.main.nativeBounds. Now, according to the UI guidelines, - https://developer.apple.com/design/human-interface-guidelines/mac-catalyst/overview/introduction/ "you can choose the "Optimize Interface for Mac" setting, or Mac idiom, in Xcode. With the Mac idiom, your app takes on an even more Mac-like appearance and the system doesn’t scale your app’s layout." This is in the same place where you enable macOS for the iOS/Catalyst app, under your project settings -- your project's target -- General -- Deployment Info. Change "Scale Interface to Match iPad" to "Optimize Interface for Mac." Here is how I changed my SceneDelegate -- scene willConnectTo: code: swift if let windowScene = scene as? UIWindowScene { let window = UIWindow(windowScene: windowScene) #if targetEnvironment(macCatalyst) if let titlebar = windowScene.titlebar, let sizes = windowScene.sizeRestrictions { titlebar.titleVisibility = .hidden titlebar.toolbar = nil sizes.minimumSize = window.screen.bounds.size sizes.maximumSize = window.screen.bounds.size } #endif window.rootViewController = UIHostingController(rootView: contentView) self.window = window window.makeKeyAndVisible() }

It would have been really helpful, @eskimo , if you would have just given a practical example. Being visually impaired, my greatest pet peeve of all is lack of good documentation in almost everything tech these days. And companies like Apple, with unlimited cash to hire good tech writers, have no excuse. Because, of course, on macOS, man ulimit does not help (it just spits out the General Commands Manual). Not helpful. Here is an actual manual page for ulimit (because Apple doesn't provide it, because, well, it's using an old version of FreeBSD, so who knows how compatible the other flags are): https://ss64.com/bash/ulimit.html And here is the flag to increase number of open file descriptors: -n The maximum number of open file descriptors. For example, before ulimit: pgbench -c 1000 -T 60 -p 6432 pgbench: error: need at least 1003 open files, but system limit is 256 pgbench: hint: Reduce number of clients, or use limit/ulimit to increase the system limit. OK, well, how? "...use ulimit..." great, thanks. Note the manual page has at least 24 argument flags!!! Increase limit for current Terminal session: ulimit -n 1004 Where 1004 is however many you need, may have to experiment. (Now how hard was that one-liner to document here? But when we all have to look it up, add up all those hours. Multiply that by 100 times per day for each of us.) pgbench -c 1000 -T 60 -p 6432 Now works.

TLDR: Surround any Swift UI updates in a: @State private var myStateVar: [MyState] = [] DispatchQueue.main.async { // ... do updates to myStateVar here } This was my problem, but Apple didn't help by changing SwiftUI, not telling us about it, not providing a stack trace, and not even providing a code lint in Xcode for state updates. Every other modern framework provides a stack trace back to our own code where we can figure out what we did wrong. It seems only Apple requires you to do some esoteric internal debug dump, send it to Apple, hold your breath, and hope to get a response. I was updating a SwiftUI Table view, and suddenly, a new version of SwiftUI on macOS (but probably doesn't matter which Apple OS), had this totally unhelpful crash: ForEach<Binding<Array>, UUID, TableRow<Binding>>: the ID 02A438DA-C928-4FCB-BA5F-518B2C476A6C occurs multiple times within the collection, this will give undefined results! Swift/ContiguousArrayBuffer.swift:675: Fatal error: Index out of range Totally unhelpful, right? And it's wrong. That ID does NOT appear more than once in the data collection itself. It's the way SwiftUI is handling the updates internally. My code worked for like 2 years until Apple did an update to SwiftUI that caused this crash. Here's my code. I am filtering a Table with a search field: struct ReplacementsView: View { var body: some View { VStack { searchField replacementsTable actionButtons } ... @State private var searchQuery = "" @State private var filteredReplacements: [Replacement] = [] private func filterReplacements() { /// THE PROBLEM IS HERE. Doing a UI @State update synchronously causes a crash here. if searchQuery.isEmpty { filteredReplacements = replacementsManager.replacements return } filteredReplacements = replacementsManager.replacements.filter { replacement in replacement.pattern.lowercased().contains(searchQuery.lowercased()) || replacement.replacement.lowercased().contains(searchQuery.lowercased()) } } private var searchField: some View { TextField("Search...", text: $searchQuery) .textFieldStyle(.roundedBorder) .padding([.top, .leading, .trailing]) .onChange(of: searchQuery) { filterReplacements() } } private var replacementsTable: some View { ScrollViewReader { proxy in Table($filteredReplacements, selection: $selection) { ... TableColumn("Replacement") { $row in TextField("", text: $row.replacement, onEditingChanged: { editing in if !editing { update(row) } }) .accessibilityTextContentType(.sourceCode) .onSubmit { update(row) } } ... Now, Poor ChatGPT can't even figure out SwiftUI because the documentation is horrible. The wealthiest company in the world should be able to hire tech writers!!! I wonder if Apple has more than 2 or 3 tech writers to cover all the developer documentation. And even then, 2 or 3 people full time should be able to do better than this. So finally, after much frustration, it helped me realize I needed to do this async: private func filterReplacements() { DispatchQueue.main.async { if searchQuery.isEmpty { filteredReplacements = replacementsManager.replacements return } filteredReplacements = replacementsManager.replacements.filter { replacement in replacement.pattern.lowercased().contains(searchQuery.lowercased()) || replacement.replacement.lowercased().contains(searchQuery.lowercased()) } } } That's it. That's all it was. Surrounded the state update with a DispatchQueue.main.async { ... } and ... voila! No crash. Now, if this is Apple best practice, why doesn't Apple's new AI in Xcode 16 lint this and yell at me that I should not be updating this synchronously? Why am I so angry? I am a visually impaired software engineer. It's hard enough for me to read gobs and gobs and gobs of posts and generated non-answers to get to the solution of a very simple problem. And I have to do this a hundred times a day. And this app I wrote is to fix accessibility on my Mac, because Apple's built-in text-to-speech is so very limited. I am angry at Apple because the average user has a hard time finding out how to use their stuff. They go on and on about how great they are on accessibility, yet no, they aren't. Accessibility is Apple's very last concern. Profits before people, always. I've been a Mac user since 2005, and grew up with an Apple //c. Steve Jobs understood people. Apple's current leadership doesn't. This is why Flutter is a million times better than SwiftUI. Flutter throws an exception and tells you not to update state while the build context is being rendered. Duh. And it runs on everything, not just Apple devices, which makes it that much more valuable. Now, I work in like 3 different languages/frameworks here, not solely on Apple stuff (probably makes me a black sheep here, not to mention being visually impaired and calling out Apple for its lack of true concern about accessibility), and Apple could be doing a lot more to help us, instead of making us spend hours and hours figuring out what Apple could have just told us in the documentation and in its own editor, Xcode, which is solely focused on Apple's ecosystem... and is the least accessible editor on the market, to boot. So why is Xcode so very, very horrible at helping us with this most basic issue? With the resources available to you, Apple, this treatment of your customers and users is not acceptable.