FB20756572

This is slightly different on iOS 26.1 beta 4. The initial page load still displays the same issue, but if you tap a link somewhere on the page and navigate, the blur updates to extend down to the bottom of the bar view.

I filed too, with a sample project. Mine is FB20069803. Note that this occurs on Seed 9, but that's not an option in the "which build" dropdown in Feedback Assistant.

FB16114803

The header appears to be fixed in the public release iOS 18.2 with Xcode 16.2.

Similar question, but specific to restoring window size and position after closing using the red stoplight button: https://developer.apple.com/forums/thread/767546

I'm seeing the same issue with Xcode 16.1 on macOS Sequoia 15.1 when building my Catalyst app. I found this StackOverflow comment saying if you change the Debug Information Format build setting away from and back to its default, "DWARF with dSYM file", the setting value becomes explicit in the project file and Xcode is forced to generate the dSYM for the main app target. This seems to work for me.

I was able to work around this issue with NSInvocation in Objective-C: WKWebViewConfiguration *config = [[WKWebViewConfiguration alloc] init]; SEL selector = @selector(setWritingToolsBehavior:); NSMethodSignature *sig = [config methodSignatureForSelector:selector]; NSInvocation *invocation = [NSInvocation invocationWithMethodSignature:sig]; [invocation setSelector:selector]; [invocation setTarget:config]; NSInteger arg = (NSInteger)UIWritingToolsBehaviorNone; [invocation setArgument:&arg atIndex:2]; [invocation invoke]; This works to set the writingToolsBehavior to none, and I don't get the Writing Tools option in my popup when selecting text in my WKWebView.

How do you get Xcode to debug your Control Center widget? I found this thread after getting this error message out of Console.app streaming logs from my device.

I've got a working sample app with a Control Center widget that writes something to UserDefaults and then opens the containing app. See here.

It's also worth noting that the LaunchAppIntent as shown in that documentation page does nothing.

I've filed this as FB13888167, as requested in a WWDC 2024 lab. I was given a couple of workarounds, but they aren't working super well for me yet: Put the action validation and routing further up the responder chain, like the scene delegate. But even if my scene delegate inherits from UIResponder, it's not automatically in the responder chain. Even with tricks to insert it in the chain, I can't (yet) get it to work. Set an explicit target on the toolbar items. But I have menu items too, and the menu items might be handled by different floating windows in my app, and I'd rather not have to re-set the targets on all those menu items every time the active window changes.

As requested in a WWDC 2024 Swift lab, I've filed FB13848771 for ergonomic improvements here.

The underlying issue in Sonoma is fixed as of 14.4. For affected OS versions, I was able to work around the issue by delaying 2 seconds from the last keypress to kicking off the parse operation in the background.

It turns out that if I hide the window title and then add the .flexibleSpace (NSToolbarFlexibleSpaceItemIdentifier) item, I can get one or more toolbar items to show up on the leading edge. I don't actually need the window title in my app, so that solves my issue.