Hi everyone, I’m facing an issue with touch handling on newer iOS versions. I have a custom view controller implemented in Objective-C that overrides touchesEnded:. The same code works correctly on iOS 18, but on newer iOS versions (tested on iOS 26), touchesEnded: is no longer being triggered. Important observations: touchesBegan: is triggered. touchesEnded: is NOT triggered. touchesCancelled: is also NOT triggered. No code changes were made between iOS 18 and iOS 26. Same code, same sample works fine in iOS18 device but not in iOS26 device Questions: Has gesture arbitration behavior changed in recent iOS 26 versions when views are inside UIScrollView? Any clarification on whether this is intended behavior or a regression would be greatly appreciated. Thank you.

Issue Summary: On iOS 26.0.1 to 26.3, apps using multiple UITextFields for OTP input face a critical issue where the system autofill pastes the entire OTP string into a single text field, usually the focused one, rather than splitting digits across fields. Delegate events like textDidChange: do not trigger consistently on autofill, breaking existing input handling logic. Expected Behavior: OTP autofill should distribute each digit correctly across all OTP UITextFields. Delegate or control events should fire on autofill to enable manual handling. (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string { if (string.length > 1) { // Autofill detected - distribute OTP manually for (int i = 0; i < string.length && i < self.arrayOTPText.count; i++) { UITextField *field = self.arrayOTPText[i]; field.text = [NSString stringWithFormat:@"%c", [string characterAtIndex:i]]; } UITextField *lastField = self.arrayOTPText[string.length - 1]; [lastField becomeFirstResponder]; return NO; } // Handle normal single character or deletion input here return YES; } // // Setup UITextFields - set .oneTimeCode on first field only for (int i = 0; i < self.arrayOTPText.count; i++) { UITextField *field = self.arrayOTPText[i]; field.delegate = self; if (@available(iOS 12.0, *)) { field.textContentType = (i == 0) ? UITextContentTypeOneTimeCode : UITextContentTypeNone; } } What We’ve Tried: Setting textContentType properly. Handling OTP distribution in delegate method. Verifying settings and keyboard use. Testing on multiple iOS 26.x versions. Impact: Major usability degradation during OTP entry. Forces fragile workarounds. Inconsistent autofill reduces user confidence. Request: Request Apple fix OTP autofill to natively support multi-field UITextField OTP input or provide enhanced delegate callbacks for consistent behavior. Did any one face this issue in recent time with iOS 26.0.1 to 26.3 beta version

Hello, I’ve encountered what seems to be a bug with the keyboard dismissal animation on iOS 26.0 Beta (25A5349a), Xcode Version 26.0 beta 5 (17A5295f). When dismissing the keyboard from a SwiftUI TextField using @FocusState, the keyboard does not animate downward as expected. Instead, it instantly disappears, which feels jarring and inconsistent with system behavior. I am attaching a short video demonstrating the issue. Below is the minimal reproducible code sample: // // ContentView.swift // TestingKeyboardDismissal // // Created by Sasha Morozov on 27/08/25. // import SwiftUI struct ContentView: View { @State private var text: String = "" @FocusState private var isFocused: Bool var body: some View { ZStack { Color.clear.ignoresSafeArea() VStack(spacing: 20) { TextField("Enter text here...", text: $text) .textFieldStyle(.roundedBorder) .focused($isFocused) .padding(.horizontal) HStack { Button("Focus") { isFocused = true } .buttonStyle(.borderedProminent) Button("Unfocus") { isFocused = false } .buttonStyle(.bordered) } } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) .padding() } .ignoresSafeArea(.keyboard, edges: .bottom) } } #Preview { ContentView() } Steps to reproduce: Run** the app on iOS 26.0 beta 5 (17A5295f). Tap Focus → keyboard appears as expected. Tap Unfocus → keyboard disappears instantly without the usual slide-down animation. Expected result: Keyboard should animate smoothly downwards when dismissed. Actual result: Keyboard instantly vanishes without animation. p.s. we should be really able to upload videos here for demostration

On testing my app with tvOS 18, I have noticed the Siri Remote back button no longer provides system-provided behavior when interacting with tab bar controller pages. Instead of moving focus back to the tab bar when pressed, the back button will close the app, as if the Home button was pressed. This occurs both on device and in the Simulator. Create tvOS project with a tab bar controller. Create pages/tabs which contain focusable items (ie. buttons) Scroll down to any focusable item (ie. a button or UICollectionView cell) Hit the Siri Remote back button. See expect behavior below: Expected behavior: System-provided behavior should move focus back to the tab bar at the top of the screen. Actual results: App is closed and user is taken back to the Home Screen. Has anyone else noticed this behavior?

I've been experimenting with Liquid Glass quite a bit and watched all the WWDC videos. I'm trying to create a glassy segmented picker, like the one used in Camera: however, it seems that no matter what I do there's no way to recreate a truly clear (passthrough) bubble that just warps the light underneath around the edges. Both Glass.regular and Glass.clear seem to add a blur that can not be evaded, which is counter to what clear ought to mean. Here are my results: I've used SwiftUI for my experiment but I went through the UIKit APIs and there doesn't seem to be anything that suggests full transparency. Here is my test SwiftUI code: struct GlassPicker: View { @State private var selected: Int? var body: some View { ScrollView([.horizontal], showsIndicators: false) { HStack(spacing: 0) { ForEach(0..<20) { i in Text("Row \(i)") .id(i) .padding() } } .scrollTargetLayout() } .contentMargins(.horizontal, 161) .scrollTargetBehavior(.viewAligned) .scrollPosition(id: $selected, anchor: .center) .background(.foreground.opacity(0.2)) .clipShape(.capsule) .overlay { DefaultGlassEffectShape() .fill(.clear) // Removes a semi-transparent foreground fill .frame(width: 110, height: 50) .glassEffect(.clear) } } } Is there any way to achieve the above result or does Apple not trust us devs with more granular control over these liquid glass elements?

An app built on Xcode 26 (beta4) presents various UIViewCOntrollers. Presentation of any UIViewController that contains a UIToolbar leads to a UIKit crash when run on an iOS 18.5 device, it does not crash when run on iOS 26. The exception logged: *** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView because no class named TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' Anyone else seen this? I've submitted a bug report via Feedback Assistant, including a minimal Xcode workspace that reproduces the crash, hoping this will get some attention.

Hi, I’m seeing a crash when running my app on iOS 18 simulators or devices using Xcode 26 beta 3. My app’s minimum deployment target is iOS 17, and the crash does not happen when running from Xcode 16.4. The crash occurs specifically at this line: return UIStoryboard(name: storyboard.rawValue, bundle: nil) .instantiateViewController(withIdentifier: view.rawValue) Crash Details: ** Terminating app due to uncaught exception 'NSInvalidUnarchiveOperationException', reason: 'Could not instantiate class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ because no class named _TtGC5UIKit17UICoreHostingViewVCS_21ToolbarVisualProvider8RootView_ was found; the class needs to be defined in source code or linked in from a library (ensure the class is part of the correct target)' *** First throw call stack: (0x191c3321c 0x18f0cdabc 0x191c91ea0 0x19d740774 0x19d740a18 0x19d740cac 0x194626680 0x194dbc784 0x19d740890 0x19d740cac 0x1949aadd8 0x19d740890 0x19d740a18 0x19d740cac 0x194802e24 0x1945f008c 0x194ed1808 0x107a8bfa0 0x107a8c05c 0x1945ec128 0x19d740890 0x19d740cac 0x1945eba60 0x19d740890 0x19d740a18 0x19d740cac 0x1945f07dc 0x1945eaea4 0x19492ee80 0x10763de00 0x1076e56fc 0x1076e5674 0x1076e5e04 0x19496108c 0x194f9b9a0 0x1949072c4 0x194f998cc 0x194f9af04 0x19445139c 0x19445ac28 0x194467508 0x1079afaec 0x1079aff5c 0x1944189a0 0x194417be4 0x1944114e4 0x194411404 0x194410ab4 0x19440c1e4 0x191b28a8c 0x191b288a4 0x191b28700 0x191b29080 0x191b2ac3c 0x1ded09454 0x19453d274 0x194508a28 0x1073564f4 0x1b89fff08) terminating due to uncaught exception of type NSException The crash occurs immediately at app launch, when attempting to load a storyboard-based UITabBarController. Works as expected on: Xcode 16.4 + iOS 18 (simulator/device) Xcode 26 beta 3 + iOS 26 (simulator/device) Running from Xcode 26 beta 3 onto iOS 18 simulators or devices and it immediate crash from the particular storyboard Setup: Xcode: 26 beta 3 macOS: 15.5 iOS Simulators: iOS 18.5 Minimum deployment target: iOS 17 UIKit-based app (not using SwiftUI) No custom toolbars or host views in use explicitly Is this a known compatibility issue when building with the iOS 26 SDK and running on iOS 18? Are there any workarounds or recommendations for running apps targeting iOS 17+ on iOS 18 simulators when using Xcode 26?

When navigationTransition returns through the return gesture, the original view disappears。 The same problem occurs when using the official example。 https://developer.apple.com/documentation/swiftui/enhancing-your-app-content-with-tab-navigation xcode Version 16.4 (16F6) macOS 15.5

I'm developing a rhythm game for iOS which has four buttons spanning the width of the screen in portrait. I noticed that my testers were having some missed inputs on the buttons on the left and right due to the fact that iOS, by default, tries to ignore accidental touches on the edges of the screen. So I enabled "Defer System Gestures" on the left and right edges, but then quickly started to notice a new, very specific, issue. Description of the issue If you have finger #1 touching and holding anywhere in the middle of the screen, and finger #2 touches on the far right or left edge of the screen just below the horizontal position of finger #1, those touches are inconsistently not recognized. If finger #1 is not present, this issue does not occur. If finger #2 is above or well below finger #1, this issue also does not occur. A dead zone is created on the right and left edges of the screen just below the horizontal position of the first touch. Here is a rough representative example of where touches #1 and #2 need to be for this issue to manifest, in case the text above is not clear. |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9; 1&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9; 2| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| It just so happens that this issue is causing major usability problems with my game, as it results in what the user sees as sporadic and inconsistent response when the game calls for two notes to be played at the same time. Steps to recreate the issue Here are the steps if you want to recreate the problem yourself using the "Create New Gesture" pane in "Assistive Touch" (Note that this problem is not specific to the Settings app, but rather is an issue across the system—however this panel defers system gestures and shows where touches are being read, so it is a great place to demonstrate): (1) Go to Settings &gt; Accessibility &gt; Touch &gt; Assistive Touch &gt; Create New Gesture...; (2) With one finger, touch the middle of the screen and hold it through step 3; (3) With a second finger, tap 4 times along the right (or left) edge of the screen in the following places: (a) well above the vertical position of the first touch, (b) just above the vertical position of the first touch, (c) just below the vertical position of the first touch, and (d) well below the vertical position of the first touch; (4) Notice how, more than half the time, touch (c) does not register. I have found that this problem is more replicatable when the first touch is on the lower half of the screen, but I have been able to replicate it when the finger is higher as well, just not as consistently. Here are the four positions described in the steps above: Position a: both touches register |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9; 2| |&amp;#9; 1&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| Position b: both touches usually register |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9; 1&amp;#9; 2| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| Position c: only touch 1 registers |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9; 1&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9; 2| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| Position d: both touches register |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9; 1&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9;&amp;#9;| |&amp;#9;&amp;#9;&amp;#9; 2| Is there anything I can do to resolve this behavior? My app requires gesture deferment to be on for the expected experience by the user, and this bug is causing other issues for my testers that kind of need to be resolved before I can confidently release the game.

Hello, While integrating the Liquid Glass UI introduced in iOS 26 into my existing app, I encountered an unexpected issue. My app uses a UITabBarController, where each tab contains a UINavigationController, and the actual content resides in each UIViewController. Typically, I perform navigation using navigationController?.pushViewController(...) and hide the TabBar by setting vc.hidesBottomBarWhenPushed = true when needed. This structure worked perfectly fine prior to iOS 26, and I believe many apps use a similar approach. However, after enabling Liquid Glass UI, a problem occurs. Problem Description From AViewController, I push BViewController with hidesBottomBarWhenPushed = true. BViewController appears, and the TabBar is hidden as expected. When performing a swipe-back gesture, as soon as AViewController becomes visible, the TabBar immediately reappears (likely due to A’s viewWillAppear). The TabBar remains visible for a short moment even if the gesture is canceled — during that time, it is also interactable. Before iOS 26, the TabBar appeared synchronized with AViewController and did not prematurely show during the swipe transition. Tried using the new iOS 18 API: tabBarController?.setTabBarHidden(false, animated: true) It slightly improves the animation behavior, but the issue persists. If hidesBottomBarWhenPushed is now deprecated or discouraged, migrating entirely to setTabBarHidden would require significant refactoring, which is not practical for many existing apps. Is this caused by a misuse of hidesBottomBarWhenPushed, or could this be a regression or design change in iOS 26’s Liquid Glass UI?

I noticing that Monterey defaults to the NSWindowToolbarStyleAutomatic / NSWindowToolbarStyleUnified toolbar style, which suppresses the "use Small Size" menu item and customization checkbox. So I've set the window to use NSWindowToolbarStyleExpanded. However, the toolbar will no longer change to a smaller icon size, as it did in MacOS 10.14, 10.15, and 11.0. I've tried to set the toolbar item sizing to "Automatic" for all of our toolbar icons, but that results in bad positioning in both Regular and Small Size mode -- the height is way too big. The native size of the icon .png files are 128 x 128. What's odd is that if I resize the window with the toolbar to be wider, the NSToolbarItems in the overflow area will be displayed in the toolbar are 128 x 128, where the rest of the toolbar icons get displayed as a 32 x 32 icon. The only way to get it to layout remotely correct is to make the NSToolbarItem to have an explicit minimum size of 24 x 24 and maximum size of 32 x 32. And that USED to allow "small size", but on Monterey, it no longer does. Anyone had any success with small size icons on Monterey?

I’m developing a share extension for iOS 26 with Xcode 26. When the extension’s sheet appears, it always shows a full white background, even though iOS 26 introduces a new “Liquid Glass” effect for partial sheets. Expected: The sheet background should use the iOS 26 glassmorphism effect as seen in full apps. Actual behavior: Custom sheets in my app get the glass effect, but the native system sheet in the share extension always opens as plain white. Steps to reproduce: Create a share extension using UIKit Present any UIViewController as the main view Set modalPresentationStyle = .pageSheet (or leave as default) Observe solid white background, not glassmorphism Sample code: swift override func viewDidLoad() { super.viewDidLoad() view.backgroundColor = .clear preferredContentSize = CGSize(width: UIScreen.main.bounds.width, height: 300) } Troubleshooting attempted: Tried adding UIVisualEffectView with system blur/materials Removed all custom backgrounds Set modalPresentationStyle explicitly Questions: Is it possible to enable or force the Liquid Glass effect in share extensions on iOS 26? Is this a limitation by design or a potential bug? Any workaround to make extension sheet backgrounds match system glass appearance?

[Submitted as FB18870294, but posting here for visibility.] In iOS 26 beta 3 (23A5287g), implicit animations no longer work when conditionally showing or hiding rows in a Form. Rows with Text or other views inside a Section appear and disappear abruptly, even when wrapped in withAnimation or using .animation() modifiers. This is a regression from iOS 18.5, where the row item animates in and out correctly with the same code. Repro Steps Create a new iOS App › SwiftUI project. Replace its ContentView struct with the code below Build and run on an iOS 18 device. Tap the Show Middle Row toggle and note how the Middle Row animates. Build and run on an iOS 26 beta 3 device. Tap the Show Middle Row toggle. Expected Middle Row item should smoothly animate in and out as it does on iOS 18. Actual Middle Row item appears and disappears abruptly, without any animation. Code struct ContentView: View { @State private var showingMiddleRow = false var body: some View { Form { Section { Toggle( "Show **Middle Row**", isOn: $showingMiddleRow.animation() ) if showingMiddleRow { Text("Middle Row") } Text("Last Row") } } } }

My app doesn't respond on iPhone Air iOS 26.1. After startup, my app shows the main view with a tab bar controller containing 4 navigation controllers. However, when a second-level view controller is pushed onto any navigation controller, the UI freezes and becomes unresponsive. The iPhone simulator running iOS 26.1 exhibits the same problem. The debug profile shows CPU usage at 100%. However, other devices and simulators do not have this problem.

On macOS 15.2, any Mac Catalyst project that does not support portrait iPad orientation will no longer be able to successfully show the contents of any popover controls. This does not appear to be a problem on earlier versions of macOS and it only affects Mac Catalyst builds, not "Designed for iPad" builds. STEPS TO REPRODUCE Create a project that utilizes Mac Catalyst. Create a simple button that shows a popover with simple content. Remove Portrait as a supported orientation. Run the project on macOS 15.2 as a Mac Catalyst build. Note that the content inside the popover is not shown the popover is shown. Run the project as Designed for iPad. Note that the popover content shows correctly.

I've been testing the safeAreaBar modifier to develop a custom tab bar. From my understanding, this should enable the .scrollEdgeEffectStyle to work with this bar, but I don't see any effect. Could you please clarify the difference between safeAreaBar and safeAreaInset?

I am using below code to change navigationBar bg colour, but the text is hidden in large title. It works fine in previous versions. Kindly refer below code and attached images. Code: override func viewWillAppear(_ animated: Bool) { super.viewWillAppear(animated) navigationController?.navigationBar.prefersLargeTitles = true navigationItem.largeTitleDisplayMode = .always let appearance = UINavigationBarAppearance() appearance.backgroundColor = UIColor( red: 0.101961, green: 0.439216, blue: 0.388235, alpha: 1.0 ) navigationController?.navigationBar.standardAppearance = appearance navigationController?.navigationBar.scrollEdgeAppearance = appearance navigationController?.navigationBar.compactAppearance = appearance } Referenced images:

I know iPhone Cannot prohibit screenshots, but I have seen someone else's solution, which is to capture a white page instead of the current design page when taking screenshots. I want to use swift implement iPhone The photo generated when taking a screenshot is a white screen, and I don't want my page to be seen by others

We have encountered a consistent problem with OTP (One Time Password) autofill on iOS versions 26.0.1 through 26.3. The issue pertains to apps implementing OTP input using multiple UITextFields (often 6 or 7 separate text boxes for each digit). Problem Details: When tapping the OTP autofill suggestion from Messages or supported third-party apps, iOS autofill pastes the entire OTP string into just one UITextField (commonly the second or focused field) rather than distributing digits across the individual text fields. The delegated UITextField methods such as textField:shouldChangeCharactersInRange:replacementString: receive an entire OTP string at once, but the usual event handlers like UIControlEventEditingChanged do not always trigger, breaking existing logic relying on those. This results in the OTP input UI showing incorrect or partial OTP, confusing users and forcing manual re-entry. Many popular apps employing multi-field OTP input UIs face similar autofill malfunctions on iOS 26.x, impacting user experience negatively. Setting textContentType = .oneTimeCode on the first text field alone is insufficient to restore the intended autofill behavior on iOS 26.x. This represents a regression or functional deficiency compared to iOS 15-18 autofill handling patterns, which worked reliably for these multi-field OTP UIs.| Expected Behavior: OTP autofill should either automatically split the filled code into each UITextField or trigger consistent delegate/callback events to enable developers to replicate this behavior manually. textDidChange or equivalent events should fire on autofill updates to reflect text changes correctly in multi-field OTP input. Apple’s OTP autofill system should transparently support or provide clear guidelines for handling multi-field OTP input on iOS 26+. What We’ve Tried: Setting .oneTimeCode content type on only the first UITextField. Handling OTP autofill in delegate methods including shouldChangeCharactersInRange. Manual distribution and custom logic triggered by textDidChange and other callbacks. Confirming all relevant system autofill settings are enabled. Testing on multiple devices and iOS versions (26.0.1 through 26.3). Note: its happen for may apps which have text field with 6 box otp fill

[Submitted as FB21078443] When using .matchedTransitionSource with .navigationTransition(.zoom), swiping back from the left edge to return from a detail view causes the source item to disappear once the transition finishes. It’s only a visual issue—the item is still there and can be tapped to open again. This doesn’t happen when using the Back button; only the swipe-back gesture triggers it. Also, it only reproduces on a physical device, not in Simulator. SYSTEM INFO Xcode 26.1.1 (17B100) macOS 26.1 (25B78) iOS 26.1 (23B85) iOS 26.2 (23C5044b) REPRO STEPS Run the code below on a physical device, tap an image, then swipe from the left edge to dismiss the detail view. ACTUAL The image zooms back to its origin, then disappears once the animation settles. EXPECTED The image card remains visible. SCREENSHOTS CODE import SwiftUI struct Item: Identifiable, Hashable { let id = UUID() let imageName: String let title: String } struct ContentView: View { @Namespace private var namespace let items = [ Item(imageName: "SampleImage", title: "Sample Card 1"), Item(imageName: "SampleImage2", title: "Sample Card 2") ] var body: some View { NavigationStack { ScrollView { VStack(spacing: 16) { ForEach(items) { item in NavigationLink(value: item) { CardView(item: item) .matchedTransitionSource(id: item.id, in: namespace) } .buttonStyle(.plain) } } .padding() } .navigationTitle("Zoom Transition Issue") .navigationSubtitle("Tap image, then swipe back from left edge") .navigationDestination(for: Item.self) { item in DetailView(item: item, namespace: namespace) .navigationTransition(.zoom(sourceID: item.id, in: namespace)) } } } } struct CardView: View { let item: Item var body: some View { GeometryReader { geometry in ZStack(alignment: .bottom) { Image(item.imageName) .resizable() .scaledToFill() .frame(width: geometry.size.width, height: geometry.size.height) .clipped() } } .frame(height: 200) .clipShape(RoundedRectangle(cornerRadius: 16)) } } struct DetailView: View { let item: Item let namespace: Namespace.ID var body: some View { Image(item.imageName) .resizable() .scaledToFill() .clipped() } }