SystemNotification: a SwiftUI library that mimics the iOS system banner

The problem: iOS has a system notification look no SwiftUI view can copy on demand

When you toggle silent mode or connect AirPods, iOS shows a banner that belongs to the system rather than to your app: a rounded, blurred panel that slides in from the top, holds briefly, and leaves. Apps that want to echo that look usually end up rebuilding it by hand, and the result reads as an imitation. SystemNotification exists to remove that work. Its description is short: a SwiftUI library that lets you mimic the native iOS system notification presented when you toggle silent mode or connect your AirPods. The audience is narrow and well defined. Any iOS developer shipping a companion app, a utility, a study app, or a companion for a device with no notification of its own can drop in a banner that matches the platform idiom instead of a custom alert. The library is a Swift package, MIT licensed, and its badge asks for Swift 6.1, so it targets a modern toolchain rather than a long tail of legacy iOS versions.

Presentation as a view modifier rather than a UIKit call

The design decision that defines this library is how the banner is attached. The documentation says you can add a system notification to any view just as you add a sheet, alert, or fullScreenCover, by applying a systemNotification view modifier, preferably on the application root view. That phrasing matters for anyone coming from UIKit. A UIKit presenter has to hold a reference, pick a presentation delegate, and resolve conflicts when two things try to appear at once. Here, the banner is part of the SwiftUI view tree, so it inherits the same layout, theming, and state model as everything else around it. Attaching it to the root view means it can float above navigation stacks, tab bars, and sheets without any of that work. The practical consequence is that presentation priority and dismissal become questions about view identity and modifiers rather than about coordinators.

State-based presentation for a single on or off banner

The simpler of the two modes takes a boolean state binding and a view builder, which mirrors how sheet or alert modifiers behave. The README example starts from a state property, flips it to true from a button, and passes the binding into the modifier along with the content closure:

import SystemNotification

struct MyView: View {

    @State
    var isActive = false

    var body: some View {
        VStack {
            Button("Show notification") {
                isActive = true
            }
        }
        .systemNotification(isActive: $isActive) {
            Text("You can use any custom content view")
                .padding()
        }
    }
}

One binding controls one banner. It is the right fit for a success or failure acknowledgement tied to a piece of state, such as a setting that turned on successfully. Because the content is any view, the banner is not limited to the native-looking message component. What this mode does not give you is a queue. Firing two state changes in quick succession means one binding drives one banner, and the library offers no documented way to hold a second message behind the first.

Context-based presentation when one modifier must serve many messages

The second mode exists for apps that show several different notifications over time. It takes a SystemNotificationContext instance and, once that context is passed to the modifier, many different notifications can be shown through the single modifier. The example holds the context as a state object, which is the correct lifetime for it since the view modifier reads from it:

import SystemNotification

struct MyView: View {

    @StateObject
    var notification = SystemNotificationContext()

    var body: some View {
        VStack {
            Button("Show text") {
                notification.present {
                    Text("Context-based notifications are more flexible.")
                        .padding()
                        .multilineTextAlignment(.center)
                }
            }
            Button("Show message") {
                notification.present {
                    SystemNotificationMessage(
                        icon: Text("👍"),
                        title: "Great job!",
                        text: "You presented a native-looking message!"
                    )
                }
            }
        }
        .systemNotification(notification)
    }
}

The difference in approach from the state based version is where the trigger lives. With a binding, the view owns the flag. With a context, a button calls present and the context decides what to show. That means a message can be triggered from a background callback or a deep link rather than from a piece of visible state. The context object being a state object also means it survives view rebuilds, which is the practical reason it is declared that way rather than as a plain property.

SystemNotificationMessage for the native look, or any view for your own

Content is where the project draws its line. SystemNotificationMessage is the native-looking view, built from an icon, a title, and a text body, and the documentation says you can use any custom view as the notification body instead. The example builds one with an icon argument, a title, and a sentence of text, which is the shape of the system banner you see on iOS: an icon in the leading corner, a bold headline, and a lighter subline. Using the built-in component is the fastest route to a convincing match, and using your own view is the route to something that fits your brand but still arrives with the system presentation and dismissal behaviour. Nothing in the library forces the native styling on the content. The limitation sits in the details: the documentation does not give the icon and text styles, the corner radius, or the timing of the banner, so matching the system exactly means relying on the component rather than on your own settings.

Installing the package and running the bundled demo

Installation is a Swift Package Manager dependency, and the README gives the repository URL to add:

https://github.com/danielsaidi/SystemNotification.git

Beyond that, the documentation points to an online getting started guide hosted at danielsaidi.github.io/SystemNotification, and the repository root contains a Demo folder holding an app that lets you explore the library. That demo app is worth treating as the real first use rather than an optional extra. It gives you a working Xcode project with the package already wired in, so you can press the buttons and compare the state based and context based flows side by side before you commit to either in your own project. The repository also ships a Package.swift at its root, Tests, Resources, a scripts folder, and a RELEASE_NOTES.md, which is where you would look to see what changed between versions rather than relying on the README.

What this library does not do, and what to use instead

The boundary is worth stating plainly. SystemNotification draws a banner inside your app. It is not a notification delivery mechanism, so it does not reach the user when the app is suspended or terminated, and it does not appear in Notification Center, and it cannot request permission. When the requirement is a message that arrives minutes later, possibly with the app closed, you need the user notification system instead. Where the two overlap, they can be combined, using a delivered notification for anything that must survive backgrounding and this library for in-app acknowledgements that should feel like the system. The second limitation is documentation depth. The README does not describe the animation timing, the dismissal behaviour, whether the banner is interactive, or how it behaves with VoiceOver or with Dynamic Type. Those answers exist in the online documentation rather than in the repository readme, so plan to read the guide before you rely on the component in an accessibility-sensitive app.

Maintenance, releases and the MIT licence

SystemNotification is not archived, and the last push was on 2026-06-05, so the code is being touched. The release history shows version 1.4.1 on 2026-02-22, preceded by 1.4.0 on 2025-10-24 and 1.3.0 on 2025-07-12. The gaps between those tags run to several months, so the project moves in considered steps rather than frequent ones, and the version numbering has stayed on the 1.x line with a minor bump for each feature set. The README badge asks for Swift 6.1, which tells you the package targets a recent language mode, so a team on an older Xcode will need to check that before pulling the dependency. Licensing is the simplest kind: MIT, with the LICENSE file at the repository root and the README stating the library is available under that licence. For a closed source commercial app, MIT means you can ship the banner without an open source obligation on your own code, and the only requirement is retaining the notice. The maintainer also lists sponsorship and contact routes for questions.

Editorial conclusion

SystemNotification suits iOS developers who want a system-style banner without dropping into UIKit, especially those who already rely on SwiftUI's presentation modifiers. It does not replace UserNotifications, since it is a rendered view rather than a delivered notification, and the documentation here does not cover animation timing, accessibility behaviour, or older iOS versions. Before adopting it, add the package at the version that matches your Swift toolchain, confirm the banner behaves correctly over your own layouts, and check the release notes for 1.4.1 dated 2026-02-22 against any SwiftUI changes you depend on.

Frequently asked questions

Official sources

1. danielsaidi/SystemNotification on GitHub
2. License: MIT
3. Project website
4. README
5. Releases