How are you setting your locale? If you aren't already, you can set it through the environment, like this: DatePicker(...) .environment(\.locale, myCustomLocale) You can customise a Locale object with the values you want for specified properties, such as the region or calendar.

So you're not using SwiftUI. You should probably place this post in the UIKit topic instead so it's less confusing. ‎ In UIKit above property isn't available I believe UIDatePicker has a locale property that you can assign a custom locale to. It will do the same as the SwiftUI solution. If this doesn't work, or you have already tried it, then you need to provide more context and the code you are using so we can understand what is going on.

I have had issues in the past when using the Binding initialisers that accept another Binding. According to the error message, it is force unwrapping the value inside instead of returning nil from the initialiser itself. I find creating your own Binding seems to work for most cases. if let number { InnerView(number: .init { number } set: { self.number = $0 }) }

Regarding your final point about modifying the space between lines, you could use the lineSpacing(_:) modifier. TextEditor(text: $text) .lineSpacing(20)

Hey there, welcome to the forums and SwiftUI! You seem to have come across a common problem in SwiftUI when dealing with protocols, like Shape. You're telling Swift that the shape property is some type that conforms to Shape, but the problem is that Ellipse and RoundedRectangle are two different concrete types — even though they both conform to Shape. Swift needs to know the exact concrete type at compile time, so you can't return two different shape types from the same computed property unless you erase the type. Swift suggests using any Shape, like this: var shape: any Shape { if isEllipsis { Ellipse() } else { RoundedRectangle(cornerRadius: 8) } } But this approach doesn't work directly with modifiers like background(_:in:), because SwiftUI's view builder needs a specific Shape type, not a generic any Shape. The solution is to use AnyShape – a type-erased shape value – and can be used by wrapping each Shape type like this: var shape: some Shape { if isEllipsis { AnyShape(Ellipse()) } else { AnyShape(RoundedRectangle(cornerRadius: 8)) } } Now Swift can infer the concrete type as AnyShape, whilst also preserving the underlying shape's behaviour (like how it draws itself). That gives you flexibility without breaking Swift's strict type system. You could also move the logic into the body and inline the condition using a ternary operator instead, like this: .background(color, in: isEllipsis ? AnyShape(Ellipse()) : AnyShape(RoundedRectangle(cornerRadius: 8))) // You can use the shorter syntax for creating shapes if you want to .background(color, in: isEllipsis ? AnyShape(.ellipse) : AnyShape(.rect(cornerRadius: 8))) I hope this explanation helps and also fixes your problem.

Available in Xcode 26 beta 2. https://developer.apple.com/documentation/swiftui/primitivebuttonstyle/glassprominent

I believe the solution to this problem is to use the new safeAreaBar(edge:alignment:spacing:content:) view modifier, as suggested by its documentation and a comment made during the SwiftUI group lab. However, I also 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.

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.

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

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.

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.

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.