A Jitsi Meet Mac app: calls in a window that stays put

Searching for a Jitsi Meet Mac app produces an unusually confusing set of results, and the confusion is not the searcher's fault. One result is a download page for a desktop application called Jitsi Desktop. Another is a GitHub project for a desktop application built with Electron. A third is an App Store listing, which is for phones and tablets. A fourth is the download page on the main Jitsi site, which lists mobile apps and server packages and does not obviously lead to a Mac build at all. Two of those are desktop software for a Mac, they are different products, and only one of them is the thing most people mean. This sorts out which is which, then covers the case where neither is the right answer and a window on the web version is.

Two Jitsi desktops, and they are not the same product

The older one is called Jitsi Desktop, and it lives on its own site. Its own description names secure audio and video calls, encrypted chat, desktop sharing and file transfer, and describes itself as working with an instant messaging network. The screen sharing section talks about showing a desktop to anyone with a video-capable XMPP or SIP client. It offers Windows, macOS and Linux packages, and mentions that a determined person can build it for FreeBSD.

That is a communicator in the older sense: an application that connects to chat and calling accounts on standards-based servers. It is not the software that runs a meet.jit.si room, and someone who downloads it expecting a meeting room will be confused twice, first by the interface and then by the absence of the room.

The one that runs Jitsi Meet rooms is a separate project, described plainly as a desktop application for Jitsi Meet built with Electron. It is published under the Apache License 2.0, the same license as the rest of the Jitsi codebase, and its releases carry date-style version numbers. The current release at the time of writing is 2026.8.0, published in August 2026, and its release notes describe bringing back remote control with a consent prompt shown in a translated native dialog.

The practical test is which address the meeting invitations use. A link to a room on meet.jit.si or on a company's own Jitsi deployment belongs to the second project. An account on an XMPP or SIP server belongs to the first.

What the official Meet desktop app provides

The project documents its own feature list, and it is worth reading before deciding whether a browser window would do the same job.

End-to-end encryption support is listed, marked as beta. The application works with any Jitsi Meet deployment, which matters for anyone whose meetings are on a self-hosted server rather than the public service. It has built-in automatic updates, screen sharing and remote control. It offers an always-on-top window, which is the feature no browser route matches. And it registers deep links, so an address written as jitsi-meet://myroom opens that room on the configured instance, while a fuller form naming a host opens a room on that specific deployment.

Downloads come from the project's releases page, and the macOS build is a single disk image file. That file is around 210 MB, which is normal for an Electron application and worth knowing before starting on a slow connection. There is also a zip archive of the same build. By contrast the Linux builds are split into separate x86_64 and arm64 packages, so the macOS side is one download for all supported Macs rather than a choice between chips.

For anyone who prefers a package manager, the project documents a Homebrew cask, installed with brew install --cask jitsi-meet. And the known issues section is short in a reassuring way: it notes that Windows shows an unsigned-application warning on first install, and for macOS it says none.

Why the download is hard to find

The Jitsi site's own download page explains the confusion. It opens by saying that Jitsi Desktop, Jitsi Meet and related projects can be downloaded there, and then what it actually lists is mobile applications for the App Store, Google Play and F-Droid, followed by self-hosting packages for Ubuntu and Debian in stable and nightly build lines, followed by a link to the free hosted meeting service.

That is a page written for two audiences, people who want the phone app and people who want to run a server, with the desktop application living on the project's releases page instead. Anyone starting from a search engine lands in the middle of that and reasonably concludes there is no Mac build.

One more thing about that page helps with the naming confusion. Its footer states that Jitsi is a trademark of 8x8, Inc., and the site also advertises a hosted commercial offering for organisations that want the same technology run for them. So the name covers an open source project, a free public meeting service, a commercial hosted product and two separate desktop applications. A search engine has no way to tell which of those a person means, which is why the results arrive mixed together and why sorting them out by hand is unavoidable.

There is a second consequence. Because the free hosted service is a website, and because it works well in a browser, a great many Jitsi users have never installed anything and have a browser tab where other people have an application. That tab is the thing worth improving, and improving it does not require choosing between the two desktop products.

Four ways to open a Jitsi room on a Mac

Route	Always on top	Auto-updates	Any deployment	Extra download
Browser tab	No	Nothing to update	Yes	None
The Electron desktop app	Yes, a listed feature	Built in	Yes, stated explicitly	About 210 MB
Safari, File then Add to Dock	Not among the documented settings	Follows Safari	Yes, per window	None
A site to app tool	Depends on the tool	Depends on the tool	Yes, per window	The tool itself

Apple documents the third row, and it requires macOS Sonoma 14 or later. In Safari, open the room or the deployment's front page, then choose File then Add to Dock from the menu bar, or use the Share button and choose Add to Dock. Type a name, click Add, and the result is saved to the Applications folder inside the home folder, openable from the Dock or Spotlight like any other application.

Apple also describes what makes that window different from a tab. A web app keeps browsing separate in the way a Safari profile does, and what happens inside it stays inside it. Its toolbar is streamlined, carrying a back button, a forward button, a Share button and buttons for installed Safari extensions, and the Share button includes an Open in Safari command for the moments when bookmarks or tabs are needed.

The fourth row is for people who need several of these at once, which in video calling is more common than it sounds. A personal room, a client's deployment and an internal server are three different hosts with three different sign-ins, and building each window by hand means repeating the same sequence and inventing names each time. Supported services lists the kinds of sites that most often end up handled this way.

When the browser window is the better answer

The desktop application is the right default for someone whose meetings are all on one deployment and who wants an always-on-top window during screen sharing. Three situations point the other way.

The first is several deployments. The application configures an instance, and deep links can name another host, but sessions and sign-ins are shared inside one application. Separate windows with separate sessions keep a client's server and an internal server from interfering with each other, which is the same reasoning that makes browser profiles useful.

The second is one standing room. Many Jitsi users have a single room address that a team uses every day. A window built on that exact address opens the room directly, with no room name to type and no chance of typing it differently and creating a second empty room. The application opens on a home screen; a web app window opens on the destination.

The third is control over what is installed. An application that updates itself is convenient until it changes during a busy week. A browser window inherits whatever the browser already does, adds no separate updater, and can be deleted by dragging it to the Trash from the Applications folder inside the home folder. On a managed Mac where installing software is a request rather than a decision, that difference is the whole conversation.

None of this is an argument against the official application. It is an argument for matching the route to the situation, and for knowing that the browser route is a real option rather than a fallback.

Setting the window up before the first call

Each web app has its own settings panel, opened by clicking its name in the menu bar and choosing Settings. Apple documents the fields: Application Name, Application URL with a Set to Current Page button, an Icon picker that accepts any image, Show navigation controls for the toolbar, Show color in title bar, a Privacy tab that can clear that site's data including cookies and caches, and an Extensions tab for enabling Safari extensions in that window alone.

Two of those are worth setting deliberately. Application URL should point at the room or the deployment's entry page, whichever is opened more often, and the Set to Current Page button means navigating there once and pressing a button rather than rebuilding. Application Name should say which deployment it is, because two identical Jitsi windows in the Dock are indistinguishable and joining the wrong organisation's server is an awkward way to start a morning.

Expect the first call from a new window to ask for camera and microphone access, and answer it in the window. A separate session is exactly what was asked for, and permissions granted in Safari earlier are part of what stays behind. The same applies to notifications: Apple states that the unread badge on a Dock icon requires responding to the site's notification request inside the web app rather than in Safari, after which the web app appears in System Settings under Notifications by its own name rather than the site's URL.

One interaction is worth planning for if both routes end up installed. The desktop application registers the deep link scheme, so an address in that form is handled by the application. A calendar invitation containing an ordinary web link, on the other hand, opens in whichever browser macOS is configured to use. Deciding which of the two is the daily surface, and building the other as a deliberate exception, prevents meetings from opening in the wrong place. The Guide covers how several of these windows behave once they coexist.

What to change first

Check which address the invitations actually use, then pick one route for it rather than keeping both. If the meetings are all on one deployment and screen sharing is frequent, install the official desktop application from its releases page and let it update itself. If there are two or more deployments, or one standing room that a team lives in, build a window on that exact address instead and name it after the deployment. Where several such windows have to exist and stay consistent, a tool such as Kagemusha makes them together rather than one menu sequence at a time.