A Mastodon Mac app: your timeline in a window of its own

Searching for a Mastodon Mac app returns more options than almost any other service, which is the opposite of the usual problem. There is an official application, there are a dozen third party clients, several of them excellent, and there is a web interface that the project itself puts forward as a legitimate desktop home. The difficulty is not scarcity. It is that these three routes are not interchangeable, and the comparison articles tend to cover one of them and skip the other two.

Three different things get called a Mac app here

The first route is the official application published by Mastodon gGmbH. Its App Store listing names iPhone on iOS 18.6 or later, iPad on iPadOS 18.6 or later, Apple Vision on visionOS 2.6 or later, and a Mac line that reads "Requires macOS 15.6 or later and a Mac with Apple M1 chip or later."

That Mac line is the fact most comparison pages are missing. Apple only shows it when a developer has allowed the iPhone and iPad build to be installed on Apple silicon, and the project has done so. On a recent Mac, the official application installs from the App Store, free, with a real Dock icon and a real place in Cmd+Tab. The current version is 2026.07 at about 115 MB, and it carries 48 interface languages. What it is not is a layout designed for a large screen and a trackpad, since it is the iPad build.

The second route is a third party native client, and this is the route most Mac articles are actually about. The third is the server's own web interface, opened in a window that is not shared with thirty other tabs.

An Intel Mac, or an Apple silicon Mac on a macOS older than 15.6, has the second and third routes only. That is the first thing to check, and it takes ten seconds under the Apple menu in About This Mac. The chip and the macOS version decide whether route one exists at all.

What an iPad build is like on a desktop

Worth knowing before installing it: an allowed iPad build is the phone and tablet interface running in a resizable window. Touch targets are sized for fingers, the layout is a single column that does not gain a second one when the window widens, and keyboard shortcuts are whatever the iPad version happened to support. Right clicking, drag and drop between windows and text selection behave close enough to native, but not identically.

For plenty of people that is fine, and the price of fine is zero. The reason to look further is a specific habit rather than a general preference. Anyone who keeps a timeline open at column width all day, or who reads through several hundred posts in a sitting, tends to want a layout built for a mouse. Anyone who checks in a few times a day is well served by the official application and can stop here.

What the third party clients require

The clients that get recommended most are iPhone and iPad applications whose developers have allowed a Mac install, which means their App Store listings carry the same kind of Mac line. The requirements differ enough to matter on an older machine.

Client	Seller	Mac requirement on its listing	How it charges
Ice Cubes	Thomas Ricouard	macOS 15.5 or later	Free, with tips and a supporter subscription
Ivory	Tapbots	macOS 13.0 or later	Paid subscription, including a tier covering macOS
Mona	Junyu Kuang	macOS 10.15 or later	Free, with a one off Pro upgrade

Mona's requirement is the one to note. A Mac on macOS 10.15 is well outside the range the other two accept, and outside the range the official application accepts, so on older hardware the list of options narrows quickly and Mona is often the only App Store answer.

Separately from the store, the project's own apps page carries a Desktop filter, and everything in that group is listed as free. It includes Mastonaut, Whalebird, TheDesk, Tuba, Fedistar and Mastui, most of them also marked as open source. These are desktop programs rather than iPad builds, so they are installed from their own sites rather than from Apple. The trade is the usual one: no store review and no automatic updates, in exchange for a layout built for a large screen from the start.

The project treats the browser as a first class option

Most services mention their website only as a fallback. The apps page on joinmastodon.org does the opposite and states the case directly.

You can always use Mastodon from the browser on your desktop or phone! It can be added to your home screen and some browsers even support push notifications, just like a native app! Source: joinmastodon.org

The same page explains why the client list is so long. It describes the interface as open and well documented and available to everyone, and invites people to build their own client or use one of the many third party ones. A network where anyone can write a client ends up with a dozen of them, and also with a web interface that has to stay complete because it is the reference implementation.

That last point is the one worth carrying forward. On most services the website is the thin version and the application is the full one. Here the relationship is reversed.

What choosing a client gives up

A client is a separate program talking to a server through the documented interface, and everything it shows had to be built by its author. Two consequences follow.

The first is coverage. A server's own web interface exposes whatever that version of the software offers, on the day it offers it. A client exposes whatever its author has implemented. The gap is small for reading and posting, and wider for the things people reach for occasionally: filter management, list editing, notification granularity, follow request handling, data export, and anything to do with moderating a space rather than participating in it. Anyone who runs a server, or helps moderate one, ends up in the web interface regularly whatever else is installed.

The second is that a client is software to keep. It updates on its author's schedule, and this ecosystem has produced clients that stopped being maintained. That is not a reason to avoid them. It is a reason to know which of the three routes is the fallback, and to have it set up before it is needed.

The honest split

Read a timeline in a client if reading speed is what matters. Keep a window on the server's own interface for everything else. These are not competing choices, and one machine can hold both without friction.

One account per server, one window per account

An account on this network belongs to one server. Somebody with a work related account on one host and a personal account on another has two addresses, two local timelines and two sets of rules. This is the situation that client comparisons handle least well.

Native clients handle multiple accounts by switching between them inside one window. That works, and it has a specific failure mode: the wrong account posts. It happens because both identities share a single window and a single composer, and the switch is a setting rather than a place.

Separate windows remove the failure rather than reducing it. Two applications with two names and two icons cannot be confused in the application switcher, because there is nothing to switch. The composer in each window can only post as the account that window holds.

A browser handles the two server case better than people expect, because cookies are stored per site, so two different hosts can be signed in at the same time in one browser. The case it cannot handle is two accounts on the same server, which is common for anyone who keeps a bot, a project account or a second identity alongside a main one. One browser holds one session per site, so the second account means signing out, or a private window that forgets the login every time it closes.

Putting a server's interface in its own window

macOS has a documented route that costs nothing. In Safari, the menu path is File then Add to Dock, and Apple is clear that the result is not a bookmark.

The web app is saved to the Applications folder of your home folder, and you can also open it from the Dock or Spotlight. Source: support.apple.com

Apple's documentation also notes that such a window shares no browsing history, cookies, website data or settings with Safari, and that the name, the icon, the opening URL and the toolbar's navigation controls can all be changed. For a timeline, three of those settings earn their keep immediately. Name the window after the account rather than the software, so two of them are distinguishable in Spotlight. Set the URL to the home timeline rather than the server's landing page. Hide the navigation controls, since a timeline rarely needs a back button.

There is a second reason a separate window suits a timeline specifically, and it has nothing to do with logins. A timeline is one of the few things people want permanently visible and permanently narrow. Dragging a browser window to a third of the display moves every tab in it to that width, so the next page opened in that browser arrives cramped. macOS remembers a size per application, so a dedicated window can sit at column width on the right of the display and come back at that size every time, while the browser stays full width and never learns about it.

Where the free route stops is the same place the browser stops: a Safari window inherits Safari's session, so two windows made this way show the same account on the same server. A site to app tool closes that gap by giving each generated application its own isolated storage, which turns two accounts into two named applications that each open on their own timeline. The supported services list shows which sites arrive already configured, which saves working out the correct starting address by hand.

What a window will not fix

Native integration stays with native applications. The macOS share sheet, Shortcuts actions, a menu bar item and a global posting shortcut belong to a program written for the platform. Notification behaviour depends on the engine the window uses rather than on the site. And the server still decides what the interface offers, what the character limit is and which posts federate, because those are properties of the host the account lives on.

What to change first

Check the chip and the macOS version, because that decides whether the official application is available at all. Then take the account used most, open its web interface, and build one window on it with Add to Dock. Read from that for a week next to whatever client is installed, and if the answer turns out to be that two accounts on one server both need a permanent window, Kagemusha creates them as separate applications with separate storage.