Descript desktop app or the web version: what to open on a Mac

Searching for the Descript desktop app usually means one of two things. Either the installer is about to be downloaded and the question is whether it is worth the disk space, or it has already been installed, it now opens by itself every time the Mac starts, and the question has quietly become how to get rid of that. Both questions have the same missing piece: Descript also runs as a full editor inside a browser, and the browser route has one restriction that decides everything about how it should be set up on a Mac.

What Descript actually ships for macOS

The download page offers two things and states one requirement: macOS 14 (Sonoma) or Windows 11 and newer. On the Mac side there is a single installer, delivered as a .zip that unpacks to an application which gets dragged into the Applications folder.

The system requirements page is more specific. The minimum is 8 GB of RAM and macOS 14 or later. The recommendation is considerably higher: 16 GB of unified memory on Apple silicon, or 16 GB for HD work and 32 GB for 4K on Intel, plus 20 to 40 GB of free space, on an Intel 7th generation CPU or newer, or Apple silicon M1 or later. The same page lists the macOS permissions the desktop app needs enabled in System Settings, namely Camera, Microphone and Screen Recording.

That last line is the honest argument for the desktop app. Screen recording on macOS is a system level permission, and an application holding it can put a recorder in the menu bar that is ready before there is anything to record. A browser tab cannot offer that in the same way.

The second thing Descript ships is easy to miss because it has no installer at all.

Run the full Descript editor in a browser tab, no install required. Source: help.descript.com

Descript for Web is reached by signing in at web.descript.com. The documentation describes recording, editing and publishing inside the browser, which places it well beyond a viewer or a light companion.

The restriction that decides the whole setup

Descript for Web is documented as working best on Chromium based browsers, and the list given is Google Chrome, Microsoft Edge and Opera. Firefox and Internet Explorer are named as unsupported. Safari is named as possibly partially working, which is a different statement from supported. The same page notes that Descript is not designed for small mobile screens or tablets.

For a Mac, that single line rules out the route most people reach for first.

Since macOS Sonoma 14, Safari can turn any page into a standalone application through File then Add to Dock. It is free, it takes two clicks, and the result behaves like a real application.

A web app functions independently of Safari. It shares no browsing history, cookies, website data, or settings with Safari. Source: support.apple.com

The problem is the engine underneath. A window made that way runs on WebKit, because it is Safari without the browser furniture. Pointing it at web.descript.com puts the editor in exactly the browser Descript declines to support. Nothing visibly breaks on the first screen, which is what makes this a trap worth naming: the failure shows up later, in a codec, a recording permission, or an export, at the point where a deadline is involved.

So on a Mac there are three honest options rather than two. The desktop app. A Chromium window. A plain Chromium tab.

Chrome's route, and the profile it drags along

Chrome installs a page as an application from the three dot menu, then Cast, save, and share, then Install page as app. Installed items are listed at chrome://apps.

A web app is an app built for the web that you can access on any device. Source: support.google.com

This is the correct engine for Descript for Web, and for a single account it is genuinely enough. The limit is the unit of separation. A window created from a Chrome profile signs in as whatever account that profile holds, and it keeps sharing that session afterwards. Two Descript logins therefore means two Chrome profiles before anything else happens, and switching between profiles in Chrome is a window level action rather than a per app one.

That matters more in editing work than in most categories, because Descript charges by the seat and each plan includes a set number of them. A freelance editor invited into a client's drive is signing into a second account, not a second project. Two accounts held open at once is the normal state of that job, not an edge case. A tool that turns a website into a standalone Mac app handles this by giving every app its own isolated profile, so both stay signed in with their own icon in the Dock, and the general shape of that approach is covered on the Features page.

Why the desktop app pushes some people back to the browser

There is one behaviour of the installed app that sends a steady trickle of people looking for alternatives, and it is documented rather than a bug.

Descript opens automatically when you sign in to your computer, this keeps the menu bar (Mac) or taskbar (Windows) Screen Recorder available whenever you need it. Source: help.descript.com

The reasoning is sound and the switch is easy to find: the Descript icon in the menu bar, then Settings, then turn off Launch at login. It is worth knowing that turning it off is also the moment the menu bar recorder stops being the always ready thing it was designed to be.

The recommended specification is the other reason. A video editor that recommends 16 GB of unified memory and 20 to 40 GB of free space is not a background application. On a 256 GB MacBook Air shared with Xcode, a photo library and a few other creative tools, that recommendation is a real decision rather than a footnote. Running the editor in a Chromium window shifts the heavy work to servers and the browser engine already installed, which is why the web route gets chosen on smaller machines even by people who prefer native applications in general.

The four routes, side by side

Route	Engine	Supported for Descript for Web	Dock and Cmd+Tab	Separate session per window	Menu bar screen recorder
Desktop app	Native	Not applicable	Yes	One account at a time	Yes
Chromium tab	Chromium	Yes	No	No	No
Chrome, install page as app	Chromium	Yes	Yes	Follows the Chrome profile	No
Safari, Add to Dock	WebKit	Not supported	Yes	Yes	No
Site to app tool on a Chromium engine	Chromium	Yes	Yes	Yes, per app	No

The table makes the shape of the decision clear. Recording is the desktop app's column. Separation is the window's column. Anyone whose work is mostly assembling and publishing footage captured elsewhere, on a phone, on a camera, or by a guest in a call, spends very little time in the recorder and a lot of time in the editor, and the columns fall the other way.

What the plan limits say about how many windows are needed

The numbers are worth reading as a signal about accounts rather than as a shopping list, because the account count is what decides the window count.

Media minutes are counted per editor: 60 minutes a month on Free, 600 minutes on Hobbyist, 1,800 on Creator, 2,400 on Business. AI credits follow the same per editor pattern, 100 one time on Free, then 400, 800 and 1,500 a month. Local video export is capped at 720p on Free with a watermark, 1080p on Hobbyist, and 4K on Creator and Business. Upload file size runs 1 GB, 10 GB, 20 GB, 50 GB across the four. Cloud storage runs 5 GB, 100 GB, 1 TB, 2 TB.

Prices are quoted per person per month. Hobbyist is $24 billed monthly or $16 per month billed annually, Creator is $35 or $24, Business is $65 or $50, and Enterprise is quoted. Seats included are one, one, one to three, and up to five.

Read the seat line next to the media minutes line and the pattern appears. Nothing scales by volume alone: a heavier month is bought with credits and minutes on the same login. What forces a second login is a second organisation. That is why the question of one window or several has almost nothing to do with which plan is chosen and almost everything to do with how many drives a person is invited into. A single Creator account needs one window. An editor serving three clients on their own plans needs three, and the reason is that a browser holds one session per site per profile.

Anyone weighing this against the other services already parked in tabs will find the common ones grouped on the Supported services page.

What to check in the first week

Five checks catch nearly everything, and a week is the right length because most of what fails is periodic rather than immediate.

Sign in survival comes first. Restart the Mac, then let a macOS update through, and confirm the window still opens signed in rather than at a login screen.

Second, permissions. Camera, microphone and screen recording are granted to the container, so a Chromium window asks for them on its own behalf rather than inheriting whatever the browser was already allowed. Record ten seconds inside the new window on day one and the answer is settled.

Third, a large import. File size limits differ by plan, and a 4 GB clip on a plan capped at 1 GB fails at the worst moment. Push one realistic file through rather than a test clip.

Fourth, export. Run both a local export and a shareable link export once, because the resolution ceiling and the web link duration limit are separate numbers on the same plan.

Fifth, the second account, if there is one. Open both windows at the same time and confirm neither signs the other out. That single test is what the whole separation argument rests on, and it takes under a minute.

The build steps for a window of this kind, including how the name, icon and starting URL get set, are laid out in the Guide.

What a window does not fix

Three things stay exactly as they were, and saying so is more useful than pretending otherwise.

Availability is the first. The system requirements page notes that Descript may not be available in certain countries or regions, tied to payment processor restrictions. A window is a container, not a workaround, and nothing about how the editor is opened changes that.

Upload time is the second. The heavy part of working in the browser is getting media to the servers, and that is a function of the connection rather than the container. A 20 GB file takes the same time from a window as from a tab. The one thing a window does change is what happens while the upload runs, because the upload no longer sits in a tab that gets closed during a tidy up.

Local disk pressure is the third, in the opposite direction from what people expect. Choosing the browser route avoids the 20 to 40 GB the installed app recommends, but recorded and imported media still lands on the Mac before it goes anywhere. The saving is real and it is smaller than the difference between the two installers suggests.

What a window genuinely changes is narrow and worth having: a fixed position in the Dock, an entry in Cmd+Tab and Spotlight, a session that survives a browser restart, and an account boundary that holds without signing anything out.

What to change first

If the work involves recording the screen often, install the desktop app and accept it as a real application, then turn off Launch at login only after the menu bar recorder has stopped being useful. If the work is mostly editing footage captured elsewhere, skip the installer, open web.descript.com in a Chromium browser, and give it a window of its own rather than a tab. For more than one Descript login, a purpose built Kagemusha app per account is what keeps both signed in at once.