Summary In iOS 18, the UICollectionViewDelegate method collectionView(_:targetIndexPathForMoveOfItemFromOriginalIndexPath:atCurrentIndexPath:toProposedIndexPath:) is not being called when moving items in a UICollectionView. This method works as expected in iOS 17.5 and earlier versions. Steps to Reproduce Create a UICollectionView with drag and drop enabled. Implement the UICollectionViewDelegate method: func collectionView(_ collectionView: UICollectionView, targetIndexPathForMoveOfItemFromOriginalIndexPath originalIndexPath: IndexPath, atCurrentIndexPath currentIndexPath: IndexPath, toProposedIndexPath proposedIndexPath: IndexPath) -> IndexPath { print("🐸 Move") return proposedIndexPath } Run the app on iOS 18. Attempt to drag and drop items within the collection view. Expected Behavior The method should be called during the drag and drop operation, and "🐸 Move" should be printed to the console. Actual Behavior The method is not called, and nothing is printed to the console. The drag and drop operation still occurs, but without invoking this delegate method. Configuration iOS Version: 18 Xcode Version: Xcode 16.0.0

Hello I'm working on implementing some changes to my app's tab bar, particularly to support some features in the new iPad floating tab bar, which has required me to adopt some of the new tab APIs from iOS 18. The issue I've encountered is that I would like the tabs visible in regular (floating tab bar) and compact (bottom tab bar) to be slightly different. The compact variant should show a subset of the tabs visible on iPad. For example: Floating tab bar: Use tabs A, B, C Bottom tab bar: Use tabs A, B I'm finding this quite difficult, especially in the scenario of split view on iPad, where the size class and tab bar location can change as the user interacts with the app. I went down the route of changing my tab bar controller's tabs property when the trait collection changed tabBarController.tabs = eligibleTabs where eligibleTabs for compact passes tabs AB, and when in regular - ABC. This throws an exception UIViewController cannot be shared between multiple UITab *** Assertion failure in -[UITab viewController], UITab.m:173 I'm not sharing view controllers between tabs. I can only assume that the system doesn't like me passing the same values (always at least tabs A & B) multiple times to the tabs property. I then later noticed a new iOS 18 property on UITabBarController - compactTabIdentifiers. This seemed like exactly what I was looking for: An optional filter to display only select root-level tabs when in a compact appearance. Default is nil, which would make all tabs available. So I changed my implementation: tabBarController.tabs = [tabA, tabB, tabC] tabBarController.compactTabIdentifiers = [tabAIdentifier, tabBIdentifier] and don't make any explicit updates when split view is enabled. Unfortunately this doesn't seem to work, at least not how I would expect it to. When enabling split view on iPad, the bottom tab bar appears, but it doesn't respect the tab identifiers I passed in tabBarController.compactTabIdentifiers. I'm not sure if this a bug or that I'm not really understanding how to use tabBarController.compactTabIdentifiers. Does anyone have any insight on this?

I have an iOS app that relies on dynamic text size such that all fonts in the app respect the user's setting of Text Size in the iOS Settings app. This app also runs on macOS via Mac Catalyst. But until macOS 14 Sonoma, there was no Text Size setting in the macOS Settings app. But even as of Sonoma, the Text Size setting isn't usable by 3rd party apps. And Sequoia doesn't seem to change that. As a work around, my Mac Catalyst app provides its own Text Size setting. I was able to make it work by providing my own UIApplication subclass and overriding preferredContentSizeCategory. Under macOS 12 to macOS 14, this workaround works just fine and all fonts in the app created with code such as UIFont.preferredFont(forTextStyle:) gives appropriately sized fonts based on the overridden content size category. However, this workaround stopped working with macOS 15 Sequoia. I've also tried code such as: self.window.traitOverrides.preferredContentSizeCategory = myCustomSizeCategoryValue and self.window.maximumContentSizeCategory = myCustomSizeCategoryValue self.window.minimumContentSizeCategory = myCustomSizeCategoryValue in the scene delegate but that made no difference. Is there any way to get code such as UIFont.preferredFont(forTextStyle:) to return an appropriately sized font based on some app provided content size category in a Mac Catalyst app running under macOS 15? It sure would be nice if Mac Catalyst apps automatically responded to the macOS Text Size setting under Settings -> Accessibility -> Display -> Text Size just like a native iOS app.

Recently I've made 1 character mistake in my code and have hard time during searching what was the problem. Basically I forgot to set dot near one of the frame modifiers and compiler did not warn me, but during app running I got 100% CPU and rocket increase of RAM (on real app). Feels like recursion, but no any hint in call stack inside Xcode on crash stop. struct BadView: View { var body: some View { Color.red frame(height: 36) } } I would like to see at least warning for such cases. Problem may look simple on this small example, but if you added 1k+ lines after last compilation - searching this type of errors could be problematic when you have no idea what to search.

Hello, I've a question about performance when trying to render lots of items coming from SwiftData via a @Query on a SwiftUI List. Here's my setup: // Item.swift: @Model final class Item: Identifiable { var timestamp: Date var isOptionA: Bool init() { self.timestamp = Date() self.isOptionA = Bool.random() } } // Menu.swift enum Menu: String, CaseIterable, Hashable, Identifiable { var id: String { rawValue } case optionA case optionB case all var predicate: Predicate<Item> { switch self { case .optionA: return #Predicate { $0.isOptionA } case .optionB: return #Predicate { !$0.isOptionA } case .all: return #Predicate { _ in true } } } } // SlowData.swift @main struct SlowDataApp: App { var sharedModelContainer: ModelContainer = { let schema = Schema([Item.self]) let modelConfiguration = ModelConfiguration(schema: schema, isStoredInMemoryOnly: false) return try! ModelContainer(for: schema, configurations: [modelConfiguration]) }() var body: some Scene { WindowGroup { ContentView() } .modelContainer(sharedModelContainer) } } // ContentView.swift struct ContentView: View { @Environment(\.modelContext) private var modelContext @State var selection: Menu? = .optionA var body: some View { NavigationSplitView { List(Menu.allCases, selection: $selection) { menu in Text(menu.rawValue).tag(menu) } } detail: { DemoListView(selectedMenu: $selection) }.onAppear { // Do this just once // (0..<15_000).forEach { index in // let item = Item() // modelContext.insert(item) // } } } } // DemoListView.swift struct DemoListView: View { @Binding var selectedMenu: Menu? @Query private var items: [Item] init(selectedMenu: Binding<Menu?>) { self._selectedMenu = selectedMenu self._items = Query(filter: selectedMenu.wrappedValue?.predicate, sort: \.timestamp) } var body: some View { // Option 1: touching `items` = slow! List(items) { item in Text(item.timestamp.description) } // Option 2: Not touching `items` = fast! // List { // Text("Not accessing `items` here") // } .navigationTitle(selectedMenu?.rawValue ?? "N/A") } } When I use Option 1 on DemoListView, there's a noticeable delay on the navigation. If I use Option 2, there's none. This happens both on Debug builds and Release builds, just FYI because on Xcode 16 Debug builds seem to be slower than expected: https://indieweb.social/@curtclifton/113273571392595819 I've profiled it and the SwiftData fetches seem blazing fast, the Hang occurs when accessing the items property from the List. Is there anything I'm overlooking or it's just as fast as it can be right now?

Hello, This code has a NavigationSplitView, whose sidebar is a List and its detail contains a NavigationStack. It is controlled by two @Observable properties, a selection and a path. The path shown in the detail depends upon the selection in the List. If I programmatically change the selection and path, the path will be set, but via SwiftUI backtraces (pasted below), it will clear out my path. This makes my code lose state. What am I doing wrong? Is this a bug? I'm using Xcode16 running against the iOS 18 simulator (although this also happens with iOS17). To reproduce, Launch the App, Note that you are on the "first" selection. Tap "Nav Path: Path: second-100". You'll go to the "second" selection, but the path will be empty. If you place a breakpoint when the $path is cleared, you'll see it is being cleared by SwiftUI. Backtrace when the path is emptied: (lldb) bt * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 2.1 * frame #0: 0x00000001043295c0 DoubleNav.debug.dylib`Navigation.path.setter(newValue=0 values) at ContentView.swift:86:22 frame #1: 0x00000001043296d0 DoubleNav.debug.dylib`key path setter for Navigation.path : Navigation at <compiler-generated>:0 frame #2: 0x000000019485b500 libswiftCore.dylib`Swift.NonmutatingWritebackBuffer.__deallocating_deinit + 132 frame #3: 0x0000000194a351c4 libswiftCore.dylib`_swift_release_dealloc + 28 frame #4: 0x0000000194a35bd4 libswiftCore.dylib`bool swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1>>::doDecrementSlow<(swift::PerformDeinit)1>(swift::RefCountBitsT<(swift::RefCountInlinedness)1>, unsigned int) + 156 frame #5: 0x00000001d2f5f584 SwiftUICore`closure #1 () -> () in SwiftUI.ObjectLocation.set(_: τ_0_1, transaction: SwiftUI.Transaction) -> () + 132 frame #6: 0x00000001d2f5f6b0 SwiftUICore`partial apply forwarder for closure #1 () -> () in SwiftUI.ObjectLocation.set(_: τ_0_1, transaction: SwiftUI.Transaction) -> () + 28 frame #7: 0x00000001d2801da8 SwiftUICore`generic specialization <()> of closure #1 () throws -> τ_0_0 in SwiftUI.withTransaction<τ_0_0>(SwiftUI.Transaction, () throws -> τ_0_0) throws -> τ_0_0 + 296 frame #8: 0x00000001d2f5f4d8 SwiftUICore`SwiftUI.ObjectLocation.set(_: τ_0_1, transaction: SwiftUI.Transaction) -> () + 336 frame #9: 0x00000001d2c42468 SwiftUICore`SwiftUI.LocationBox.set(_: τ_0_0.Value, transaction: SwiftUI.Transaction) -> () + 148 frame #10: 0x00000001d2c42c84 SwiftUICore`protocol witness for SwiftUI.Location.set(_: τ_0_0.Value, transaction: SwiftUI.Transaction) -> () in conformance SwiftUI.LocationBox<τ_0_0> : SwiftUI.Location in SwiftUI + 20 frame #11: 0x00000001d2c42e90 SwiftUICore`SwiftUI.ProjectedLocation.set(_: τ_0_1.Projected, transaction: SwiftUI.Transaction) -> () + 196 frame #12: 0x00000001d2c42468 SwiftUICore`SwiftUI.LocationBox.set(_: τ_0_0.Value, transaction: SwiftUI.Transaction) -> () + 148 frame #13: 0x00000001d2cf2fe8 SwiftUICore`SwiftUI.Binding.ScopedLocation.set(_: τ_0_0, transaction: SwiftUI.Transaction) -> () + 28 frame #14: 0x00000001d2c42468 SwiftUICore`SwiftUI.LocationBox.set(_: τ_0_0.Value, transaction: SwiftUI.Transaction) -> () + 148 frame #15: 0x00000001d2cf3190 SwiftUICore`function signature specialization <Arg[0] = Owned To Guaranteed> of SwiftUI.Binding.wrappedValue.setter : τ_0_0 + 32 frame #16: 0x00000001d2cf12c0 SwiftUICore`SwiftUI.Binding.wrappedValue.setter : τ_0_0 + 28 frame #17: 0x00000001d1d0e538 SwiftUI`closure #1 () -> () in SwiftUI.NavigationColumnState.popAllForSelectionChange(popReplacedRoots: Swift.Bool) -> SwiftUI.NavigationState.RequestResults + 524 frame #18: 0x00000001d281be58 SwiftUICore`partial apply forwarder for reabstraction thunk helper from @callee_guaranteed (@guaranteed Swift.Dictionary<__C.NSAttributedStringKey, Any>, @unowned __C._NSRange, @unowned Swift.UnsafeMutablePointer<ObjectiveC.ObjCBool>) -> () to @escaping @callee_guaranteed (@guaranteed Swift.Dictionary<__C.NSAttributedStringKey, Any>, @unowned __C._NSRange, @unowned Swift.UnsafeMutablePointer<ObjectiveC.ObjCBool>) -> () + 20 frame #19: 0x00000001d2b3b64c SwiftUICore`static SwiftUI.Update.dispatchActions() -> () + 1080 frame #20: 0x00000001d2b3ac4c SwiftUICore`static SwiftUI.Update.end() -> () + 108 frame #21: 0x00000001d18daf44 SwiftUI`closure #1 (Swift.Optional<Swift.UnsafeMutableRawPointer>, Swift.Double, Swift.UnsafePointer<__C._UIUpdateTiming>) -> () in static SwiftUI.UIKitUpdateCycle.addPreCommitObserver(() -> ()) -> () + 168 frame #22: 0x00000001d18dafbc SwiftUI`reabstraction thunk helper from @escaping @callee_guaranteed (@unowned Swift.Optional<Swift.UnsafeMutableRawPointer>, @unowned Swift.Double, @unowned Swift.UnsafePointer<__C._UIUpdateTiming>) -> () to @escaping @callee_unowned @convention(block) (@unowned Swift.Optional<Swift.UnsafeMutableRawPointer>, @unowned Swift.Double, @unowned Swift.UnsafePointer<__C._UIUpdateTiming>) -> () + 64 frame #23: 0x0000000185030388 UIKitCore`_UIUpdateSequenceRun + 76 frame #24: 0x00000001859d22e8 UIKitCore`schedulerStepScheduledMainSection + 168 frame #25: 0x00000001859d1720 UIKitCore`runloopSourceCallback + 80 frame #26: 0x000000018041b324 CoreFoundation`__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 24 frame #27: 0x000000018041b26c CoreFoundation`__CFRunLoopDoSource0 + 172 frame #28: 0x000000018041a9d0 CoreFoundation`__CFRunLoopDoSources0 + 232 frame #29: 0x00000001804150b0 CoreFoundation`__CFRunLoopRun + 788 frame #30: 0x0000000180414960 CoreFoundation`CFRunLoopRunSpecific + 536 frame #31: 0x0000000190183b10 GraphicsServices`GSEventRunModal + 160 frame #32: 0x0000000185aa2b40 UIKitCore`-[UIApplication _run] + 796 frame #33: 0x0000000185aa6d38 UIKitCore`UIApplicationMain + 124 frame #34: 0x00000001d1e2eab4 SwiftUI`closure #1 (Swift.UnsafeMutablePointer<Swift.Optional<Swift.UnsafeMutablePointer<Swift.Int8>>>) -> Swift.Never in SwiftUI.KitRendererCommon(Swift.AnyObject.Type) -> Swift.Never + 164 frame #35: 0x00000001d1e2e7dc SwiftUI`SwiftUI.runApp<τ_0_0 where τ_0_0: SwiftUI.App>(τ_0_0) -> Swift.Never + 84 frame #36: 0x00000001d1b70c8c SwiftUI`static SwiftUI.App.main() -> () + 148 frame #37: 0x0000000104333df0 DoubleNav.debug.dylib`static DoubleNavApp.$main() at <compiler-generated>:0 frame #38: 0x0000000104333ea0 DoubleNav.debug.dylib`main at DoubleNavApp.swift:11:8 frame #39: 0x00000001048f9410 dyld_sim`start_sim + 20 frame #40: 0x000000010440e154 dyld`start + 2476 Thanks for any tips! Here's the code.

Hey there, Is there a way to launch another view by tapping on the preview of a context menu? Something like the behavior of the Photos app where tapping on the preview navigates to the details view. Tap gesture handlers on the preview don't seem to get called, even as high priority gestures. Thanks for the help! Gab

It appears that starting with macOS Sequoia, Quick Look Preview extension no longer loads MapKit maps correctly anymore. Map tiles do not appear, leaving users with a beige background. Users report that polylines do render correctly, but annotations appears black. This was previously working fine in prior macOS versions including Sonoma. STEPS TO REPRODUCE Create a macOS app project, with an associated document. Ensure project has a Quick Look preview extension, with necessary basic setups. Ensure that the extension mentioned in (2) must have a MKMapView. Any other cosmetic changes, etc, does not need to be implemented to observe the base issue. Do note that it has been reported that in addition to the map tiles not loading, annotations don't render correctly as well.

The sample code provided in "Building a document-based app with SwiftUI" (https://developer.apple.com/documentation/swiftui/building-a-document-based-app-with-swiftui) does not work as expected. The DocumentGroup/StoryView toolbar does not appear for documents opened in the App. By removing the DocumentGroupLaunchScene block from the App the toolbar does appear and works as expected - but of course the App's DocumentGroupLaunchScene customizations are lost. I've tested this on 18.0 devices, as well as production 18.0 and 18.1 beta 6 simulators. If I modify the StoryView by wrapping the content in a NavigationStack I can make some progress - but the results are unstable and hard to pin down - with this change the first time a document is opened in the WritingApp the toolbar appears as expected. When opening a document subsequently the toolbar is corrupted. Please is this a bug or is there a good example of incorporate both DocumentGroupLaunchScene customizations at the App level and retina the toolbar in documents presented via DocumentGroup?

I've encountered a major issue with the iOS 18.1 RC and watchOS 11.1 RC. It appears that complications running on WidgetKit cannot be synced as .watchface to these new release candidates. The error message indicates that "the Watch Faces app and complication are not available," which is affecting all apps utilizing WidgetKit. This issue renders all WidgetKit-based complications unusable on watchOS 11.1 RC. It’s a serious problem for those of us who rely on these complications for our apps and for users expecting consistent functionality. APPLE, PLEASE FIX THIS ISSUE ASAP! This bug is a significant setback for developers and users alike, and any guidance or updates would be greatly appreciated.

I'm trying to make a Swift Chart where 24 AreaMarks an hour apart on X axis over a day display a vertical gradient. The gradient is vertical and is essentially [Color.opacity(0.1),Colour,Color.opacity(0.1] The idea here is where the upper and lower points of each AreaMark are the same or close to each other in the Y axis, the chart essentially displays a line, where they are far apart you get a nice fading vertical gradient. However, it seems that the .alignsMarkStylesWithPlotArea modifier is always set for AreaMarks even if manually applying it false. Investigating further, I've learnt that with AreaMarks in a series, Swift Charts seems to only listen to the first foreground style set in. I've created some sample code to demonstrate this. struct DemoChartView: View { var body: some View { Chart { AreaMark(x: .value("Time", Date().addingTimeInterval(0)), yStart: .value("1", 40), yEnd: .value("2", 60)) .foregroundStyle(LinearGradient(colors: [.pink, .teal], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) AreaMark(x: .value("Time", Date().addingTimeInterval(3600)), yStart: .value("1", 44), yEnd: .value("2", 58)) .foregroundStyle(LinearGradient(colors: [.orange, .yellow], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) AreaMark(x: .value("Time", Date().addingTimeInterval(03600*2)), yStart: .value("1", 50), yEnd: .value("2", 90)) .foregroundStyle(LinearGradient(colors: [.green, .blue], startPoint: .top, endPoint: .bottom)) .alignsMarkStylesWithPlotArea(false) } } } Which produces this: So here, all the different .foregroundStyle LinearGradients are being ignored AND the .alignsMarkStylesWithPlotArea(false) is also ignored - the amount of pink on the first mark is different to the second and third 🤷‍♂️ Has anyone encountered this. Are AreaMarks the correct choice or are they just not setup to create this type of data display. Thanks

I'm adding widget interactivity to my home screen widgets via buttons and AppIntents, but running into some interesting behavior the way the timeline is reloaded after. I'm following this guide from Apple https://developer.apple.com/documentation/widgetkit/adding-interactivity-to-widgets-and-live-activities And the widget is guaranteed to be reloaded when a button pressed with an intent, But whenever the AppIntent is done with the perform action, the widget timeline is always reloaded twice. It's also interesting to note that both reloads happen after the perform method. If you add a 10 second sleep in the perform, nothing happens for 10 seconds, then both reloads happen. This issue with this is 2-fold. calculating and rendering the entire widget timeline can be Networking and DB intensive operations, so I would ideally like to avoid doing all the work twice and save the users battery and processing. The even worse issue, sometimes data on the server changes in between the split second duplicate widget timeline reloads, causing the widget to flash one state, then update to another a second later which is not a good user experience. I have a sample project which shows the issue and is very easy to reproduce. The widget simply keeps track of the number of reloads. To reproduce: Add the widget to the homescreen Press the refresh button, and observe the timeline refresh count always goes up by 2. I've filed a Feedback and attached the sample project and screen recording for anyone to reproduce. FB15595835

Before I waste time creating an Apple Developer Support ticket, I’m hoping an Apple DTS engineer can confirm if this is just log noise. Here’s the code: import SwiftUI struct ContentView: View { @State private var editMode: EditMode = .inactive @State private var items = ["Item 1", "Item 2", "Item 3"] var body: some View { NavigationStack { List { ForEach(items, id: \.self) { item in Text(item) } .onDelete { indexSet in items.remove(atOffsets: indexSet) } } .environment(\.editMode, $editMode) .toolbar { ToolbarItem(placement: .topBarTrailing) { EditButton() .environment(\.editMode, $editMode) } } } } } #Preview { ContentView() } When you run this code and tap Edit, you’ll initially get: CoreSVG has logged an error. Set environment variabe [sic] "CORESVG_VERBOSE" to learn more. After setting CORESVG_VERBOSE = YES, you’ll see: CoreSVG: Error: NULL ref passed to getObjectCoreSVG: Error: NULL ref passed to getObject This error only appears the first time Edit is tapped after a build and run. It won't happen again, even after force-quitting and reopening the app. The issue also only happens on iOS 18.0 and 18.1—I can’t reproduce it on iOS 17.5. Fortunately, it doesn’t seem to cause any negative side effects. Is this just log noise?

Hi, I have noticed a major uptick in crash reports, ever since I updated my app for macOS Sequoia. All of them have to do with NSOutlineView, and they all have a similar internal API in the crash log, which shows that the issue is something to do with the framework. They all have references to NSConcreteMapTable and _TtCs12_SwiftObject isEqual. The issue isn't reproducible, but it's reported by many different users, all on macOS15+, and it was never an issue with macOS14 or below, so I'm not sure what to do about it. Here's a couple of examples of the new crash reports: Date/Time: 2024-10-29T06:55:19.999Z Launch Time: 2024-10-29T06:50:08Z OS Version: Mac OS X 15.0.1 (24A348) Report Version: 104 Exception Type: SIGTRAP Exception Codes: TRAP_BRKPT at 0x1a98c9c90 Crashed Thread: 0 Thread 0 Crashed: 0 libswiftCore.dylib 0x00000001a98c9c90 -[_TtCs12_SwiftObject isEqual:] + 240 1 Foundation 0x0000000199ad4e0c probeGC + 408 2 Foundation 0x0000000199b01e6c -[NSConcreteMapTable removeObjectForKey:] + 76 3 AppKit 0x000000019c5966a8 _NSOVFreeRowEntry + 44 4 AppKit 0x000000019c5965c4 _NSOVRecursiveFreeChildrenAndItem + 100 5 AppKit 0x000000019c59649c _NSOVFastRemoveChildRowEntries + 260 6 AppKit 0x000000019c595d40 -[NSOutlineView reloadItem:reloadChildren:] + 1016 7 MyApp 0x0000000104b454fc CJ_CRM.MacCJSidebarViewController.compareContactsDictionariesForPublicGroups() -> () (MacCJSidebarViewController.swift:1611) 8 MyApp 0x0000000104b44518 $s20MyApp26MacCJSidebarViewControllerC27contactsChangedNotificationyySo14NSNotificationCFySo7NSTimerCYbcfU_ (MacCJSidebarViewController.swift:461) 9 MyApp 0x0000000104ba5310 $sSo7NSTimerCIeghg_ABIeyBhy_TR (<compiler-generated>:0) 10 Foundation 0x0000000199b64cfc __NSFireTimer + 100 11 CoreFoundation 0x0000000198988184 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 28 12 CoreFoundation 0x0000000198987e28 __CFRunLoopDoTimer + 1008 13 CoreFoundation 0x0000000198987938 __CFRunLoopDoTimers + 352 14 CoreFoundation 0x000000019896d0f0 __CFRunLoopRun + 1852 15 CoreFoundation 0x000000019896c334 CFRunLoopRunSpecific + 568 16 HIToolbox 0x00000001a3da50cc RunCurrentEventLoopInMode + 288 17 HIToolbox 0x00000001a3daaebc ReceiveNextEventCommon + 632 18 HIToolbox 0x00000001a3dab020 _BlockUntilNextEventMatchingListInModeWithFilter + 72 19 AppKit 0x000000019c4b0a70 _DPSNextEvent + 656 20 AppKit 0x000000019cdd67b8 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 684 21 AppKit 0x000000019c4a3b7c -[NSApplication run] + 476 22 AppKit 0x000000019c47a44c NSApplicationMain + 884 23 MyApp 0x0000000104a1e26c main (main.m:24) 24 ??? 0x0000000198504274 0x0 + 0 Another one with a different trigger but same internal API: Date/Time: 2024-10-29T16:49:12.999Z Launch Time: 2024-10-29T15:51:27Z OS Version: Mac OS X 15.1 (24B83) Report Version: 104 Exception Type: SIGSEGV Exception Codes: SEGV_MAPERR at 0x4cde11282080 Crashed Thread: 0 Thread 0 Crashed: 0 libswiftCore.dylib 0x00000001a04efa1c isSubclass(swift::TargetMetadata<swift::InProcess> const*, swift::TargetMetadata<swift::InProcess> const*) + 28 1 libswiftCore.dylib 0x00000001a04ef9f8 _swift_class_isSubclass + 12 2 libswiftCore.dylib 0x00000001a04ffa9c -[_TtCs12_SwiftObject isEqual:] + 252 3 Foundation 0x00000001906b4cec probeGC + 408 4 Foundation 0x00000001906b4adc -[NSConcreteMapTable objectForKey:] + 64 5 AppKit 0x00000001930f8eec -[NSOutlineView _rowEntryForItem:requiredRowEntryLoadMask:] + 48 6 AppKit 0x00000001930f8e80 -[NSOutlineView parentForItem:] + 24 7 MyApp 0x0000000100e2faec MyApp.MacCJSidebarViewController.outlineView(_: __C.NSOutlineView, selectionIndexesForProposedSelection: Foundation.IndexSet) -> Foundation.IndexSet (MacCJSidebarViewController.swift:759) 8 MyApp 0x0000000100e30dbc @objc MyApp.MacCJSidebarViewController.outlineView(_: __C.NSOutlineView, selectionIndexesForProposedSelection: Foundation.IndexSet) -> Foundation.IndexSet (<compiler-generated>:0) 9 AppKit 0x000000019324c4e4 -[NSTableView _userSelectableRowIndexesForProposedSelection:userCanAlreadyChangeSelection:] + 288 10 AppKit 0x00000001933176c4 -[NSTableView _userSelectRowIndexes:withNewSelectedRow:] + 140 11 AppKit 0x00000001933175a0 -[NSTableView _userSelectSingleRow:] + 76 12 AppKit 0x0000000193315c8c -[NSTableView mouseDown:] + 2536 13 AppKit 0x0000000193315120 -[NSOutlineView mouseDown:] + 72 14 MyApp 0x0000000100dabb38 -[CustomNSOutlineView mouseDown:] (CustomNSOutlineView.m:180) 15 AppKit 0x000000019320d98c forwardMethod + 248 16 AppKit 0x000000019320d98c forwardMethod + 248 17 AppKit 0x0000000193213518 -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 3668 18 AppKit 0x000000019319f00c -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 380 19 AppKit 0x000000019319ecbc -[NSWindow(NSEventRouting) sendEvent:] + 280 20 AppKit 0x00000001939b6bf0 -[NSApplication(NSEventRouting) sendEvent:] + 1652 21 AppKit 0x00000001935c489c -[NSApplication _handleEvent:] + 56 22 AppKit 0x000000019306ab08 -[NSApplication run] + 516 23 AppKit 0x0000000193041364 NSApplicationMain + 884 24 MyApp 0x0000000100d0626c main (main.m:24) 25 ??? 0x000000018f0e4274 0x0 + 0 I just created a Feedback FB15625970. Please let me know if this is a known issue, and/or if there's any ideas out there on how I can do to avoid this. It's causing a lot of instability in my app, that wasn't there before macOS15, so something changed in the internal APIs, and hopefully there's a way to work around it.

I have a List with draggable items. According to this thread (https://developer.apple.com/forums/thread/664469) I had to use .itemProvider instead of .onDrag, because otherwise the selection of the list will not work anymore. The items in my list refer to a file URL. So the dragging allowed to copy the files to the destination of the drag & drop. Therefore I used this code .itemProvider { let url = ....... // get the url with an internal function return NSItemProvider(object: url as NSURL) } Since the update to macOS 15.1 this way isn't working anymore. It just happens nothing. I also tried to use .itemProvider { let url = .... return NSItemProvider(contentsOf: url) ?? NSItemProvider(object: url as NSURL) } but this doesn't work too. The same way with .onDrag works btw. .onDrag { let url = ....... // get the url with an internal function return NSItemProvider(object: url as NSURL) } but as I wrote, this will break the possibility to select or to use the primaryAction of the .contextMenu. Is this a bug? Or is my approach wrong and is there an alternative?

Hi, When using SwiftUI ‘List’ with a large number of elements (4000+), I noticed a significant performance issue if extracting the views inside the ‘ForEach’ block into their own subview class. It affects scrolling performance, and using the scroll handle in the scrollbar causes stutters and beachballs. This seems to happen on macOS only ... the same project works fine on iOS. Here's an example of what I mean: List (selection: $multiSelectedContacts) { ForEach(items) { item in // 1. this subview is the problem ... replace it with the contents of the subview, and it works fine PlainContentItemView(item: item) // 2. Uncomment this part for it to work fine (and comment out PlainContentItemView above) /*HStack { if let timestamp = item.timestamp, let itemNumber = item.itemNumber { Text("\(itemNumber) - \(timestamp, formatter: itemFormatter)") } }*/ } } struct PlainContentItemView: View { let item: Item var body: some View { HStack { if let timestamp = item.timestamp, let itemNumber = item.itemNumber { Text("\(itemNumber) - \(timestamp, formatter: itemFormatter)") } } } } Item is a NSManagedObject subclass, and conforms to Identifiable by using the objectID string value. With this, scrolling up and down using the scrolling handle, causes stuttering scrolling and can beachball on my machine (MacBook Pro M1). If I comment out the ‘PlainContentItemView’ and just use the HStack directly (which is what was extracted to ‘PlainContentItemView’), the performance noticeably improves, and I can scroll up and down smoothly. Is this just a bug with SwiftUI, and/or can I do something to improve this?

In creating a sequenced gesture combining a LongPressGesture and a DragGesture, I found that the combined gesture exhibits two problems: The @GestureState does not properly update as the gesture progresses through its phases. Specifically, the updating(_:body:) closure (documented here) is only ever executed during the drag interaction. Long presses and drag-releases do not call the updating(_:body:) closure. Upon completing the long press gesture and activating the drag gesture, the drag gesture remains empty until the finger or cursor has moved. The expected behavior is for the drag gesture to begin even when its translation is of size .zero. This second problem – the nonexistence of a drag gesture once the long press has completed – prevents access to the location of the long-press-then-drag. Access to this location is critical for displaying to the user that the drag interaction has commenced. The below code is based on Apple's example presented here. I've highlighted the failure points in the code with // *. My questions are as follows: What is required to properly update the gesture state? Is it possible to have a viable drag gesture immediately upon fulfilling the long press gesture, even with a translation of .zero? Alternatively to the above question, is there a way to gain access to the location of the long press gesture? import SwiftUI import Charts enum DragState { case inactive case pressing case dragging(translation: CGSize) var isDragging: Bool { switch self { case .inactive, .pressing: return false case .dragging: return true } } } struct ChartGestureOverlay<Value: Comparable & Hashable>: View { @Binding var highlightedValue: Value? let chartProxy: ChartProxy let valueFromChartProxy: (CGFloat, ChartProxy) -> Value? let onDragChange: (DragState) -> Void @GestureState private var dragState = DragState.inactive var body: some View { Rectangle() .fill(Color.clear) .contentShape(Rectangle()) .onTapGesture { location in if let newValue = valueFromChartProxy(location.x, chartProxy) { highlightedValue = newValue } } .gesture(longPressAndDrag) } private var longPressAndDrag: some Gesture { let longPress = LongPressGesture(minimumDuration: 0.2) let drag = DragGesture(minimumDistance: .zero) .onChanged { value in if let newValue = valueFromChartProxy(value.location.x, chartProxy) { highlightedValue = newValue } } return longPress.sequenced(before: drag) .updating($dragState) { value, gestureState, _ in switch value { case .first(true): // * This is never called gestureState = .pressing case .second(true, let drag): // * Drag is often nil // * When drag is nil, we lack access to the location gestureState = .dragging(translation: drag?.translation ?? .zero) default: // * This is never called gestureState = .inactive } onDragChange(gestureState) } } } struct DataPoint: Identifiable { let id = UUID() let category: String let value: Double } struct ContentView: View { let dataPoints = [ DataPoint(category: "A", value: 5), DataPoint(category: "B", value: 3), DataPoint(category: "C", value: 8), DataPoint(category: "D", value: 2), DataPoint(category: "E", value: 7) ] @State private var highlightedCategory: String? = nil @State private var dragState = DragState.inactive var body: some View { VStack { Text("Bar Chart with Gesture Interaction") .font(.headline) .padding() Chart { ForEach(dataPoints) { dataPoint in BarMark( x: .value("Category", dataPoint.category), y: .value("Value", dataPoint.value) ) .foregroundStyle(highlightedCategory == dataPoint.category ? Color.red : Color.gray) .annotation(position: .top) { if highlightedCategory == dataPoint.category { Text("\(dataPoint.value, specifier: "%.1f")") .font(.caption) .foregroundColor(.primary) } } } } .frame(height: 300) .chartOverlay { chartProxy in ChartGestureOverlay<String>( highlightedValue: $highlightedCategory, chartProxy: chartProxy, valueFromChartProxy: { xPosition, chartProxy in if let category: String = chartProxy.value(atX: xPosition) { return category } return nil }, onDragChange: { newDragState in dragState = newDragState } ) } .onChange(of: highlightedCategory, { oldCategory, newCategory in }) } .padding() } } #Preview { ContentView() } Thank you!

I have a Catalyst app that uses popovers frequently, and I'd love to have them stay active when the app loses focus. It appears this is controlled in a native AppKit app via NSPopover.Behavior. Is this functionality exposed somewhere in Catalyst?

Basic Information Please provide a descriptive title for your feedback: Sheet presentationDetents breaks after rapid open/dismiss cycles Which platform is most relevant for your report? iOS Description Steps to Reproduce: Create a sheet with presentationDetents([.medium]) Rapidly perform these actions multiple times (usually 3-4 times): a. Open the sheet b. Immediately scroll down to dismiss Open the sheet again Observe that the sheet now appears at .large size, ignoring the .medium detent Expected Result: Sheet should consistently maintain .medium size regardless of how quickly it is opened and dismissed. Actual Result: After rapid open/dismiss cycles, the sheet ignores .medium detent and appears at .large size. Reproduction Rate: Occurs consistently after 3-4 rapid open/dismiss cycles More likely to occur with faster open/dismiss actions Configuration: iOS 18 Xcode 16.0 (16A242d) SwiftUI Device: iPhone 14

In Swift 6, stricter concurrency rules can lead to challenges when making SwiftUI views conform to Equatable. Specifically, the == operator required for Equatable must be nonisolated, which means it cannot access @MainActor-isolated properties. This creates an error when trying to compare views with such properties: Error Example: struct MyView: View, Equatable { let title: String let count: Int static func ==(lhs: MyView, rhs: MyView) -> Bool { // Accessing `title` here would trigger an error due to actor isolation. return lhs.count == rhs.count } var body: some View { Text(title) } } Error Message: Main actor-isolated operator function '==' cannot be used to satisfy nonisolated protocol requirement; this is an error in the Swift 6 language mode. Any suggestions? Thanks FB: FB15753655 (SwiftUI View cannot conform custom Equatable protocol in Swift 6.)