Using desaturated mode on an image in a widget will break any links or buttons that use the image as their 'label'. Using the following will just open the app as if there was no link at all - therefore just using the fallback userActivity handler, or any .widgetURL() urls provided. Link(destination: URL(string: "bug://never-works")!) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } The same goes for buttons: Button(intent: MyDemoIntent()) { Image("puppy") .widgetAccentedRenderingMode(.desaturated) } I've tried hacky solutions like putting the link behind the image using a ZStack, and disabling hit testing on the image, but they don't work. Anything else to try? Logged as Feedback #15152620.

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

I have SwiftData models containing arrays of Codable structs that worked fine before adding CloudKit capability. I believe they are the reason I started seeing errors after enabling CloudKit. Example model: @Model final class ProtocolMedication { var times: [SchedulingTime] = [] // SchedulingTime is Codable // other properties... } After enabling CloudKit, I get this error logged to the console: 'NSKeyedUnarchiveFromData' should not be used to for un-archiving and will be removed in a future release CloudKit Console shows this times data as "plain text" instead of "bplist" format. Other struct/enum properties display correctly (I think) as "bplist" in CloudKit Console. The local SwiftData storage handled these arrays fine - this issue only appeared with CloudKit integration. What's the recommended approach for storing arrays of Codable structs in SwiftData models that sync with CloudKit?

I have a SwiftUI Mac Catalyst app. I create a toolbar like this NavigationSplitView(columnVisibility: $sceneModel.columnVisibility, preferredCompactColumn: $preferredColumn) { sidebarView() } detail: { contentView() .toolbar { ToolbarItemGroup(placement: .topBarTrailing) { HStack { Button { sceneModel.onMaps(sender: self) } label: { Image(systemName: "map") .font(.title2) } Button { sceneModel.onSearch(sender: self) } label: { Image(systemName: "magnifyingglass") .font(.title2) } ... } } } } When my Mac Appearance is set to dark mode and the content under the toolbar is dark the toolbar looks good like this. But then if I have light content under the toolbar, the glass effect changes to light, but the tint on the icons stays white instead of changing to black and it is hard to see the icon. It looks like this. When I set the Appearance on my Mac to light, then the toolbar works just fine on both dark and light colored backgrounds. Does anyone know how I can fix this when the appearance is Dark?

I have something that looks like: NavigationStack { List(self.items, id: \.self, selection: self.$selectedItems) { item in NavigationLink { ItemView(item: item) .environment(\.managedObjectContext, self.viewContext) } label: { LabelWithMenuView(object: item) { ptr in self.labelHandler(item: item, newName: ptr) } } } if self.editMode?.wrappedValue == .active { editButtons } else { TextField("Add Item", text: self.$newItem) .onSubmit { self.addItem() self.newItem = "" } .padding() } } #if os(iOS) .toolbar { EditButton() } .onChange(of: self.editMode?.wrappedValue) { old, new in print("editMode \(old) -> \(new)") } #endif With that layout, the edit button doesn't show up at all; if I put it as part of the List, it does show up, but the first click doesn't do anything; after that, it works, but the onChange handler doesn't show it getting changed, and the editButtons don't go away.

I have an existing Mac app which has evolved through over twenty years of development. It is currently written in a mixture of C++ and Objective-C, with a bit of C and Swift in a few places. For a few years now, I have been tinkering with replacing the UI with SwiftUI. The model has been completely rewritten in Swift and works fine. After a few tries, no version has been working acceptably, so I'm thinking that I need to rethink the architecture. The UI consists of a window with a master-detail view. The detail view is what users spend most of their time with. It contains a lot of subviews, around 100 typically. Keyboard events affect the display, so I've had a dedicated data structure to hold the state that is needed for displaying all the subviews. Using Instruments, I see that the view seems to recreate the subviews three times per keyboard event, so I'm clearly doing something wrong. A second factor is that there are a couple of dozen commands that are applicable to the detail view, driven either by menu items, keyboard shortcut, or toolbar button. Adding all of those to the view makes for a massive SwiftUI View, which seems unlikely to be good practice. The current implementation has the controller class broken up with categories, but still they are big classes. Most SwiftUI stuff on the web is iOS-oriented, and typically has a focus on fairly simple apps, so the whole topic of dealing with menu commands doesn't get a lot of coverage, so I've been doing all that through my own solutions, which are probably nothing like optimal. What I've been able to find is not particularly helpful for a full-fledged application like mine, so I'm looking for advice on how to structure the app. The existing one is largely MVC, but I've tried a similar approach and a shot at MVVM, but I'm not getting good results so far. So, pointers, places I can read more, or samples of real-world apps is what I'm after. Anyone?

Please has anyone found a workaround for duplicate back buttons appearing on the toolbar of a ContentView launched from a DocumentGroup? The problem occurs with Xcode 14.0 running a basic DocumentGroup App on iOS 16.0. To reproduce, simply build a new project using the "Document App" template. Build and run in the iOS/iPadOS simulator or on an iOS/iPadOS device. Two back buttons appear. Only one functions. I've not found a way to eliminate the dud. This problem has occurred throughout the Xcode 14.0 beta program.

Hi all, After upgrading to the iOS 26 beta, the scrolling in my SwiftUI chat view is completely broken. The exact same code works perfectly on iOS 18. Context: I have a chat view using ScrollViewReader and a vertically-reversed ScrollView (with .rotationEffect(.degrees(180))). Each message row (MessageBubble) uses multiple simultaneousGesture handlers: Horizontal drag for swipe-to-reply (and other actions: pin, delete) Long press for showing popover/actions Vertical scroll for normal chat scrolling This was working great on iOS 18. In iOS 26 beta, the vertical scroll is either completely disabled, jittery, or hijacked by the message row’s drag gestures, even though .simultaneousGesture is used (see code below). Minimal Repro Sample MessageListView.swift swift Copy Edit ScrollViewReader { proxy in ScrollView(.vertical, showsIndicators: false) { LazyVStack(spacing: 0) { // ... grouped messages ForEach(...) { ... MessageBubble(...) // see below } Color.clear.frame(height: 8).id("BOTTOM_ANCHOR") } .padding(.horizontal, 4) .rotationEffect(.degrees(180)) } .rotationEffect(.degrees(180)) } MessageBubble.swift struct MessageBubble: View { // ... var body: some View { // horizontal swipe-to-reply gesture let dragGesture = DragGesture(minimumDistance: 10) // ... ZStack { // ... HStack { ... } // ... .simultaneousGesture( DragGesture(minimumDistance: 0) // for long press // ... ) .simultaneousGesture(dragGesture) // for horizontal swipe } // ... } }

A few days ago scanning NFC tags or QR codes for AppClips with advanced experiences started showing the error "The operation couldn't be completed. (CPSErrorDomain error 2.)" in the AppClip sheet as seen here: We are providing AppClips to our customers and they trust AppClips to always work, since it is a big part of their business. Since this is happening at our customers phones and on the phones of their customers, I don't have a sysdiagnose. I already created a feedback entry about this FB16601674. We checked everything, our AASA file, the Appstore Experiences.

I'm struggling to understand whether TextField handles undo by itself, or how to properly handle it myself. In a macOS app with a SwiftUI lifecycle, in a DocumentGroup scene, I'm using both TextEditors and Textfields. The text editors handle undo out of the box, with undo coalescing. The text fields seem not to. However, on occasion, they do create undo points, leaving me confused as to what conditions are needed for that to happen. Is there a way to reliably get text fields to handle undo on their own? Or, how should I implement typing undo, including undo coalescing, manually?

When you use .navigationTransition(.zoom(sourceID: "placeholder", in: placehoder)) for navigation animation, going back using the swipe gesture is still very buggy on IOS26. I know it has been mentioned in other places like here: https://developer.apple.com/forums/thread/796805?answerId=856846022#856846022 but nothing seems to have been done to fix this issue. Here is a video showing the bug comparing when the back button is used vs swipe to go back: https://imgur.com/a/JgEusRH I wish there was a way to at least disable the swipe back gesture until this bug is fixed.

We use SwiftUI's .tabViewBottomAccessory in our iOS apps for displaying an Audio MiniPlayer View (like in the Apple Music App). TabView(selection: $viewModel.selectedTab) { // Tabs here } .tabViewBottomAccessory { if viewModel.showAudioMiniPlayer { MiniPlayerView() } } The Problem This code works perfectly on iOS 26.0. When viewModel.showAudioMiniPlayer is false, the accessory is completely hidden. However, on iOS 26.1 (23B5059e), when 'viewModel.showAudioMiniPlayer' becomes false, the MiniPlayerView disappears, but an empty container remains, leaving a blank space above the tab bar. Is this a known Bug in iOS 26.1 and are there any effective workarounds?

My app has the following UI layout: NSSplitViewController as the windows contentViewController NSPageController in the content (right) split item NSTabViewController as the root items of the NSPageController NSViewController with a collection view in the first tab of that NSTabViewController The collection view is using a NSCollectionViewCompositionalLayout in which the sections are set up to have a header using NSCollectionLayoutBoundarySupplementaryItem with pinToVisibleBounds=true and alignment=top With macOS 26, the pinned supplementary item automatically gets a blurred/semi-transparent background that seamlessly integrates with the toolbar. When the window's title bar has a NSTitlebarAccessoryViewController added, the said semi-transparent background gets a bottom hard edge and a hairline to provide more visual separation from the main content. During runtime, my NSPageController transitions from the NSTabViewController to another view controller. When transitioning back, the semi-transparent blur bleeds into the entire section. This happens no matter if there's a NSTitlebarAccessoryViewController added or not. It doesn't happen 100% of the cases, it seems to depend on section size, header visibility and/or scroll position. But it happens more often than not. Most of the time, a second or so after the back transition - shortly after pageControllerDidEndLiveTransition: of the NSPageControllerDelegate is called - the view updates and the supplementary views are back to normal. Sometimes, the issue also appears not when transitioning using NSPageController, but simply by scrolling through the collection view. Anyone has an idea what is happening here? Below are two screenshots of both the "ok" and "not ok" state I'm on macOS 26.0.1 and I'm using XCode 26.0.1

I've encountered a potential bug where a TextField connected to an optional value (not a string) works as expected when bound to a @State property, but won't update a @Binding property. Here is some example code import SwiftUI struct ContentView: View { @Binding var boundValue: Double? @State private var stateValue: Double? = 55 var body: some View { TextField("Bound value", value: $boundValue, format: .number) Text("\(boundValue ?? .nan)") TextField("State value", value: $stateValue, format: .number) Text("\(stateValue ?? .nan)") } } #Preview { ContentView(boundValue: .constant(42.00)) } It's as though the optional value stored externally is preventing the value updating. Can anyone confirm whether this is intentional, or a bug? This is in Xcode 26b6, on macOS Tahoe 26b8, but from this query it looks like the problem has existed for years.

NSWindow objects with custom styleMask configurations seem to behave erratically in macOS Tahoe 26.3 RC. For example an NSWindow is not resizable after issuing .styleMask.remove(.titled) or some NSWindow-s become totally unresponsive (the NSWindow becomes transparent to mouse events) with custom styleMask-s. This is a radical change compared to how all previous macOS versions or the 26.3 beta3 worked and seriously affects apps that might use custom NSWindows - this includes some system utilities, OSD/HUD apps etc, actually breaking some apps. Such fundamental compatibility altering changes should not be introduced in an RC stage (if this is intentional and not a bug) imho.

When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?

In one of my apps, i am using .glassEffect(_:In) to add glass effect on various elements. The app always crushes when a UI element with glassEffect(_in:) modifier is being rendered. This only happens on device running iOS 26 public beta. I know this for certain because I connected the particular device to xcode and run the app on the device. When i comment out the glassEffect modifier, app doesn't crush. Is it possible to check particular realeases with #available? If not, how should something like this be handled. Also how do i handle such os level erros without the app crushing. Thanks.

I have the following view hierarchy in my app: [UINavigationController] -> [MainViewController] -> [MyTabBarController] -> [DashboardViewController] In my MainViewController I have a button that pushes the MyTabBarController onto the navigation controllers stack. In the tab bar controller I only have one tab in this example showing the DashboardViewController. That all works fine, and when I tap the back button on MyTabBarController, everything works fine and the MainViewController is shown again. The UI works exactly how I want it, but when I load up the 'Debug Memory Graph' view, I can see that my DashboardViewController is still in memory and it seems the UITab has a reference to it. The MyTabBarController is NOT in memory anymore. MyTabBarController is very simple: class MyTabBarController: UITabBarController { override func viewDidLoad() { super.viewDidLoad() self.mode = .tabSidebar var allTabs:[UITab] = [] let mainTab = UITab(title: "Dashboard", image: UIImage(systemName: "chart.pie"), identifier: "dashboard", viewControllerProvider: { _ in return UINavigationController(rootViewController: DashboardViewController()) }) allTabs.append(mainTab) setTabs(allTabs, animated: false) } } And the DashboardViewController is empty: class DashboardViewController: UIViewController { } The only reason I created as a seperate class in this example is so I can easily see if it's visible in the memory debug view. I have uploaded the simple sample app to GitHub: https://github.com/fwaddle/TabbarMemoryLeakCheck Anyone have any suggestions? Here is a screen grab of the memory debug view showing the UITab having a reference to the DashboardViewController even though MyTabBarController has been dealloc'd:

On testing my app with tvOS 18, I have noticed the Siri Remote back button no longer provides system-provided behavior when interacting with tab bar controller pages. Instead of moving focus back to the tab bar when pressed, the back button will close the app, as if the Home button was pressed. This occurs both on device and in the Simulator. Create tvOS project with a tab bar controller. Create pages/tabs which contain focusable items (ie. buttons) Scroll down to any focusable item (ie. a button or UICollectionView cell) Hit the Siri Remote back button. See expect behavior below: Expected behavior: System-provided behavior should move focus back to the tab bar at the top of the screen. Actual results: App is closed and user is taken back to the Home Screen. Has anyone else noticed this behavior?

My app is a SwiftUI document based app using DocumentGroupLaunchScene. In iOS(iPadOS) 18.4, when it launches, it has duplicate toolbar items, and when I close the current document and open other documents, it adds more duplicates. It also shows a wrong document name, which shows the first opened document name. This issue can be reproduced in the sample code (Building a document-based app with SwiftUI). I have submitted Feedback (FB17025216), but not sure if this is a known bug or if I'm missing anything.