---
title: How a Mac window stays off a screen share
description: macOS gives every window a sharing property. Set it to none and the window server leaves that window out of screenshots, recordings and shared screens.
date: 2026-09-21
tags: [macos, privacy, swift]
image: https://ik.imagekit.io/somanshu/HushNotes/shot-desk-on-screen-share.png
related: [hide-notes-from-screen-sharing-mac, floating-notes-mac]
---

A window on macOS can decline to appear in a screen share. No trick of layering is involved and
nothing is cropped after the fact. Every window on your Mac carries a sharing property, and when
the app that owns a window sets that property to none, the part of the system that assembles your
desktop leaves the window out of the picture it hands to anything capturing the screen. The window
stays on your display, exactly where you put it. It is simply absent from the stream.

That is the answer in full. What follows is how the mechanism works, how it differs from the
workarounds people reach for first, and where its edges are, because a privacy measure you do not
understand is one you will misuse on the call that matters.

## Your Mac draws two pictures

It helps to stop thinking of a screen capture as a photograph of your display.

On macOS a single system process composites every window into the image you see. Your apps do not
draw to the screen directly. They draw their own windows, hand them over, and the compositor
decides what sits in front of what, with which shadow, at what scale, on which display. What you
are looking at is a picture assembled for you.

When something asks to capture the screen, that same compositor assembles a second picture. It is
built from the same windows at the same moment, for a different audience: the screenshot key, a
screen recording, or a conferencing app that has been granted Screen Recording permission in
System Settings. Most of the time the two pictures are identical, which is exactly why it is easy
to forget there are two of them at all.

The sharing property is how a window says which of the two it belongs in.

Because the decision happens during compositing, nothing downstream has to cooperate. The
conferencing app is not asked to filter anything and could not decline, because the frames it
receives never contained the window in the first place. There is no visible hole either. The
windows behind the hidden one composite normally, so the far side sees an ordinary desktop rather
than a desktop with something conspicuously removed.

## The property every window carries

In AppKit the property is `sharingType` on `NSWindow`, and it takes one of three values.

| Value | What a capture sees | Where you meet it |
| --- | --- | --- |
| `.readOnly` | The window, composited normally | The default. Every window starts here unless its app says otherwise |
| `.none` | Nothing. The window is skipped entirely | Notes, credentials, anything you would not mirror |
| `.readWrite` | The window, and historically also open to being driven by another process | Deprecated on current macOS. Not a value to reach for |

Two things about this are worth holding on to.

The first is that no permission is involved. An app asks you for nothing to set it, there is no
entitlement to request, and no prompt appears. That sounds alarming until you notice which
direction it runs in. The property only ever removes the app's own window from a capture. It
cannot touch anyone else's window, it cannot read the capture, and it cannot stop a capture from
happening. It is a window declining to be included, not an app reaching outward.

The second is that it belongs to a window and not to an app. A window created later starts at the
default like any other. An app that wants a consistent policy has to apply it to everything it
owns, including the things you do not picture as windows: panels, popovers, alerts, and the small
confirmation that appears for a second and disappears.

### If you build Mac apps

One line, on each window you own.

```swift
// The compositor stops including this window in any capture stream.
window.sharingType = .none
```

Set it where the window is made, so there is no frame in which the window exists at the default.
If the policy is something a person can toggle in your settings, apply the new value to every
window the app already has open rather than only to windows created afterwards. A toggle that
quietly skips the windows that existed before you flipped it is worse than no toggle at all,
because it teaches people to trust something that is only partly true.

## How this differs from the usual workarounds

### Cropping or region sharing

Several conferencing and streaming tools let you share a rectangle instead of a display. The crop
is applied by that tool, to a stream that already contains everything on your screen. This holds
until the geometry moves. A window you drag, a system alert placed wherever the system likes, a
display you unplug, a resolution change: any of those can put something inside the rectangle that
you meant to keep outside it. A crop also places the whole burden on the piece of software
furthest from the system.

### Sharing one window instead of a display

This is a real answer and often the right one. What it costs is movement. The share follows one
window, so switching apps mid call either shows the far side nothing useful or forces you to
change what you are sharing while people watch.
[What the other side sees](/blog/what-the-other-side-sees-when-you-share-your-mac-screen/) walks
through each sharing mode and what it leaks.

### A second display

Solid, as long as the discipline holds. The private material lives on a display you never share
and never mirror. The failure mode is arrangement rather than software: mirroring turned on for a
demo, a different desk with a different setup, or a window that opens on the wrong screen because
that is where you left it last week.

### Closing everything first

Free, and more reliable than it gets credit for. It depends on two things. You have to remember
every time, and nothing can arrive during the call. Notifications are the usual leak here, and
they are worth handling on their own terms whatever else you do.

The sharing property differs from all four because it needs no choreography at the moment it
matters. Nothing has to be closed, moved, cropped, or remembered while people are watching.

## What it protects, and what it does not

Be precise about the boundary. The property governs what the system composites into a capture. It
has nothing to say about anything outside that path.

- A camera pointed at your display sees everything. A phone held up, a photograph of a monitor, a
  person standing behind you in a shared office: none of that goes anywhere near the compositor.
- The window has to be a real window. Content drawn inside another app's window, a browser tab, or
  a panel hosted by something else belongs to a window that its own app does not own and cannot
  set this on.
- The menu bar is the honest exception. A status item lives in a window the framework owns, and
  that window will accept the property and carry on drawing into captures regardless. When you
  share a whole display the menu bar is in the shot anyway, so the useful question is what your
  menu bar items are showing rather than whether they are visible.
- It is Apple's mechanism rather than ours, so treat it as a strong privacy measure and not a
  guarantee, and check it against your own setup before a call that matters.

That last point is not a disclaimer for its own sake. Capture on macOS has more than one path
through it, conferencing apps update on their own schedules, and the only setup whose behaviour
you actually need to know is the one in front of you.

## Checking it yourself, in about two minutes

The screenshot key is the fastest honest test, because a screenshot travels the same capture path
a share does.

1. Put the window somewhere obvious on the display you plan to share.
2. Press ⇧⌘3 for a full screen capture, or ⇧⌘5 and choose to capture the entire screen.
3. Open the file that lands on your desktop. If the window is not in it, the property is in force
   on that display.
4. Repeat with a screen recording from the ⇧⌘5 toolbar. A still and a recording are both captures,
   and watching both come back clean is more convincing than assuming the second from the first.

Then run the test that actually counts. Start a meeting on the service you will use, join it from
a phone or a second computer, and share exactly what you intend to share on the day, in the same
mode: one window, or a whole display, or a browser tab. Look at the far side with your own eyes.
Do that once per service, and again after any large update to it, and you will know rather than
hope. If you use several services, they are worth checking separately, since each one decides for
itself how it asks macOS for the screen.

## Where HushNotes comes in

HushNotes is a menu bar notes app, and every note window it opens sets this property. It is on by
default, needs no permission, and requests none. Flipping the toggle in Settings re-applies the
policy to every window the app already owns rather than only to the next one it makes.

![A desk with a document, as a screen share sees it, with the notes absent](https://ik.imagekit.io/somanshu/HushNotes/shot-desk-on-screen-share.png?tr=w-1200,f-auto)

The menu bar icon is the disclosed exception described above. It holds a 20pt icon and no note
content, and macOS keeps it visible. One consequence is worth knowing before it surprises you: the
same property that keeps a note off a call keeps it out of your own screenshots, so turn the
toggle off for a moment when you want to capture your own notes.

If invisibility on a call is not the whole problem, because the person you are thinking about is
sitting at your desk rather than watching a stream, that is a different layer. Any note can be
locked behind Touch ID, with its body encrypted at rest while its title stays searchable, so a
locked note is still a note you can find.

## Read next

- [What the other side sees when you share your Mac screen](/blog/what-the-other-side-sees-when-you-share-your-mac-screen/), a pre-call audit covering notifications, the menu bar, Spaces and second displays.
- [How to take notes during a call without anyone seeing](/blog/how-to-take-notes-during-a-call-without-anyone-seeing/), which weighs this approach against presenter view, a second monitor and paper.
- The feature page for [screen-share privacy](/hide-notes-from-screen-sharing-mac/) shows one desk captured twice, once as its owner sees it and once as a share sees it, and [floating notes](/floating-notes-mac/) covers the windows themselves.