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

Hi all, I was trying to have a UI similar to Preview app which we have in iPhone. We have a tab bar view and behind it, we have a sheet view. I was trying to achieve that, but the .sheet modifier covers the bottom tab bar view.

I have a chat app with a floating composer pill (NSGlassEffectView) pinned to the bottom of my content area. Messages scroll behind it. The pill looks fine but content behind it is completely clear. Fully legible text showing through, no frosting at all. Mail, Messages, Notes all have this frosted look where content behind a floating bar is blurred enough that you can't read it. That's what I'm going for. My scroll view has wantsLayer = true. I tried hasVerticalScroller = true + scrollerStyle = .overlay based on a tip I saw in another thread. No change. Is NSGlassEffectView supposed to blur what's behind it, or is the frosting in Apple's apps coming from the scroll edge effect? If it's the scroll edge effect, is there any way to trigger it for a custom floating view at the bottom of a scroll view? I can't find any AppKit API for this. I also spent time trying this in SwiftUI using .glassEffect() on macOS. Same result, the material renders nearly clear with no way to control the frosting level via any public API. If I'm missing something obvious I'd love to know. I've been stuck on this one for a while. Thanks for any advice! I've attached photos of my input bar (clearly transparent) and Apple Messages, which has a style that I see all over iOS and Mac OS 26.

This is an iOS app that runs on Mac in iPad mode. on Mac, I want to be able to drop a file (pdf) on the app icon and see it in the app to display some notification that operation was OK. For this, I use notification, sent from sceneDelegate. All VC add observer for the notification, allowing to display whatever the front VC is. It works OK in most cases, except when: I drop a file on the app icon in the dock (app launched from Xcode which creates the icon in dock) In this case, I need to repeat the drop to get the notification sent. After that, it works systematically. The problem does not come from notification, but because func scene(_ scene: UIScene, openURLContexts URLContexts: Set) is not called, as I could test with: func scene(_ scene: UIScene, openURLContexts URLContexts: Set<UIOpenURLContext>) { print("dropped") } dropped is logged only on second drop. Why does this occur only for the dock icon ?

Posting here in case other CarPlay developers are hitting the same thing, and to give Apple engineers a forum-side reference for the radar. Filed as FB22828125. Symptom In a CarPlay app using CPListTemplate, UIImage instances assigned to CPListItem.image start rendering as the system placeholder glyph after extended CarPlay use (several hours to a few days of cumulative session time). Text labels and accessory chevrons still render correctly — only the leading image is affected, and it affects every visible template surface at once. Known recovery Once the failure starts, it survives: Killing and relaunching the app Force-quitting and relaunching from CarPlay itself Disconnecting and reconnecting CarPlay The only known recovery is rebooting the iPhone. After reboot, the same code path renders correctly again — until the failure reoccurs. App-side ruling-out UIImage instances passed to CPListItem.image are non-nil at failure time (verified by assertions) Each template rebuild calls UIGraphicsImageRenderer afresh from UIImage(systemName:) — no caching of UIImage across rebuilds Images are baked via withTintColor(_:renderingMode: .alwaysOriginal) then rasterized, so CarPlay receives a finished bitmap rather than a template image relying on its tinting pipeline Same code path renders correctly on launch and for hours afterward — the input bytes are identical before and after the failure boundary Because the failure survives both the app process and the CPTemplateApplicationScene teardown, the corrupted state appears to live in an iOS system process rather than in the app or the CarPlay session. Question for the forum Is there a known workaround on the app side — a different image-supply API, or a way to force the CarPlay rendering pipeline to invalidate its cache without an iPhone reboot?

On iOS 26 (26.0–26.5), a rectangular region in the lower half of the screen sometimes does not render while the content underneath remains laid out and interactive — scrolling works, hit testing succeeds, and rows visibly emerge from behind the floating tab bar as you scroll. This is a render-server / compositor gap, not a layout or safe-area issue. We see it on both UIKit and SwiftUI scroll surfaces inside the same UITabBarController: UIKit: UICollectionView with UICollectionViewFlowLayout (sectionInsetReference = .fromSafeArea) SwiftUI: List(.plain) nested in TabView(.page) inside a UIHostingController Confirmed on iPhone 16 Pro, iPhone 17 Pro, iPhone 13 Pro Max. Community threads (linked below) report the same symptom in Messages, Notes, Safari, Mail, and the App Store. Questions for Apple Is this acknowledged as an OS-level regression, and is a fix targeted for an upcoming iOS 26.x release? Is there a deterministic repro? We've tried background/foreground cycles, push notifications mid-scroll, tab switches during inertia, lock/unlock, orientation flips, simulated memory warnings, layout-invalidation storms, and trait-collection cycles — none reliably trigger it on our test devices. Is there a developer-side mitigation (e.g. avoiding specific UIVisualEffectView / Glass configurations, opting out of a rendering optimization) until a system fix lands? Is there a runtime signal on CALayer or UIScrollView we can inspect to detect this gap state and force a recovery (tile redraw, backing-store discard, etc.)? Notes We cannot reproduce locally. Affected users hit it organically; once it appears it persists across re-layout until the view controller is torn down. Community reports consistently mention Reduce Transparency being enabled on affected devices, and toggling it off clears the issue for many. In our own testing, RT alone is not sufficient to trigger the bug — it appears to be a contributing condition rather than the trigger. References: Apple Discussions: https://discussions.apple.com/thread/256182149 Reddit r/ios (multiple system apps): https://www.reddit.com/r/ios/comments/1nlzn7f/some_apps_cutting_off_half_the_display/ https://www.idownloadblog.com/2026/03/23/webpage-content-cutting-off-safari/

When I try to create bindings between a xib file and it's associated objective-c source code, xcode no longer autocompletes to either an action or an outlet binding. The little circles in the code editor that would previously indicate bindings are no longer there. I can now only create bindings in the tree heirarchy of the UIKit editor after manually adding IBOutlets to the header files.

We are facing an issue with VNDocumentCameraViewController where the tick button in the top-right corner becomes completely unresponsive after a document is scanned. When the user taps the tick button immediately after capturing the document — before the "Ready for next Scan" text appears on screen — the button freezes and the documentCameraViewController(_:didFinishWith:) delegate is never called. Through debugging, we observed that if the tick is tapped before the scanned image thumbnail appears in the bottom-left corner, the delegate is never triggered. However, if the user waits for the thumbnail to appear and then taps the tick, it works as expected. This indicates that VNDocumentCameraViewController has an internal processing pipeline that must complete before the tick button becomes truly interactive, but there is no visual indication or API callback to inform the user or the developer when it is safe to tap. We would appreciate Apple looking into this and either disabling the button during processing, queuing the tap, or providing a delegate callback for when the controller is truly ready.

In an Xcode 26.4 + iOS 26.x environment, I called evaluateJavaScript inside webView(_ webView: WKWebView, didCommit navigation: WKNavigation!) and got the following error: Printing description of error: ▿ Optional<Error> - some : Error Domain=WKErrorDomain Code=4 "A JavaScript exception occurred" UserInfo={WKJavaScriptExceptionLineNumber=0, WKJavaScriptExceptionMessage=TypeError: undefined is not a function, WKJavaScriptExceptionColumnNumber=0, NSLocalizedDescription=A JavaScript exception occurred}) However, this worked fine in earlier versions before Xcode 26.4 (> 26.0 and < 26.4, though I do not remember the exact version), still with iOS 26.x. It also works fine in an Xcode 26.4 + iOS 18.x environment. And if I add a slight delay using DispatchQueue.main.asyncAfter in the Xcode 26.4 + iOS 26.x environment, then it works without any issue. So what exactly is going on here? I would really appreciate an explanation.

Hi, I’m seeing a visual issue with a SwiftUI Menu styled with Liquid Glass on iOS 26. I have a top bar control where a Menu is inside a GlassEffectContainer. The menu label uses .glassEffect(.regular.interactive()), glassEffectID, and glassEffectUnion. The control normally looks translucent, matching the background correctly. But when I open the menu and then dismiss it, the glass control briefly becomes solid black for a moment before returning to the expected transparent/glass appearance. This is visible especially on a colorful/blurred background: Before opening the menu: the control is transparent Liquid Glass. Open the SwiftUI Menu. Dismiss the menu. The menu label/control briefly renders as a black pill. After a short delay, it returns to the correct transparent glass style. Here is the simplified structure: @Namespace private var namespace GlassEffectContainer(spacing: 18) { VStack(spacing: 4) { Menu { Button { selectedMode = .automatic } label: { Label("Automatic", systemImage: "wand.and.sparkles") } Button { selectedMode = .instant } label: { Label("Instant", systemImage: "bolt.fill") } Button { selectedMode = .thinking } label: { Label("Thinking", systemImage: "brain.head.profile") } Divider() Button { showSettings = true } label: { Label("Configure", systemImage: "slider.horizontal.3") } } label: { HStack(spacing: 8) { Image(systemName: selectedMode.icon) Text(selectedMode.title) Image(systemName: "chevron.down") } .padding(.horizontal, 16) .frame(minWidth: 92, minHeight: 48) .contentShape(RoundedRectangle(cornerRadius: 24, style: .continuous)) } } .glassEffect(.regular.interactive(), in: RoundedRectangle(cornerRadius: 24, style: .continuous)) .glassEffectUnion(id: "smart-intelligence-connected-menu", namespace: namespace) .glassEffectID("smart-intelligence-menu-pill", in: namespace) .buttonStyle(.plain) .labelStyle(.iconOnly) } I also tried applying .buttonStyle(.glass) directly to the Menu, and tried moving the glass effect between the Menu label and the wrapper VStack. The issue still appears: after dismissing the menu, the glass label briefly falls back to a solid black appearance before the transparent glass effect recovers. Is this expected behavior for SwiftUI.Menu with Liquid Glass, or is there a recommended way to avoid this black flash after menu dismissal? Should Menu labels avoid .glassEffect(.regular.interactive()) / GlassEffectContainer, or is there a different modifier order recommended for iOS 26? Thanks for reply.

I probably should know the answer to this but I don't, so I'll ask. When I enable state restoration and have like three windows open, and I quit the app (via Quit menu, not 'Stop In Xcode') the following happens: -NSApplication calls _closeForTermination on all the windows and this causes state restoration to fail to restore these open windows on next app launch. This behavior is not aligned with the behavior of apps like Mail. If I have two "Viewer Windows" open in Mail and I quit the app, when I relaunch the two viewer windows are restored. I can of course track this and write data to restore for these auto closed window myself but shouldn't there be an easy way to opt in to this behavior?

I am using NSSearchField for a non-incremental search UI. The field is configured as follows: let searchField = NSSearchField() searchField.sendsSearchStringImmediately = false searchField.sendsWholeSearchString = true searchField.target = target searchField.action = #selector(submit(_:)) My expectation is that the action is sent only when the user explicitly commits the search, such as by pressing Return or clicking the search button. I understand that clicking the cancel button inside the NSSearchField clears the text and sends the action with an empty string. That behavior is documented and makes sense. However, I am also seeing the action sent when the user edits the text normally and deletes the last character, causing the search field’s stringValue to become empty. In other words, while the user is just editing the field with the Delete key, the action is sent even though the user did not press Return or explicitly commit the search. Is this expected behavior for NSSearchField, or is it a bug? If it is expected, is there a recommended public API to distinguish these cases? User pressed Return with a non-empty string User clicked the search/cancel button User simply edited the text and the string became empty I would like to keep using NSSearchField’s built-in recent searches behavior, so intercepting Return with control(_:textView:doCommandBy:) is not ideal. If this is not expected behavior, I will file Feedback with a sample project. Environment: macOS 26.5 (25F71) Xcode 26.5 (17F42)

My app is a SwiftUI lifecycle app. I want to disable its multiple windows feature on iPadOS . I have tried to set the Enable Multiple Scenes option to false in Application Scene Manifest, but it doesn't work.

Hi, is there any textfield init with both formatter and axis for multiline? I notice the there are both an init to include a formatter like so: init(_:value:formatter:prompt:) and another one to include an axis for multiline like so: init(_:text:prompt:axis:). Is there any that can be used to set both of them? If not, is there any workaround? Because I happen to need both of them. Thank you.

Hi, I have a SwiftUI "work time" screen with a rotating ring (60 tick marks, Canvas-based). While the app stays in foreground, rotation is fine. After the app is in background for a while and comes back to foreground, I consistently see one visual glitch: the ring makes one very short step in the opposite direction once then continues rotating clockwise normally So this is not a crash, only a visual reverse tick on resume. What I expect: no direction change after foreground resume continuous clockwise motion What I already tried: withAnimation(.linear(...).repeatForever(...)) + restart on scenePhase TimelineView (.animation and .periodic) with time-based angle angle with and without modulo wrapping wall-clock and monotonic time sources rotation via rotationEffect and also via Canvas geometry warmup delays after resume restoring original ring visuals (long/short tick marks) The effect is still reproducible. Question: What is the correct SwiftUI approach to implement a continuously rotating ring that stays direction-stable across background/foreground transitions, with no one-frame reverse step on resume? Any pattern that is robust on current iOS versions and avoids visual artifacts on scene phase changes would be appreciated. Minimal repro: import SwiftUI struct ReproClockView: View { @Environment(\.scenePhase) private var scenePhase private let tickCount = 60 private let rotationDuration: Double = 120 @State private var rotationDegrees: Double = 0 @State private var hasAppeared = false var body: some View { ZStack { Canvas { context, size in let center = CGPoint(x: size.width / 2, y: size.height / 2) let radius = min(size.width, size.height) / 2 - 8 for index in 0..<tickCount { let angle = Double(index) * (360.0 / Double(tickCount)) - 90 let radians = angle * .pi / 180 let isLongTick = index % 5 == 0 let length: CGFloat = isLongTick ? 22 : 14 let outerRadius = radius let innerRadius = radius - length let startPoint = CGPoint( x: center.x + cos(radians) * outerRadius, y: center.y + sin(radians) * outerRadius ) let endPoint = CGPoint( x: center.x + cos(radians) * innerRadius, y: center.y + sin(radians) * innerRadius ) var path = Path() path.move(to: startPoint) path.addLine(to: endPoint) context.stroke( path, with: .color(.red), style: StrokeStyle(lineWidth: 2.5, lineCap: .round) ) } } .rotationEffect(.degrees(rotationDegrees)) .drawingGroup() } .frame(width: 340, height: 340) .onAppear { guard !hasAppeared else { return } hasAppeared = true startRotation() } .onChange(of: scenePhase) { oldPhase, newPhase in if oldPhase == .background && newPhase == .active { withAnimation(.linear(duration: 0)) { rotationDegrees = 0 } DispatchQueue.main.asyncAfter(deadline: .now() + 0.05) { startRotation() } } } } private func startRotation() { rotationDegrees = 0 withAnimation(.linear(duration: rotationDuration).repeatForever(autoreverses: false)) { rotationDegrees = 360 } } }

If an application utilizes MapKit exclusively to render custom content via MKTileOverlay (with canReplaceMapContent = true to entirely suppress Apple’s default map layers), are developers still contractually or technically mandated to display Apple's default "Legal" link? Currently, the hardcoded Apple attribution document details extensive copyright disclaimers for data suppliers like TomTom, Acxiom, and Breezometer. When an application renders entirely standalone, proprietary, or open-source map tiles, displaying this link creates two distinct issues: User Confusion: It incorrectly implies to end-users that the custom data being viewed is sourced from or validated by Apple's third-party data partners. Attribution Inaccuracy: It forces the display of entirely irrelevant copyright data while doing a disservice to the actual copyright holders of the active custom tile layers, who require their own distinct, prominent on-screen credit. It would be a significant UX improvement if the framework could dynamically hide the global data attribution link when canReplaceMapContent is active, allowing developers to provide accurate, context-specific legal text for the data layers actually in use.

I'm trying to get the count of how many windows an iPadOS app has 'open' (open from the user's perspective in the app switcher). This is for the sake of determining whether I should show or hide a button that takes action on every window (if there is only 1 window, the button will be hidden). According to the documentation the proper API for this is this property on UIApplication: // All of the representations that currently have connected UIScene instances or had their sessions persisted by the system (ex: visible in iOS' switcher) @property(nonatomic, readonly) NSSet<UISceneSession *> *openSessions So I print the count (only sessions with role UIWindowSceneSessionRoleApplication) when scenes are added/removed etc via appropriate lifecycle notifications like -sceneDidDisconnect: -sceneDidBecomeActive: and so forth. What I noticed is when I add a new window scene, the count increases by one so cool, that works. But when I kill a window in the App switcher the count does not decrease. I can end up in a situation where the app has only 1 window in the app switcher but the count prints 8, so this is wrong. So am I using the wrong API? How can I just get scene count in the app switcher? The documentation makes it seem like using 'connectedScenes' for this would be wrong because that property is not supposed to include 'archived' scenes in the app switcher (or is it?)? I do know I can't take action on an archived scene 'yet' but I would still show the button because whether or not the scene is archived in the app switcher is a fact that remains hidden from the user. My code will take care of that later after state restoration. Is iPadOS 26 potentially keeping scene sessions open for too long? Is there a good way to reliably detect how many scenes I have in the app switcher? Is a scene session explicitly killed by the user supposed to remain the .openSessions set? I am testing on the Simulator FWIW. iPad 26.5.

Using .glassEffect(.clear.interactive(), in: shape), where shape is some concentric shape that adapts to corner radius of the device, results in appearing of highlighted capsule shape. Code to reproduce this behavior import SwiftUI struct HelloLiquidGlass: View { var body: some View { if #available(iOS 26.0, *) { Text("Hello, World!") .frame(maxWidth: .infinity, maxHeight: .infinity) // .glassEffect(.clear.interactive(), in: .rect(corners: .concentric)) // .glassEffect(.clear.interactive(), in: ConcentricRectangle(uniformTopCorners: .fixed(80))) .padding(36) .ignoresSafeArea() .preferredColorScheme(.dark) } } } #Preview { HelloLiquidGlass() } Either of both commented-out modifiers produces the same result when user interacts with Liquid Glass pane (revealing of capsule shape that is not relative to actual shape of liquid glass effect modifier) iOS 26.5 (23F73) SDK + iOS 26.5 (23F77) Simulator

I was recently charging my macbook, just like any normal time i do. i expected to see the battery at 80%, but the macbook was hiding a surprise for me. the magsafe glowed amber, so i knew it cant be on 80%, so when i opened the lid, the surprise was a shocking 94%. I didn't know what to expect, but my macbook is running macOS tahoe 26.5, so everything seemed normal to me until: someone please help in fixing this bug, as it isn't the first time this happens to me. please link this to my magsafe 4 idea here, as the magsafe could activate pulsing amber (1 second on 1 second off, for both amber and yellow pulsing lights) in case of failure to stop on set limit, making it visually much easier to understand if there is an issue.

I have written an app where the user can select a golf course from a picker list. In the simulator the list of courses is displayed as expected with one course name per line however when I run the app on my phone the course names are being wrapped onto a second line. e.g. simulator Collier Park Lakes Pines iPhone Collier Park Lakes Pines I'm new to app development so I apologise if the answer is obvious but how can I get the iPhone behaviour to be the same as the simulator (iPhone 17 Pro Max in both cases). Thanks in advance for any suggestions. XCODE 26