Droppy started with one small annoyance: moving a file between two windows should not require a careful drag across half the screen. The notch was sitting above the work, unused, so I turned it into a place where a file could wait.
The app grew from there. Clipboard history, media controls, timers, alerts, and optional Droplets all use the same bit of screen. Growth makes a product useful, but it also makes it easy to lose the original idea. These are the rules I use when deciding what belongs in Droppy and what gets cut.
1. Start with friction, not a feature list
I do not begin with “what can the notch show?” That question produces demos. I begin with a repeated interruption: a file has nowhere to wait, a copied address has vanished, a music control is hidden behind another window, or a timer needs attention without becoming a notification.
A feature earns its place when it removes steps from a real task. The file shelf is the clearest example. Drag a file to the top, let go, and pick it up later. It preserves the physical idea of putting something down. Apple’s current Human Interface Guidelines make the same case in broader terms: start with purpose, keep people in control, and remove what is not necessary.
2. Treat the notch as a place
The notch is hardware, but people already understand it as a landmark. It stays in the same position, sits outside most content, and is easy to reach with a pointer. That makes it useful even when the screen has no physical cutout. On an iMac or external display, Droppy draws the same small top-center island so the interaction does not move.
That consistency matters more than the shape. Apple’s guidance for designing for macOS stresses predictable placement, keyboard support, precise pointer input, and respecting the way people arrange their displays. Droppy should feel like Mac software first and a notch app second.
Motion stays quiet by default and only moves to show cause and effect, preserve context, or confirm an action.
The app follows Mac expectations, so keyboard shortcuts, familiar menus, real dragging, and accessibility all just work.
The notch is one place, where the file shelf, clipboard history, media controls, and timers share the same bit of screen.
Put a file down at the top of the screen and pick it up later, with private work kept local until you choose to share.
Four of the tests a feature has to pass before it becomes part of Droppy.
3. Keep the common path immediate
A shelf should open when a file reaches it. Clipboard history should be ready when it is summoned. Media controls should not need a setup wizard. The main action needs one obvious route, with advanced controls nearby but never in the way.
This is also why Droplets are optional. A terminal, voice transcription, or window snapping can be valuable without belonging in everyone’s interface. Turning an extension on is a deliberate choice. Until then, it takes no room.
4. Keep private work on the Mac
A clipboard manager sees sensitive material. A file shelf holds documents before they reach their destination. The primary path for both is local. Clipboard entries stay on the device, and concealed or transient pasteboard types are skipped. Cloud sharing only begins when someone explicitly asks Droppy to upload a file and create a link.
Permissions follow the same rule: ask at the point a feature needs them, explain why, and leave unrelated features working without them. Apple’s design principles call this responsibility. I think of it more simply: the app should never be surprising about someone’s data.
5. Motion must explain something
The notch opens because an item is arriving. A timer contracts into a compact state because the task is still running. A volume slider emerges from the place that now owns that feedback. Motion should preserve context, show cause and effect, or confirm an action. If it only decorates a pause, it goes.
Droppy also needs to respect Reduce Motion. Apple documents the macOS setting through AppKit’s accessibility APIs and recommends avoiding large spatial animation when it is enabled. A polished animation is not polished if someone has asked the system not to show it.
6. Use native behavior as the baseline
Native does not mean every surface must look like a stock settings panel. It means the app follows Mac expectations: keyboard shortcuts work, menus use familiar language, dragging behaves like dragging, controls expose useful accessibility information, and the app remains quick when it is not visible.
Standard AppKit controls bring accessibility behavior with them by default, which Apple explains in its AppKit accessibility documentation. Custom surfaces still need the same care. The notch may be unusual, but the interaction around it should not require relearning the Mac.
7. Charge once, then keep earning it
Droppy is a one-time $6.99 purchase with lifetime updates. I chose that because the app is a utility, not a stream of rented content. A subscription would make the business more predictable, but it would make the product feel less honest to me.
One-time pricing does not mean finished software. It creates a harder promise: keep the app working across macOS releases and keep improving it without turning every new idea into another checkout. The public changelog is where that promise becomes visible.
The test before shipping
Before I add anything, I ask seven questions:
- What repeated friction disappears?
- Is the top of the screen the right place for it?
- Can the common action stay immediate?
- Can the private path remain local?
- Does every animation explain a change?
- Will it behave like good Mac software?
- Does it improve the product people already bought?
A feature does not need seven perfect answers, but weak answers should be obvious. That is the point of principles. They make saying no easier, and a focused no is often the thing that keeps a useful app useful.