An offline-first macOS workflow that survives flaky Wi-Fi and AI hype

Half the apps on a modern Mac stop working when the network does. Your launcher's AI panel returns a spinner. Your notes app refuses to open the local file until it has authenticated. Your text expander syncs from a server before it lets you type. None of this used to be true. Most of it does not need to be true now.

This post documents an offline-first macOS workflow that I have run for two years. Every tool in it works without an internet connection. Every config is in plain files. Nothing requires sign-in to bootstrap. The result is a Mac that behaves the same on a 12-hour flight, in a coffee shop with broken Wi-Fi, or on a corporate network that blocks half the cloud endpoints — and that does not become useless if a vendor decides to deprecate a feature behind a paywall.

The reason to care: offline-first is not about being a luddite. It is about owning the failure modes. When a tool depends on a cloud service, you adopt that service's availability, its pricing decisions, and its data policies. When a tool runs locally, the only failure mode is your own machine.

The core constraint

A tool earns a place in this workflow only if it satisfies all three:

It launches and works without a network connection. Not "with reduced features." Fully functional.
Its data lives in files I can read with cat — or at least in a SQLite database I can open with sqlite3.
Its config lives in plain files I can put in a dotfiles repo.

Roughly 60% of the popular productivity apps in 2026 fail one of these three. That is the surface area I have replaced.

The stack

Launcher

Lume — local-first, no account, no remote endpoints. Spotlight is the macOS fallback. Both work offline because the indices are on the machine.

What I avoid: launchers that require sign-in to activate AI features that I cannot disable without their server confirming. Raycast's AI panel is a useful product for people who want it; for an offline-first workflow it is dead weight.

Notes

Plain Markdown in a folder. The folder is synced via Syncthing across my machines (peer-to-peer, no cloud account). The notes are readable in every text editor, in Finder Quick Look, and via cat.

What I avoid: Notion, Evernote, Bear, Obsidian Sync. Each is a fine product; each phones home before letting me edit a note in some circumstance.

For users who want a richer notes experience without the cloud dependency: Obsidian with local-only vaults (no Obsidian Sync), or Logseq which stores everything as Markdown by default.

Mail

Apple Mail with IMAP/SMTP against my own mail server. Messages are stored locally; the network is required only to send and fetch.

What I avoid: web-only mail clients. Gmail's web UI is a great product; on a flight it is unusable.

Calendar

Apple Calendar with CalDAV against my mail server.

What I avoid: Fantastical Premium tier (cloud features), Google Calendar web.

Editor

Neovim or Zed, both running locally with locally-installed extensions. No required login, no remote settings replication (settings are in dotfiles).

What I avoid: Cursor's "needs an account to start" flow, GitHub Copilot when I am offline (I run local Codeium or Tabby instead for AI completions).

Terminal

Ghostty or Alacritty, config in a single file in dotfiles. Works offline.

Text expansion

Espanso, config in YAML, runs entirely locally. macOS Text Replacements (iCloud-based replication) is a fallback for multi-device snippets when I am willing to accept the network dependency for the replication alone.

Clipboard history

Maccy, free, open source, stores history in a local SQLite file. No cloud history. Twenty items deep is more than enough.

Window management

Rectangle, free, open source. Configured via plain plist. Zero network.

File search

fd for filenames, ripgrep for content, mdfind for metadata. All local CLI tools, all bundled into Lume's file search index for the GUI side. None of them call out to a server.

Password manager

1Password with local vaults synced via my own cloud, or KeePassXC with the database file in Syncthing. 1Password's web service is a fine offering; the local-vault setup is the offline-first variant.

AI assistance

Ollama for local LLMs. Codeium for code completion when I am online and want the network model. The Ollama models are slower than the cloud frontier; for the queries an offline-first workflow needs (rewording an email, explaining a regex), local quality is acceptable.

What I avoid: any tool that defaults to cloud and degrades silently when offline.

Why each "fits"

The pattern across the list: every tool either has no cloud component or makes the cloud optional. The cloud component is usually for sync; the core function works without it.

Sync across machines is the one genuine need that cloud answers cleanly. The alternatives in this workflow:

Syncthing for files. Peer-to-peer, encrypted, your machines find each other on LAN or via a relay. No account.
Dotfiles in a git repo for configs. git pull is the sync; you choose when.
CalDAV/CardDAV against your own server for calendar and contacts. NextCloud, Mailcow, or a small self-hosted CalDAV is a one-evening setup.

The cost is real: more setup, more maintenance. The benefit is that no vendor can break your workflow with a policy change.

What it feels like day to day

The workflow is invisible most of the time, which is the goal. A typical morning:

Open the laptop. No login screen waiting for cloud auth. Local password unlocks.
⌘Space — Lume opens. Local index, no network round-trip.
Open the notes folder in Neovim. Plain Markdown, no remote replication to wait on.
Mail and Calendar open in their respective apps. IMAP and CalDAV both connect when they can; meanwhile, local data is visible.
Editor connects to local files; LLM completions come from Ollama running on the M-series chip.

When the Wi-Fi dies — or I move the laptop into airplane mode — nothing changes. Notes still load. Mail still shows the last sync. Calendar still shows the week. Editor still completes. Most cloud-dependent users do not realize how much of their daily Mac stops working when the connection drops, because it has not happened to them in a while.

The migration is unglamorous

If you want to move toward this kind of workflow, the migration is not a weekend project. It is six months of "swap one tool every two weeks."

The order I suggest:

Editor. Most editors are already local. Stop syncing settings via the cloud; commit them to dotfiles.
Notes. Hardest step. Migrate to Markdown files in a folder. Decide whether you need the syncing layer (Syncthing) or whether one machine is enough.
Launcher. Replace Spotlight or Raycast with Lume or another local-first launcher.
Clipboard / snippets / window manager. All three are quick swaps.
Mail and calendar. Optional. Many people are content to keep these cloud-backed. The offline-first variant requires running a server.

Each step is small. The cumulative effect is a machine that you own end to end.

What you give up

An honest accounting. An offline-first workflow has real trade-offs:

No frictionless multi-device replication. Syncthing works, but it is not iCloud-smooth.
No "open from any browser." If you forget your laptop at home, your notes stay at home.
No cloud AI assistance unless you opt in. Local LLMs are slower and dumber than frontier cloud models.
More moving parts. You become the sysadmin for parts of your own setup.

For some users, these trade-offs are deal-breakers. For others — especially people who travel, work from poor-connection environments, or care deeply about data ownership — they are acceptable in exchange for a workflow that does not break when the network does.

The Raycast / cloud-launcher case

A specific note on launchers. Raycast is a well-designed product. The reason it does not fit an offline-first workflow is not quality — it is the direction of its product strategy. AI features are central, sync between machines is central, and the account is the unit of authorization for both. None of those are "wrong"; they are just the opposite of offline-first.

Lume was built explicitly as the local-first alternative. No account, no remote endpoint required for any core feature, indices on the machine. If you want the launcher half of an offline-first workflow, that is the recommendation. If you want the broader case: When a launcher syncs to a remote server, the real price.

The lock-in question

The deeper reason to care about offline-first is lock-in. Every cloud-backed tool is an exchange: their convenience for your dependence. When a vendor changes pricing, sunsets a feature, or fails for a day, you absorb the consequences.

An offline-first stack reduces that exposure. You still depend on Apple for the OS, on Homebrew for package distribution, on the open-source maintainers of each tool — but those dependencies are slow-moving and the failure modes are tractable. A single vendor making a single product decision cannot brick your workday.

This is not an argument for paranoid maximalism. It is an argument for picking your dependencies deliberately, with eyes open.

A starter shopping list

For someone who wants to start tomorrow:

# CLI tools
brew install fd ripgrep starship espanso syncthing

# GUI apps
brew install --cask lume maccy rectangle ghostty neovim
brew install --cask obsidian   # if you want richer notes than plain Markdown
brew install --cask ollama     # if you want local LLM

# Optional self-hosted helpers
brew install --cask nextcloud   # if you want your own CalDAV/CardDAV server

Twelve installs. A weekend to configure. A daily-driver Mac that no longer panics when the Wi-Fi blinks.