Why almost no Mac app knows which document you have open

A note that shows up only when you are looking at the thing it belongs to sounds like a small feature. It took us longer than most of the rest of the app put together, and the reason is simple: macOS will not tell you what you are looking at.

We think this is the honest answer to a question we get fairly often, which is why Apple Stickies, or Notes, or any of the dozens of sticky note apps on the Mac do not already work this way. It is not an oversight. The information you would need is mostly not available, and where it is available, every app hands it over differently.

What the system actually gives you

Ask macOS what the user is doing and you get two useful facts. You get the frontmost application, and you get the title of its focused window. That is close to the end of the list.

"Which document is this window showing" is not a question the operating system answers. There is no general API for it. A window title is a hint, and often a bad one: it might be a file name, or a project name, or a subject line, or nothing at all. So a note that needs to attach to one specific spreadsheet tab rather than the whole app has to work out that spot on its own, per application, using whatever that particular app happens to expose.

Four tiers, decided by the app and not by us

We ended up classifying every integration on two questions. Can a note attach to the exact sub-document, meaning a browser tab, a document, a folder, a conversation, and hide and show as you move between them? And when you click that note later, can we take you straight back to that exact thing?

Depending on what an app exposes, the answers give four levels. At the top, notes follow the exact document and one click returns you to it, every time. Below that, scoping is just as precise but the jump back is best effort, landing you on the exact item most of the time and degrading gracefully when it cannot. Lower still, a note attaches to the window as a whole, which is honest but coarser. We publish which apps sit where, because pretending an integration is deeper than the app allows would only produce surprises later.

Browsers were supposed to be the easy case

A browser tab has a URL, and a URL means the same thing on any Mac, so browser notes should be the simplest thing we do. Safari and Chrome cooperate: ask over AppleScript and they hand back the active tab's URL.

Firefox does not implement that at all. There is no AppleScript route to the current URL. So for Firefox we read the address bar through the Accessibility API instead, the same interface a screen reader uses to describe the interface out loud. It arrives at the same answer by a considerably uglier path.

Messages, where we had to click a row like a person would

Messages has no AppleScript command to bring an existing conversation to the front. There is an imessage: URL scheme, which sounds like exactly the thing, except it opens a new message to that person rather than the thread you asked for.

So when we can resolve the conversation's address we deep link to it directly. When we cannot, we find the conversation's row in the sidebar and synthesize an actual mouse click on it. Asking the Accessibility API to press the row does nothing, because those rows are static text rather than buttons, and only buttons respond to being pressed. Group conversations are the weak spot and fall back to simply bringing Messages to the front.

The feature we shipped and then took back out

DaVinci Resolve keeps its projects in a database rather than as files on disk, so there is no path to store. Scoping still works, because the window title is the project name. Getting you back to a project was the hard half, and it needed Resolve's own Python scripting bridge.

We built that, and we shipped it. Then we found that the bridge's load call crashes Resolve if it has to switch away from a project with unsaved changes. Losing an editor's unsaved timeline to make a note slightly more convenient is not a trade we are willing to make on someone else's behalf, so we removed it. Resolve now comes to the front and switches to the right page, and you open the project yourself.

That moved DaVinci down a tier in our own documentation. We would rather publish the lower number than ship the crash.

A herd of Apple events will eat your CPU

Here is a bug worth passing on, because the shape of it is general.

Every note stuck to a browser was independently asking that browser for the URL it was showing. With ten notes on one window, that became ten separate requests for one single fact, fired in the same instant, every refresh cycle. On macOS 15 those calls are slow enough that the pile up turned into visible CPU use.

It is an ordinary cache stampede, the same thing that happens when a row of web servers all miss cache and hit the database at once, and it takes the ordinary fix. There is now one short lived cache per browser process with a single flight guard, so the first caller does the read and everyone else is handed the answer. It clears itself when the window title changes, since on a browser that means the tab changed and the cached answer is stale by definition.

The build that kept revoking its own permission

The other one cost us more time than it should have. TackNote needs Accessibility permission, because reading the focused window is the entire mechanism. During development, that permission kept disappearing, and it had to be granted again before every single test run.

macOS ties that grant to the app's code signature. Signing ad hoc produces a new code hash on every build, so the system saw a different application each time and dropped the permission accordingly. The grant was keyed to content when it needed to be keyed to identity. Signing development builds with a stable identity keeps the signature's designated requirement constant across rebuilds, and the permission stays put. Released builds are signed and notarized as normal.

Why this is most of the product

There is no general answer to "what is this window showing," which means there is no shortcut. Every application is its own small research problem, its own workaround, and its own set of edges to be honest about. That is why so few apps do this, and it is most of what we have been building.

What you get from it is narrow and, we think, worth it: a note that is present when the thing it concerns is in front of you, and out of the way the rest of the time.