Dynamic Island on a Mac: What Lives Around the Notch

The appeal of a dynamic island on a Mac is easy to state. The camera housing sits in the middle of the most valuable strip on the screen and does nothing, while the same cut-out on an iPhone became a control surface. Several apps offer to fix that, and installing one takes a minute.

What the screenshots never show is who else already lives in that strip. The top of a Mac display is crowded, the crowding is invisible until something collides, and most of the regret people report after installing an island app comes from a collision rather than from the app being bad.

What the strip is made of

The menu bar is one bar with several owners, and each region behaves differently.

Region	Owner	Behaviour when space runs short
Far left, the Apple menu	The system	Fixed, never moves
Next along, app menus	Whichever app is frontmost	Set by the app, changes on every app switch
The middle, on a laptop	The camera housing	Takes width from both sides
Right group, status menus	The system and resident apps	Leftmost items are silently not drawn
Right of the status group	Privacy indicators	One dot at a time, always shown
Far right	The clock, then Notification Center	The clock cannot be removed

Apple's guide is precise about the right hand group and about how much control a person has over it.

Toward the right end of the menu bar are items (sometimes called status menus), typically represented by icons, that let you check the status of your Mac (such as the battery charge) or customize features (such as keyboard brightness). Source: support.apple.com, read September 25, 2026

Two consequences matter for anyone adding an island. The app menus on the left are outside anybody's control, so the space available in the middle changes every time the frontmost app changes. And the status group on the right has no overflow behaviour at all, which is why the strip is already under pressure before a new overlay arrives.

Why the iPhone version cannot be copied exactly

On an iPhone, the expanding cut-out is a system feature. Apps do not draw it. They hand the system a piece of state and the system renders it inside a container it owns, which is why the animation looks the same no matter which app is behind it.

macOS offers third party developers no equivalent container. Every app in this category therefore does the same thing: it draws its own always-on-top window positioned over the camera housing, and it watches for the pointer entering that region.

That single architectural fact explains most of the trade-offs. The panel belongs to one app rather than to the system, so two of these apps installed at once compete for the same pixels and the same pointer events. The app has to observe what is playing, what the battery is doing and what was copied, rather than being handed that state, which is why each one needs permissions. And when the app quits or crashes, the notch simply reverts to being a camera housing.

None of that makes the category pointless. It does mean the accurate description is a well behaved overlay, not a system feature Apple forgot to ship.

What an island app claims, and what it collides with

The region an island app takes is adjacent to the region macOS uses for status menus, and the two interact in three specific ways.

The hover zone. The top centre of the screen is somewhere the pointer crosses constantly on its way to a menu or to an icon. A panel that expands on hover will expand during that journey. Most of these apps allow a click or a keyboard shortcut instead, and switching the trigger is the single most useful change to make on the first day.

Full screen. Video, presentations and anything running edge to edge use the whole display, including the strip the panel wants. An app that still expands over a full screen film is an app that gets quit during the first film, so that case is worth exercising deliberately rather than discovering in front of an audience.

Wake and display changes. Connecting a monitor, closing a lid or docking rearranges every screen, and a panel anchored to a camera housing has to work out where it belongs again. This is the usual source of a panel appearing on the wrong display or not appearing at all.

There is also a newer neighbour. On macOS 27, a double arrow appears when the notch or the menu system is covering menu bar items, and clicking it shifts the covered items to the left of the notch temporarily so they can be used. That control lives in the same crowded area an island app wants, which is worth knowing before wondering why a click near the housing did something unexpected.

The apps, and what each one puts there

The figures below were read on each project's own page and in Homebrew cask metadata on September 25, 2026. Prices and requirements in this category change often, so the date is part of the data.

App	Price	Requires	What appears around the notch
Notchy	Free	macOS 13 Ventura or later	Music, synced lyrics, clipboard, timers, HUDs, screenshots
boring.notch	Free, GPL-3.0	macOS 14 Sonoma or later	Music controls with a visualiser, calendar, a file shelf with AirDrop
Alcove	$14.99 one time	macOS 15 or later	Notifications, live activities, HUDs, lock screen widgets
DynamicLake	Free, with a Pro version	See the vendor page	Notifications, drag and drop, AirDrop, battery and calendar alerts
TopNotch	Free	macOS 11.0 or newer	Nothing. It hides the housing rather than using it

Alcove's requirement of macOS 15 or later is the detail that removes it from consideration on a Mac staying on an older release. The free entries are not stripped trials: Notchy states that it is free forever on its own page and reports following the system language automatically, and boring.notch is published under GPL-3.0 with its source open and over ten thousand stars on its repository.

One practical note on the open source route. The boring.notch project states that it has no Apple Developer account yet, so macOS warns on first launch that the app comes from an unidentified developer, and its own documentation points out that a Homebrew install avoids that warning.

Budgeting the strip instead of filling it

The useful question is not which app has the most features. It is what each region of the strip is for, and what should therefore be removed from the others.

An island panel is good at things that are temporary and worth an animation: the track that just started, a timer counting down, a file waiting to be dragged somewhere, a volume change. Those are events. They appear, they matter for a few seconds, and they should go away.

Status menus are good at things that are continuous and worth one glance: a connection state, a battery figure, an unread count, whether a backup ran. Those are states. They need to be readable without any interaction at all.

Sorting existing items by that distinction usually shrinks the status group noticeably, because several resident apps are occupying permanent width to report an event rather than a state. An icon whose only job is to say that the app is still running is occupying width it has not earned. Removing it, or moving it behind a divider, buys back room for the items that are read constantly.

That sorting also decides whether an island is worth installing at all. Someone whose complaint was that the strip is full has a width problem, and adding a second panel over the middle of the same strip does not create width. The relevant options and how they differ are laid out in how it compares, and the permissions this class of resident app needs are set out in the FAQ.

Machines with no camera housing

Not every Mac has one. A Mac mini, a Mac Studio, an iMac, an external display and older MacBook models all have an uninterrupted menu bar, and the apps handle that case differently.

Notchy addresses it directly, floating the same interface as a pill in the position where a housing would be, and naming Airs, iMacs, Mac minis and external monitors as the cases it covers. That means one configuration works both on a laptop screen and at a desk, which matters for anyone who closes the lid and drives a monitor.

The general shape of the problem should be stated plainly. An island app on a display without a housing is drawing a floating widget near the top of the screen. That can be useful, but it is no longer about the notch, and it competes with the menu bar for the same pixels. On such a display a plain status menu item or an ordinary floating window is usually the better fit.

What happens when one of these apps goes away

A resident utility from a small team is a bet on that team, and this category has already shown what losing the bet looks like. NotchNook, for a long time the best known paid app of the kind, had its Homebrew cask disabled on September 19, 2026, with the reason recorded as unreachable. An app already installed keeps running until a macOS update breaks it, but new installs and updates through that route stop.

Free and open source projects carry a version of the same risk, since a project can simply stop being maintained. The difference is that the source remains available, so a broken build after an OS update is at least something someone can fix rather than something nobody can reach.

Two habits reduce the cost either way. Prefer the app that does the one job that prompted the search, since a narrow app has fewer permissions and less to break. And keep the information that matters out of a single third party panel: anything that has to be visible whether or not one particular app is running belongs in the status menus, which are the system's own and do not depend on a vendor staying online.

Three settings worth finding on the first day

Whichever app is chosen, the same three settings decide whether it survives the first week.

The trigger, changed from hover to a click or a shortcut, so the panel answers rather than interrupts. Behaviour in full screen, set so the panel stays out of the way during video. And what the app added to login items along with which permissions it holds, noted somewhere, so that removing it later is a clean operation rather than an investigation. Dragging an app to the Trash rarely revokes an Accessibility grant on its own.

What to change first

Sort the top strip before adding to it. Move anything that reports a continuous state into the status menus and leave the middle for events, then pick the narrowest island app that covers the one job that prompted the search and set its trigger to a deliberate click. If the real complaint is that the status group keeps losing icons, that is width rather than decoration, and a menu bar manager such as Koffret is the piece that addresses it.