Bringing the Dynamic Island to Windows 11

Dynamic Island on Windows

Windows notifications have looked the same for years. A toast slides in from the bottom right corner, sits there for a few seconds, and disappears, easy to miss if you are focused on anything fullscreen. iOS solved a version of this problem with the Dynamic Island, a small pill at the top of the screen that expands to show live activity instead of interrupting whatever you are doing. This project brings that same interaction pattern to Windows 11, built natively in .NET 8 rather than as a skin on top of the existing notification system.

This post walks through how the app actually intercepts notifications, why the codebase is layered the way it is, and the specific design decisions that make the overlay feel native instead of bolted on.

The Core Problem: Windows Does Not Let You Replace Toasts Easily

Windows does not expose a clean way to swap out its own toast notification UI. There is no setting that says "use my custom overlay instead." So this project has to solve two separate problems that are easy to underestimate.

First, it needs to actually see notifications as they arrive, which means listening to the same WinRT notification pipeline that the OS itself uses, rather than polling installed apps individually. Second, it needs to stop the native toast from also appearing, since showing both the system toast and the new pill at the same time would defeat the entire point. Neither of these is a UI problem. They are both systems level problems, and that is why the architecture puts them in their own dedicated layer, separate from anything related to how the pill actually looks or animates.

Why the Codebase Is Split Into Core, Services, and UI

Core/       Data models, Win32 interop, zero UI dependencies
Services/   Notification listening, toast suppression, zero UI dependencies
UI/         Animation engine, overlay window, depends on Core only

The dependency direction here is deliberate. Core and Services have zero UI dependencies, and UI depends only on Core, never the other way around. That means the notification listening logic and the toast suppression logic could run headless, with no window at all, and they would work exactly the same.

This separation exists because the two hardest problems in the app, reliably catching notifications and reliably suppressing native toasts, have nothing to do with animation or layout. Keeping them isolated from UI means a change to how the pill animates can never accidentally break notification listening, and testing the listener logic does not require spinning up the actual overlay window at all. It also means if a future version of this project wanted to expose the same notification pipeline through a completely different UI, a widget instead of a pill for example, the Core and Services layers would not need to change at all.

Listening for Notifications Without Polling Every App

NotificationListener.cs uses WinRT's notification APIs to receive events as they happen rather than polling installed applications on a timer. Polling is the easy way to build this feature and the wrong way. It either checks too often and wastes CPU cycles constantly, or checks too rarely and the notification feels delayed by the time the pill shows up, which breaks the entire feeling of immediacy the Dynamic Island pattern depends on.

Hooking into the actual WinRT notification pipeline means the app finds out about a new notification at essentially the same moment the OS does, which is what makes the drop down animation feel instant rather than like a background service catching up a second late.

Suppressing the Native Toast

ToastSuppressor.cs manages Do Not Disturb state through the registry to keep native Windows toast banners from appearing while the custom pill is handling notifications. This is arguably the least glamorous part of the project and also the part that makes or breaks whether the whole thing feels like a real replacement rather than an addition.

Registry based toggling of Do Not Disturb was chosen because it operates at the same level Windows itself uses to control toast visibility, rather than trying to intercept or hide toast windows after they have already been created, which is fragile and tends to break across Windows updates. Working through the same mechanism Windows exposes for this purpose is more stable specifically because it does not depend on undocumented UI internals that Microsoft is free to change without warning.

The Animation Layer

IslandAnimator.cs handles the actual motion, a drop down bounce on arrival, a horizontal expand when there is more content to show, and a slide up exit when the notification is dismissed or times out. None of these are just visual flourish. Each one is doing a specific communication job that mirrors what the real Dynamic Island does on iOS.

The drop down bounce signals arrival without needing sound or a modal interruption. The horizontal expand is what lets the pill show more information, like an app icon and message preview, without needing a second, separate notification style for longer content. The slide up exit closes the loop so the pill never just vanishes abruptly, which would feel like a glitch rather than an intentional dismissal. Getting all three of these to feel closer to the iOS original than to a generic slide in animation is most of what makes this project feel like a real Dynamic Island instead of a rounded rectangle that happens to say "notification" on it.

Deterministic Accent Colors

Each app gets a unique, consistent avatar color, generated deterministically rather than assigned randomly or stored in a lookup table. A deterministic approach means the same app always produces the same color across restarts and across machines without needing to persist a color mapping anywhere. This is a small detail, but it matters for the same reason consistent app icons matter: recognition happens faster when the visual identity of a notification source never changes.

Working Over Fullscreen Apps and Games

The overlay window is configured to stay always on top, including over fullscreen applications and games. This is a deliberate design choice, not just a technical flag flipped on by default. A notification system that silently stops working the moment you open a game defeats much of the point of having one, especially for anything time sensitive. Making the overlay respect the same "always visible" expectation the Dynamic Island pattern implies on iOS meant explicitly handling the window layering behavior that Windows otherwise reserves for a small set of system level surfaces.

Running Quietly in the System Tray

The app lives in the system tray rather than as a visible window or taskbar entry during normal use, since a notification overlay that draws attention to its own management interface all the time works against the pattern it is trying to replicate. The Dynamic Island on iOS is meant to feel like part of the OS, not like a separate app you have to think about. Tray based controls keep the actual application surface out of the way until you deliberately want to interact with it.

Why This Was Worth Building Natively

It would have been faster to build this as an Electron overlay sitting on top of the OS. The reason it is built in .NET 8 with direct Win32 interop instead comes down to what the app actually needs to do at a systems level: hook into WinRT notification events, manipulate registry state for Do Not Disturb, and manage window layering above fullscreen surfaces. None of those are things a web based overlay can do cleanly without wrapping native calls anyway, so building natively from the start avoided an entire layer of indirection between the app and the actual OS behavior it depends on.

Getting Started

git clone https://github.com/sadeeshasathsara/dynamic-island-windows.git
cd dynamic-island-windows
dotnet build
dotnet run

On first launch, Windows will prompt for notification listener access under Settings → Privacy & Security → Notifications, where you can enable Dynamic Island Notifier. Turning on Windows' own Do Not Disturb mode alongside it lets the pill fully take over notification duty without any native toasts competing for attention.