You can use a ZStack, like this: ZStack { // background view code TotalList() }

It looks like the issue is with UIColor.tintColor. A color value that resolves at runtime based on the current tint color of the app or trait hierarchy. When adding this line of code: UIView.appearance(whenContainedInInstancesOf: [UIAlertController.self]).tintColor = .tintColor the same buggy behaviour occurs, but setting it to any other colour makes it work fine. Apple's implementation must use UIColor.tintColor which is why alert buttons' colours are "broken".

You can't change the colour of the alert's message in SwiftUI. There are ways to customise the alert message in a UIAlertController, but I recommend staying clear of them as it uses private APIs.

This is a common problem people have. It’s probably because you have a NavigationView nested inside another one. Remove the NavigationView from the detail view (Espacios Protegidos) so that you only have one at the top of the view hierarchy. If this doesn’t work or you only have one NavigationView, you will need to show some actual code so that the issue can be identified.

The implementation of ViewBuilder relies on the @resultBuilder attribute. These articles provide a good overview of result builders: https://www.hackingwithswift.com/swift/5.4/result-builders https://www.avanderlee.com/swift/result-builders This is why you can't explicitly return a value. Something like this will work: @ViewBuilder var osText: some View {     #if os(iOS)     let os = "iOS"     #elseif os(macOS)     let os = "macOS"     #endif     let str = "You are on \(os)"     Text(str) } Adding the return keyword results in this warning: Application of result builder 'ViewBuilder' disabled by explicit 'return' statement This means that the @ViewBuilder won't do anything. You need to remove return to restore the desired behaviour. ‎ If I apply either of the fixes it suggests, it breaks my code with errors so it can't compile. This must be to do with the code you are running beforehand, as in my example performing either of the fixes complies cleanly. Can you show this code you are running? Note: The body property of View is already marked with @ViewBuilder so there is no need to add it yourself.

Then yes, move this variable copying to an action closure. You could either put this in an onAppear(_:) modifier on the Section, or if you have a Button that goes to this next page, put it in its action.

I am assuming this is where the problem lies: hoursLogged = hoursGoal minutesLogged = minutesGoal You shouldn't modify @State variables inside a view's body property or content closure. Do this in an onAppear(_:) modifier or similar. That's what might be causing the issue. Also, you haven't shown enough code to understand how things are connected. Where is the "next page" Section located? Is it in ContentView?

Apply either of these two modifiers to the NavigationLink: .buttonStyle(.plain) .buttonStyle(.borderless)

From the way Apple made the NavigationSplitView API, it is clear that having two and three column layouts shouldn't happen or should be avoided. Nevertheless, you can still achieve this through the use of two split views wrapped in a condition. Something like this, which I have tested, will work: struct ContentView: View {     @State private var selectedInt: Int? = 1     @State private var columnVisibility: NavigationSplitViewVisibility = .all     var sidebarList: some View {         List(1...10, id: \.self, selection: $selectedInt) { int in             NavigationLink("Row \(int)", value: int)         }         .navigationTitle("Sidebar")     }     var contentView: some View {         Text("Content \(selectedInt ?? 0)")     }     var detailView: some View {         Text("Detail \(selectedInt ?? 0)")     }     var body: some View {         Group { // Only rows that are a multiple of 2 will have a two-column layout             if selectedInt?.isMultiple(of: 2) == true {                 NavigationSplitView(columnVisibility: $columnVisibility) {                     sidebarList                 } detail: {                     detailView                 }             } else {                 NavigationSplitView(columnVisibility: $columnVisibility) {                     sidebarList                 } content: {                     contentView                 } detail: {                     detailView                 }             }         }         .navigationSplitViewStyle(.balanced)     } } I don't know, however, what impact this has on performance or rendering, if any.

As of iOS 16 beta 4 this now works with ScrollView. ScrollView { ... } .refreshable { // refresh action }

As of iOS 16 beta 4 this now works. ScrollView { ... } .refreshable { // refresh action }

Looks like in beta 5 the contextAction modifier has been removed and merged with contextMenu. The new modifier is contextMenu(forSelectionType:menu:primaryAction:).

Try changing the part in viewDidLoad to this: addChild(contentView) view.addSubview(contentView.view) contentView.didMove(toParent: self) // add this

By rearranging the way properties are fed into SwiftUI, you can make it fit for the new APIs. Something like this should work: NavigationStack { List(workoutTypes) { workoutType in NavigationLink(workoutType.name, value: workoutType) } .navigationDestination(for: HKWorkoutActivityType.self) { workoutType in SessionPagingView() } } NavigationSplitView { List(workoutTypes, selection: $workoutManager.selectedWorkout) { workoutType in NavigationLink(workoutType.name, value: workoutType) } } detail: { SessionPagingView() }

You need to specify that the navigation bar can display large titles, like this: navigationController?.navigationBar.prefersLargeTitles = true