I have attached a screenshot showing the type of behavior in Apple's own Weather app that I am looking to disable in my own app. There is a zoom / card effect where the presenting view shrinks / zooms in the background, exposing a different background color that can look out of place. Notice that when dragging the map view to dismiss it, the views behind it are zoomed in exposing a different background. The presenting view that has this "card" effect has hard edges that do not match the screens corner radius as well, so it just looks out of place. Using this as an example, what would be the way to keep this matched zoom transition but keeping the Weather's background still going edge to edge? In my app I am trying to keep my mesh gradient edge to edge and not zoomed in with black or white borders in a similar situation to what we are seeing in the Weather app on 26.4 Let me know if I need to explain it more. Thank you!

I just finished writing a tonn of codes to get a pill on top of my keyboards that gives you the option to go up/down and close the keyboard. Very similar to what I see on safari keyboard. It should be included in the next SwiftUI as a modifier.... it would be so helpful

I have two apps written in SwiftUI. Both use a NavigationSplitView as their primary content with a list-based sidebar. Both apps have a few toolbar items offering functionality relevant to the application purpose. Both sidebars have toolbar items, declared using the .toolbar view modifier, that add ToolbarItems to their view (a "filter" menu). Both the apps' main content view use .toolbar to add some ToolbarItems to the main content toolbar as well. Both also include the SidebarCommands() command group. My question is this: in one app, when I click the Hide Sidebar button, the toolbar items that were attached to the sidebar move to the main toolbar. In my second app, the toolbar items move to the "More" disclosure menu at the end of the toolbar. Video showing sidebar leading Video showing sidebar trailing I want behavior like the first app (where the toolbar items end up in the leading edge of the main toolbar) in the second app, but I've scrubbed through both applications' toolbar code, I've had coding assistants compare the two, I've tried stripping down the toolbar items to remove all but the Hide Sidebar. Nothing I can discover shows me why one app moves the toolbar items to the main toolbar up front, while the other moves them to the back. Am I missing something about how to declare toolbar items? Is there some visibility priority thing I’m missing?

When upgrading to iOS 26.4, the guidance panel in CPMapTemplate is displayed in a striking red color. This happens with App Store version of the app which was compiled with iOS 26.2. Up to iOS 26.4 this panel has always been shown with a color which matches the ETA view below, in a dark gray. Compiling the app with iOS 26.4 makes nos difference. I have checked my code and I cannot see anything on my side which can trigger this change in the colour and only for iOS 26.4. I thought of restoring the old behaviour by using the property guidanceBackgroundColor in CPMapTemplate. But although I have tried to use a gray, I still get the red color. Is this the intended color in iOS 26.4? Is it a bug? Is there a way to use a custom color which matches the left and ETA panels? Thank you.

Hello, we are currently integrating Writing Tools into our macOS application using NSWritingToolsCoordinator with a custom NSView. Overall, the integration is going well and we are generally satisfied with the API. However, text replacement is sometimes not using NSWritingToolsCoordinator callback function. When selecting “Replace” from a preview in a Writing Tools UI popup, the text replacement is performed via the NSTextInputClient callback function (insertText:), which does not seem correct. This is especially problematic in multi-context scenarios, because NSTextInputClient insertText: does not provide the required information about the Writing tools context being used. As a result, it is not possible to determine which context is being modified when managing more than a single context. In our view, Writing Tools should consistently use the callback function of NSWritingToolsCoordinator for text replacement, whatever is the action performed. This is essential for properly handling multi-context use cases. This issue is reproducible with the sample app project provided here https://developer.apple.com/documentation/appkit/enhancing-your-custom-text-engine-with-writing-tools. If you define a breakpoint in function writingToolsCoordinator:replaceRange:inContext:proposedText:reason:animationParameters:completion: of the Writing tools coordinator, the function is not triggered if text replacement is performed from a preview like for "Summary" with "replace" button. NSWritingToolsCoordinator callback function seems to be called only when text replacement is performed directly inline (in the text view) without external preview so. i have opened a issue with feedback assistant: FB22401950. Best regards.

Hello, we are currently integrating Writing Tools into our macOS application using NSWritingToolsCoordinator with a custom NSView. Overall, the integration is going well and we are generally satisfied with the API. However, text replacement is sometimes not using NSWritingToolsCoordinator callback function. When selecting “Replace” from a preview in a Writing Tools UI popup, the text replacement is performed via the NSTextInputClient callback function (insertText:), which does not seem correct. This is especially problematic in multi-context scenarios, because NSTextInputClient insertText: does not provide the required information about the Writing tools context being used. As a result, it is not possible to determine which context is being modified when managing more than a single context. In our view, Writing Tools should consistently use the callback function of NSWritingToolsCoordinator for text replacement, whatever is the action performed. This is essential for properly handling multi-context use cases. This issue is reproducible with the sample app project provided here https://developer.apple.com/documentation/appkit/enhancing-your-custom-text-engine-with-writing-tools. If you define a breakpoint in function writingToolsCoordinator:replaceRange:inContext:proposedText:reason:animationParameters:completion: of the Writing tools coordinator, the function is not triggered if text replacement is performed from a preview like for "Summary" with "replace" button. NSWritingToolsCoordinator callback function seems to be called only when text replacement is performed directly inline (in the text view) without external preview so. i have opened a issue with feedback assistant: FB22401950. Best regards.

I have a Document based app. It supports different document types. One document type my app supports conforms to another document type that my app also supports. In my app these two UTIs are designated to open different NSDocument subclasses / window controllers. So say we have these two UTIs: com.DocumentType.SuperType com.DocumentType.SubType. Now I just noticed on Tahoe 26.4, the system is launching my app using NSDocument/window controller that is designated for com.DocumentType.SuperType, when I double click a file with the com.DocumentType.SubType UTI. I haven't changed the NSDocument configuration in many years but it looks like something changed recently.

There are 2 text entry points, a text view and a text field. The text view Compose disallows touch. Enter text in the text field, return to the text view and the text view cursor is gone. Is there a way to reset the pointer to visible using a xcode button? My workaround is to change views, return (the cursor is visible) then restore the text. Which is an annoying process. The app myownkeyboard PAD is free. The Compose view has the problem. Any suggestions would be appreciated. Thanks.....Charlie 10apr2026

Hello, I’ve noticed an issue with custom keyboard extensions in iOS 26 that seems specific to native apps. When a custom keyboard is opened in apps like Messages, Notes, or Safari, there’s an extra strip of native grey space around the left, right, and top edges of the keyboard. This extra margin cannot be rendered over by the keyboard’s own views. Interestingly, this behaviour does not occur in third-party apps like Instagram. It also wasn’t present in earlier iOS versions. The result is that keyboards with custom or non-grey backgrounds look visually inconsistent (they appear framed by unwanted grey). Has anyone else run into this? Is this a known change in iOS 26, or could it be a bug? Any guidance or official clarification would be appreciated. Thanks!

Hello everyone, I am experiencing a layout issue in a SwiftUI project where an icon inside a button becomes laggy after the keyboard is dismissed. I have a custom input bar designed with an HStack containing a TextField and a Button with a microphone.fill icon. The entire HStack is styled using a .clipShape(.capsule) and a background color and I am using @FocusState to manage the keyboard focus. When the user taps the TextField, the keyboard appears, and the entire view moves up correctly to make room. But when the keyboard is dismissed by the button action isPromptFieldFocused = false, the capsule-shaped background and the text field return to their original position, but the icon on the button (and just the icon) doesn't. The microphone icon inside the button does not follow the movement. It remains stuck at the "keyboard-up" height for a moment until the view is refreshed, breaking the UI. And by the way, the icon correctly returns to its original position with the other UI elements if the user presses the return key on their keyboard. import SwiftUI struct ContentView: View { @State var userText: String = "" @FocusState var isTextFieldFocused: Bool var body: some View { HStack { TextField("Type here...", text: $userText) .focused($isTextFieldFocused) .textInputAutocapitalization(.sentences) .textFieldStyle(PlainTextFieldStyle()) .padding(.leading, 12) .padding(.trailing, 4) Button(action: { print("Microphone pressed") isPromptFieldFocused = false }) { Image(systemName: "microphone.fill") .font(.system(size: 22, weight: .semibold)) .foregroundStyle(.white) .padding(14) } .background(Color.black) .clipShape(Circle()) .padding(.trailing, 14) .padding(.vertical, 14) } .background(Color.lightGray) .clipShape(Capsule()) .padding() } } I've already tried using different animation types (e.g., .default, .spring) and explicitly setting the frame of the button. Has anyone encountered this specific behavior where an Image(systemName:) ignores the parent container's transition during keyboard dismissal? I would appreciate any insights on how to ensure the entire HStack and its children animate back down in sync.

Hi Team I’m facing an issue with UISwitch inside a UITableViewCell on iOS 26. When the switch is toggled, I update my data and call tableView.reloadData(). Since both the switch animation and table view reload happen at the same time, the UISwitch does not show its glass effect properly (it looks flat/missing during the animation). If I delay the reload, the switch renders correctly. Is this a known issue? Is there a recommended way to handle this without affecting the switch’s visual appearance?

I have been using this block of Swift code for weeks with no problems. Then, today, every time I invoke it it fails: let openPanel = NSOpenPanel() openPanel.canChooseFiles = true openPanel.allowsMultipleSelection = false openPanel.canChooseDirectories = true openPanel.canCreateDirectories = false openPanel.title = NSLocalizedString("Open a CSV file", comment: "Open a CSV File") var result = NSApplication.ModalResponse.OK do { try result = openPanel.runModal() } catch { print("Open Panel failed: \(error)") return } if result == .OK { CSVFile = openPanel.url!.path } else { openPanel.close() print("No CSV file selected.") return } I get this message pointing to the .openModal expression: "Thread 1: Fatal error: Unexpectedly found nil while unwrapping an Optional value" It's a real head-scratcher!

We're experiencing a severe main thread hang (29 seconds) in our CarPlay audio app when calling [CPListItem setImage:] on iOS 26.4. This issue affects 81% of our reported hang cases, and is concentrated on iOS 26.4. Environment iOS 26.4 CarPlay Audio app Images are downloaded via SDWebImage, resized to appropriate scale, then set via [CPListItem setImage:] on the main thread Problem When multiple list item images finish downloading around the same time, each setImage: call triggers expensive synchronous CoreUI operations on the main thread. The total accumulated time causes a 29-second freeze. The entire hang occurs inside Apple frameworks — no app code is on the hot path after calling setImage:. Call Stack (simplified) [CPListItem setImage:] └─ [CPImageSet initWithImage:treatmentBlock:] (57% + 21% + 18% = 96%) └─ [UIImageAsset imageWithTraitCollection:] └─ [UIImageAsset _withLock_imageWithConfiguration:] └─ [UIImageAsset _performLookUpRegisteredObjectForTraitCollection:] └─ [UITraitCollection _enumerateThemeAppearanceNamesForLookup:] └─ [CUICatalog _imageWithName:scaleFactor:deviceIdiom:...] └─ [CUIMutableStructuredThemeStore canGetRenditionWithKey:] └─ [CUIMutableStructuredThemeStore renditionWithKey:] └─ copyKeySignatureForKey / NSDictionaryM objectForKey: / CFStringCreateImmutableFunnel3 Code // Image download completion callback (dispatched to main queue by SDWebImage) if (finished && image) { UIImage *carPlayScaleImage = [UIImage imageWithCGImage:image.CGImage scale:[self getCarPlayDisplayScale] orientation:UIImageOrientationUp]; [item setImage:carPlayScaleImage]; // <-- hang here } Analysis Inside setImage:, the CarPlay framework creates a CPImageSet, which calls [UIImageAsset imageWithTraitCollection:] three times (at offsets +540, +344, +300 in CPImageSet initWithImage:treatmentBlock:). Each call performs a full CoreUI rendition key lookup via CUIMutableStructuredThemeStore, involving key signature computation, dictionary lookups, and string allocation. On iOS 26.4, these CoreUI operations appear significantly slower than previous iOS versions. When a CarPlay list loads ~20 items and images complete downloading in a short window, the serial execution of these setImage: calls on the main queue accumulates to a multi-second hang. Questions 1. Is this a known CoreUI performance regression in iOS 26.4? 2. Is there a recommended way to set images on CPListItem that avoids the heavy CPImageSet / UIImageAsset trait collection resolution path? 3. Are there any planned fixes for the CoreUI rendition lookup performance in upcoming iOS 26.x releases? Any guidance would be appreciated. We have also filed a Feedback report.

I have a simple reproducer here: struct ContentView: View { @State private var isOn = false @State private var isPresented = false var body: some View { NavigationStack { Color.blue .toolbar { ToolbarItem(placement: .topBarTrailing) { Button("Press here") { isPresented = true } .popover(isPresented: $isPresented) { Color.green .frame(idealWidth: 400, idealHeight: 500) .presentationCompactAdaptation(.popover) } } } } } } When I tap on the button in the toolbar you can see there is a hang then the popover shows. Then every time after there is no longer a hang so this seems like a bug. Any ideas? I'm using Xcode 26.3 and a iPad Pro 13-inch (M5) (26.4) simulator.

I’m seeing a weird iOS Password AutoFill behavior in React Native and I’m trying to figure out whether this is: expected iOS behavior, a known React Native TextInput issue, or something I can work around. Setup: React Native 0.81.5 iOS app with Associated Domains configured and working Password AutoFill generally works fine two fields on a login screen: username/email: autoComplete="username" password: autoComplete="current-password" What happens: when the login screen opens, the iOS autofill bar above the keyboard shows the saved credential suggestion as expected as soon as I type a single character into the username field, the autofill bar goes blank instead of continuing to show a suggestion if I press delete while the field is already empty, the autofill suggestion flickers Important detail: autofill itself is not completely broken Associated Domains are set up and credential suggestions do appear the issue is specifically the unstable behavior of the autofill bar while editing Question: has anyone seen this with React Native TextInput on iOS? is this just how iOS reevaluates credential suggestions once the username starts changing? or is there a known RN-side trigger here, for example controlled inputs, secureTextEntry, rerenders, focus changes, or textContentType / autoComplete combinations?

If you use .navigationTransition(.zoom(sourceID: zoomID, in: namespace)) with a carousel or a card view, which uses : .stroke(Color.secondary.opacity(0.5), lineWidth: 5) It causes the border stroke to render incorrectly, and even in some cases, the card glitches out and disappears from the screen. The card is clickable but there is no entity in the placeholder of that place.

I have built my custom keyboard, is there a way to customize the bottom most layer of keyboard where only globe and system mic icons are visible . Iike I want to put my app name between globe and mic icon. Also I know that by setting hasDictationKey = true, we can remove showing the system mic icon from keyboard , but can I add any text or icon to that area of keyboard.

I'm trying to understand why would a single button appear twice in the toolbar, like so: Do you see the eclipsed button peeking from underneath the top button? It's the same button, somehow doubled or cloned, or replicated. To reproduce it, I only needed to create a fresh iOS project in Xcode and apply this code change: diff --git a/BugRepro20260409/ContentView.swift b/BugRepro20260409/ContentView.swift index 426b298..d22433f 100644 --- a/BugRepro20260409/ContentView.swift +++ b/BugRepro20260409/ContentView.swift @@ -28,7 +28,7 @@ struct ContentView: View { ToolbarItem(placement: .navigationBarTrailing) { EditButton() } - ToolbarItem { + ToolbarItem(placement: .bottomBar) { Button(action: addItem) { Label("Add Item", systemImage: "plus") } This is all I needed to do for the double-vision button. Why would this button appear twice when moved to .bottomBar? By the way, when moved to the side and displayed on a smaller device like iPhone SE, the duplication is quite jarring: Interestingly, both buttons are active, and both trigger the same code path. Any ideas what's going on? ContentView.swift

All system colors are displayed incorrectly on the popover view. Those are the same views present as a popover in light and dark mode. And those are the same views present as modal. And there is also a problem that when the popover is presented, switching to dark/light mode will not change the appearance. That affected all system apps. The following screenshot is already in dark mode. All those problem are occured on iOS 26 beta 3.

The Lock Screen customization menu fails to replace the default "Camera" shortcut with a selected third-party or system control. Despite the UI appearing to save the new selection, the Lock Screen reverts to the Camera icon immediately upon exiting customization mode.