Scenario: Typing Chinese Zhuyin “ㄨㄤ” and then selecting the candidate word “王”. On iOS 18, the delegate (textField:shouldChangeCharactersInRange:replacementString:) is called with: range: {0, 2} replacementString: "王" On iOS 26, the delegate (textField:shouldChangeCharactersInRanges:replacementString:) instead provides: ranges: [{2, 0}] replacementString: "王" This results in inconsistent text input handling compared to earlier system versions. Implement: Limit user input to a maximum of 100 Chinese characters. - (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if ([textField markedTextRange]) { return YES; } NSString *changedString = [textField.text stringByReplacingCharactersInRange:range withString:string]; if (changedString.length > 100) { return NO; } return YES; } Questions: Is this an intentional change in iOS 26? If intentional, what is the recommended way to handle such cases in order to support both iOS 18 and iOS 26 consistently?

Already filed a feedback in case this is a bug, but posting here in case I'm doing something wrong? I'd like the search field to automatically be displayed with the keyboard up when the view appears. This sample code works in iOS 18, but it does not work in iOS 26 beta 7 I also tried adding a delay to setting searchIsFocused = true but that did not help struct ContentView: View { var body: some View { NavigationStack { NavigationLink(destination: ListView()) { Label("Go to list", systemImage: "list.bullet") } } .ignoresSafeArea() } } struct ListView: View { @State private var searchText: String = "" @State private var searchIsPresented: Bool = false @FocusState private var searchIsFocused: Bool var body: some View { ScrollView { Text("Test") } .searchable(text: $searchText, isPresented: $searchIsPresented, placement: .automatic, prompt: "Search") .searchFocused($searchIsFocused) .onAppear { searchIsFocused = true } } }

After upgrading my OS to Tahoe OS , in my application observed that Cmd+V is not working only on runForModalWindow. But menu Edit->Paste and Right click Paste is working on the same screen. Other screens in the application have no issues with Cmd+V. Could you please help with this issue why Cmd+V is not working only in this screen. Thanks, Sowmya

Fatal safeAreaInsets Error on Certain iOS/iPadOS 26 Devices On certain devices that have updated to iOS/iPadOS 26, the safeAreaInsets value is displayed incorrectly when rotating. On the iPhone SE3, the safeAreaInsets.top value is displayed inverted when rotating. It should return 20.0 when rotated vertically and 0.0 when rotated horizontally. Currently, the value is reversed. (0.0 when rotated horizontally and 20.0 when rotated vertically.) On iPad Pro devices, the safeAreaInsets.top value is always returned as 0.0 when the app is first launched. (This issue is believed to occur on all iPad devices, including the iPad Pro.) If the user subsequently rotates the iPad, the safeAreaInsets value is returned correctly. On the iPhone 17 with dynamic islands, the safeAreaInsets value is displayed correctly. My guess is that all devices running iOS/iPadOS 26 without dynamic islands will experience an issue where the safeAreaInsets value is displayed incorrectly. This issue occurs when building with Xcode 26. Apple, please issue an OS update as soon as possible. Or, if this is an Xcode issue, please update Xcode.

The screenshot is showing the same app deployed using Xcode version 26.0 beta 4 (17A5285i) on iOS 18.5 and on iOS 26.0. In iOS 26 beta 4 on the right the spacing of the UIBarButtonItem elements does not look good: The buttons are created like so: colorButtonText = [[UIBarButtonItem alloc] initWithImage:[UIImage systemImageNamed:@"paintbrush"] style:UIBarButtonItemStylePlain target:self action:@selector(drawingActionColor:)]; //... [drawingToolbarText setItems:@[colorButtonText, ...]]; Is this a known issue with the current iOS 26? Am I doing something wrong?

If you use UISceneDelegate's scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) to handle deep links (such as tapping a widget) you might run into an issue where this callback is called twice in the majority of cases. If you push a view controller in response to this, you might end up with two pushed view controllers, if you do not mitigate this. This is exclusively an issue in iOS 26.0 and works as expected on iOS 18. func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { /// Add any widget to the home screen that uses the widgetURL modifier and tap them. Most of the time, openURLContexts() will get called twice. /// If you run this project on iOS 18, it's *always* called once as expected. print("openURLContexts \(URLContexts)") } Filed as FB20301454

Hey there, does someone know why the ContentUnavailableView is behaving differently on iOS 26 than in iOS 18 but the code is the same?

Getting this error in iPhone Portrait Mode with notch. Currrently using AVQueuePlayer to play more than 30 mp3 files one by one. All constraint properties are correct but error occures only in Apple iPhone Portrait Mode with notch series. But same code works on same iPhone in Landscape mode. **But I get this error: ** LoudnessManager.mm:709 unable to open stream for LoudnessManager plist Type: Error | Timestamp: 2025-02-07 | Process: | Library: AudioToolbox | Subsystem: com.apple.coreaudio | Category: aqme | TID: 0x42754 LoudnessManager.mm:709 unable to open stream for LoudnessManager plist LoudnessManager.mm:709 unable to open stream for LoudnessManager plist Timestamp: 2025-02-07 | Library: AudioToolbox | Subsystem: com.apple.coreaudio | Category: aqme

We are trying to write an iOS app that supports regular and constrained widths using a TabView with .tabViewStyle(.sidebarAdaptable). On the surface this seems like a great way to write an app that supports all the different widths that your app may run in. Especially since Stage Manager and Apple Vision have made it easy for users to resize your apps window while it is running. We are facing many challenges though. I will give a brief one liner of each below, but to truly experience them you need to run the sample app, or watch the sample videos included. Issues Basic TabView Issues Double Navigation Bar: When tabs are collapsed into a "More" tab, there's an unwanted double navigation bar Selection Sync: Tab selection gets out of sync when switching between narrow/wide layouts through the "More" tab TabView Crash Fatal crash occurs when resizing window to narrow width while Tab 5 is selected Error: SwiftUI/SidebarAdaptableTabViewStyle_iOS.swift:482: Fatal error: Tried to update with invalid selection value Section Handling Issues Section Display Bug: Bottom tabs incorrectly show section names instead of tab names in narrow width Tab Selection Mismatch: Tab identifiers don't match selected tabs in narrow width mode Customization Issues Inconsistent "Edit" button behavior in More tab Unable to properly disable tab customization Sample app and video https://github.com/copia-wealth-studios/swiftui-tabview-sample

Hi everyone, I’m testing my Catalyst SwiftUI project on iOS 26 / iPadOS 26 / macOS 26. I started with a NavigationSplitView (triple-column) inside a WindowGroup. On iPad it looks great: the toolbar items merge into the navigation bar, with the three traffic lights. But on Mac Catalyst, the app always reserves a blank safe area below the traffic lights, and places the toolbar on a separate line beneath the title bar. That leaves wasted vertical space I don’t want. What I expect (based on Apple’s WWDC session “Elevate the design of your iPad app”): The toolbar should merge into the title bar with the traffic lights, no separate row. Content should extend into the full height of the window. What I get on Mac Catalyst: Title bar + traffic lights at the top. Then a completely separate toolbar row below it. Safe area inset prevents my content from reaching the top of the window. What I’ve tried: .toolbarRole(.automatic), .editor, .browser → no effect. Hiding the title bar via titlebar?.titleVisibility = .hidden → removes the text but not the toolbar gap. Clearing titlebar?.toolbar → no difference. So far, I can’t find any way to get Catalyst to integrate toolbars into the window chrome the way native SwiftUI on macOS does. Is this a known limitation of Mac Catalyst, or is there a supported way to achieve the same “inline toolbar with window controls” layout? Switching to a Mac app vs. Catalyst fixes the issue, but I would have a lot more work to do to get the app ready for release, not ideal since it works near perfect on iPad. Thanks!

Hi Apple Team and community, We've noticed a change in how UITableView separators are rendered in iOS 26 (tested using Xcode 26.0), and we'd like to confirm if this is an intentional behaviour change or a potential bug. Issue Description In a .plain-style UITableView, the top separator line above the first cell in each section is no longer rendered in iOS 26. We've confirmed that this separator is also absent from the view hierarchy. This issue did not occur in previous iOS versions (e.g., iOS 18), where the top separator above the first cell of a section was rendered as expected. The issue doesn't occur for UITableView with no sections. Expected Behavior When using a .plain style UITableView, the standard top separator should appear above the first cell of each section, as part of the default system rendering. Actual Behavior In iOS 26, this top separator is missing, even though the rest of the separators render normally. Environment iOS version: iOS 26 (Simulator) Xcode version: Xcode 26.0 Tested using: UIKit with Swift, both Storyboard and programmatic view setups Sample app and screenshots: Drive link: https://drive.google.com/drive/folders/1aoXeFHO_Sya-6Rvp0fZ0s2V4KLQucRMb?usp=sharing Questions: Is this a known change in rendering behavior for UITableView in iOS 26? If not, is anyone else experiencing the same issue? We'd appreciate any insights or potential workarounds to restore the top separator in .plain-style table views. Any clarification or guidance would be appreciated. Thanks in advance!

For certain contexts, I'd like to still have my .sheet() be full width even when it's at a small height. In iOS 26, the sheet is inset from the edges at small detents and expands to full width at larger detents. For example, I have a view where I have a .sheet() that has a height of about 200pts and it contains a horizontally scrolling picker that extends past the bounds of the screen. I'd like the .sheet to expand all the way to the edge when at these small detents, like it would previous to iOS 26. Is it possible to configure this? This change will break a number of existing designs :( A new ViewModifier such as enum PresentationWidth { case dynamic, fixed } func presentationWidth(_ width: PresentationWidth) -> some View would be very nice.

I'm currently using the extension below to determine whether an iPhone has a notch so I can adjust my UI accordingly. extension UIDevice { var hasNotch: Bool { if userInterfaceIdiom == .phone, let window = (UIApplication.shared.connectedScenes .compactMap { $0 as? UIWindowScene } .flatMap { $0.windows } .first { $0.isKeyWindow }) { return window.safeAreaInsets.bottom > 0 } return false } } (Adapted from https://stackoverflow.com/questions/73946911/how-to-detect-users-device-has-dynamic-island-in-uikit) This no longer works in iOS 26, and I have yet to find a similar method that works. Does anyone have any fixes?

Hi all - i'm encountering a strange issue since updating to Xcode 26.0.1. It seems that any SwiftUI Views that have an :ObservedObject property that contains @Published properties, and use those properties inside the View, no longer update when those properties are updated when the view also has an @Environment property. If I remove the @Environment property and any usage of it, the view updates correctly. The specific environment property i'm using is .safeAreaInsets, like so: @Environment(\.safeAreaInsets) private var safeAreaInsets Is this a recognised bug in the latest iOS 26 SDK? Thanks

Given a sheet with [.medium] detents, that contains a native ColorPicker in SwiftUI: struct SheetView: View { @State var color: Color = .white var body: some View { ColorPicker( "Color", selection: $color, supportsOpacity: false ) .padding() } } struct ContentView: View { @State var isSheetOpen = false var body: some View { Button("Open Sheet") { isSheetOpen = true } .sheet(isPresented: $isSheetOpen) { SheetView() .presentationDetents([.medium]) } } } When I tap the ColorPicker's color indicator button, it presents the color picker sheet with a layout glitch. During the color picker presentation animation, the original sheet (SheetView) is rapidly pushed up and back down. It is a wild guess but I think it has to do something with keyboard avoidance. Unfortunately, this makes it impossible to use the picker in my app....

We are currently implementing App Clips in our app. While we have carefully optimized the App Clip size to keep it lightweight (~3.69MB), we have noticed that on the first load, displaying the App Clip Card and activating the “Open” button takes a surprisingly long time (approximately 2–3 seconds). Subsequent loads appear to perform normally. We understand that this behavior may not be directly controllable from the app development side, but we would like to know if there are any possible ways to improve it. Minimizing the time it takes for users to access the content is extremely important, as delays on the first interaction can negatively impact the user experience. Any guidance or best practices to make the App Clip Card and its “Open” button respond faster on first load would be greatly appreciated.

This new modifier is supposedly backported to iOS 17, but on attempting to use it on the latest iOS 18.5, this happens: Symbol not found: _$s7SwiftUI17EnvironmentValuesV33_navigationIndicatorVisibilityABIAA0G0OvpMV This happens with any usage of the modifier. An availability check won't save you either. The cruelest part of this is that I only need the modifier on iOS 26, lmao. Am I just missing something?

I have a TabView (no modifiers) as the top-level view in my app. Starting with iOS 26 it starts off partially "under" the Status Bar, and then repositions if I switch between apps. Starting Point After Switching To/From Another App In the simulator, pressing "Home" and then reopening the app will fix it. Anyone else seeing something similar? Is there a modifier I'm missing on TabView that might prevent this behaviour? Thanks!

I've got a Catalyst app that exposes some custom context menu items via the buildMenu API. When it runs on Tahoe, there's some weirdness with how the images in the menu items are sized. See attached screenshot below. The three items on the bottom are using SF Symbols for their images, and the rest are using custom images from an asset catalog. Is this a bug in Tahoe 26.0? Or should I be resizing my images before giving them to UIAction? If the latter, what should the size be, and is this documented somewhere or available from an API?

When I add a TextField with @FocusState to a toolbar, I noticed that setting focus = false doesn't cause the form to lose focus If I move the TextField out of the toolbar setting focus = false works fine. How can I unfocus the text field when the cancel button is tapped? Minimal example tested on Xcode Version 26.0 beta 6 (17A5305f): import SwiftUI struct ContentView: View { @State private var text: String = "" @FocusState private var focus: Bool var body: some View { NavigationStack { List { Text("Test List") } .toolbar { ToolbarItem(placement: .bottomBar) { TextField("Test", text: $text) .padding(.horizontal) .focused($focus) } ToolbarItem(placement: .bottomBar) { Button(role: .cancel) { focus = false // THIS DOESN'T WORK! } } } } } } #Preview { ContentView() }```