BandLab on a Mac: recording in a window of its own

Searching for "bandlab mac" usually ends in a moment of confusion. The App Store listing is for iPhone and iPad. The Google Play listing is for Android. The download button on the site offers an APK. Nothing on the page says "for macOS", and yet the Studio clearly runs on a Mac, because it is running right now in a browser tab. The question is not whether it works. The question is what to do about the fact that a recording session now lives in the same window as email, a support ticket and nine other tabs.

That is a real problem, not a cosmetic one. A digital audio workstation expects the whole keyboard. A browser has other plans for it.

What BandLab actually ships, and for which platforms

The Studio is a web application. The site describes it as a fully functional DAW available in a pocket or through the browser, and the platform links point to the iOS App Store, Google Play and a direct Android APK. There is no separate macOS installer in that list. On a Mac, the browser is the product, not a stopgap while a native version is in the works.

The cost of entry is zero:

No boundaries to your creativity with unlimited multi-track projects and free cloud storage. Source: bandlab.com

The free Studio covers multi-track recording, mixing and collaboration, with projects stored in the account rather than on the local disk. Collaboration is a headline feature, with up to 50 people able to work on a single project. Paid Membership sits above that and adds a 32-track Studio, a set of AI tools including Voice Cleaner, Voice Changer, AutoMix and Audio-to-MIDI, additional mastering presets, an upgraded Splitter, Visual EQ, distribution to streaming platforms and a verified profile badge. Membership also opens early access to Cakewalk Next and Cakewalk Sonar, which are desktop applications of their own and a separate decision from anything described here.

The practical point for a Mac owner is narrower than any of that. Every tier of the Studio, free or paid, opens in a browser. So the only thing a Mac user can still change is which window the browser puts it in, and that turns out to matter more than it sounds.

What a browser tab costs during a session

A DAW and a browser want the same keys. Space is transport in one and page scroll in the other. Command plus S is save in one and save page in the other. Command plus W is close tab in the browser, and it sits one key away from Command plus Q. A web DAW handles most of this by capturing keystrokes itself, but the browser keeps the outer layer, and that outer layer is where the accidents happen.

Three failure modes show up repeatedly in a browser based session.

The first is the accidental close. A project that autosaves to the cloud survives a closed tab, but a take in progress and an undo history do not necessarily survive it. One misfired keystroke ends the session state even when it does not end the project.

The second is competition for resources. Audio work is latency sensitive. A browser window holding a video call, a streaming site and a heavy dashboard in neighbouring tabs is sharing a process tree with the thing trying to keep a metronome steady. The Studio does not get a private lane just because it is the tab in front.

The third is retrieval. A session is not one visit. It is thirty short visits over a week, and each one starts with hunting for the right tab. That cost is small and constant, which is exactly the kind that never gets measured.

None of these are faults in the Studio. They are properties of running a workstation inside a document viewer.

Where the audio input is actually decided

A web DAW does not talk to an audio interface directly. It asks the browser, the browser asks macOS, and macOS hands over whichever input device it has been told to hand over. That chain has three places to look when a guitar interface or a USB microphone does not show up, and only one of them is inside the Studio.

The first is the macOS privacy setting for microphone access, granted per application. The application in question is the browser, not the site. The second is the browser's own site permission, granted per site and per profile, which is also where a specific input device can be chosen when more than one is attached. The third is the input selector inside the Studio, which can only offer what the two layers above it have already allowed through.

This is the part that changes when a session moves into a standalone window. The new window is a separate profile, so the second layer resets. The permission prompt returns once, the device is selected once, and after that the app keeps its own answer. That is a small one time cost, and it buys something useful: the audio input choice for the session stops being shared with every other site that ever asked for a microphone.

Sample rate and buffer behaviour stay where they always were, under the control of macOS and the interface driver rather than the page. Changing browsers or moving to a wrapped window does not change them, which is worth knowing before blaming the window for a latency problem that belongs to the hardware chain.

Cloud projects change what a closed window means

Projects live in the account rather than on the local disk, which is the reason a closed tab is survivable at all. It also shifts where the risks sit. A local DAW loses work when the disk fails and keeps working when the network drops. A cloud DAW inverts both.

Two habits follow from that. The first is treating network interruption as a session event rather than a background annoyance, because an upload that does not complete is a take that is not stored. The second is exporting finished work rather than leaving every version only in the account, particularly for anything that will be needed after the project stops being active.

Collaboration works on the same foundation. A project shared with up to 50 people is a shared server side object, so every participant sees changes against the same copy. That is a genuine advantage over passing files around, and it is also a reason to keep the account boundary clean. Anyone who records under both a personal identity and a band or client identity has a real need for two signed in sessions at once, and a browser with one profile cannot provide it.

The three ways to open it on a Mac

There are only three real options, and they differ in what they isolate.

Route	Runs in	Isolated from other tabs	Own Dock icon	Cost
Ordinary browser tab	Main browser window	No	No	Free
Pinned or separate browser window	Main browser	Partly	No	Free
Standalone app built by a site to app tool	Its own window and profile	Yes	Yes	Free tier available

A pinned tab solves retrieval and nothing else. It is still the same window, the same profile and the same keyboard conflicts. It is worth doing if the answer stops there.

The third route is what most people are actually looking for when they search for a Mac app. A tool that turns a website into a standalone Mac app wraps the same URL in its own window, gives it a Dock icon, and lets the tab bar and address bar be switched off entirely. The result is not a native rewrite of the Studio. It is the same web application with the browser furniture removed and a boundary drawn around it. For a service that never shipped a Mac build, that boundary is the whole improvement available.

What changes once it has its own window

Removing the tab bar removes the thing that was one keystroke from destroying a take. With no other tabs in the window, Command plus W has nothing to close but the app itself, and the session stops competing for attention with a shopping cart.

A separate profile is the second half. These tools keep cookies and login state per app, which has two consequences worth planning for. A microphone or audio input permission granted in the main browser does not carry over, so the first launch will ask again, once. In exchange, a second account becomes possible without logging anything out. Anyone who keeps a personal account and a project or band account separate gets both open at the same time, in two windows, with no switching.

Extensions still work in this arrangement, which is not obvious. Because the app runs on an installed browser engine rather than a stripped down runtime, Chrome Web Store extensions can be loaded into it. That matters less for a DAW than for a reading app, but it does mean an ad blocker or a password manager is available if wanted. The Guide walks through the per app settings that control the tab bar, the address bar, notifications and window behaviour, which is where most of the tuning happens.

One more detail is worth knowing before committing. These tools generally point at the real browser binary through a symlink rather than bundling a copy, so when the browser updates, the app follows. That avoids the slow decay that used to affect this whole category, where a wrapper built on an old engine gradually stopped rendering modern sites correctly.

Whether the Studio is the right candidate

Not every site deserves its own icon. The test that holds up is frequency multiplied by focus. A site opened many times a day in passing does not need a window. A site that gets opened less often but demands full attention while it is open does.

A DAW is the clearest case in the second category. So is a video editor, a design tool, a writing environment and an administrative console for something in production. All of them want the keyboard and none of them want neighbours.

Applied honestly, that test usually produces a short list, not a long one. Three or four apps covers most people, which is why the free tier of tools in this category tends to cap at a small number of apps rather than a small number of features. The published free tier allows three apps with no feature restrictions, and the paid upgrade is a one time $24.99 rather than a subscription, with a stated requirement of macOS 12 or later. Checking the Pricing section before building anything is the sensible order, because the free three may well be enough.

The other thing worth doing early is checking whether the service is already recognised. Tools in this category ship preset lists covering several hundred common services, with icons and URLs already filled in, and the Supported services list shows what is included. A service that is absent is still buildable from a custom URL, so absence costs a minute of setup rather than blocking anything.

What to change first

Open the Studio in its own window before changing anything else, and keep the browser out of it for one full session. If the accidental closes stop and the session becomes easier to return to, the same treatment is worth extending to the next two candidates on the frequency and focus list. Kagemusha builds those windows from a preset or a plain URL, and the free tier covers three of them.