Islet
iPhone's Dynamic Island, brought to your Mac's notch
Start new thread

Islet - iPhone's Dynamic Island, brought to your Mac's notch

by•
Most notch utilities just draw a static shape over the cutout. Islet actually behaves like iPhone's Dynamic Island: native spring-physics expand/collapse, real-time HUDs for volume and brightness, a live music glance with full playback controls, one-tap audio output switching (no System Settings detour), plus calendar, weather, and a file tray you can drop into from anywhere. Built natively in Swift + AppKit, not Electron, fast and fullscreen-aware.

Add a comment

Replies

Best
Maker
📌
Hey Product Hunt 👋 I'm Lippi, solo dev. The notch on newer MacBooks just sits there as dead space — meanwhile iPhone turned the same cutout into something actually useful with Dynamic Island. So I built that for Mac. The concept was the easy part. Getting the spring-physics expand/collapse to feel native — not janky — took a lot of manual trial-and-error, way more hands-on debugging than "just prompt an AI and ship it." 3-day free trial, one-time $5.99 (launch price, code LAUNCH). Would love feedback, especially from anyone running a Mac with a notch daily.
Huge congrats to the launch! The animations look super smooth. Transitioning the Dynamic Island feel to macOS without making it feel unnatural is no easy task. Will definitely try it out!
Maker

  Thanks a lot, means a lot! Yeah that was the whole goal, wanted it to feel like it belongs on macOS, not bolted on. Let me know what you think once you've tried it!

these notch utilities always make me nervous about the next macOS point release. Apple's changed how the notch/camera housing area behaves at the API level before without much warning. is this drawing into a stable public area (menu bar extra, NSStatusItem territory) or is it doing something closer to overlaying private window layers that could just break on the next update?

Maker

  Fair question. The main overlay window is a plain NSPanel at .statusBar level, totally public API. The one exception is the fullscreen-overlay feature (keeping the island visible over fullscreen apps), which uses CGSSpace, an undocumented API a bunch of other notch apps also rely on. It's isolated to that one feature, so worst case it breaks while everything else keeps working. I keep an eye on betas and patch fast if it happens.

That distinction between the concept being easy and the physics feel being the actual hard part rings true, since a notch expand collapse that's even slightly off in timing or easing reads as fake immediately, the same way people can tell a laggy or overshooting animation apart from a native one without being able to say exactly why. Curious what ended up being the trickiest part to match, was it more about matching Apple's actual spring constants and damping, or was it more about getting the trigger conditions right, like exactly when it should expand versus stay collapsed during things like fullscreen apps or multiple displays. Also, built natively in Swift and AppKit rather than Electron is a good call for something meant to feel like system chrome, but that also means every macOS point release is a real risk to something reaching into that specific notch area. How much of Islet's behavior depends on private or undocumented APIs versus fully public ones, since that's usually the thing that quietly breaks a utility like this after an OS update.
Maker

Trigger conditions were the harder part by far. The spring itself is just two numbers (response/damping) tuned once and left alone. But figuring out exactly when to expand vs stay collapsed, especially across fullscreen apps and multiple displays, needed its own dedicated detection logic (separate fullscreen probe, separate display resolver) plus a grace delay so quick pointer movements don't cause flicker. That state machine took way more iteration than the animation curve did.

And to your other question: same answer as above, the main window is public API (NSPanel, .statusBar level), only the fullscreen-overlay part leans on an undocumented CGSSpace call.