Atoll: a Dynamic Island for the MacBook notch, built in SwiftUI

What problem Atoll solves, and for whom

The MacBook notch is dead space. Atoll's premise is that this space can host the controls you would otherwise go hunting for: media playback, CPU and memory readouts, timers, clipboard history, a colour picker and calendar previews. The README describes it as a command surface that "stays out of the way until needed, then expands with responsive, native SwiftUI animations."

The audience is narrow and specific. You need a MacBook with a notch, specifically the 14-inch or 16-inch MacBook Pro across Apple silicon generations, and macOS 14.0 or later, with the README noting optimisation for macOS 15 and above. If you run a Mac mini, a Mac Studio, an iMac or an external display as your primary screen, the entire interaction model has nothing to attach to. This is not a general macOS utility with a fallback mode; the notch is the interface.

Within that group, the appeal is consolidation. Media controls for Apple Music, Spotify and Cider sit next to live activities for Focus, screen recording, privacy indicators, downloads and battery state. System insight covers CPU, GPU, memory, network and disk. Productivity tools cover timers, clipboard history, colour picking and calendar previews. Each of those exists as a separate menu bar app somewhere. Atoll's bet is that the notch is a better home for them than a row of icons.

How the notch surface is actually assembled

Atoll is a SwiftUI application, and the repository layout shows a conventional Xcode project structure: DynamicIsland.xcodeproj, a DynamicIsland source directory, separate DynamicIslandTests and DynamicIslandUITests targets, a Frameworks directory, and a mediaremote-adapter directory alongside scripts and tests at the top level. The default branch is dev, not main, which matters if you plan to build from source rather than download a release.

The README is candid about provenance, and that candour is worth reading before you evaluate the code. Atoll builds on Boring.Notch for the foundational codebase, including the initial media player integration, the AirDrop surface, file dock functionality and calendar event display. System metrics collection derives from the Stats project's readers, with CPU temperature monitoring through SMC access, frequency sampling through IOReport bindings and per-core CPU utilisation tracking. Lock screen widget rendering uses SkyLightWindow. The music visualiser adapts rtaudio, the terminal tab adapts SwiftTerm, and battery HUDs come from DynamicNotch. Weather data comes from Open Meteo, and LLM usage tracking from OpenUsage with OpenRouter for model pricing.

That list tells you something the feature list does not: Atoll is largely an integration layer. The distinctive contribution is the notch interaction model and the assembly of these pieces into one surface. If you are evaluating the project for a fork or a contribution, the licence and the attribution chain are the first things to read, because several components carry their own upstream terms.

Media control on macOS is the hard part. The presence of a dedicated mediaremote-adapter directory suggests the project routes around the private MediaRemote framework rather than relying solely on public APIs, which is typical for this class of app and is also why media integrations tend to break on OS updates.

Installing Atoll from the DMG and the first hover

The README gives a three-step installation. Download the latest DMG from the releases page, open it, drag Atoll into Applications, then launch and grant the requested permissions. There is no Homebrew formula documented, so the DMG is the path.

If you prefer to build from source, the requirements are Xcode 15 or later, and the default branch is dev. Cloning and opening the project is the straightforward route:

git clone https://github.com/Ebullioscopic/Atoll.git
cd Atoll
open DynamicIsland.xcodeproj

After the first launch, the app asks for permissions as needed: Accessibility, Camera, Calendar, Screen Recording and Music. The troubleshooting section is blunt about the most common failure: after granting Accessibility or Screen Recording, quit and relaunch the app. Permissions granted to a running process are not always picked up live.

Once it is running, hover near the notch to expand it and click to enter controls. Tabs cover Media, Stats, Timers and Clipboard. If the Stats tab shows nothing, the README points at Settings, where metric categories are off by default and must be enabled individually. That is a deliberate choice, since sampling CPU and GPU continuously costs power.

Shelf is reachable from the command line, which is the one place Atoll exposes a scriptable entry point:

open -a Atoll /path/to/file

That adds a file to the Shelf without touching the notch. It is a small feature, but it is the only documented way to drive Atoll from outside the app, and it is the one to check first if you want to automate anything.

Gesture control and the settings that decide whether it feels right

Atoll's default interaction is hover to open. If that gets in the way, the README documents a two-finger swipe down to open the notch and a swipe up to close it, which requires disabling hover-to-open first.

The more interesting configuration is horizontal media gestures, enabled under Settings, General, Gesture control. Turning this on makes the music pane behave like a trackpad: swipes move to the previous or next track, or seek by ten seconds. The README notes that the gesture skip behaviour is configured independently from the skip button, so swipes can scrub while buttons change tracks, or the reverse. Swipes trigger the same haptics and button animations as taps.

That independence is a real design decision rather than a checkbox. Most notch apps bind one action to one concept. Separating the gesture action from the button action means the same pane supports two mental models at once, which is useful if you scrub often but skip rarely, and confusing if you do not read the settings. The README does not document a way to reset gesture configuration to defaults, so if you experiment with these toggles, note what you changed.

Settings also cover appearance, animation style, per-feature toggles, global shortcut remapping and lock screen widget data sources. Lock screen appearance and positioning for panels and widgets are configurable separately. The breadth here is a trade-off: the settings surface is large enough that the defaults matter more than usual, and the README does not describe what the defaults are.

Where Atoll is the wrong tool

The permission set is the first real cost. Screen Recording, Accessibility, Camera, Calendar and Music are not incidental. Screen Recording in particular is a broad grant for an app whose primary job is showing media controls and system stats, and the README does not explain which features require it or what is captured. If you cannot justify that grant on your machine, Atoll is not for you regardless of how good the notch interaction is.

The second limitation is hardware. No notch, no product. The README is explicit that a notched MacBook is a requirement, and there is no documented external-display mode. If you dock to a monitor most of the day, you are paying the permission and background-process cost for something you see a fraction of the time.

The third is release maturity. The recent release list shows v2.3.3-beta.3 and v2.3.3-alpha.4 both dated 2026-09-07, with v2.3.3-beta.2 earlier on 2026-08-20. Alpha and beta tags appearing in the same window, on a project whose default branch is dev, means the stable channel is not where development happens. Downloads (beta) is listed as a live activity, which confirms beta-gated features ship in the main line. If you need a build you can set and forget, this is not that.

Finally, media integration is inherently fragile. Apple Music, Spotify and Cider are named as supported, and the mediaremote-adapter directory implies private framework usage. macOS updates have historically broken this class of integration, and the README does not document a fallback when a player stops responding beyond checking that the player is active and Music permission is granted.

Atoll against Boring.Notch, which it is built on

The honest comparison is with Boring.Notch, because Atoll's README names it as the foundational codebase and credits it with the initial media player integration, AirDrop surface, file dock and calendar event display. The two projects share architectural patterns and notch interaction models.

The difference is scope. Boring.Notch, on the README's account, contributed the media and file-handling core. Atoll adds the surrounding surface: system metrics via the Stats readers, lock screen widgets via SkyLightWindow, a music visualiser adapted from rtaudio, a terminal tab adapted from SwiftTerm, LLM usage tracking from OpenUsage, and weather from Open Meteo. It also adds the settings layer for gesture remapping and per-feature toggles.

So the choice is between a smaller, more focused notch app and a broader one that pulls in components from at least nine other projects. The broader option gets you more features and a longer dependency and attribution chain. The narrower option gets you less surface area to break and fewer upstream licences to reconcile. Neither is obviously correct; it depends on whether you want a media and file dock or a general-purpose notch surface.

If you are choosing on licence grounds, both are open source, but Atoll is GPL-3.0 and bundles work from projects with their own terms. The NOTICE, TRADEMARKS and COPYRIGHT_ASSETS files at the repository root exist for that reason, and they are the files to read before redistributing anything.

Licence, maintenance and what upgrades cost you

Atoll is released under GPL-3.0. The practical implication for most users is nil: you download a DMG and run it. The implication for anyone embedding Atoll in another product, or shipping a modified build, is that the GPL's source-disclosure terms apply, and the bundled components from Boring.Notch, Stats, SkyLightWindow, rtaudio, SwiftTerm, DynamicNotch, OpenUsage and others may add their own conditions. The repository carries NOTICE, TRADEMARKS and COPYRIGHT_ASSETS files specifically to track this. That is not legal advice; read the LICENSE and NOTICE files yourself.

On maintenance, the last push to the repository was on 2026-09-22, and the repository is not archived. Development is clearly ongoing on the dev branch, with alpha and beta releases in the same month. What the release history does not show is a stable release cadence you can plan around, and the README does not document a rollback path if a beta build misbehaves. If you install from the latest release link and that release is a beta, you have no documented way back except downloading an older DMG manually.

Upgrade cost is mostly permission churn. macOS treats Accessibility and Screen Recording grants as sensitive, and the README's own troubleshooting advice, quit and relaunch after granting, indicates that permission state does not always refresh cleanly. Expect to re-verify permissions after major OS updates. The system metrics features also depend on SMC and IOReport access inherited from the Stats project, which is the layer most likely to need adjustment when Apple changes hardware interfaces.

Editorial conclusion

Atoll is for people on a notched MacBook running macOS 14 or later who want media controls, system stats and small utilities in one place, and who accept that the app depends on Accessibility, Screen Recording, Camera, Calendar and Music permissions. It is not for external-monitor-only setups, Macs without a notch, or anyone uncomfortable granting screen recording access to a third-party app. Before adopting it, verify that your machine has a notch, check the release page for the current beta or alpha tag, and confirm which permissions the build you download actually requests.

Frequently asked questions

Official sources

1. Ebullioscopic/Atoll on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases