Launched this week
Islet
iPhone's Dynamic Island, brought to your Mac's notch
148 followers
iPhone's Dynamic Island, brought to your Mac's notch
148 followers
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.
Islet
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?
Islet
@omri_ben_shoham1 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.
Islet
@thys_beesman 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.
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
Islet
@galdayan 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.
@lippi304 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.
Islet
@leo404 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.
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?
Islet
@artstavenka1 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.
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?
Islet
@terminal_candy 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.