Turning Airtable into a standalone app on macOS
Unlike most services people want out of the browser, Airtable already has a Mac app, and it is published by Airtable itself. That makes the useful question a different one. Not whether a desktop version exists, but whether one application holding one signed in session is the right shape for the way a base actually gets used. Anyone running three client workspaces, or keeping a project tracker open beside an unrelated content calendar, hits the limits of a single window quickly. This covers where the official download lives, what it changes, and what to do when one app is not enough.
Where the official Mac app comes from
Airtable lists its downloads in one place. The downloads page shows two desktop entries and two mobile entries: macOS requiring macOS 10.13 or later, Windows requiring Windows 10 or later in 64 bit, iOS requiring iOS 16.0 or later on iPhone or iPad, and Android requiring Android 7.0 or later.
The macOS button leads to airtable.com/mac, which starts a download of a disk image named AirtableInstaller.dmg served from Airtable's own static host. It is a large file, a little over 216 MB as of this writing, and the copy currently being served was published in mid August 2026. Both details are worth knowing before starting. The size tells anyone on a constrained laptop what they are committing, and the recent date answers the question people usually ask next, which is whether the desktop build is still being kept current.
It does not come from the Mac App Store
Searching the Mac App Store for Airtable returns third party utilities from independent developers, not the application Airtable publishes. That is normal for direct distribution and it has one practical consequence: updates do not arrive through the App Store's update list, and the app is not tied to an Apple ID. Anyone who inventories software by looking at their purchased list will not find it there.
A support requirement worth reading twice
The macOS 10.13 floor is unusually low, which is good news for an older machine that modern software has started refusing. Anyone stuck on an earlier release than a service normally supports should check this page before assuming a Mac is too old for a desktop client.
What installing it actually changes
The official app gives Airtable a Dock icon, an entry in the application switcher, and a window that can be quit without disturbing anything else. Those three things are what most people mean when they search for a desktop app, and installing it delivers them without any configuration.
It also gives Airtable a session of its own. Signing into the desktop app is a separate step from being signed into airtable.com in a browser, and signing out of one does not sign out of the other. This surprises people who expect the app to inherit the browser session, and it is the same separation that makes the alternatives further down this page workable.
The cost on disk and who is allowed to pay it
A 216 MB disk image becomes an application of a similar order once expanded, and it is installed once per machine for every person who wants it. On a personal Mac that is unremarkable. On a work Mac it can matter twice over, because dragging an application into the system Applications folder is an action that a managed device may require an administrator password for, and some configurations block unsigned or non store installers outright.
The browser built routes sidestep that question entirely. Apple's documentation is explicit that a Safari web app is saved to the Applications folder of the home folder, which is a per user location rather than a system one. Nothing is installed system wide, no administrator password is requested, and the bundle itself is small because the rendering is done by machinery already present in macOS. For anyone who has been told they cannot install software on a company laptop, this is the difference between having a Dock icon and not having one.
What it does not change is the number of accounts that can be visible at once. One installed copy of an application runs as one process with one storage area. A second workspace under a second login means signing out and back in, which is the specific friction that sends people looking for something else even after the official app is already installed.
When one app is not enough
Three situations come up repeatedly, and none of them are solved by the official download.
The first is more than one account. Consultants, agencies, and anyone with a personal base alongside a company workspace need two sessions alive at the same time, not one session that switches.
The second is more than one base. Airtable's useful unit of work is rarely the home screen. It is a specific base, often a specific view or interface inside it, and each of those is addressable by its own URL. A single app that always opens on the home screen means navigating back to the same place several times a day.
The third is window discipline. A base used for planning and a base used for support triage are different jobs, and keeping them in one window means the application switcher can only get a person as far as Airtable, not as far as the thing they were doing.
Each of these is a request for more windows, not for a different application. That reframing points at the routes below.
A fourth case is narrower but comes up in agency work. Forms and shared views are addressable pages that collaborators use without ever touching the base behind them. Someone whose actual job is submitting intake requests all day does not need the full product in the Dock, they need that one page, open, reachable from the switcher, and unable to wander anywhere else. The official app cannot be constrained that way. A window built from the form URL can be.
The four routes compared
| Route | Sessions | Opens on | Updates |
|---|---|---|---|
| Official Mac app | One at a time | The home screen | Handled by the app |
| Safari, Add to Dock | Separate per app | Any URL chosen | Follows the website |
| Chrome, Install page as app | Shared with the profile | Any URL chosen | Follows the website |
| A site to app tool | Separate per app | Any URL chosen | Follows the website |
The browser built routes are documented by their makers. Apple's support note explains that from macOS Sonoma 14 onward, File then Add to Dock in Safari saves a webpage as a web app that functions independently of Safari, sharing no browsing history, cookies, website data, or settings with it. The app lands in the Applications folder in the home folder, the name and the icon can be set to anything, and the settings panel exposes an Application URL field with a button to set it to the current page.
Chrome's route, described in its help pages, goes through More, then Cast, save, and share, then Install page as app. The important difference is that the installed app belongs to the Chrome profile that created it. The Airtable session from that profile carries straight over, which removes a login step and also removes the isolation that a second account needs.
Building a window per base
The technique that makes this worth the effort is choosing the URL deliberately. Open the base, the view, or the interface that a particular job starts from, then build the app from that page rather than from airtable.com. The result opens exactly where the work happens.
Two or three of these, named after the job rather than after the product, behave differently from one Airtable window. The switcher stops offering Airtable and starts offering the client tracker and the editorial calendar, which is the distinction a person is actually holding in their head. Naming matters more here than it does for a service with one surface, and so does the icon, because several windows of the same site are otherwise impossible to tell apart in the Dock.
This is also where the browser routes start to show their seams. Safari builds one web app at a time through a menu, with the icon set by hand afterwards. Chrome ties each one to a profile. For a single window neither is a problem. For five windows across two accounts, the repetition is the problem, and a purpose built tool exists for that shape of work. Supported services shows the sites that most often end up treated this way, and the Guide covers how the window rules get set.
What does not follow the window
Three things reliably surprise people on the first day, and all three are worth testing before a workflow is rebuilt around a new window.
Extensions do not come along by default. A password manager, a clipper, or a script that was reshaping a grid view inside the browser is absent from a Safari web app unless it is enabled for that web app in its settings panel. For Airtable specifically, the password manager is the one that gets noticed, because the first sign in happens in a window that has never seen the vault.
Links clicked elsewhere still open in the default browser. A base URL pasted into a chat message or arriving by email goes to whatever browser macOS is configured to use, not to the window built for that base. That is a routing rule at the operating system level, not a shortcoming of any particular route, and it means the browser copy stays in the picture. Keeping the browser signed into the same account the windows use avoids a confusing moment later.
File dialogs behave normally. Uploading an attachment to a record and downloading one back open the standard macOS panels, because the window is a real application as far as the system is concerned. Anyone worried that a lightweight route would compromise on file handling can stop worrying about that one.
Keeping the official app in the mix
None of this requires uninstalling anything. A common arrangement keeps the official app for the primary account, where its Dock icon and its own update mechanism are genuinely convenient, and adds separate windows for the second account and for the two or three bases that deserve their own entry in the switcher. The sessions do not collide, because each storage area is separate.
What to change first
Install the official app from Airtable's downloads page first, since it costs nothing to try and it settles the Dock icon question immediately. If the thing still missing is a second account or a window that opens on one specific base, build that one window next, and consider a tool such as Kagemusha once there are more than two of them to keep tidy.
Frequently asked questions
Does Airtable have an official Mac app?
Yes. Airtable's downloads page lists a macOS app alongside Windows, iOS, and Android. The macOS build requires macOS 10.13 or later and is distributed as a disk image from Airtable's own site rather than through the Mac App Store.
Can two Airtable accounts be open at the same time?
Not in one copy of the official app, which holds one session and requires signing out to switch. Two simultaneous sessions need two separate storage areas, which is what a Safari web app or a purpose built app provides. Two Chrome profiles with one installed app each achieves the same thing.
Is the desktop app still being updated?
The installer currently served from Airtable's static host was published in mid August 2026, so the desktop build is being kept current. Checking the file date on the download is a quicker answer than looking for a changelog, and it works for any vendor that distributes a disk image directly.
Can an app be made that opens one specific base?
Yes. Every base, view, and interface in Airtable has its own URL, and all three of the browser based routes let that URL be the starting point. Apple's web app settings even allow changing the address later, so a window built on the wrong page can be repointed without being rebuilt.
Will notifications work in a window built from the website?
They can, but permission is granted per app rather than inherited. Apple's documentation notes that for websites that send notifications, a web app's Dock icon can show the number of unread notifications. Allowing notifications in the browser does not carry that permission into a web app created afterwards, so the prompt has to be accepted inside the new window.