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.

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.

.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.

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.

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)

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.

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 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.

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.

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.

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 I'm trying to get across is that you would need to wait for the next layout pass after the call to valueChanged so that the new width is the correct one. So, it's however you would do that normally — either by: 1‎. Waiting for the next update (I'd assume the equivalent to Task would be using GCD, like Swift used to have DispatchQueue.main.async): dispatch_async(dispatch_get_main_queue(), ^{ CGFloat width = [datePicker systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].width; }); 2‎. Forcing a layout update so the width is updated immediately: [datePicker setNeedsLayout]; [datePicker layoutIfNeeded]; CGFloat width = [datePicker systemLayoutSizeFittingSize:UILayoutFittingCompressedSize].width; 3‎. Another method you prefer using. Hope I've explained it better and this solves your issue.

Okay, I think I figured it out. What I didn't realise before when testing systemLayoutSizeFitting was that the width being printed was actually the old width, not the updated one. Just to confirm, I wrapped the print statement in a Task (or you could do a tiny delay), and now it prints the correct width after the change.

Couldn't you just use the systemLayoutSizeFitting method in the value-changed selector? datePicker.systemLayoutSizeFitting(UIView.layoutFittingCompressedSize).width

What is your custom transformer class? Since NSAttributedString isn't automatically transformed, you need to create your own one. Something like this will suffice: class AttributedStringToDataTransformer: NSSecureUnarchiveFromDataTransformer { override class var allowedTopLevelClasses: [AnyClass] { [NSAttributedString.self] } override class func transformedValueClass() -> AnyClass { NSAttributedString.self } override class func allowsReverseTransformation() -> Bool { true } } extension NSValueTransformerName { static let attributedStringToDataTransformer = NSValueTransformerName("AttributedStringToDataTransformer") } The name of the transformer you set in the Core Data editor would be "AttributedStringToDataTransformer", and the custom class would be "NSAttributedString". And then you need to register this custom transformer before initialising your persistent container with Core Data. ValueTransformer.setValueTransformer(AttributedStringToDataTransformer(), forName: .attributedStringToDataTransformer) The second point is converting between NSAttributedString and AttributedString. You can make things easier by adding a property of type AttributedString to your Item class that does the conversion. @NSManaged private var attributedString: NSAttributedString? public var notesText: AttributedString { get { attributedString.map(AttributedString.init) ?? "" } set { attributedString = NSAttributedString(newValue) } } You can then use this property directly in SwiftUI, and even bind the text editor to it. For example: @State private var notesText: AttributedString = "" // Load text init(item: Item) { self.item = item self._notesText = State(initialValue: item.notesText) } // Save text func saveButtonTapped() { item.notesText = notesText try? managedObjectContext.save() } Hope this helps and solves your issue.