Hi, I was wondering if it's possible (and advisable) to use the new glass effects available in iOS 26 in Swift Charts? For example, in a chart like the one in the image I've attached to this post, I was looking to try adding a .glassEffect modifier to the BarMarks to see how that would look and feel. However, it seems it's not available directly on the BarMark (ChartContent) type, and I'm having trouble adding it in other ways too, such as using in on the types I supply to modifiers like foregroundStyle or clipShape. Am I missing anything? Maybe it's just not advisable or necessary to use glass effects within Charts?

I’m seeing a macOS 26 AppKit issue with a sidebar + full-size content window + titlebar accessory setup. The main problem is that an NSTitlebarAccessoryViewController can visually cover the first item in the sidebar when System Settings > Accessibility > Display > Reduce Transparency is enabled. In my app this made the first sidebar/menu item look blacked out/covered by the titlebar/accessory area. While investigating possible workarounds, I also compared NSTitlebarAccessoryViewController with NSSplitViewItemAccessoryViewController and found two related issues that make the split-view accessory hard to use as a replacement. I could not attach the full sample project directly, so I included the two relevant Swift files below. The screenshots were taken from the same minimal AppKit repro with Reduce Transparency enabled. Repro setup The sample project shows: a fixed-width sidebar one content pane using NSTitlebarAccessoryViewController one content pane using NSSplitViewItemAccessoryViewController both accessories use the same custom view both custom views request the same intrinsic height each accessory displays its requested and actual height main.swift AppDelegate.swift Issue 1: titlebar accessory can cover sidebar content With Reduce Transparency enabled, the titlebar/accessory area can visually cover content at the top of the sidebar. This is the original issue I’m trying to solve. Expected: the sidebar content should not be covered by the titlebar accessory/material. Actual: the top sidebar item can appear blacked out/covered. In the first attached screenshot, "First sidebar row" is hidden/covered while "Second row" and the following rows are still visible. Issue 2: split-view accessory does not get the same hard separator As a possible workaround, I tried using NSSplitViewItemAccessoryViewController instead of NSTitlebarAccessoryViewController. Both controllers are configured with: if #available(macOS 26.1, *) { accessory.preferredScrollEdgeEffectStyle = .hard } The titlebar accessory shows the expected hard boundary/separator behavior, but the split-view item accessory does not appear to get the same hard edge treatment. The second attached screenshot shows the workaround comparison between the titlebar accessory and the split-view accessory. Expected: preferredScrollEdgeEffectStyle = .hard should produce a comparable hard separator for the split-view accessory. Actual: the split-view accessory still looks visually different and does not show the same hard boundary. Issue 3: split-view accessory is inset differently The NSSplitViewItemAccessoryViewController also appears to be laid out with spacing/insets around it. In the repro, the accessory custom view has a faint red background. Both accessory views request and receive the same height: requested 36 pt, actual 36.0 pt So the mismatch does not seem to be caused by the accessory view’s own intrinsic height. Instead, the split-view accessory appears to be hosted inside an inset container, with spacing around it, while the titlebar accessory is flush with the titlebar/content edge. Expected: if both accessories host the same view with the same intrinsic height, their effective placement should be comparable, or there should be a documented way to remove/control the split accessory insets. Actual: the split-view accessory is visually inset on multiple sides, making it unsuitable as a drop-in workaround for the titlebar accessory issue. The second attached screenshot also shows this: the split-view accessory has the same requested and actual height as the titlebar accessory, but it is still visually inset and does not align the same way. Question Is this expected behavior on macOS 26, especially with Reduce Transparency enabled? If so, what is the recommended AppKit approach for placing a filter/search accessory below the toolbar/titlebar without covering sidebar content, while still getting a hard separator and predictable layout?

I would like to implement a focus-based Menu-Bar command in my SwiftUI iPadOS app, or react to key command while certain elements are focused. Traditionally, this requires using @FocusedValue and focusable() and focused, however, it appears that setting a @FocusState on macOS will work, but setting a @FocusState on iPadOS will never work. How can this API work and support MenuBar commands and keyboard inputs? It kind of has an accessibility impact as well. Not all users are going to know, or want to turn on "full keyboard control" for basic interactions. Here's a small sample that doesn't appear to focus on iPadOS: struct FocusableTestView: View { @FocusState private var isRectFocused: Bool var body: some View { VStack { // This text field should focus the custom input when pressing return: TextField("Enter text", text: .constant("")) .textFieldStyle(.roundedBorder) .onSubmit { isRectFocused = true } .onKeyPress(.return) { isRectFocused = true return .handled } // This custom "input" should focus itself when tapped: Rectangle() .fill(isRectFocused ? Color.accentColor : Color.gray.opacity(0.3)) .frame(width: 100, height: 100) .overlay( Text(isRectFocused ? "Focused" : "Tap me") ) .focusable(true) .focused($isRectFocused) .onTapGesture { isRectFocused = true print("Focused rectangle") } // The focus should be able to be controlled externally: Button("Toggle Focus") { isRectFocused.toggle() } .buttonStyle(.bordered) } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) } }

I have a custom input view in my app which is .focusable(). It behaves similar to a TextField, where it must be focused in order to be used. This works fine on all platforms including iPad, except when when an external keyboard is connected (magic keyboard), in which case it can't be focused anymore and becomes unusable. Is there a solution to this, or a workaround? My view is very complex, so simple solutions like replacing it with a native view isn't possible, and I must be able to pragmatically force it to focus. Here's a very basic example replicating my issue. Non of the functionality works when a keyboard is connected: struct FocusableTestView: View { @FocusState private var isRectFocused: Bool var body: some View { VStack { // This text field should focus the custom input when pressing return: TextField("Enter text", text: .constant("")) .textFieldStyle(.roundedBorder) .onSubmit { isRectFocused = true } .onKeyPress(.return) { isRectFocused = true return .handled } // This custom "input" should focus itself when tapped: Rectangle() .fill(isRectFocused ? Color.accentColor : Color.gray.opacity(0.3)) .frame(width: 100, height: 100) .overlay( Text(isRectFocused ? "Focused" : "Tap me") ) .focusable(true, interactions: .edit) .focused($isRectFocused) .onTapGesture { isRectFocused = true print("Focused rectangle") } // The focus should be able to be controlled externally: Button("Toggle Focus") { isRectFocused.toggle() } .buttonStyle(.bordered) } .frame(maxWidth: .infinity, maxHeight: .infinity, alignment: .center) } }

I have encountered the following issue on iPadOS. Has anyone experienced this issue or reported it before? Steps to Reproduce Enable Windowed Apps mode in Settings. Launch the Settings app and another app (App X), and display both in windowed mode. Use the Settings app to completely cover App X (App X becomes inactive at this point). From the Settings app, enable Full Screen Apps mode. Bring App X to the foreground. Expected Result App X becomes active when brought to the foreground. Actual Result Even after bringing App X to the foreground, it immediately becomes inactive. The issue persists even if App X is restarted. To resolve the issue, it is necessary to either restart the iPad or switch back to Windowed Apps mode. Verified OS Versions iPadOS 26.5: Reproducible iPadOS 26.4.2: Reproducible iPadOS 26.2: Not reproducible iPadOS 26.0.1: Not reproducible Additional Information According to the console logs, App X appears to remain inactive because the deactivation reason "sceneOverlap" persists.

Summary On iOS 18 and later, Chinese text rendering shows a noticeable performance regression related to the HVF (Hierarchical Variable Font) pipeline. Environment iOS Version: iOS 18+ Framework: libhvf.dylib (Hierarchical Variable Font) Affected Font: PingFangUI.ttc (private system font, automatically used for Chinese text) Related Frameworks: CoreText, CoreGraphics, FontParser Devices: All iOS devices (more noticeable on older hardware) Background iOS 18 Change: PingFang.ttc was removed from /System/Library/Fonts/ Private PingFangUI.ttc was added (inaccessible via normal font APIs) System automatically uses PingFangUI.ttc for all Chinese text rendering PingFangUI.ttc contains HVF tables → utilizes libhvf.dylib HVF Architecture: HVF (Hierarchical Variable Font) organizes glyphs as tree structures Each glyph = Composite → multiple Parts → nested hierarchy Rendering a single character requires traversing this tree Key Observation A single Chinese glyph typically triggers ~20 calls to HVF::LoaderHVGL::loadPartAtIndex. Cache invalidation is triggered via IncrementRenderCount after every 18 glyphs: __ZNK27THierVariationsDataForkFont20IncrementRenderCountEv: ldr w8, [x0, #0x12c] add w8, w8, #0x1 str w8, [x0, #0x12c] cmp w8, #0x12 b.lo return ldr x0, [x0, #0x120] bl HVF_clear_part_cache str wzr, [x19, #0x12c] return: ret This causes the cache to be cleared before a typical sentence finishes rendering. Complete Call Stack (Rendering Hot Path) #0-1 HVF::LoaderHVGL::loadPartAtIndex #2 HVF::FlatPartCache::partAtIndex #3 HVF::PartTransformRenderer::renderComposite #4 HVF::PartTransformRenderer::render #5 HVF::PartTransformRenderer::renderToContext #6 _HVF_render_current_part #7 THierVariationsFontHandler::GetOutlinePath #8 TFontHandler::CopyGlyphPath #9 THierVariationsFontHandler::CopyGlyphPath #10 TFPFont::CopyGlyphPath #11-12 TFPFont::CopyGlyphPath / _FPFontCopyGlyphPath #13 _CGFontCreateGlyphPath #14 _CGGlyphBuilderLockBitmaps #15 _render_glyphs #16 _draw_glyph_bitmaps #17 _ripc_DrawGlyphs #18 CG::DisplayList::executeEntries #19 _CGDisplayListDrawInContextDelegate #20 _CABackingStoreUpdate_ #21-22 CALayer display/layout #23-24 CA::Transaction::commit #25-30 UIApplicationMain / RunLoop HVF::LoaderHVGL::loadPartAtIndex is consistently observed as a hot function in Instruments and in production. Cache Clear Call Stack #0 HVF::FlatPartCache::clear #1 HVF_clear_part_cache #2 THierVariationsDataForkFont::IncrementRenderCount #3 THierVariationsFontHandler::GetOutlinePath #4 TFontHandler::CopyGlyphPath #5 FPFontCopyGlyphPath #6 CGFontCreateGlyphPath #7 _render_glyphs #8 _draw_glyph_bitmaps #9 _ripc_DrawGlyphs This shows that cache clearing occurs within the glyph rendering path. Impact For a typical Chinese sentence (~20 characters): Each glyph requires multiple part loads (~20 per glyph) Cache is cleared before rendering completes Previously loaded parts cannot be reused Observed effects: Increased loadPartAtIndex invocation count Low cache hit rate Increased CPU usage in glyph rendering Main-thread blocking during Core Animation commit Regression iOS 17 and earlier: Rendering is smooth under similar workloads. iOS 18+: Increased rendering cost and visible frame drops. The issue is more pronounced on older devices such as iPhone XS and iPhone 11. Reproduction Render a Chinese text string longer than 18 characters, for example: 刷新测试中文文本用于验证渲染性能问题需要超过十八个字 Observe: Repeated loadPartAtIndex calls Frequent cache clearing Request It would be helpful to review the cache eviction strategy for HVF, particularly for complex scripts such as Chinese. Potential considerations: Adjusting or scaling the cache threshold Avoiding full cache clears during continuous rendering Improving reuse of parts across glyphs within the same rendering batch

please help, i am new to SWIFTUI getting an error: A NavigationLink is presenting a value of type “String” but there is no matching navigationDestination declaration visible from the location of the link. The link cannot be activated. struct debug_navigation_3: View { @State private var path = NavigationPath() @StateObject private var debug_Client_Lead_Data_ListVM = Debug_Client_Lead_Data_List_Model() var body: some View { NavigationStack(path:$path) { VStack { List(debug_Client_Lead_Data_ListVM.Debug_Client_Lead_Data_Rows, id: \.self) { curr_clientLeadRequest in NavigationLink(curr_clientLeadRequest.Client_Message, value: curr_clientLeadRequest.Client_Message) } } .navigationDestination(for:Debug_Client_Lead_Data.self) { curr_clientLeadRequest in debug_navigation_3_DetailView(rec_id: Int64(curr_clientLeadRequest.id)) } } .onAppear() { Task { await debug_Client_Lead_Data_ListVM.search(rec_id:Int64(0)) //bring all REST API } } } } // data model import Foundation struct Debug_Client_Lead_Data_Response: Decodable { let Debug_Client_Lead_Data_Rows: [Debug_Client_Lead_Data] private enum CodingKeys: String, CodingKey { case Debug_Client_Lead_Data_Rows = "rows" // root tag: REST API } } struct Debug_Client_Lead_Data: Decodable, Hashable, Identifiable { let id:Int32 let Client_Message: String private enum CodingKeys: String, CodingKey { case id = "id" case Client_Message = "Client_Message" } } //list view model import Foundation @MainActor class Debug_Client_Lead_Data_List_Model: ObservableObject { @Published var Debug_Client_Lead_Data_Rows: [Debug_Client_Lead_Data_ListViewModel] = [] func search(rec_id:Int64) async { do { let Debug_Client_Lead_Data_Rows = try await Webservice_debug_client_lead_data().getClientLeadRequestSummary(rec_id:rec_id) // '0' optional self.Debug_Client_Lead_Data_Rows = Debug_Client_Lead_Data_Rows.map(Debug_Client_Lead_Data_ListViewModel.init) } catch { print(error) } } } struct Debug_Client_Lead_Data_ListViewModel: Identifiable, Hashable { let debug_Client_Lead_Data: Debug_Client_Lead_Data var id:Int32 { debug_Client_Lead_Data.id } var Client_Message: String { debug_Client_Lead_Data.Client_Message } } //REST API import Foundation class Webservice_debug_client_lead_data { func getClientLeadRequestSummary(rec_id:Int64) async throws -> [Debug_Client_Lead_Data] { var components = URLComponents() components.scheme = Global_REST_API_URL_HTTP components.host = Global_REST_API_URL components.port = Global_REST_API_URL_port components.path = "/GetClientLeadRequest" components.queryItems = [ URLQueryItem(name: "rec_id", value: String(rec_id)) // Optional, pass '0' for all rows ] guard let url = components.url else { throw NetworkError.badURL } let (data, response) = try await URLSession.shared.data(from: url) guard (response as? HTTPURLResponse)?.statusCode == 200 else {throw NetworkError.badID } let Debug_Client_Lead_Data_Response = try? JSONDecoder().decode(Debug_Client_Lead_Data_Response.self, from: data) return Debug_Client_Lead_Data_Response?.Debug_Client_Lead_Data_Rows ?? [] } }

I have a custom UIGestureRecognizerRepresentable that causes a crash. Only happens about once a week, and that’s with about a thousand times it gets invoked. But it’s persistent and annoying when it happens. The code looks like func handleUIGestureRecognizerAction(_ recognizer: Recognizer, context: Context) { let startLocation = context.converter.convert(globalPoint: recognizer.startLocation, to: coorinateSpace) coorinateSpace is set in init and has crashed on .global, .local, and .named("foo") The convert function gets caught in a AGGraphGetValue loop before finally failing. It has happened while attached to the debugger, but there is not any more information than is in the logs. I don’t even know why it would invoke AttributeGraph in the first place. Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x23aedd1d0 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1eb0cf7dc pthread_kill + 268 2 libsystem_c.dylib 0x197a89c98 abort + 148 3 AttributeGraph 0x1befffef0 AG::precondition_failure(char const*, ...) + 216 4 AttributeGraph 0x1bf000f68 AG::Graph::input_value_ref_slow(AG::data::ptr<AG::Node>, AG::AttributeID, unsigned int, unsigned int, AGSwiftMetadata const*, unsigned char&, long) + 936 5 AttributeGraph 0x1beffb2a8 AGGraphGetValue + 232 6 SwiftUICore 0x19626eee8 specialized UnaryLayoutComputer.updateValue() + 92 7 SwiftUICore 0x196bdc9cc specialized implicit closure #1 in closure #1 in closure #1 in Attribute.init<A>(_:) + 24 8 AttributeGraph 0x1bf001914 AG::Graph::UpdateStack::update() + 496 9 AttributeGraph 0x1bf00152c AG::Graph::update_attribute(AG::data::ptr<AG::Node>, unsigned int) + 352 10 AttributeGraph 0x1bf000e68 AG::Graph::input_value_ref_slow(AG::data::ptr<AG::Node>, AG::AttributeID, unsigned int, unsigned int, AGSwiftMetadata const*, unsigned char&, long) + 680 11 AttributeGraph 0x1beffb2a8 AGGraphGetValue + 232 12 SwiftUICore 0x196287604 specialized UnaryChildGeometry.value.getter + 92 13 SwiftUICore 0x196a21bc0 specialized implicit closure #1 in closure #1 in closure #1 in Attribute.init<A>(_:) + 52 14 AttributeGraph 0x1bf001914 AG::Graph::UpdateStack::update() + 496 15 AttributeGraph 0x1bf00152c AG::Graph::update_attribute(AG::data::ptr<AG::Node>, unsigned int) + 352 16 AttributeGraph 0x1bf000e68 AG::Graph::input_value_ref_slow(AG::data::ptr<AG::Node>, AG::AttributeID, unsigned int, unsigned int, AGSwiftMetadata const*, unsigned char&, long) + 680 17 AttributeGraph 0x1beffb2a8 AGGraphGetValue + 232 18 SwiftUICore 0x196a21b28 specialized implicit closure #1 in closure #1 in closure #1 in Attribute.init<A>(_:) + 72 19 AttributeGraph 0x1bf001914 AG::Graph::UpdateStack::update() + 496 20 AttributeGraph 0x1bf00152c AG::Graph::update_attribute(AG::data::ptr<AG::Node>, unsigned int) + 352 21 AttributeGraph 0x1beffb560 AG::Graph::value_ref(AG::AttributeID, unsigned int, AGSwiftMetadata const*, unsigned char&) + 296 22 AttributeGraph 0x1beffb2f8 AGGraphGetValue + 312 23 AttributeGraph 0x1bf00206c AGGraphGetInputValue + 60 24 SwiftUICore 0x19626d0a8 GeometryProxy.transform.getter + 220 25 SwiftUICore 0x19699ce80 GeometryProxy.convert<A>(globalPoint:to:) + 76 26 SwiftUI 0x195ddf71c UIGestureRecognizerRepresentableCoordinateSpaceConverter.convert<A>(globalPoint:to:) + 76 27 myapp.debug.dylib 0x1033b3a30 MyAppDragGesture.handleUIGestureRecognizerAction(_:context:) + 1560

Environment Device: Apple Vision Pro (real device) OS: visionOS 26.5 Xcode: 26.5 Framework: AVFAudio / AVFoundation Summary On visionOS 26.5, tapping an empty Button consistently emits the following internal warning before the action closure executes: <<<< FigAudioSession(AV) >>>> signalled err=-19224 (<>:612) After this warning is emitted, any subsequent call to configure AVAudioSession silently stops working — audio input and output become non-functional for the lifetime of the session. If the same configuration is performed without a preceding button tap (e.g., inside View.task {}), it succeeds and audio works correctly. Reproduction Due to a dependency on LiveKitWebRTC (livekit/webrtc-xcframework) for WebRTC-based Realtime API audio, we are unable to provide a full self-contained sample project. However, the AVAudioSession configuration code involved is as follows: static func configureAudioSession() { #if !os(macOS) do { let audioSession = AVAudioSession.sharedInstance() #if os(tvOS) try audioSession.setCategory(.playAndRecord, options: []) #else try audioSession.setCategory(.playAndRecord, options: [.defaultToSpeaker]) #endif try audioSession.setMode(.videoChat) try audioSession.setActive(true, options: .notifyOthersOnDeactivation) } catch { print("Failed to configure AVAudioSession: \(error)") } #endif } Scenario A — Button tap (fails): Button("Start") { configureAudioSession() // FigAudioSession err=-19224 appears; audio stops working } Scenario B — View.task (succeeds): .task { configureAudioSession() // No warning; audio works correctly } The only difference is whether a user gesture (Button tap) precedes the call. Observed Behavior Tapping any Button on visionOS 26.5 causes FigAudioSession(AV) err=-19224 to be signalled at <>:612, even before the action closure runs. After this warning, AVAudioSession configuration appears to have no effect — setActive(true) does not throw, but audio appears to stop functioning. Configuring the session prior to any button interaction (e.g., in View.task {}) works correctly. Expected Behavior A Button tap should not implicitly interfere with the audio session state. AVAudioSession configuration should succeed regardless of the UI event context that triggers it. Questions What does FigAudioSession(AV) err=-19224 mean? Does it correspond to a documented AVAudioSession.ErrorCode? Why does a Button tap trigger a FigAudioSession signal on visionOS? Is the system performing implicit audio session management when detecting user interaction? Is there a recommended pattern for configuring AVAudioSession in response to a user gesture on visionOS? Our current workaround (View.task {}) is not suitable for on-demand audio start triggered by the user. Is err=-19224 causally responsible for the subsequent audio issue? Since setActive(true) does not throw after the warning, it is unclear whether this signal is the direct cause of the apparent audio failure or a symptom of a deeper conflict. Are there UI components or APIs on visionOS that do not trigger this signal, while still being user-interaction driven? Additional Notes Reproducible only on physical Apple Vision Pro hardware; not observed in Simulator. AirPlay mirroring is not in use during testing. No other apps are playing audio in the background at the time of reproduction. We use LiveKitWebRTC (livekit/webrtc-xcframework, revision 94ce1c9) for WebRTC audio. However, the FigAudioSession warning appears independently of the WebRTC layer — it is emitted on Button tap even before configureAudioSession() is called. We have verified that calling configureAudioSession() before performHandshake() (i.e., before WebRTC initializes its audio pipeline) does not resolve the issue when a Button tap precedes the call.

I'm in the unenviable position of needing the current UIViewController to keep an external library happy. Essentially, I need to do this in SwiftUI: import LibraryOutOfMyControl ViewControllerReader { viewController in Button("Action") { LibraryOutOfMyControl.action(with: viewController) } } My simple attempt below functions correctly but I'm relying on makeUIViewController always being immediately followed by updateUIViewController. Is the a reasonable assumption or should I set everything up assuming updateUIViewController might never be called? struct ViewControllerReader<Content>: UIViewControllerRepresentable where Content: View { @ViewBuilder var content: (UIViewController) -> Content func makeUIViewController(context: Context) -> UIHostingController<Content> { UIHostingController(rootView: content(UIViewController())) } func updateUIViewController(_ uiViewController: UIHostingController<Content>, context: Context) { uiViewController.rootView = content(uiViewController) uiViewController.view.isUserInteractionEnabled = context.environment.isEnabled } func sizeThatFits(_ proposal: ProposedViewSize, uiViewController: UIHostingController<Content>, context: Context) -> CGSize? { uiViewController.sizeThatFits(in: proposal.replacingUnspecifiedDimensions()) } }

I have a SwiftUI view inside a NavigationStack with a custom navigation bar background color. I want the navigation bar buttons to have a consistent color throughout the app. The issue is that the navigation bar button color changes depending on the first/root view in the body. When the root view is a ScrollView var body: some View { ScrollView { // content } .toolbarBackground(Color(red: 0.02, green: 0.27, blue: 0.13), for: .navigationBar) .toolbarBackground(.visible, for: .navigationBar) .toolbarColorScheme(.dark, for: .navigationBar) } The navigation bar buttons appear white. However, if I replace the ScrollView with a VStack, while keeping the same modifiers, the navigation bar buttons appear black: var body: some View { VStack { // content } .toolbarBackground(Color(red: 0.02, green: 0.27, blue: 0.13), for: .navigationBar) .toolbarBackground(.visible, for: .navigationBar) .toolbarColorScheme(.dark, for: .navigationBar) } The navigation bar buttons appear black. How can I make the navigation bar buttons stay the same colour in both cases?

I'm trying to use SwiftUI views inside an NSToolbarItem, and I feel like I'm fighting the system. The goal is to create custom toolbar controls. I don't want AppKit or SwiftUI to recognize that there's a SwiftUI view in the toolbar and then try to style it automatically, which is what I think is happening. Consider this hierarchy: - NSToolbar - NSToolbarItem - view -> MyCustomNSView - addSubview(NSHostingView<CustomView>) So CustomView is inside an NSHostingView, which is inside an NSView, which is assigned to the .view property of an NSToolbarItem. For a while, I struggled to get this working at all because SwiftUI's layout metrics appeared to be affected by safe area insets. SwiftUI's ignoresSafeArea() only seemed to move the problem around. For now, I've disabled full-size content view, which I don't really need anyway. However, a SwiftUI Button or Menu still doesn't behave or style the way I would expect when placed inside an NSToolbarItem. They don't seem to honor many of the styling attributes or view modifiers that work elsewhere. Is there a way to tell AppKit to "ignore" the children of my NSToolbarItem and not apply toolbar-specific styling to them? Am I even correct in thinking that AppKit is recognizing a Button or Menu in the toolbar and forcibly applying styling to it? Previously, I tried implementing my "custom toolbar" entirely outside of NSToolbar, but then SwiftUI struggled with placing views under the transparent, non-existent toolbar. I'd appreciate any direction or hints here. It would be really nice to use SwiftUI for the controls I have in mind, but at the moment I can't get close to the result I'm aiming for.

Environment Device: iPad Pro 11-inch 2nd gen (iPad8,9 / A12X) OS: iPadOS 26.5 (23F77) Xcode: 26.3 Issue App crashes with EXC_BREAKPOINT / SIGKILL when user scrolls through a PDF in PDFView on iPadOS 26.5. Crash Log (ASI) "BUG IN CLIENT OF LIBPLATFORM: Trying to recursively lock an os_unfair_lock" Abort Cause 259 Root Cause (from .ips) Two threads deadlock on os_unfair_lock inside CGPDFPageInsertTableDescriptions: Thread 0 (main): _os_unfair_lock_recursive_abort CGPDFPageInsertTableDescriptions [PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:]_block_invoke_2 _dispatch_async_and_wait_invoke ← main thread waiting Thread (PDFKit.PDFDocument.formFillingQueue): _dispatch_sync_f_slow ← background queue waiting for main thread +[PDFPageAnalyzerV2 addTablesFromVisionDocument:documentImage:toPage:withBox:] +[PDFPageAnalyzerV2 analyzePage:withBox:requestTypes:] -[PDFView visiblePagesChanged:] ← triggered by scrolling PDFPageAnalyzerV2 dispatches_sync back to the main thread from PDFKit.PDFDocument.formFillingQueue, while the main thread is already blocked in dispatch_async_and_wait for the same operation. This results in a recursive lock on os_unfair_lock in CGPDFPageInsertTableDescriptions → SIGKILL. Notes PDFPageAnalyzerV2 appears to be a new iOS 26 Vision-based table analysis feature No public API found in PDFKit headers to disable this analysis Workaround: pdfView.usePageViewController(true, withViewOptions: nil) appears to reduce frequency of visiblePagesChanged: triggers Question Is there an official API to disable PDFPageAnalyzerV2 table analysis on iOS 26? Is this a known issue with a fix planned?

Fatal Exception: NSInternalInconsistencyException Cannot remove an observer <WKWebView 0x135137800> for the key path "configuration.enforcesChildRestrictions" from <STScreenTimeConfigurationObserver 0x13c6d7460>, most likely because the value for the key "configuration" has changed without an appropriate KVO notification being sent. Check the KVO-compliance of the STScreenTimeConfigurationObserver [class.] I noticed that on iOS 26, WKWebView registers STScreenTimeConfigurationObserver, Is this an iOS 26 system issue? What should I do?

Dynamic UISegment control in collection view returns selected segment index 0 on click of other segments after updating iOS and Xcode 26 for first time afterwards its working as expected in iOS less than 26 devices. But woking fine in iOS 26 devices. Please suggest how to resolve Thanks in advance

[Also submitted as FB19313064] The .disabled() modifier doesn't visually disable buttons inside a ToolbarItem container on iOS 26.0 (23A5297i) devices. The button looks enabled, but tapping it doesn't trigger the action. When deployment target is lowered to iOS 18 and deployed to an iOS 18 device, it works correctly. It still fails on an iOS 26 device, even with an iOS 18-targeted build. This occurs in both the Simulator and on a physical device. Screen Recording Code struct ContentView: View { @State private var isButtonDisabled = false private var osTitle: String { let version = ProcessInfo.processInfo.operatingSystemVersion return "iOS \(version.majorVersion)" } var body: some View { NavigationStack { VStack { Button("Body Button") { print("Body button tapped") } .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) Toggle("Disable buttons", isOn: $isButtonDisabled) Spacer() } .padding() .navigationTitle("Device: \(osTitle)") .navigationBarTitleDisplayMode(.large) .toolbar { ToolbarItem { Button("Toolbar") { print("Toolbar button tapped") } .buttonStyle(.borderedProminent) .disabled(isButtonDisabled) } } } } }

[Also submitted as FB20213961] SwiftUI Button with a label: closure containing only an Image view has a smaller tap target than buttons created with a Label or the convenience initializer. The hit area shrinks to the image bounds instead of preserving the standard minimum tappable size. SCREEN RECORDING On a physical device, the difference is obvious—it’s easy to miss the button. Sometimes it even shows the button-tapped bounce animation but doesn’t trigger the action. SYSTEM INFO Xcode Version 26.0 (17A321) macOS 15.6.1 (24G90) iOS 26.0 (23A340) SAMPLE CODE The following snippet shows the difference in hit targets between the convenience initializer, a Label, and an Image (the latter two in a label: closure). // ✅ Hit target is entire button Button("Button 1", systemImage: "1.square.fill") { print("Button 1 tapped") } // ✅ Hit target is entire button Button { print("Button 2 tapped") } label: { Label("Button 2", systemImage: "2.square.fill") } // ❌ Hit target is smaller than button Button { print("Button 3 tapped") } label: { Image(systemName: "3.square.fill") }

I'm getting a log error and a slight delay in the UI when displaying a system image that changes at the end of a sequence. I'm using a ternary operator to determine the image; the fact that the image changes seem to be the issue, rather than the value itself. The issue only occurs for a newly installed app, and not when the app is rerun. (I'm using similar code to display an onboarding sequence after installation.) This happens on device (iphone 15 pro v25.6) and simulator (iphone 17 pro v25.6 and iphone 16 pro v18.5); xcode 26.5 (17F42). Console errors (device and iphone 17 simulator): fopen failed for data file: errno = 2 (No such file or directory) fopen failed for data file: errno = 2 (No such file or directory) Repro Code: import SwiftUI struct ContentView: View { // NOTE: error only occurs with new install. @State private var currentItem = 0 @State private var totalItems: Int = 4 var body: some View { VStack(spacing: 0) { Spacer() Text("totalItems: \(totalItems)") TabView(selection: $currentItem) { ForEach(0...totalItems, id: \.self) { item in Text("\(item) ~ \(currentItem)") .tag(item) } } //TV .tabViewStyle(.page(indexDisplayMode: .never)) .frame(height: 200) Button { if currentItem < totalItems { currentItem += 1 currentItem = min(totalItems, currentItem) } } label: { let imgString: String = (currentItem == totalItems ? "arrowshape.turn.up.right" : "arrowshape.right") // error // let imgString: String = ((currentItem == totalItems) ? "x.circle" : "smallcircle.filled.circle") // error // let imgString: String = "smallcircle.filled.circle" // no error // let imgString: String = "x.circle" // no error Text("\(imgString)") // if only print text, no error, so issue seems to be with Image. Image(systemName: imgString) } Spacer() } } } Click through the button sequence to see issue at end of sequence. Uncomment the various imgString lines to see indicated differences in behavior. Need to delete app each time to repro issue. Running in simulator on iphone 16 Pro iOS 18.5 has slightly different error messages: fopen failed for data file: errno = 2 (No such file or directory) Errors found! Invalidating cache... fopen failed for data file: errno = 2 (No such file or directory) Errors found! Invalidating cache...

According to our crash analytics, the application crashes when trying to share a PDF file in the UIDocumentInteractionController. This crash takes place on iOS 26+ only. Based on analytics, user sessions end when the pdf file is opened in the UIDocumentInteractionController. We couldn't reproduce it on a physical device or a simulator. Can you please help with a fix or at least workaround for this issue? What's your opinion for bug localization (application or framework)? Crash log is attached below. CoreFoundation __exceptionPreprocess + 164 libobjc.A.dylib objc_exception_throw + 88 CoreFoundation -[__NSArrayM insertObject:atIndex:] + 1276 ShareSheet __79-[SHSheetActivityItemsManager loadItemProvidersForRequest:activity:completion:]_block_invoke + 972 ShareSheet __79-[_UIShareServiceActivityProxy _loadItemProvidersFromActivityItems:completion:]_block_invoke + 88 ShareSheet __74+[UIActivity _loadItemProvidersFromActivityItems:withCacheURL:completion:]_block_invoke_4 + 352 libdispatch.dylib _dispatch_call_block_and_release + 32 libdispatch.dylib _dispatch_main_queue_drain.cold.5 + 812 libdispatch.dylib _dispatch_main_queue_drain + 180 CoreFoundation __CFRunLoopRun + 1944

We are implementing starting an activity via Push-To-Start. For the most part it works great, however we have run into a few edge cases. Currently, we send the "start activity" push notification and it creates the Activity as expected. If the app doesn't send an update token w/in a configured time, we assume the activity didn't start and try to start the activity again. Occasionally we get into a situation where there have been multiple activities started, but it should really only be one. Here is my theory: We store an auth token in the keychain for all REST endpoints if the phone has been restarted and not unlocked, the app doesn't have access to the auth token and fails to send the update token to our backend. Are there any best practices on how to manage PTS and UPDATE tokens? (updating these w/o authentication seems problematic)