There has been a long lasting UIStackView bug dating back to 2016 that still exists in the latest Xcode 16.3 and SDKs, where calling setHidden:true multiple times (lets say twice) on a subview of that stack view requires calling setHidden:false twice before the subview shows up again. This was originally documented via Radar #25087688. Hopefully a Frameworks Engineer here on the forums can raise it to the attention of the appropriate engineers. It would be really nice if this eventually gets fixed, because it's one of those odd issues where you end up wasting a lot of time trying to debug because everything looks correct.

Title: SIGTRAP Crash in QuartzCore/CALayer during UI Lifecycle Changes Description: My app is experiencing occasional crashes triggered by a SIGTRAP signal during UI transitions (e.g., scene lifecycle changes, animations). The crash occurs in QuartzCore/UIKitCore code paths, and no business logic appears in the stack trace. Crash Context: Crash occurs sporadically during UI state changes (e.g., app backgrounding, view transitions). Stack trace involves pthread_mutex_destroy, CA::Layer::commit_if_needed, and UIKit scene lifecycle methods. Full crash log snippet: Signal: SIGTRAP Thread 0 Crashed: 0 libsystem_platform.dylib 0x... [symbol: _platform_memset$VARIANT$Haswell] 2 libsystem_pthread.dylib pthread_mutex_destroy + 64 3 QuartzCore CA::Layer::commit_if_needed(...) 4 UIKitCore UIScenePerformActionsWithLifecycleActionMask + 112 5 CoreFoundation _CFXNotificationPost + 736 Suspected Causes: Threading Issue: Potential race condition in pthread_mutex destruction (e.g., mutex used after free). UI Operation on Background Thread: CALayer/UIKit operations not confined to the main thread. Lifecycle Mismatch: Scene/UI updates after deallocation (e.g., notifications triggering late UI changes). Troubleshooting Attempted: Enabled Zombie Objects – no obvious over-released objects detected. Thread Sanitizer shows no clear data races. Verified UIKit/CoreAnimation operations are dispatched to MainThread. Request for Guidance: Are there known issues with CA::Layer::commit_if_needed and scene lifecycle synchronization? How to debug SIGTRAP in system frameworks when no app code is in the stack? Recommended tools/approaches to isolate the mutex destruction issue.

Hi Apple team and community, We’re encountering a strange issue with Live Activity that seems related to memory management or background lifecycle. ❓ Issue: Our app updates a Live Activity regularly (every 3 minutes) using .update(...). However, after the app remains in the background for around 8 hours, the Live Activity reverts to the initial state that was passed into .request(...). Even though the app continues sending updates in the background, the UI on the Lock Screen and Dynamic Island resets to the original state.

now i must use voip + livekit to developing, When incoming offline messages arrive at the device through VoIP, call ConversationManager The method of reporting NewIncomingConversation (uuid: update:) only first time can push new system UI,second or more time will crash, and acrsh stack appears to indicate that callkit has not been called

Using the new floating tab bar with ios18 on ipad with an RTL language, when the tabbar is correctly flipped and the right buttons become left buttons, the buttons are pushed off the screen on initial load but do come back after some navigating / reloading, have recreated in a fresh project.

I have a UITextView that contains paragraphs with text bullet lists (via NSTextList). I also implement NSTextContentStorageDelegate.textContentStorage(_:, textParagraphWith:) in order to apply some custom attributes to the text without affecting the underlying attributed text. My implementation returns a new NSParagraph that modifies the foreground color of the text. I based this on the example in the WWDC 21 session "Meet Text Kit 2". UITextView stops rendering the bullets when I implement the delegate function and return a custom paragraph. Why? func textContentStorage(_ textContentStorage: NSTextContentStorage, textParagraphWith range: NSRange) -> NSTextParagraph? { guard let originalText = textContentStorage.textStorage?.attributedSubstring(from: range) else { return nil } let updatedText = NSMutableAttributedString(attributedString: originalText) updatedText.addAttribute(.foregroundColor, value: UIColor.green, range: NSRange(location: 0, length: updatedText.length)) let paragraph = NSTextParagraph(attributedString: updatedText) // Verify that the text still contains NSTextList if let paragraphStyle = paragraph.attributedString.attribute(.paragraphStyle, at: 0, effectiveRange: nil) as? NSParagraphStyle { assert(!paragraphStyle.textLists.isEmpty) } else { assertionFailure("Paragraph has lost its text lists") } return paragraph }

I’m having a weird UIKit problem. I have a bunch of views in a UIScrollView and I add a UIContextMenuInteraction to all of them when the view is first loaded. Because they're in a scroll view, only some of the views are initially visible. The interaction works great for any of the views that are initially on-screen, but if I scroll to reveal new subviews, the context menu interaction has no effect for those. I used Xcode's View Debugger to confirm that my interaction is still saved in the view's interactions property, even for views that were initially off-screen and were then scrolled in. What could be happening here?

So I'm dealing with a really obtuse crash that appears to be a stack overflow in an internal SwiftUI code path creating a Color.Resolved. I haven't found anyone one else with this issue online, and I cannot get it to reproduce on my own device. Interestingly enough, it is only happening on 1 device in the field (according to XCode crash logs). Here are some lines from the crashed thread. You can see that my code is never called, and it appears to be starting in some Array equality check checking the equality of colors (which I can't think of anywhere in my app I am doing anyway). You can see from this trace here that it appears to be a recursive call through Color.Resolved and NSColor.withColorAppearance. I don't have any idea how to solve this, but it keeps happening with at least one in-the-field device across multiple app updates. So my whole app is open source on github at https://github.com/msdrigg/roam, but I don't even use NSColor explicitly anywhere except for here which doesn't match the stack trace. I also tried changing the accent color of the app with defaults write com.msdrigg.roam AppleAccentColor -integer 1 to see if that somehow caused the crash, but my app opened up totally fine (and respected the change). Besides this, the only places I think I could be using dynamic colors is I when define an AccentColor and a WidgetBackground color for my app using xcassets, and then I use these colors from SwiftUI. In most of my app I stick to the system colors (Color.gray and such). Thread 0 Crashed: 0 libsystem_pthread.dylib 0x000000018601213c ___chkstk_darwin + 60 1 CoreFoundation 0x0000000186108434 -[NSArray isEqualToArray:] + 52 (NSArray.m:454) 2 AppKit 0x000000018a21fcd4 -[NSCoreUICatalogColor resolvedCUINamedColorForAppearance:] + 164 (NSColor.m:5057) 3 AppKit 0x0000000189c32cd4 -[NSCoreUICatalogColor resolvedColor] + 48 (NSColor.m:5148) 4 AppKit 0x0000000189c31e74 -[NSDynamicNamedColor colorUsingColorSpace:] + 32 (NSColor.m:4410) 5 SwiftUICore 0x0000000221ca9fd8 CoreColorPlatformColorGetComponents + 116 (CoreColorFunctions.m:149) 6 SwiftUICore 0x0000000221faaf28 specialized Color.Resolved.init(platformColor:) + 92 (CoreColor.swift:14) 7 SwiftUICore 0x0000000221faa5b0 Color.Resolved.init(platformColor:) + 16 (<compiler-generated>:0) 8 SwiftUI 0x00000001b53b1dc4 closure #1 in NSColor.resolve(in:) + 20 (AppKitColorConversions.swift:156) 9 SwiftUI 0x00000001b53b222c partial apply for closure #1 in static NSColor.withColorAppearance(in:_:) + 32 (<compiler-generated>:0) 10 SwiftUI 0x00000001b46b1e54 closure #1 in SubmitTriggerSource.dispatchUpdate(_:) + 28 (PlatformViewCoordinator.swift:12) 11 SwiftUI 0x00000001b5484488 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0) 12 AppKit 0x0000000189c174a4 +[NSAppearance _performWithCurrentAppearance:usingBlock:] + 72 (NSAppearance.m:2408) 13 SwiftUI 0x00000001b53b2088 specialized static NSColor.withColorAppearance(in:_:) + 324 (AppKitColorConversions.swift:142) 14 SwiftUI 0x00000001b53b1e7c protocol witness for ColorProvider.resolve(in:) in conformance NSColor + 68 (<compiler-generated>:151) 15 SwiftUICore 0x0000000222436e6c ColorBox.resolve(in:) + 124 (Color.swift:288) 16 SwiftUICore 0x0000000222435e30 Color.resolve(in:) + 72 (Color.swift:87) 17 SwiftUI 0x00000001b53b1c88 closure #1 in NSColor.init(_:) + 196 (AppKitColorConversions.swift:124) 18 SwiftUI 0x00000001b4542714 thunk for @escaping @callee_guaranteed (@guaranteed NSAppearance) -> (@owned NSColor) + 56 (<compiler-generated>:0) 19 AppKit 0x0000000189c31e74 -[NSDynamicNamedColor colorUsingColorSpace:] + 32 (NSColor.m:4410) //// ... Repeating for 500 lines 500 SwiftUICore 0x0000000221ca9fd8 CoreColorPlatformColorGetComponents + 116 (CoreColorFunctions.m:149) 501 SwiftUICore 0x0000000221faaf28 specialized Color.Resolved.init(platformColor:) + 92 (CoreColor.swift:14) 502 SwiftUICore 0x0000000221faa5b0 Color.Resolved.init(platformColor:) + 16 (<compiler-generated>:0) 503 SwiftUI 0x00000001b53b1dc4 closure #1 in NSColor.resolve(in:) + 20 (AppKitColorConversions.swift:156) 504 SwiftUI 0x00000001b53b222c partial apply for closure #1 in static NSColor.withColorAppearance(in:_:) + 32 (<compiler-generated>:0) 505 SwiftUI 0x00000001b46b1e54 closure #1 in SubmitTriggerSource.dispatchUpdate(_:) + 28 (PlatformViewCoordinator.swift:12) 506 SwiftUI 0x00000001b5484488 thunk for @escaping @callee_guaranteed () -> () + 28 (<compiler-generated>:0) 507 AppKit 0x0000000189c174a4 +[NSAppearance _performWithCurrentAppearance:usingBlock:] + 72 (NSAppearance.m:2408) 508 SwiftUI 0x00000001b53b2088 specialized static NSColor.withColorAppearance(in:_:) + 324 (AppKitColorConversions.swift:142) 509 SwiftUI 0x00000001b53b1e7c protocol witness for ColorProvider.resolve(in:) in conformance NSColor + 68 (<compiler-generated>:151) 510 SwiftUICore 0x0000000222436e6c ColorBox.resolve(in:) + 124 (Color.swift:288) full-log.crash

Hello. I use NavigationStack for navigating in app. I have 4 screens - A, B, C, D. In some moment I have path [A, B, C] for NavigationStack. After user did action I should show path [A, B, D]. In other hands I should replace screen C with screen D. struct HomeView: View { @ObservedObject var viewModel: HomeViewModel var body: some View { NavigationStack(path: $viewModel.path) { ContentView() .navigationDestination(for: HomeViewModel.Path.self) { destination in // B, C, D views here... } } .navigationViewStyle(StackNavigationViewStyle()) } } Solution looks like same as for UIKit. I replaced last item in stack. It works, but "push" animation broke. var updatedPath = self.path updatedPath.removeLast() updatedPath.append(newPathItem) self.path = updatedPath I found suggest in Internet that you can remove view from stack after some delay. But it has some magic. For example 1 second delay works properly on iOS 18, but cause crash on iOS 16. 1 millisecond delay works on iOS 16, but sometimes didn't. self.path.append(newPathItem) DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(1000)) { UIView.setAnimationsEnabled(false) self.path.remove(at: self.path.count - 2) DispatchQueue.main.asyncAfter(deadline: .now() + .milliseconds(1)) { UIView.setAnimationsEnabled(true) } } It is easy task to replace current top screen in UINavigationController of UIKit. How I can do it properly in SwiftUI and save animation?

SwiftUI, using LPLinkView through UIViewRepresentable. Default behavior is a long press brings up a context menu and a popover to preview content. I want to replace that default long press behavior with my own custom screen. Adding a UILongPressGestureRecognizer didn't work. Thanks!

When the perform method of my AppIntent returns the custom view's dialog, and after I click the "Click Test" button, my app will be launched, but this dialog does not close. How can I close it? struct QuestionResultView: View { var body: some View { VStack { if #available(iOS 17.0, *) { Button(role:.cancel, intent: OpenAppIntent()) { Text("Click Test") } } }.frame(height: 300) } } struct OpenAppIntent : AppIntent { static let title: LocalizedStringResource = "Open my app" static let openAppWhenRun: Bool = true static let isDiscoverable: Bool = false; @MainActor func perform() async throws -> some IntentResult { return .result() } } struct OpenPhotoRecognizing: AppIntent { static let title: LocalizedStringResource = "Read photo" static let description = IntentDescription("") static let openAppWhenRun: Bool = false func perform() async throws -> some IntentResult & ShowsSnippetView & ProvidesDialog{ return .result(dialog: "Demo Test") { DemoResultView() } } }

Hey, Anyone knows of a possible way to present a PasteButton in a .confirmationDialog on iOS? when I try adding it, it's ignored and not displayed with the rest of the buttons struct MyView: View { @State var flag: Bool = false var body: some View { Text("Some Text") .confirmationDialog("Dialog", isPresented: $flag) { Group { Button("A") {} Button("B") {} PasteButton(payloadType: Data.self) { data in } } } } }

Hello, I've managed to get rid of these spaces in different ways. Using scrollview, giving negative insets, rewriting modifiers from scratch with plain style etc. But I couldn't solve this with a simple solution. I've read comments from many people experiencing similar problems online. It seems like there isn't a simple modifier to remove these spaces when we use sidebar as the list style in SwiftUI, or I couldn't find the simple solution. I wonder what's the simplest and correct way to reset these spaces? let numbers = Array(1...5) @State private var selected: Int? var body: some View { List(numbers, id: \.self, selection: $selected) { number in HStack { Text("Test") Spacer() } .frame(maxWidth: .infinity, alignment: .leading) } .listStyle(.sidebar) } }

Hi, I have been trying to subscribe to brightnessDidChangeNotification (https://developer.apple.com/documentation/uikit/uiscreen/brightnessdidchangenotification) with my code: var publisher = NotificationCenter.default.publisher(for: UIScreen.brightnessDidChangeNotification) .map { _ -> Double in return UIScreen.main.brightness } But it does seem that no such event is fired on Mac Catalyst 15.5. https://developer.apple.com/documentation/uikit/uiscreen/brightnessdidchangenotification claims that API is available since 13.1. Could anybody tell me if I'm doing something wrong or if the API is not supported at the moment? Thank you!

Is there any way to change the height of the "day" cells in the UICalendarView? The view is very tall on the screen and I'd like to shorten it so I can put more content below it without using a scroll view. I'm using SwiftUI with a UICalendarView with UIViewRepresentable. The calendar will have default decorations to indicate a date with events.

Various TextField and TextView elements of Apple apps have text edit actions for text correction, but also auto completion. How can I create such a menu for a TextField in SwiftUI on macOS? the textCompletion modifier did not result in this menu. Many thanks in advance! Jan

I'm creating an app which gamifies Screen Time reduction. I'm running into an issue with apples Screen Time setting where the user can disable my apps "Screen Time access" and get around losing the game. Is there a way to detect when this setting is disabled for my app? I've tried using AuthorizationCenter.shared.authorizationStatus but this didn't do the trick. Does anyone have an ideas?

Hi everyone, we’d appreciate your input on the following use case – thanks in advance! In our iPhone and Apple Watch app, we’re using the NearbyInteraction API to measure the distance between both devices via UWB. Setup: On the iPhone, we start a LiveActivity together with the NISession, to keep the ranging active in the background. ✅ Good news: On iOS 18.4, this works as expected – the NISession stays active in the background as long as the Live Activity is running. Current issues: As soon as the Watch app moves to the background, ranging seems to pause and is eventually terminated. → Question 1: Is there a way to keep the NISession active on the Watch when the app goes into the background? Audio playback from background not working: We'd like to trigger audio playback when certain distance changes are detected. So far, we can only trigger haptic feedback in the background – audio does not play. → Question 2: Is it possible to play audio (e.g. using AVAudioPlayer) while a NISession and a LiveActivity are running in the background? We’d be grateful for any advice or best practices for this combination. Thanks and best regards!

I'm testing using Group Activities and having no trouble iOS<->iOS or starting an activity on macOS and joining via iOS. However, when I start an activity and then try to join it from another macOS client, the starting side joins the session just fine, but the receiving side acts like I don't have the required app, even when it is already running. I see the active SharePlay icon in the menu bar, and the Current Activity is shown, but instead of an "Open" button there is a "MyApp Required" string and a "View" button that goes to the App Store. (Where the app is not available yet, as expected, since I'm still working on it.) There is no GroupSession started on that Mac yet, obviously. I'm looking for any hints to help debug what is going on. How does Group Activities find the app for the activity on macOS and how can I figure out why it isn't finding mine? Thanks!

I am working on implementing a new Intents UI Extension and have noticed that when it is triggered via the "Hey Siri" voice command, the intent dismisses after a few seconds. However, if it is launched from the Shortcuts app, the intent remains active and does not dismiss automatically. Additionally, I’ve observed that this behavior occurs on specific iOS versions, such as 17.5.1 or 17.7. On other versions, like 17.4.1 or 18.4, the intent persists as expected. Does Siri automatically close the intent based on its own logic? Could the iOS version be influencing this behavior? Given the requirement to make the intent persistent, is there any option or configuration available to achieve this?