How to share multiple apps without sharing your full screen

To share multiple apps without sharing your full screen, use native multi-app selection when your meeting tool supports it, or compose approved apps into one audience window. Share a single tab or window when the entire task can stay there.

The right choice depends on what must change during the call. A fixed slide deck needs a smaller boundary than a product demo that moves from browser to terminal, editor, and support dashboard.

Choose the smallest share boundary that still supports the job

There are four practical Mac workflows:

Workflow	Switch across apps	Handles a new work window	Keeps private apps out	Distinguishes Chrome profiles	Stable meeting share target
Share one tab or window	No	Usually requires a new share	Yes, outside the chosen surface	Only by choosing the correct tab or window	Yes until you re-share
Select multiple apps in Zoom	Yes, among selected apps	May require updating the selection	Yes, if selection stays correct	Not at the app-identity level	Zoom-specific
Share a portion of the screen	Yes, inside the region	Yes, if moved into the region	Only outside the region	No	Yes, but the region is positional
Share ScreenK9 Audience View	Yes, among approved sources	Yes, when it satisfies the active profile	Yes, for the audience window	Yes, for fresh and unique Work matches	Yes across window-sharing tools

No option is universally best. The useful rule is: choose one native surface for a fixed task, and use a controlled audience surface for a dynamic multi-app task.

Option 1: share one tab or one window

This is the simplest and often safest native answer. Google Meet lets presenters choose a tab, a window, or the entire screen. Meet can also switch the presented Chrome tab through its sharing banner.

Use a single tab or window when:

the presentation stays in one deck, document, dashboard, or browser tab;
you do not need to show a second application;
the chosen window does not contain other private tabs or account controls you may open;
you are comfortable changing the share target if the workflow expands.

This method is not a failure to use a more sophisticated privacy tool. It is the correct minimal boundary when one surface is enough.

Option 2: select several application windows in Zoom

Zoom's current macOS instructions document sharing one or more specific applications. In the Screens picker, hold Shift to select more than one application window.

This is useful when the call is in Zoom and the set of windows is known before you begin. The audience receives the selected applications instead of the entire desktop.

Check three details before relying on it:

Select the exact windows, not merely the application names you remember.
Test whether a new document or browser window becomes visible or requires reselection.
Confirm that private Chrome and client contexts are not among the selected windows.

Zoom notes that some sharing options can depend on administrator settings. Other meeting tools do not necessarily offer the same multi-selection control, so this is a Zoom workflow rather than a universal Mac workflow.

Option 3: share a portion of the screen

Zoom also documents a resizable portion-of-screen share. A fixed region can work well for a visual comparison or a controlled canvas: move the approved windows into the bordered area and keep everything else outside it.

The privacy boundary is positional, not semantic. If Slack, a personal browser, or a notification moves into the region, it can enter the share. If an approved dialog opens outside it, the audience may miss it.

Use a region when the layout is stable and spatial control is the point. Avoid it for a fast product demo that constantly opens new windows or changes arrangements.

Option 4: give the meeting one audience window

A separate audience window reverses the relationship. Instead of placing windows inside a physical rectangle, you decide which applications and browser identities are eligible for a composed output.

ScreenK9 uses Apple's public ScreenCaptureKit capture model to receive filtered frames and render them into ScreenK9 — Audience View. You then share that ordinary window in Zoom, Meet, Teams, Loom, or OBS.

This workflow is useful when:

the call moves among several approved applications;
the presenter must keep private apps available on the real desktop;
different Chrome profiles carry different client or personal identities;
the meeting or recording tool can share a window but lacks the same multi-app picker;
you want the selected meeting share target to remain stable while the approved source changes.

ScreenK9 does not inject into, intercept, or modify meeting traffic. It controls only the audience window it creates. If you select a physical display directly in the meeting tool, that display bypasses ScreenK9.

Configure a multi-app ScreenK9 profile

Start from what the audience is allowed to see, not from a long list of private things to remember.

Create or choose an Allow only profile.
Approve the applications required by the demo—perhaps Chrome, Terminal, an editor, and a deck.
In each Chrome profile, label the context Work, Personal, or Unclassified.
Add user-defined redaction regions for stable private areas when needed.
Start the capture and wait for a complete frame in ScreenK9 — Audience View.
Rehearse app switches, file pickers, links that open new windows, and Chrome-profile changes while watching that view.
Share ScreenK9 — Audience View in the meeting tool.

At the macOS application layer, all Chrome profiles look like Chrome. ScreenK9 therefore excludes Chrome first and adds back only a fresh, uniquely matched window from a profile labelled Work. Personal, Unclassified, stale, or ambiguous Chrome matches remain hidden. The companion workflow is explained in how to keep Chrome profiles private during screen sharing.

Plan for new windows and uncertain states

A good multi-app workflow has an explicit recovery state. ScreenK9 holds a protected placeholder while capture starts and returns to it if the stream stalls or privacy state becomes uncertain.

That conservative behavior can briefly interrupt a demo. It is preferable to guessing that a stale or ambiguous frame is safe. If a required window does not appear:

keep the placeholder visible;
check that the application is approved;
confirm the intended Chrome profile is Work and reporting a fresh state;
resolve duplicate or ambiguous window titles;
verify the audience window again before continuing.

Redaction regions have their own boundary. They are user-positioned overlays, not OCR, automatic secret detection, or a guarantee that a moving interface stays covered. Test them against the exact layout used in the call.

Use this decision rule before the call

One fixed surface: share one tab or one window natively.
Several known windows in Zoom: test Zoom's multi-app selection.
A stable visual canvas: consider a screen portion.
A dynamic workflow across approved apps or Chrome identities: share a verified audience window.

Whichever route you choose, watch the audience preview while performing the riskiest transition—not just the opening slide. For ScreenK9's local data and permission boundary, read the privacy model. If the audience-window workflow fits your demos, download the free Mac beta for Apple silicon Macs running macOS 14 or newer.

Sources checked

Platform documentation and ScreenK9 public-beta behavior were rechecked on August 28, 2026.