A Mailchimp desktop app: campaigns in their own Mac window

Anyone looking for a Mailchimp desktop app on a Mac runs into the same gap twice. The App Store has a listing, but it turns out to be for a phone. Catalogue sites offer something called Mailchimp for Mac, but it is a wrapper someone else built around the website. Intuit does not publish a desktop client, and the reason the search happens in the first place is rarely a wish for native code. It is that building an email in a browser tab is a long, fiddly, easy to interrupt job, and a tab is a bad place to do a long, fiddly, easy to interrupt job.

What Intuit ships, and for which devices

The only application Intuit publishes for this product is Mailchimp Email Marketing on the App Store. Its supported device list covers iPhone, iPad and iPod touch. There is no Mac entry on the listing, and no Mailchimp application from Intuit in the Mac App Store at all.

What the mobile app covers is worth reading closely, because the list is longer than most people assume. Four groups are named on the listing. A marketing CRM and inbox, which adds contacts from the device, scans business cards, imports from files, Google Drive or Dropbox, tracks audience growth, and allows calling, texting and emailing with notes and tags recorded after each interaction. Reports and analytics for email, landing pages, social posts, SMS, automations and surveys. Emails and automations, which includes creating, editing and sending campaigns, newsletters, one-click resend to non-openers, and abandoned cart automations. And notifications, covering anomaly detection, non-opener insights, new subscriber alerts and sales summaries.

So the gap is not a missing feature set. It is a missing platform. Everything above runs on iPhone and iPad, and none of it runs on macOS. On a Mac the product is a website, and the website is the complete product, which means the only decision left is what kind of window that website gets.

Why the campaign editor suffers in a tab

An email build is not a five second visit. It runs to twenty or forty minutes of moving blocks, editing copy, checking a mobile preview, fixing a link, and reopening the same draft after someone else reviews it. Several things about a browser make that worse, and they compound.

The first is accidental closure. Cmd+W closes a tab and Cmd+Q quits the browser, and both are reached for constantly while working in adjacent tabs. Losing a half built email to a mistyped shortcut is a specific, memorable irritation, and the risk scales with how many other tabs are in the same window. A window holding one site has one thing to lose and no reason to be closed in passing.

The second is keyboard focus. The editor is full of text fields, and so is the browser. The address bar, the find bar and the tab strip all compete for keystrokes with a subject line and a body block. Most people learn to click into the canvas first out of habit, which is a click that exists only because the page is inside a browser.

The third is the sheer number of panels. A campaign build already involves a content area, a settings sidebar, a style panel and a preview pane. Stacking a tab strip, an address bar and a bookmark bar on top of that is three rows of screen height taken from the part of the layout that needs it most. On a laptop display, that is often the difference between seeing the footer of the email and scrolling to it.

The fourth is the tab that never gets closed. A campaign in progress is a tab that has to stay open for days, which means it drifts leftward in a window of twenty tabs and gets found by squinting at favicons.

The two free routes on macOS

Before installing anything, try what the operating system already offers. Both take under a minute and cost nothing.

Route	Where it comes from	What it produces
Add to Dock	Safari, File menu	An icon in the Dock and in Spotlight, a simplified toolbar, the signed in state usually carried over
Install page as app	Chrome or Edge, browser menu	A window with no tab strip, its own Dock icon, and browser level features such as notifications

Apple documents Add to Dock as turning a website into an app with its own icon and a stripped down toolbar. Google documents the Chromium version in its web apps help page, reached through Install page as app, and notes that installed web apps can gain notifications and offline storage.

For one person with one Mailchimp login, either route solves the problem completely. Point it at the campaigns list rather than at the marketing home page, so a launch lands on work in progress instead of on an upsell.

Where the free routes stop: more than one account

The limit is the same one every browser based route has. A Safari web app inherits Safari's session, and a Chromium web app inherits the profile it was installed from, so two windows built this way show the same account.

That matters more for this product than for most, because Mailchimp accounts tend to multiply. Pricing on the plans page is set per contact tier, running from a band of 0 to 500 contacts up to a band above one million, with Free, Essentials, Standard and Premium sitting across it. An agency does not consolidate five clients into one account to save money, because each client's list is their own asset and their own billing relationship. A freelancer running a personal newsletter and a client's announcements list has the same split for a simpler reason: the lists belong to different people.

One browser session cannot hold two of those logins at once. The common workaround is one Chrome profile per client, which works and then becomes its own chore, because five profiles means five windows that look identical and a mental note about which is which.

This is where a tool that turns a website into a standalone Mac app earns its place, since the useful ones give every generated app its own isolated storage and its own icon. Five clients become five named applications in the Dock and in the application switcher, each opening on its own campaigns list, each holding its own login. The features page covers the controls usually exposed per app, and the supported services list shows which sites arrive already configured.

The first launch costs a login

An isolated profile has no cookies, so the first launch of each app lands on a sign in screen. Where two-factor authentication is switched on, that is a code as well as a password. Doing this five times is a one off cost, and it is better paid at a desk on a quiet afternoon than at nine in the morning on a send day.

Send day wants a window that stays put

There is one day in a campaign cycle where the window matters more than on any other, and it is the hour after a send.

Open rates and clicks arrive gradually, bounces surface early, and unsubscribes need watching. That is a report page somebody wants visible at the edge of the screen for an hour, next to whatever else they are doing. A browser is bad at this because tiling it to one side of the display moves every tab there, and the next page opened in that browser lands in the same narrow window.

A dedicated application sized once for that job is remembered by macOS at that size. It can also be put into its own space, which is the difference between glancing at numbers and hunting for them. Where the window is built on a Chromium engine, the browser level notification permission documented in Google's help page can carry through, so an alert can arrive without the window being in front.

The same argument applies to the pre-send review. A test email needs opening in a mail client while the campaign stays exactly as it was. Two separate applications side by side is a calmer arrangement than two tabs and a mail window in the same browser.

How many windows the job actually needs

The answer is smaller than it first sounds, and getting it wrong in either direction is costly.

One window per account is the right default. The account is the unit that holds a login, a list, a plan and a billing relationship, so it is the unit that deserves an icon. Anyone tempted to build a window per campaign will end up with a Dock full of applications that stop being relevant the day the email goes out.

The one useful exception is the reports view. Where a newsletter goes out weekly and the numbers are checked every week, a second window pointed at the reports section of the same account is worth having, because it is the one page opened on a rhythm rather than on demand. It shares the login with the campaigns window if the tool allows two apps on one profile, and where it does not, signing in twice for the same account is a small price for a window that never has to be navigated.

Starting URLs deserve a minute of thought as well. A window pointed at the marketing home page arrives at promotional content. A window pointed at the campaigns list arrives at work in progress, and a window pointed at the audience view arrives at the list. The address in the browser bar when the useful page is on screen is the address the window should be built from, which is easier than guessing at it later.

A reasonable rule: build one window per login, add a reports window only for the account that sends on a schedule, and resist everything else until the need proves itself over a fortnight.

What a standalone window does not change

A window is presentation. It does not touch the service behind it, and it is worth being clear about the boundary.

Sending limits and billing are unchanged. The pricing page states that overages apply when a contact or send limit is exceeded, and that is a property of the plan, not of the container the site runs in.

Deliverability is unchanged. Authentication records, list hygiene and reputation decide whether an email lands, and none of them care what the sending interface looked like.

The mobile-only capabilities stay on mobile. Scanning a business card into a contact record needs a camera, and that feature belongs to the App Store app rather than to the website.

Rendering depends on the engine the window uses. A Chromium based window behaves like Chrome, including how it draws the editor canvas and how it prints. A Safari based web app behaves like Safari. Choosing the engine is the same choice as choosing a browser to build emails in, which is why a tool that lets the engine be set per app is worth more here than on a text heavy site.

Integrations are unaffected. The connections to a store, a payment processor or a scheduling tool are server to server, and a window on the Mac has nothing to do with them.

What to change first

Point one window at the campaigns list of the account used most, using Safari's Add to Dock, and build the next email in it. If the remaining problem is a second or third account that needs its own login and its own icon, a tool such as Kagemusha can produce them as separate applications with separate storage. Fix the entry point first, then decide whether anything is genuinely missing.