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.
Congrats to the launch, i'm using boringnotch, what're advantages of your Islet?
Maker

 Thanks! We share some overlap (music controls, calendar, HUD replacements, file shelf), but a few things Islet does differently:

- Live Activities incl. a Meeting HUD — call timer + system-wide mic mute for Zoom/Teams

- Encrypted Clipboard History

- Custom Timer/Pomodoro you can create yourself

- Automatic updates (no manual re-downloads)

- Configurable Weather widget (compact/large)

- Audio output switcher (quick device switching, not just a volume HUD)

- Quick Notes with Obsidian export coming up too, for capturing stuff on the fly

Would love for you to give it a try and let me know what you think — feedback's very welcome!

 thanks, I would also like to ask: did you develop this from scratch, or is it based on an existing open-source codebase?

Maker

 Built from scratch own Swift/SwiftUI codebase and window architecture, no shared/forked base with any other notch app. That said, I did take UX inspiration from a few apps for specific features (e.g. Droppy's onboarding flow and destination-picker pattern, Ice's menu bar overflow concept) just borrowing ideas, not code, same as most apps in this space do from each other.

Interesting launch! Everyone fixates on the spring, but catching a brightness change on macOS is the real headache since there's no clean public event to subscribe to. Did you guys land on polling the IOKit display values? Or did you find a notification that fires reliably?

Maker

  Neither actually, we don't watch for a brightness change at all. There's a HID-level event tap that intercepts the physical F1/F2 key press before it even reaches the window server, then Islet drives the real brightness change itself through DisplayServices.framework, a private framework loaded via dlopen since Apple Silicon's internal display has no reliable public API for this. If that private write ever fails, it falls back to just passing the key through untouched so nothing breaks silently.

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.

@lippi304 good to hear it's scoped to just the one feature, that's a sane tradeoff. plain NSPanel for the main overlay means the core experience survives even in a worst case, and CGSSpace breaking would be an annoying but contained regression rather than the whole app going down. appreciate the honesty about tracking betas instead of pretending it's a non-issue.

Maker

 Appreciate that that's exactly the mindset with private APIs, isolate the blast radius and stay honest about it.

the isolate-the-blast-radius approach to the private APIs is reassuring, and the boringnotch comparison answer was honest too. one thing I'm curious about that hasn't come up - the encrypted clipboard history feature, what's actually being protected against there? is the encryption mainly for at-rest storage on disk in case someone else has access to the machine, or does it also mean Islet itself can't read back old clipboard entries without you unlocking something? asking because clipboard history is exactly the kind of feature that quietly becomes a liability if it's just sitting in a plaintext sqlite file somewhere

Maker

 honest answer: it's at-rest only. AES-GCM via CryptoKit, key lives in the macOS Keychain (kSecAttrAccessibleAfterFirstUnlock), no Secure Enclave, no biometric gate. Islet decrypts and loads the full history transparently on every launch, no unlock step involved. So it protects against someone pulling the raw file off disk, like another local user account or an unencrypted backup/Time Machine copy, but it's not meaningfully stronger than what FileVault already gives you once you're logged in. If you want the "app itself can't read it without you unlocking something" model, that would need a LocalAuthentication gate on the Keychain item. Not there today, could be a good follow up though.

 that's a clean answer honestly, most makers would've let "encrypted" imply more than it does. FileVault-equivalent is genuinely fine for the threat model you described, I just wouldn't want someone reading "encrypted clipboard history" in the App Store listing and assuming it means the second thing. worth a one-line clarifier in the description either way, but no complaints on the actual security choice.

The spring-physics expand/collapse is what separates this from every menu bar utility that just reserves the notch — you can feel the difference immediately. Curious about the file tray: when I drop something in, does it persist between sessions or is it a quick-transfer scratchpad that clears on reboot? I do a lot of screen recording setups where I need to stage a handful of assets before recording, and a persistent tray I don't have to refill every time would change how I use it.

Maker

 Good question — right now it's a quick-transfer scratchpad, not a persistent shelf. Dropped files get copied into a temp directory for the session, but nothing gets reloaded on relaunch, so it resets on app restart or reboot (by design, not a bug). If you need staged assets to survive across sessions, for now you'd want to drag them out into a real folder before quitting. Persistent shelf storage is something I could see adding later if there's demand for exactly that recording workflow — appreciate the use case, it's a good data point.

Congrats on the launch! Turning the notch from a thing people complain about into the useful bit of the screen is a lovely flip. What was the first thing you tried putting up there that turned out to be a bad idea?

Maker

 First real dead end was a "3 files saved" toast that was supposed to pop up when you closed a drop session — it reused our song-change-toast animation almost verbatim. Killed it because the trigger condition (island collapsing right after a drop) barely ever happened in practice — turns out people just leave the island open after dropping files. Redesigning the trigger wasn't worth it for what the feature added, so it got fully reverted.

12
Next