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?

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.

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?

We're observing new crashes specifically on iOS 18.4 devices with this pattern: Exception Type: SIGTRAP Exception Codes: fault addr: 0x000000019bc0f088 Crashed Thread: 0 Thread 0 0 libsystem_malloc.dylib _xzm_xzone_malloc_from_tiny_chunk.cold.1 + 36 1 libsystem_malloc.dylib __xzm_xzone_malloc_from_tiny_chunk + 612 2 libsystem_malloc.dylib __xzm_xzone_find_and_malloc_from_tiny_chunk + 112 3 libsystem_malloc.dylib __xzm_xzone_malloc_tiny_outlined + 312 4 CoreGraphics CG::Path::Path(CG::Path const&) + 132 5 CoreGraphics _CGPathCreateMutableCopyByTransformingPath + 112 6 CoreGraphics _CGFontCreateGlyphPath + 144 7 CoreGraphics _CGGlyphBuilderLockBitmaps + 1112 8 CoreGraphics _render_glyphs + 292 9 CoreGraphics _draw_glyph_bitmaps + 1116 10 CoreGraphics _ripc_DrawGlyphs + 1464 11 CoreGraphics CG::DisplayList::executeEntries(std::__1::__wrap_iter<std::__1::shared_ptr<CG::DisplayListEntry const>*>, std::__1::__wrap_iter<std::__1::shared_ptr<CG::DisplayListEntry const>*>, CGContextDelegate*, CGRenderingState*, CGGStack*, CGRect const*, __CFDictionary const*, bool) + 1328 12 CoreGraphics _CGDisplayListDrawInContextDelegate + 340 13 QuartzCore _CABackingStoreUpdate_ + 612 14 QuartzCore ____ZN2CA5Layer8display_Ev_block_invoke + 120 15 QuartzCore -[CALayer _display] + 1512 16 QuartzCore CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 420 17 QuartzCore CA::Context::commit_transaction(CA::Transaction*, double, double*) + 476 18 QuartzCore CA::Transaction::commit() + 644 19 UIKitCore ___34-[UIApplication _firstCommitBlock]_block_invoke_2 + 36 20 CoreFoundation ___CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 21 CoreFoundation ___CFRunLoopDoBlocks + 352 22 CoreFoundation ___CFRunLoopRun + 868 23 CoreFoundation _CFRunLoopRunSpecific + 572 24 GraphicsServices _GSEventRunModal + 168 25 UIKitCore -[UIApplication _run] + 816 26 UIKitCore _UIApplicationMain + 336 27 app _main + 132 28 dyld __dyld_process_info_create + 33284 Key Observations: Crash occurs during font glyph path creation (CGFontCreateGlyphPath) Involves memory allocation in malloc's xzone implementation 100% reproducible on iOS 18.4, not seen in prior OS versions Occurs during standard CALayer rendering operations Not tied to any specific font family or glyph content Questions for Apple: Is this crash signature recognized as a known issue in iOS 18.4's CoreGraphics? Could changes to xzone memory management in iOS 18.4 interact poorly with font rendering? Are there specific conditions that might trigger SIGTRAP in CGPathCreateMutableCopyByTransformingPath? Any recommended mitigations for text rendering while awaiting system updates?

When testing with iOS 18.4 Beta on iPhones which support Dynamic Island, after doing a Face ID authentication, the amount of time it takes before the AppDelegate method applicationDidBecomeActive() is called takes longer than iPhones that do not support Dynamic Island. The time it takes is about double, 1.2 seconds vs 2.5 seconds on average. This does not occur with versions before 18.4 Beta. Anyone else seeing this?

I understand this is a known issue, but it’s truly unacceptable that it remains unresolved. Allowing users to customize toolbars is a fundamental macOS feature, and it has been broken since the release of macOS 15. How is it possible that this issue persists even in macOS 15.3 beta (24D5040f)? FB15513599 import SwiftUI struct ContentView: View { @State private var showEditItem = false var body: some View { VStack { VStack { Text("Instructions to reproduce the crash") .font(.title) .padding() Text(""" 1. Click on "Toggle Item" 2. In the menu go to File > New Window 3. In new window, click on "Toggle Item" """) } .padding() Button { showEditItem.toggle() } label: { Text("Toggle Item") } } .padding() .toolbar(id: "main") { ToolbarItem(id: "new") { Button { } label: { Text("New…") } } if showEditItem { ToolbarItem(id: "edit") { Button { } label: { Text("Edit…") } } } } } }

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'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 have a custom document-based iOS app that also runs on macOS. After implementing -activityItemsConfiguration to enable sharing from the context menu, I found that the app crashes on macOS when selecting Share… from the context menu and then selecting Save (i.e. Save to Files under iOS). This problem does not occur on iOS, which behaves correctly. - (id<UIActivityItemsConfigurationReading>)activityItemsConfiguration { NSItemProvider * provider = [[NSItemProvider alloc] initWithContentsOfURL:self.document.presentedItemURL]; UIActivityItemsConfiguration * configuration = [UIActivityItemsConfiguration activityItemsConfigurationWithItemProviders:@[ provider ]]; // XXX crashes with com.apple.share.System.SaveToFiles return configuration; } Additionally, I found that to even reach this crash, the workaround implemented in the NSItemProvider (FBxxx) category of the sample project is needed. Without this, the app will crash much earlier, due to SHKItemIsPDF() erroneously invoking -pathExtension on an NSItemProvider. This appears to be a second bug in Apple’s private ShareKit framework. #import <UniformTypeIdentifiers/UniformTypeIdentifiers.h> @implementation NSItemProvider (FBxxx) // XXX SHKItemIsPDF() invokes -pathExtension on an NSItemProvider (when running under macOS, anyway) -> crash - (NSString *)pathExtension { return self.registeredContentTypes.firstObject.preferredFilenameExtension; } @end Again, this all works fine on iOS (17.5) but crashes when the exact same app build is running on macOS (14.5). I believe these bugs are Apple's. Any idea how to avoid the crash? Is there a way to disable the "Save to Files" option in the sharing popup? I filed FB13819800 with a sample project that demonstrates the crash on macOS. I was going to file a TSI to get this resolved, but I see that DTS is not responding to tech support incidents until after WWDC.

I am using a common UI pattern: UITabBarController as window root, each tab with a separate UINavigationController stack. I want the (bottom!) tab bar to be only visible when the user is at the root of the app and hide it when a detail page is opened. To do that, I used hidesBottomBarWhenPushed on any view controller that would be pushed on my navigation stacks and that worked fine in the past. But with iOS 26, I am seeing several issues: On iOS where when the bottom tab bar is used, when in a details page and navigating back, the tab bar becomes fully visible immediately instead of slowly animating in as it has been in the past. This is particular visible and annoying when using the "swipe to go back" gesture On iPad, the situation is even worse: On iPadOS 18, the tab bar appeared in the navigation controller's navigation bar - no matter if hidesBottomBarWhenPushed was set or not - fine. But now, with iPadOS 26, this top tab bar disappears when a child is pushed. Not only that, it disappears abruptly, without animation, and the Liquid Glass effect on the UIBarButtonItems is broken as well. There is no transition whatsoever, buttons are simply replaced with the new UIBarButtonItems of the pushed view controller once it became fully visible. It gets even worse when swipe-back navigating on iPadOS: As soon as the back transition starts, the tab bar becomes visible again (without animation), covering the title (view) of the UINavigationController. If the swipe-back transition is not completed the tab bar suddenly stays visible When the swipe-back transition is interrupted close to the end of the transition and it goes back to the pushed view controller, the top UIBarButtonItems are showing a visual glitch where the content (text or icon) stays on the area where the tab bar is, while their container (the glass effect) are on the vertically aligned to the title view. I am surprised that I have not found any similar reports of these problems, so I am wondering if I am doing anything wrong or using hidesBottomBarWhenPushed simply isn't recommended or supported any more.

Summary I’m experiencing two issues with SwiftUI’s navigationTransition(.zoom) on iOS 26.0 and 26.1 that break previously smooth transitions. These issues appear both on real devices and Simulator. The same code works correctly on iOS 18. Issue 1 - Source View Disappears After Drag-Dismiss When using .navigationTransition(.zoom(sourceID:..., in:...)), the source view disappears completely after the transition finishes. This only happens when the detail view is dismissed via drag (interactive dismiss). When the view is dismissed by tapping the back button, the source view remains visible as expected. Reproduced on: iOS 26.0, iOS 26.0.1 (17A400), iOS 26.1 (Simulator + physical device) Issue 2 — Flickering and Geometry Mismatch During Transition Compared to iOS 18 behavior, the outgoing view and incoming view no longer share consistent geometry. Current behavior on iOS 26: The disappearing view flickers during the drag-dismiss interaction. The source and destination views no longer align geometrically. Instead of smoothly morphing as in previous iOS versions, the two views briefly overlap incorrectly before applying the zoom animation. Expected (iOS 18) behavior: Matched geometry between source and destination. Smooth, stable zoom transition with no flickering. // // ContentView.swift // DummyTransition // // Created by Sasha Morozov on 12/11/25. // import SwiftUI struct RectItem: Identifiable, Hashable { let id: UUID = UUID() let title: String let color: Color } struct ContentView: View { @Namespace private var zoomNamespace private let items: [RectItem] = [ RectItem(title: "Red card", color: .red), RectItem(title: "Blue card", color: .blue), RectItem(title: "Green card", color: .green), RectItem(title: "Orange card", color: .orange) ] var body: some View { NavigationStack { ScrollView { VStack(spacing: 16) { ForEach(items) { item in NavigationLink { DetailView(item: item, namespace: zoomNamespace) .navigationTransition( .zoom(sourceID: item.id, in: zoomNamespace) ) } label: { RoundedRectangle(cornerRadius: 16) .fill(item.color.gradient) .frame(height: 120) .overlay( Text(item.title) .font(.headline) .foregroundStyle(.white) ) .padding(.horizontal, 16) .matchedTransitionSource(id: item.id, in: zoomNamespace) } .buttonStyle(.plain) } } .padding(.vertical, 20) } .navigationTitle("Cards") } } } struct DetailView: View { let item: RectItem let namespace: Namespace.ID var body: some View { ZStack { item.color Text(item.title) .font(.largeTitle.bold()) .foregroundStyle(.white) } .ignoresSafeArea() .navigationTitle("Detail") .navigationBarTitleDisplayMode(.inline) } } #Preview { ContentView() } Testing Environment MacBook Pro (2023, M2 Pro, 16 GB RAM) macOS 26.2 Beta (25C5031i) Xcode: Version 26.0.1 (17A400) Devices tested: Simulator (iOS 26.0 / 26.1) Physical device (iPhone 16) running iOS 26.1

Hi, I am running iOS Simulator on iOS 26 and I am trying to change unselectedItemTintColor of UITabBarItem in my TabBarViewController but it did not work when I tried following ways: Setting an iconColor through UITabBarAppearance() class Setting unselected item tint color like tabBar.unselectedItemTintColor = .black As an example attached file, I would like to set Settings tab's item color (icon + title) with different one when it is unselected.

Hello Apple Team, I’ve encountered a regression in iOS 26.1 when building my app with Xcode 26 (iOS 26 SDK). The issue affects PKPaymentButtonType.plain, which now renders as fully invisible and produces transparent snapshots, even though the same code worked correctly in previous Xcode/iOS versions. This has a real-world impact because many apps generate static images from PKPaymentButton for payment selection UIs using UIGraphicsImageRenderer, layer.render(in:), or custom snapshot utilities. When using PKPaymentButton(paymentButtonType: .plain, paymentButtonStyle: .black) on iOS 26.1, when built with Xcode 26, the button: Appears blank / invisible Cannot be snapshotted Produces a fully transparent UIImage, even though the CGImage object exists Behaves differently than older SDKs (Xcode 16.x / iOS < 26.1 This regression only appears when compiling with the new SDK. Other button types work fine. Expected Behavior .plain button should render glyphs as documented snapshot generated via UIGraphicsImageRenderer or drawHierarchy(in:) should produce a visible image Behavior should be consistent with older SDKs unless explicitly deprecated in release notes Expected Behavior .plain button should render glyphs as documented Snapshot generated via UIGraphicsImageRenderer or drawHierarchy(in:) should produce a visible image Behavior should be consistent with older SDKs unless explicitly deprecated in release notes Actual Behavior .plain button renders no glyph at all Snapshot image is fully transparent (alpha = 0), even though size and CGImage metadata are correct Only happens when built with Xcode 26 SDK Same build from Xcode 16.x does not reproduce the issue Steps to Reproduce Create a minimal sample project in Xcode 26 Add the following code: let button = PKPaymentButton(paymentButtonType: .plain, paymentButtonStyle: .black) button.frame = CGRect(x: 0, y: 0, width: 180, height: 48) let renderer = UIGraphicsImageRenderer(size: button.bounds.size) let image = renderer.image { _ in button.drawHierarchy(in: button.bounds, afterScreenUpdates: true) } print(image) Run on iOS 26.1 device or simulator Observe that: The button appears visually empty The generated image is fully transparent Environment Xcode: 26.x (iOS 26 SDK) iOS: 26.1 (iPhone 15 Pro tested) Device: Real device Framework: UIKit + PassKit Button type: .plain ONLY Other types: .pay/.buy/.checkout = OK

Apparently now with iOS 26.1 if you have .tabViewBottomAccessory { } you get a pill shape floater all the time. That was not like that in 26.0.

Project minimum iOS deployment is set to 16.4. When running this simple code in console we receive "Observation tracking feedback loop detected!" and map is unusable. Run code: Map(coordinateRegion: .constant(.init())) Console report: ... Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_TtGC7SwiftUI21UIKitPlatformViewHostGVS_P10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS2_P10$24ce3fc8014AnnotationData____: 0x10acc2d00; baseClass = _TtGC5UIKit22UICorePlatformViewHostGV7SwiftUIP10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS3_P10$24ce3fc8014AnnotationData____; frame = (0 0; 353 595); anchorPoint = (0, 0); tintColor = UIExtendedSRGBColorSpace 0.333333 0.333333 0.333333 1; layer = <CALayer: 0x12443a430>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observable object key path '\_UICornerProvider.<computed 0x00000001a2768bc0 (Optional<UICoordinateSpace>)>' changed; performing invalidation for [layout] of: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> Observation tracking feedback loop detected! Make a symbolic breakpoint at UIObservationTrackingFeedbackLoopDetected to catch this in the debugger. Refer to the console logs for details about recent invalidations; you can also make a symbolic breakpoint at UIObservationTrackingInvalidated to catch invalidations in the debugger. Object receiving repeated [layout] invalidations: <_TtGC7SwiftUI21UIKitPlatformViewHostGVS_P10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS2_P10$24ce3fc8014AnnotationData____: 0x10acc2d00; baseClass = _TtGC5UIKit22UICorePlatformViewHostGV7SwiftUIP10$1a57c8f9c32PlatformViewRepresentableAdaptorGV15_MapKit_SwiftUI8_MapViewGSaVS3_P10$24ce3fc8014AnnotationData____; frame = (0 0; 353 595); anchorPoint = (0, 0); tintColor = UIExtendedSRGBColorSpace 0.333333 0.333333 0.333333 1; layer = <CALayer: 0x12443a430>> Observation tracking feedback loop detected! Make a symbolic breakpoint at UIObservationTrackingFeedbackLoopDetected to catch this in the debugger. Refer to the console logs for details about recent invalidations; you can also make a symbolic breakpoint at UIObservationTrackingInvalidated to catch invalidations in the debugger. Object receiving repeated [layout] invalidations: <_MapKit_SwiftUI._SwiftUIMKMapView: 0x10ae8ce00; frame = (0 0; 353 595); clipsToBounds = YES; autoresize = W+H; layer = <CALayer: 0x113beb7e0>> IDE: Xcode 26 Beta 3 Testing device: iPhone 15 Pro iOS 26 Beta 3 MacOS: Tahoe 26 Beta 3

I’m encountering an accessibility issue in SwiftUI related to keyboard navigation. 🐞 Problem When using an AttributedString to display Markdown content in a SwiftUI view (such as a Text view), any links included in the Markdown are not keyboard focusable when Full Keyboard Access is enabled. This means users can’t navigate to or activate the links using the Tab key or other keyboard-only methods. 💻 Platform iOS version: 16+ Framework: SwiftUI Device: All tested iPhones and iPads 🧪 Steps to Reproduce Enable Full Keyboard Access in iOS settings. Run the included SwiftUI Playground or equivalent app using the code below. Try to navigate to the link using Tab or keyboard arrow keys. Observe that the Markdown link is not reachable via keyboard focus. 🧩 Expected Behavior The Markdown link should be reachable via keyboard focus. It should be possible to activate the link using Space or Return. 📚 Example code struct ContentView: View { let attributedString: AttributedString init() { self.attributedString = try! AttributedString( markdown: "This is a [test link](https://apple.com) inside an attributed string." ) } var body: some View { VStack { Text("Issue: Attributed Markdown Link Is Not Focusable with full keyboard access") .font(.headline) .padding() Text(attributedString) // The link is not focusable with .padding() .border(Color.gray, width: 1) Text("Expected: The link should be focusable with Full Keyboard Access.") .foregroundColor(.red) .padding() } } }

We are using a TabView as the TabBarController in our app for main navigation. On one of the tabs we have a view that consists of a TabView with .tabViewStyle(.page) in order to scroll horizontally between pages inside of that specific tab. The .tabBarMinimizeBehavior(.onScrollDown) works on all the other TabItem views, but for this one it does not recognise any vertical scrolling in any of the pages, in order to minimize the TabBar. I believe this is a bug? If we don't wrap the views inside the TabView with .page style, we are able to get the expected behaviour using the tabBarMinimizeBehavior. Please let us know if this is going to be fixed in a future iOS 26 beta release.

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.

after i updated to iOS 26.0 Beta3, UIScrollEdgeElementContainerInteraction crashed: let scrollInteraction = UIScrollEdgeElementContainerInteraction() scrollInteraction.edge = .bottom scrollInteraction.scrollView = webView?.scrollView bottomBar.addInteraction(scrollInteraction) i got this crash info:unrecognized selector sent to instance: UIScrollEdgeElementContainerInteraction setEdge: and UIScrollEdgeElementContainerInteraction setScrollView

How do we disable the new swipe left anywhere to navigate back? I already use that swipe motion for custom actions in my app.