I have been making iOS and Android apps as a solo developer since 2014, and for the past few years my life has settled into a rhythm of moving between a Mac mini at home and a MacBook Air I take outside. Releases happen at the desk. Light edits and article drafts happen at a café. Logs get watched from a phone on a park bench. The more daily life and creative work blend, the more the small frictions between editors add up.
I had been quietly waiting for Antigravity's Settings Sync to bridge that gap. After three weeks of running it on both machines, I learned that my initial expectation — that "the same environment just appears on both Macs" — was about half right, and half a misunderstanding I needed to unlearn. Below is the path I walked to get to a sync design I actually trust, written along the shape of real daily work.
What pushed me to set up a second Mac
The trigger was selling an old iPad Air in spring 2026 and replacing it with a lightweight MacBook Air. Until then I had done most of my outside editing on the iPad, but once I started seriously running Antigravity's Background Agent, a full macOS environment became necessary. Around the time my apps crossed a cumulative fifty million downloads, the appeal of being able to "touch something the moment it crosses my mind" outside the house quickly outweighed the cost of carrying a laptop.
For the first few days I configured both Antigravity installs by hand. Within a week I noticed that when I updated a custom rule on one Mac, the other behaved differently for the same project. Same file, same line — completion would show up on the desk and not at the café. That kind of subtle drift quietly eats away at the sense of "this is my editor."
When I started writing iOS apps in 2014, one Mac was enough. Twelve years later, with four Lab sites and a handful of apps living in parallel, my workflow had quietly stretched across multiple machines. Settings Sync became necessary because the shape of my life had changed, not because the editor had.
What Settings Sync handled well from day one
Antigravity's Settings Sync uses a GitHub account behind the scenes to synchronize a personal settings repository. When I first turned it on, the breadth of what came across surprised me. The synced layer includes the editor basics (font, theme, tab width), keyboard shortcuts, the list of extensions, and the snippets I have written myself. All of this landed on the second Mac within minutes of signing in, and for about the first thirty minutes I simply thought, "this is great."
The keyboard shortcut sync was the part that paid off most. I have customized the standard bindings fairly heavily — Cmd+Shift+L to launch a Background Agent, Option+E to enter Edit Selection, and so on. Having those muscle-memory bindings appear on the second Mac, exactly where my fingers expected them, took far more cognitive load off than I had estimated.
Snippet sync helped just as much. My MARK: comment patterns for Swift, SwiftUI ViewModifier templates, the article opening that pulls from _documents/PERSONALIZATION_MAX_GUIDE.md — twelve years of accumulated reflexes arrived in the same places on both machines. The "warm-up cost" of starting a session outside the house dropped to roughly half of what it had been.
Mapping what does not get synced
The honeymoon broke on the afternoon of day two. I opened Antigravity on the MacBook Air and tried to invoke a custom rule I had set up at the desk. It was nowhere to be found. I checked the Mac mini, and the rule was right where I had left it. Settings Sync was supposedly enabled, but several pieces of configuration were quietly not crossing the wire.
After three days of patient bisecting, the things that do not sync turned out to fall into three clean buckets.
The first is project-specific custom rules. These live in a file like .antigravity/rules.json at the project root, and they belong to the repository, not to me as a user. Settings Sync rightfully leaves them alone. In my case I solved this by adding the .antigravity/ folder of all four Lab sites to Git, so the rules travel with the project rather than with the editor.
The second is workspace-scoped configuration. As a VS Code-derived editor, Antigravity gives per-workspace settings (in .code-workspace files) priority over user settings. Those are tied to the workspace file or the repository, and therefore also outside Settings Sync's remit.
The third bucket caught me out for a while: local LLM connection settings. I run Gemma 4 locally and point my editor to http://localhost:11434. Both Macs have a Gemma instance, but the connection details should clearly stay machine-local — syncing them would actively cause harm. Settings Sync correctly excludes this category, but for about thirty minutes I was convinced something was broken before I understood why.
Once these three buckets settled in my head, the picture clarified: Settings Sync is for synchronizing me, not the project or the machine. Obvious in hindsight, but having to draw the line for myself is what made the feature feel trustworthy.
The sync design I have arrived at
After three weeks, my layered design looks like this.
Trusted to Settings Sync
- Editor basics (font
JetBrains Mono, themeOne Dark Pro, tab width 4) - Keyboard shortcuts (eighteen custom bindings)
- Extension list (twenty-four extensions, four of which auto-install on both Macs)
- User snippets (Swift, TypeScript, MDX — sixty-two in total)
Moved into Git
.antigravity/rules.jsonfor each repository (four Lab sites plus four apps)- Per-project
.code-workspacefiles - Custom Commands that belong to a specific project
Maintained separately per machine
- Local LLM endpoint
- Git commit author identity (I deliberately use different addresses at the desk and on the road)
- Terminal integration launch options (zsh at home, fish on the road for faster cold start)
After settling into this three-layer separation, the "wait, where is this thing again?" moment when opening the second Mac dropped to near zero. A month ago, getting the MacBook Air productive after I opened it took about fifteen minutes. Now it takes under one.
Walls I hit and how I climbed over them
Writing only the smooth parts is not useful, so here are three concrete walls from the past three weeks.
Snippet conflicts. I updated a snippet named swiftview on the desk, then opened the laptop and found the older version still there. The cause was that I had edited the same snippet on both Macs shortly before, in slightly different ways. Antigravity does pop up a conflict dialog, but once you dismiss it the "pick one and discard the other" option becomes hard to find again. Now my rule is: finish snippet edits on one Mac, then run Cmd+Shift+P → Settings Sync: Pull explicitly on the other before I touch them there.
Waiting for extensions to install. Installing a new extension on the first Mac does not make it instantly available on the second. The download runs in the background, and if you start working right after opening Antigravity, the extension may not yet be active. I now treat the first five minutes after opening the laptop as warm-up time — usually the minutes I am making coffee anyway.
Git author identity being overwritten. This one I almost missed. My global Git author info nearly got overwritten via the synced settings. Because I keep separate addresses for home and road use, syncing them would have polluted my commit history. I moved Git author identity to be set per workspace instead. Settings Sync exists to align the editor, not the Git identity behind every commit — drawing that line explicitly is, I think, the safer default.
Where I have landed on Settings Sync
Both of my grandfathers were temple carpenters, and I have a childhood memory of being told that they kept similar tools at home, each set up for the house where they worked. Same hands, same craft, but the conditions of each house belonged to that house. After three weeks with Settings Sync, something like that line has quietly grown inside me as well.
Antigravity Settings Sync is a tool for synchronizing me — my reflexes, my keymap, my snippets. The shape of each project belongs to the repository. The shape of each machine belongs to the machine. Once those three layers are clear in your head, moving between two Macs stops feeling like "should I just stick to one?" and starts feeling like "this is what having two is for."
If you are about to set up a second Mac for solo development, I would suggest not chasing perfection on day one. Spend the first week deliberately exploring what does not sync. Once that line becomes visible, Settings Sync starts to support your daily editing more quietly and more reliably than you might expect.
I hope this is useful for anyone else who works across multiple Macs. Thank you for reading.