You can access your app's settings page URL from the UIApplication.openSettingsURLString property. Use it like this: Button("Open Settings") { // Get the settings URL and open it if let url = URL(string: UIApplication.openSettingsURLString) { UIApplication.shared.open(url) } } There is currently no way to deep link directly to your app's location settings. iOS 16 did, however, introduce a UIApplication.openNotificationSettingsURLString property for the notifications settings section, so maybe the location settings URL is possible in the future, or through this.

Your QuotesViewModelImpl.init is marked as being async, and this is causing the issue. When you create your vm property, you are using the StateObject property wrapper which is initialised with this: init(wrappedValue thunk: @autoclosure @escaping () -> ObjectType) // ObjectType ends up being your QuotesViewModelImpl QuotesViewModelImpl needs to be initialised asynchronously, but in a place that doesn't support concurrency – no async – so you can't use that initialiser. Since there is nothing in that initialiser that needs to be executed asynchronously (i.e. called with await), I suggest you remove the async.

In macOS Ventura, a new modifier, contextMenu(forSelectionType:menu:primaryAction:), was introduced to allow for a primary action to executed in selection-based containers along with the standard context menu. List(selection: $selectedItem) { ... } .contextMenu(forSelectionType: String.self, menu: { _ in }) { // double tap action } Single tap selection still works as well as the double tap action (specific to macOS). There was a contextAction(forSelectionType:action:) modifier originally which was removed and merged with the context menu one. I'm not sure why but it does mean you have to pass in an empty closure to the menu parameter if you want the same functionality.

You can place the button in the toolbar with the ToolbarItemPlacement.primaryAction placement. .toolbar { ToolbarItem(placement: .primaryAction) { // place button here } }

You simply need to use the WKNavigationDelegate to detect when there has been a navigation request (i.e. clicked on a link). You will need a class for this and that is where UIViewRepresentable.Coordinator comes in. You can implement it like this: struct NewsItemWebView: UIViewRepresentable {     var text: String     func makeUIView(context: Context) -> WKWebView {         let webView = WKWebView()         webView.navigationDelegate = context.coordinator         return webView     }     func updateUIView(_ webView: WKWebView, context: Context) {         ...     }     func makeCoordinator() -> Coordinator {         Coordinator()     } } extension ItemWebView {     @MainActor class Coordinator: NSObject, WKNavigationDelegate { // used the async method so you don't forget to call a completion handler // you can still use the completion handler method         func webView(_ webView: WKWebView, decidePolicyFor navigationAction: WKNavigationAction) async -> WKNavigationActionPolicy {             if let url = navigationAction.request.url, /* should `url` be opened in Safari */, await UIApplication.shared.open(url) {                 return .cancel             } else {                 return .allow             }         }     } } You will need to check the navigation request's url to see if it should be opened in Safari. This will prevent opening the originally loaded content in Safari instead of the app.

What is the actual problem? Which sample code fails to compile? The old modifier, contextAction(forSelectionType:action:), was removed and its functionality was added to the contextMenu(forSelectionType:menu:primaryAction:) modifier. It is now used like this: .contextMenu(forType: Book.ID.self, menu: { _ in }) { books in // perform primary action } That's just what happens during the beta period: things are added, removed and modified. It's the final version that counts.

I've found that editMode works very strangely and only some of the time when you know how it works. Try extracting the parts that access the editMode property from the container that changes based on it, like List/Form. // container that does editing // changes based on editMode Form { EditingView() // extract to new view } // EditingView @Environment(\.editMode) private var editMode if editMode?.wrappedValue.isEditing == true { Text("Editing") } else { Text("Not Editing") }

Xcode 14.0.1 includes everything you need to create amazing apps for all Apple platforms. It includes SDKs for iOS 16, iPadOS 16, tvOS 16, watchOS 9, and macOS 12.3. Use Xcode 14.0 beta 6 or Xcode 14.1 beta 3 instead.

I'm assuming you mean change the List background to a custom image, since you are already changing the NavigationLink background with this: .listRowBackground(Color.black) In iOS 16, List no longer relies on UITableView, so your appearance proxy workarounds won't work. Instead, a new modifier, scrollContentBackground(_:), was introduced to remove the default background of a List and let you customise it with whatever view you wanted. You would use it like this: List(...) { ... } .scrollContentBackground(.hidden) // new in iOS 16 .background { Image("ImageName") .resizable() .scaledToFill() }

You can just remove the background colour for the list row, like this: Picker(...) { ... } .pickerStyle(.segmented) .listRowBackground(Color.clear) .listRowInsets(.init()) // optional

Check out this article, particularly the "Register your URL scheme" section.

The first option is the recommended way of doing it. Create the ObservableObject class as an @StateObject property first, and only once Pass it into the environment, with environmentObject(_:) Access the class from subviews using @EnvironmentObject

Your issue is not because of the NavigationView but the fact that you have a List. Up until iOS 16 there had been no direct SwiftUI way of changing the background colour of a List. You had to access the UITableView appearance proxy and "remove" the background colour that way. Now there is a dedicated modifier for this: scrollContentBackground(_:). Use either of these methods, dependant on the target version, to clear the default list background colour, and then set your own, like this: // iOS 15 and earlier init() { UITableView.appearance().backgroundColor = .clear } List { ... } // iOS 16 .scrollContentBackground(.hidden) // set background to any colour or gradient .background(.linearGradient(colors: [.green, .red], startPoint: .top, endPoint: .bottom))

What do you mean by "displaying" the links? (1) Is it showing them repeatedly in a row/column? (2) Or do you want the links to be interpolated in some standard text? I would recommend using an array of a custom type that can then each be converted into a Link view, instead of storing the actual view. Something like this: struct DisplayedLink { let title: String let url: URL } let links: [DisplayedLink] = [ ... ] Option 1: // any suitable layout container VStack { ForEach(links, id: \.self) { link in Link(link.title, destination: link.url) } } Option 2: var linksText: AttributedString { var str = AttributedString("text comprised of the links' titles") for link in links { if let range = str.range(of: link.title) { str[range].link = link.url } } return str } // the linked text is coloured and tappable Text(linksText)

You can use it like this: Link("Click this link", destination: URL(string: "https://some.destination.url")!) The init(_:destination:) initialiser will convert the title string parameter to a Text object, hence getting you to your Link<Text> object. Check out the documentation for more.