From the watchOS 26 Beta 2 Release Notes: Known Issues toolbarForegroundStyle no longer tints toolbar button labels on watchOS. (151487439) Workaround: Tint the button label directly, using Text("foo").foregroundStyle(...).

You can set the sourceItem on the alert controller's popoverPresentationController, like this: alertController.popoverPresentationController?.sourceItem = button However, I think the effect only works if the button is a UIBarButtonItem. The same is the case in SwiftUI: toolbar bar buttons have the morph effect but regular buttons don't. Instead, the new behaviour in iOS 26 is to show the action sheet as a popover with an arrow, like on iPad. If no source is set, an alert is presented.

SwiftUI provides a similar set of features. To get the standard system buttons, a new Button initialiser allows you to create a button with a role and action, and provides a default label for you. You can get the system button for any of these button roles: .cancel, .destructive, .close, .confirm. And you can use them like this: // Standard close button Button(role: .close) { ... } // Standard done button (prominent in toolbar) Button(role: .confirm) { ... } // Prominent tinted button .buttonStyle(.borderedProminent)

Assuming the supplementary view has been registered properly, then the only other thing I see is that the element kind strings are mismatched. In your layout, you are specifying the elementKind as UICollectionView.elementKindSectionHeader (which is the string "UICollectionElementKindSectionHeader"). But when you dequeue the view, you are requesting it be of kind ElementKind.sectionHeader.rawValue ("section-header-element-kind"). I think this might be the cause of the crash.

.scrollEdgeEffectStyle is a view modifier in SwiftUI. It is available on both iOS and macOS. In UIKit, you configure a UIScrollEdgeEffect and assign it to the desired property of a UIScrollView. According to the session video, it seems that the system will automatically apply a scroll edge effect, setting the style (soft or hard) based on context. That doesn't necessarily mean that you can't customise it, given its ability to in SwiftUI and UIKit, so I suggest filing feedback or waiting to see if the functionality is added to NSScrollView in a later beta.

I'm having trouble reproducing the crash. What does your storyboard look like? You are using a UICollectionView with a custom layout (UICollectionViewCompositionalLayout by the looks of it). You have a subclass of UICollectionReusableView set as a header for the custom layout. According to the error message: must register a nib or a class for the identifier or connect a prototype cell in a storyboard I think this might be the other issue you are having. You can either manually register your custom class, like this: collectionView.register( EmotionFiltersHeaderView.self, forSupplementaryViewOfKind: ElementKind.sectionHeader.rawValue, withReuseIdentifier: "emotionFiltersHeaderReusableView" ) Or connect the reusable view in the storyboard (whatever that means). I would try manually registering first and see if that works. I'm not a fan of using storyboards, especially when working with collection views. With the introduction of compositional layouts, diffable data sources, and modern cell registrations — all designed to be configured in code — combining them with storyboards just turns into a mess, and results in error messages like yours. That's just my opinion though.

This must be a bug as it doesn't make sense to be a feature. As a workaround, I would wrap the content in a LazyVStack or something similar like you would normally. Either way, I would file feedback for this.

This feature should be coming in a later beta.

Firstly, I would recommend making the delegate property in your cell weak to avoid retain cycles. weak var delegate: EmotionExplorerCellDelegate? Whether that's the cause of the issue or not, I don't know. Without you providing more code of the surrounding context, it will be difficult to figure out a solution. For example, how is the delegate defined, what does the custom cell and the configure method look like, are there any other things to note about the cell registration and data source — just to examine if there are any other potential causes, because there aren't any immediate issues visible.

The new Liquid Glass APIs are certainly not SwiftUI-only. They are available in UIKit and AppKit. You should use UIGlassContainerEffect to get the effects of morphing and grouping. [Documentation] When using UIGlassContainerEffect with a UIVisualEffectView you can add individual glass elements to the visual effect view's contentView by nesting UIVisualEffectViews configured with UIGlassEffect. In that configuration, the glass container will render all glass elements in one combined view, behind the visual effect view's contentView.

When I preview your sample code I get this result (color = .red): This is the expected behaviour: a red rounded rectangle with a drop shadow and then stroked with a semi-transparent border. When you say the shadow is being draw over the top of the stroke, this isn't the case. It only appears like that because the stroke is 50% transparent so the shadow is visible through it. I'm not quite understanding the end result you want either. Do you want: A filled rounded rectangle with a drop shadow applied to it, and then a stroke border on top. RoundedRectangle(cornerRadius: 11) .fill(.red.shadow(.drop(color: .gray, radius: 2, x: 2, y: 2))) .stroke(.blue, lineWidth: 5) A filled rounded rectangle, and a stroke border with a drop shadow on top. RoundedRectangle(cornerRadius: 11) .fill(.red) .stroke( .blue.shadow(.drop(color: .gray, radius: 2, x: 2, y: 2)), lineWidth: 5 ) The reason I'm saying this, and also adding a blue border instead of 50% red, is because I think you are getting confused with what is happening because of the opacity you are adding to the stroke, and the fact that the stroke is half blending in with the rectangle and half overlapping the shadow which is seeping through. If I were to provide my solution to what I think you are trying to achieve, it would be this: RoundedRectangle(cornerRadius: 11) .fill(color.shadow(.drop(color: .gray, radius: 2, x: 2, y: 2))) .strokeBorder(color.mix(with: .white, by: 0.5), lineWidth: 5) I have used strokeBorder here because of the way stroking works. stroke(_:lineWidth:) traces the outline of the shape and draws itself half inside and half outside. This results in the shadow being drawn over. Using strokeBorder(_:lineWidth:) instead draws the border fully inside the shape's bounds. It's effectively the same as regularly stroking the shape that is inset by half the line width. Of course the colours and constants can be adjusted, but hopefully this explanation has helped and you have a solution to your problem.

That's actually what navigation bars looked like back in iOS 12 so maybe your simulator is getting nostalgic. I also noticed in your sample code you are embedding a NavigationStack inside another which isn't recommended, but that isn't the cause of the problem. I would definitely file a feedback because there is no reason for the navigation bar to look like that just because of a map somewhere in the view hierarchy. However, there is some good news… this doesn't seem to be a problem in iOS 26, and most importantly, I have a fix and it's this: .toolbarBackground(.automatic, for: .navigationBar) // renamed to toolbarBackgroundVisibility in Xcode 26 What you were seeing was the background of the navigation bar being permanently visible, regardless of the scroll position. It seems like the map sort of forced this behaviour.

In iOS 26, UINavigationController has a new property called interactiveContentPopGestureRecognizer and is described as this: The interactive content pop gesture recognizes on the entire content area of the navigation controller in cases that are not covered by the interactive pop gesture recognizer and initiates an interactive pop. This property should only be used to set up failure requirements with it. So I believe now the pop gesture properties are defined as so: interactivePopGestureRecognizer is the swipe from the edge gesture interactiveContentPopGestureRecognizer is the swipe anywhere in the main content gesture So by disabling both gesture recognisers, you should be good to implement your custom swipe gestures. navigationController?.interactivePopGestureRecognizer?.isEnabled = false navigationController?.interactiveContentPopGestureRecognizer?.isEnabled = false

I don't know exactly what the Settings app uses internally, but using UICollectionView with a UICollectionViewCompositionalLayout.list layout in .sidebar style is the modern, recommended approach for creating lists with default styling and system backgrounds. Since Apple introduced modern collection views, they've recommended UICollectionView over UITableView for more complex layouts and advanced list styles. Check out Advances in UICollectionView, Lists in UICollectionView, and the official docs for more examples and code.

In your code, you've configured a URLRequest object but aren't using it anywhere. Currently, you're fetching data like this: URLSession.shared.dataTask(with: url) This performs a GET request to the specified URL. Instead, you should use the method that accepts a URLRequest: URLSession.shared.dataTask(with: request)