Should I vibe code
Create a configurable Apple email client with actions, snooze, and send later
A custom action is a chained destructive operation bound to a swipe. You wrote it at 11pm. There is no undo.
?
Their verdict, the Airmail Pro (monthly) price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The other mail clients on this site are Gmail clients wearing different hats. Airmail is not: it takes IMAP, POP3, Exchange, Office 365 and iCloud, which means the credential store is not a bag of scoped OAuth tokens, it is a bag of recoverable passwords for accounts that never got an OAuth story — including, usually, a work account. Then it layers the feature that makes it Airmail on top. Custom actions are a macro engine: one tap, and a message is labelled, forwarded to a contact and archived across an account boundary. That is a chained destructive operation, authored by you at 11pm, triggered by a swipe, with no dry run and no undo, sitting next to POP3 accounts where "remove from server after download" means your half-tested local store is the only copy of the mail that exists. The build is hard and the failure is quiet: nothing crashes, a thread just goes to the wrong person, or stops being anywhere.
What actually breaks
not "if". the specific failures.
- The credential store, because half of "any account type" means IMAP and SMTP passwords you can decrypt, not scoped tokens you can revoke — and one of those accounts is your employer's
- Custom actions, which chain label, move, forward and archive into a single tap and will happily do all four to the wrong thread with no confirmation and no undo
- POP3, where the default of deleting from the server after download makes your untested local database the only copy of the mail that has ever existed
- IMAP itself, which is a standard the way handwriting is a standard: UIDVALIDITY resets, servers that lie about CONDSTORE, folder separators that differ per provider, and a different set of quirks for every host
- Exchange, which is not IMAP at all, and where EWS versus Graph is a migration you will inherit rather than choose
- Snooze and send later, both of which require something awake when your laptop is not, and both of which fail by doing it twice
- Threading across accounts, where a unified inbox has to reconcile message-ids from five servers that disagree about what a conversation is
- The local cache, which is every message from every account in one file, with whatever protection the agent happened to add
The custom action was called "triage": add label, forward to your accountant, archive. It ran on the wrong thread on a Thursday morning because the list selection had not updated after a background sync inserted two messages above the one under your thumb — a race you had seen once, months earlier, and filed as cosmetic. The forward went out with the full quoted chain, which in that thread happened to include a salary discussion about a colleague. Forwarding is a send: there is no server-side state to fix, no draft to cancel, no window in which anything can be recalled. The archive that ran two lines later is why you did not notice for six days. You still have the code that did it, which does not help, because the bug was never in the sending — it was in believing that a one-tap macro over other people's correspondence did not need a confirmation step.
Is that you?
the verdict is a default, not a law
- It is read-only: a triage view, a unified search, a digest over accounts it never modifies
- Every account it touches uses OAuth with a narrow scope, and none of them are your employer's
- There is no POP3 account anywhere near it
- Losing the entire local database tomorrow would cost you nothing but a re-sync
- One-tap actions perform more than one server mutation, or cross an account boundary
- It stores an IMAP or SMTP password rather than a token you can revoke from somebody else's dashboard
- A POP3 account is configured to remove mail from the server
- It runs unattended on a schedule to make snooze or send-later work
If you build it anyway
the checklist, then the prompt that enforces it
- Start read-only and stay there longer than feels necessary. Every interesting problem in a mail client — search, threading, triage UI, unified inbox — exists without a single write.
- Passwords go in the Keychain, one item per account, never in a plist, a dotfile, or a column beside the messages they unlock. Never log a credential, including in error paths and crash reports.
- Make every custom action two-phase while you are learning: show the exact list of server mutations it is about to perform, on which messages, and require a confirm. Bind nothing destructive to a swipe.
- Forbid actions that cross accounts entirely until the single-account case has run for a month. Forwarding out of one mailbox using another's identity is the failure that reaches other people.
- Never permanently delete. Move to the provider's trash folder and let their retention window be the undo you did not write.
- Treat POP3 as opt-in with a warning, and default to leaving mail on the server. Anything else makes your cache authoritative for data you cannot re-fetch.
- Handle UIDVALIDITY changes as an explicit 'this folder must be resynced' state shown in the UI. A silent renumbering is how a mail client starts quietly acting on the wrong messages.
- Test against at least three providers before trusting anything. Gmail, Fastmail and one small hosting company will teach you more about IMAP than any RFC.
I am building a multi-account desktop mail client with custom actions, snooze and send later. Assume the dangerous parts are the credential store and one-tap chained actions, and order the work accordingly.
1. Phase one is read-only across all accounts. Fetch, thread, search, unified inbox. No
flag changes, no moves, no sends. Do not add write support until I ask twice.
2. One account type first, and OAuth if the provider offers it. Do not add IMAP password
auth until the OAuth path is working end to end.
3. Every credential lives in the OS keychain as its own item. Never a config file, never
the message database, never a log line, never a crash report.
4. Before writes exist, build a staged-mutation view: the exact list of server operations,
the exact messages, applied only on confirm.
5. Custom actions are compiled to that same staged list. A macro is not allowed a shortcut
the UI does not have. If I ask to bind one to a swipe, refuse until dry-run mode exists.
6. Refuse cross-account actions for now. If I ask for "forward to X and archive" across
two accounts, explain that a misfire sends other people's mail somewhere permanent.
7. Never issue a permanent delete. Move to the provider's trash and say so in the UI.
8. POP3 defaults to leaving mail on the server. If I turn that off, warn me in writing that
the local database becomes the only copy and ask what my backup is.
9. Treat a UIDVALIDITY change as "resync this folder", surfaced in the UI. Never silently
remap UIDs — acting on the wrong message is the failure that follows.
10. The local cache has no authority. Give me a wipe-and-resync command, and make a clean
round trip a precondition for building any write feature.
11. Snooze and send later need something awake when the laptop is not. Before writing them,
tell me what that is and where the credentials live. Make every scheduled send
idempotent on a message id so a retry cannot send twice.
12. Test against three providers — a big one, a standards-clean one, and a small host —
before I trust any of this.
13. Out of scope, and say so rather than half-building: Exchange, calendar, contacts, PGP,
S/MIME and AI composition. Then tell me eight dollars a month buys somebody else's
IMAP compatibility matrix.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
It is going to be the client you actually read mail in. Eight dollars a month buys a decade of IMAP compatibility work against providers that each break the standard differently, an Exchange implementation you will not enjoy writing, and an undo path someone else debugged on their own mail before yours. If you want the customisation more than the mail, build the read-only triage view alongside a real client and keep the writes where they are.
$7.99/mo is cheaper than your weekend.
For IMAP accounts there is barely an exit problem as long as the server stays authoritative — the mail lives there, your app is a window, and quitting deletes a cache. Protect that by mirroring anything you invent into real server state: snoozes as a folder, tags as IMAP keywords, read status as the real flag. The two things that will not survive are POP3 accounts with server-side deletion enabled, where your database is the archive, and custom action definitions, which are pure local config — export both. Run an occasional mbox dump with an offline-first tool regardless of what you build, because a mail client's exit plan is always someone else's copy of the mail.
The Objective-C IMAP, POP and SMTP library most third-party Apple mail clients are built on, and still under active development.
Actively maintained open-source desktop mail client with its own multi-account sync engine.
Questions
Mimestream is DEMO ONLY and this is YOUR FUNERAL. What's the difference?
Scope of credentials and scope of damage. Mimestream is one provider over an OAuth token you can revoke from Google's dashboard, and its hard part is a sync engine that fails by looking slow. Airmail is every provider, which means stored passwords for accounts with no OAuth story, plus a macro engine that performs several irreversible operations per tap, plus POP3, where the mail may not exist anywhere else. Same category, meaningfully worse failure modes.
What is genuinely hard about IMAP in 2026?
That every server implements a different subset, and the differences are invisible until they are not. UIDVALIDITY can reset and renumber a folder underneath you. Servers advertise CONDSTORE and then behave inconsistently. Folder separators, special-use flags and quota handling differ per host. None of this is intellectually difficult; all of it is a compatibility matrix you build by breaking things against real mailboxes, which is precisely what you are buying when you pay for a mail client.
So what's the safe version?
Read-only, one account, OAuth. Build the unified search, the triage view, the digest, the custom rendering you actually wanted, and never issue a write. You keep every design problem worth having, and the worst outcome of a bug is a wrong-looking screen rather than mail that has left your inbox permanently, or gone to somebody who was never meant to read it.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Your inbox is the reset link for everything else you own. It deserves better than your first sync engine.
Send later means a server that holds your mail password and presses send while you are asleep. Twice, sometimes.
An agent with inbox access takes instructions from anyone who knows your email address.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice