7 SwiftUI ViewModifiers Introduced in iOS 26

With iOS 26, small yet powerful ViewModifiers that simplify everyday development have entered the game. At first glance, these new modifiers may look like minor details, but they significantly streamline SwiftUI code and make the resulting user experience feel much more native.

If you are not a Medium Member, you can read the entire article for free here.

Press enter or click to view image in full size

Problems that previously required extra state management, custom wrappers, or even UIKit bridges can now be solved with a single modifier. In this article, we’ll take a closer look at 7 ViewModifiers introduced in iOS 26 that truly make a difference in day-to-day projects.

1.sliderThumbVisibility(visibility: Visibility)

Although Slider is a native SwiftUI component and one of the most commonly used controls in interactive screens, the classic “thumb” appearance isn’t ideal for every scenario.

In cases such as media controls, progress-driven interactions, or more minimal interfaces, you may want the slider to behave more like a value indicator than a traditional control. The sliderThumbVisibility modifier introduced in iOS 26 steps in exactly here, allowing you to adjust the slider’s visual behavior based on the context and giving you more flexible and precise control over its appearance.

struct SliderTest: View {
    @State private var progress: CGFloat = 0.5

    var body: some View {
        Slider(value: $progress)
            .padding(.horizontal, 16)
    }
}

and if we add the sliderThumbVisibility modifier here as well

.sliderThumbVisibility(.hidden)

Below, you can see how the slider looks before and after applying the modifier. With this modifier, it becomes possible to use a slider as a plain progress view, while still keeping user interaction when needed.

2- safeAreaBar(edge:alignment:spacing:content:)

Although the concept of safe areas has been part of SwiftUI for a long time, building fixed action areas — especially at the top or bottom of the screen — often still required extra layout work. Creating a structure that works seamlessly with a ScrollView, moves naturally with the content, and doesn’t visually clash with system bars was usually achieved through safeAreaInset combined with custom solutions.

The safeAreaBar modifier introduced in iOS 26 addresses this need in a much more natural and system-aligned way, making “sticky” bar usage significantly easier for developers in SwiftUI.

In practice, it works similarly to safeAreaInset, but instead of a flat transparent background, it offers both progressive and hard blur options. The blur effect and its visibility can be further customized using the scrollEdgeEffectStyle modifier.

struct SafeAreaBarTest: View {
    var body: some View {
        NavigationStack {
            List {
                ForEach(1...20, id: \.self) { index in
                    Text("\(index). Item")
                }
            }
            .safeAreaBar(edge: .bottom) {
                Text("Hello, This is Bottom Bar!")
                    .padding(.vertical, 15)
            }
            .scrollEdgeEffectStyle(.soft, for: .bottom)
            //.scrollEdgeEffectStyle(.hard, for: .bottom)

        }
    }
}

Then our screens will look like this. You can choose either .soft or .hard as the effect style.

3- onOpenURL(prefersInApp:)

Before iOS 26, the Link view in SwiftUI would open the provided URL in the Safari app by default. If you wanted to change this behavior, you usually had to rely on UIKit-based solutions such as SFSafariViewController.

With iOS 26+, this requirement is handled in a much more straightforward way. By setting prefersInApp to true on the openURL environment property, links can now be opened directly in an in-app web browser. This allows you to keep users inside your app and preserve the flow, while controlling link-opening behavior declaratively within SwiftUI using a single modifier.

struct OpenURLTest: View {
    @Environment(\.openURL) var openURL

    var body: some View {
        let website = URL(string: "https://hasanalidev.medium.com")!
        VStack {
            // Eski stil
            Link(destination: website) {
                Text("Hasan Ali Medium Website")
            }

            Button("Hasan Ali Medium Website") {
                openURL(website, prefersInApp: true)
            }.buttonStyle(.borderedProminent)
        }
    }
}

If we examine it:

4- Close Role for Button

With iOS 26+, new button roles called .close and .confirm are introduced in SwiftUI. You no longer need to create a custom label to represent a close action on modal or sheet-based screens. When Button(role: .close) is used — especially inside a toolbar — the system automatically renders a closing button styled with an X icon and a glass effect, providing a native and consistent dismissal experience without any extra configuration.

struct CloseRole: View {
    @State private var showSheet: Bool = false

    var body: some View {
        Button("Show Sheet") {
            showSheet.toggle()
        }
        .sheet(isPresented: $showSheet) {
            NavigationStack {
                VStack {}
                .navigationTitle("Info")
                .toolbar {
                    ToolbarSpacer(.flexible, placement: .topBarTrailing)
                    ToolbarItem(placement: .topBarTrailing) {
                        Button(role: .close) {
                            showSheet = false
                        }
                    }
                }
            }
            .presentationDetents([.medium])
        }
    }
}

5 ve 6- GlassButtonStyle ve buttonSizing(_ sizing: ButtonSizing)

Requires iOS 26.1+

When iOS 26 was first released, SwiftUI introduced two basic glass button styles: .glass and .glassProminent. Both provided the classic glass effect, but if you wanted a clear glass appearance or a more tinted / colored glass effect, you typically had to add extra layers and build a custom button view.

Starting with iOS 26.1+, this changes in a very welcome way. With GlassButtonStyle, you can now manage different glass effect variations much more easily and in a truly native manner.

On top of visual styling, layout control also becomes simpler. Thanks to the buttonSizing modifier introduced in iOS 26, you can decide whether a button should fill all available space (.stretch) or fit its label size (.fit) with a single line of code. This modifier works not only with plain text buttons but also with custom labels (icon + text, HStack / VStack, etc.), allowing both the button style (glass / tinted / clear) and layout behavior (fit / stretch) to be expressed declaratively in SwiftUI.

struct GlassButtonTest: View {
    var body: some View {
        ZStack {
            Image(.BG)
                .resizable()
                .aspectRatio(contentMode: .fill)
                .ignoresSafeArea()

            VStack {
                Button("Glass Button") {

                }
                .fontWeight(.bold)
                .foregroundStyle(.white)
                .buttonStyle(GlassButtonStyle(.clear))
                .buttonSizing(.flexible)
                .font(.title)
            }
            .padding()
        }
    }
}

This is how it will appear on our screen:

7- searchToolbarBehavior(_:)

Search experience is a critical element in helping users reach the right content quickly, especially on list- and content-heavy screens. While .searchable has been part of SwiftUI for a long time, the behavior of the search field inside the toolbar was often limited. As navigation bars became more crowded, the search bar either took up too much space or disrupted the overall visual rhythm.

So what if we want a search bar that behaves like the one in a Tab Bar — more compact when not focused, and expanding only when needed? The searchToolbarBehavior modifier introduced in iOS 26 is designed exactly for this scenario. It allows you to declaratively define how the search field is presented in the toolbar, resulting in a cleaner UI and a more focused search experience.

struct SearchToolbarBehaviorTest: View {
    @State private var searchText: String = ""

    var body: some View {
        NavigationStack {
            List {
                Text("User 1")
                Text("User 2")
                Text("User 3")
            }
            .navigationTitle("Search Users")
            .searchable(text: $searchText)
            .searchToolbarBehavior(.minimize)
            .toolbar {
                ToolbarSpacer(.flexible, placement: .bottomBar)
                DefaultToolbarItem(kind: .search, placement: .bottomBar)
            }
        }
    }
}

You can see our screen before and after using .searchToolbarBehavior(.minimize) below.

BONUS If you’ve run this code in the simulator, you’ve probably noticed that when the search bar becomes active, the navigation title disappears. If you don’t want the title to be hidden, you can prevent this by using the .searchPresentationToolbarBehavior(.avoidHidingContent) modifier.

Note: This is not an iOS 26 modifier — it’s available starting from iOS 17.1 and later.

These new ViewModifiers introduced with iOS 26 clearly show how much impact “small touches with big results” can have in SwiftUI. While each addition may seem simple on its own, together they enable cleaner code, fewer custom solutions, and a user experience that feels fully aligned with the system. In short, iOS 26 empowers SwiftUI developers not with more complexity, but with better defaults, bringing us one step closer to the refined experience we see in Apple’s own apps.

Happy coding!