Hello and welcome to Swift and the forums! In your code snippets, the map doesn't actually switch styles because the SwiftUI Map view in iOS 14 doesn't support changing map types out of the box. The id modifier won't magically change the underlying style — it only forces a re-render if the ID is truly different. The mapStyle(_:) modifier only exists from iOS 17 onwards, so no luck if you need to support iOS 14. To properly support different map types (standard, satellite, hybrid) on iOS 14, you'll need to drop down to UIKit and use MKMapView via UIViewRepresentable. Here's a stripped-down example to get you started: struct MapView: UIViewRepresentable { @Binding var coordinateRegion: MKCoordinateRegion let style: MKMapType func makeUIView(context: Context) -> MKMapView { let map = MKMapView() map.showsUserLocation = true map.delegate = context.coordinator return map } func updateUIView(_ map: MKMapView, context: Context) { map.region = coordinateRegion map.mapType = style } func makeCoordinator() -> Coordinator { Coordinator(parent: self) } class Coordinator: NSObject, MKMapViewDelegate { private let parent: MapView init(parent: MapView) { self.parent = parent } func mapViewDidChangeVisibleRegion(_ mapView: MKMapView) { parent.coordinateRegion = mapView.region } } } Then in your SwiftUI view: if case .openStreetMap = selectedMapStyle { openStreetMapView() } else { MapView(coordinateRegion: $locationManager.region, style: selectedMapStyle) } Hope this helps. If you have any questions or extra context about your current code, just shout.

The main point here is that to be able to change the style of a map in iOS 14, you must use MKMapView. Another thing to note is that SwiftUI's Map and MKMapView actually rely on the same underlying technologies. The key difference is that MKMapView (UIKit) gives you much more granular control, whereas the SwiftUI Map is a higher-level, declarative wrapper that, in iOS 14, simply doesn't expose the needed map style API. Remember, SwiftUI was only a year old at that point, so it didn't have half the features it does today, including proper integration with other frameworks. Regarding tracking and user-following: you can definitely replicate this behaviour using MKMapView. It just takes a bit more code, but a quick skim through the documentation will point you in the right direction. You can make use of view properties and delegate methods to handle your tracking logic as needed, as well as any additional features you want to implement. For example, you can set userTrackingMode to .follow or .followWithHeading, and react to user interactions by implementing the mapView(_:regionWillChangeAnimated:) and mapView(_:regionDidChangeAnimated:) delegate methods. In other words, all the "automated" stuff SwiftUI does under the hood is still possible — you just need to handle it yourself imperatively in UIKit. Once you wrap that up neatly in your UIViewRepresentable, you'll have full control over style switching and user interaction, without giving up tracking. I know it sounds a bit tedious, but that's unfortunately the reality with iOS 14 and SwiftUI's early map support. The focus of this post is on how to change the map style of Map in iOS 14, and I believe I've covered that question here. If you have other issues, I suggest creating a new post to keep the topics clean and focused.

I believe Apple has long discouraged using a bottom toolbar together with a tab bar, as it can "make an app feel cluttered and difficult to navigate." Instead, the recommendation has been to place actions in the navigation bar, use menus or swipe gestures, or occasionally introduce a floating or modal UI element. With the new UI changes in iOS 26, this guidance still seems to hold. I've seen some developers repurpose the search tab item as a button rather than a true tab to achieve a floating-action-style shortcut — though this is more of a creative workaround than an officially endorsed pattern. Ultimately, it's up to you how you design your app, but I'd suggest leaning on Apple's previous advice to avoid mixing bottom bars. In any case, filing an enhancement request (or I guess waiting for someone from Apple to respond here) is a good way to get some clarity.

You are correct in saying that the safeAreaBar modifier additionally adjusts the scroll edge effect. However, I believe that this modifier is currently broken (as of beta 2), because its behaviour seems to be no different to using safeAreaInset. I have filed feedback for this: FB18350439.

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.