DEV Community: TypeFire

Why Your Mac Opens .md Files in Xcode, and How to Fix It From the Terminal

TypeFire — Fri, 30 Oct 2026 18:31:43 +0000

You clone a repo, double-click README.md, and Xcode starts up. Or TextEdit opens it as a wall of hashes and asterisks. Every AI tool you use now writes Markdown, and the Mac still treats it like a config file.

This is fixable in a few minutes, and once you see how macOS decides which app opens a file, the fix stays put. We'll go through it from the terminal, with the Finder version for anyone who'd rather click.

How macOS picks the app: one type, a few extensions

macOS doesn't map extensions to apps directly. It maps each file to a Uniform Type Identifier (UTI), and apps register as handlers for UTIs. Ask Spotlight what type a file is:

mdls -name kMDItemContentType README.md
# kMDItemContentType = "net.daringfireball.markdown"

We checked this on macOS 26.3: .md and .markdown both resolve to net.daringfireball.markdown, the type named after John Gruber's site, where Markdown started. Set a handler for that type and both extensions follow.

On a developer's Mac, several apps usually claim that type: Xcode, a couple of editors, whatever IDE you installed last. Until you pick one, macOS picks for you, and it's rarely the one you'd choose.

.mdown and .mkd are different. Unless an installed app declares them, macOS gives them dynamic types (dyn.ah62d4rv...), so they need their own handler. If your files use those extensions, renaming them to .md is the simplest fix.

Fix it with duti (two commands)

duti is a small command-line tool that sets default handlers by UTI. Install it with Homebrew:

brew install duti

Check what currently opens Markdown:

duti -x md
# Xcode.app
# /Applications/Xcode.app
# com.apple.dt.Xcode

Then set the handler by bundle ID. all covers every role (viewer, editor, shell):

duti -s <bundle-id> net.daringfireball.markdown all

To find any app's bundle ID:

defaults read "/Applications/Visual Studio Code.app/Contents/Info" CFBundleIdentifier
# com.microsoft.VSCode

So, for VS Code:

duti -s com.microsoft.VSCode net.daringfireball.markdown all

Run duti -x md again to confirm. Because it's one line, it fits in a dotfiles bootstrap script, so a new Mac gets the right default on day one:

# ~/dotfiles/macos/defaults.sh
duti -s com.microsoft.VSCode net.daringfireball.markdown all
duti -s com.microsoft.VSCode public.json all
duti -s com.microsoft.VSCode public.yaml all

Check the type, set the handler, confirm. The .mdown file is the one that needs its own default.

The Finder way

If you'd rather not install anything:

Select any .md file and press ⌘I (Get Info).
Expand Open with and pick the app.
Press Change All, then confirm.

The step people skip is Change All. Picking an app without it only changes that one file, which is why the problem seems to come back.

Why it keeps reverting

An app re-registered on update. Xcode, in particular, can claim the type again after a big update. Re-run your duti line; this is where having it in a script pays off.
The file has its own override. A file you once set with "Open with" (without Change All) keeps that choice. Select it, Get Info, and press Change All from there.
A stale Launch Services database. If nothing sticks, rebuilding the database usually clears it. It resets every file association on the Mac, so treat it as a last resort:

LSREGISTER=/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister
$LSREGISTER -kill -r -domain local -domain system -domain user
killall Finder

Reading without opening: Quick Look

A default app fixes double-clicking. Most of the time, though, you just want to read the file: a README in a repo you cloned, notes an AI agent left behind, release notes in a download.

That's Quick Look: select the file in Finder and press Space. Out of the box, macOS shows Markdown as raw source. A Quick Look extension can render it with headings, lists, tables and code blocks instead. To test whatever's installed from the terminal:

qlmanage -p README.md      # preview a file the way Finder's Space does
pluginkit -mAv -p com.apple.quicklook.preview   # list installed preview extensions
qlmanage -r && qlmanage -r cache         # reset Quick Look if a new extension doesn't show up

Space in Finder with a Markdown Quick Look extension: headings, tables, task lists and code instead of raw text.

Where TypeFire fits

This part is ours, so here's exactly what it does. TypeFire is a Mac app that includes a Markdown Quick Look extension. Install the app and Space in Finder renders .md and .markdown files, math included ( $x^2$ inline and $$ blocks). It's free, with nothing to switch on. If another Markdown previewer is installed, TypeFire tells you which one it replaced, and you can switch to another previewer in Settings → Markdown.

It also has a one-click default: Settings → Markdown → Set as Default makes TypeFire the default app for .md and .markdown files (under the hood, the same Launch Services call duti makes).

Once a default is set, every .md file in Finder carries that app's icon.

You don't need TypeFire for anything above; duti and Finder do the job. It's for anyone who wants rendered previews and an editor in one install. Our guide to the default Markdown editor on Mac has the Finder steps.

Here's opening and editing a .md from Finder in 85 seconds:

The short version

.md and .markdown share one type, net.daringfireball.markdown. Set the handler once.
brew install duti, then duti -s <bundle-id> net.daringfireball.markdown all. Put it in your dotfiles.
In Finder, the step that matters is Change All.
For reading, use Quick Look (Space) with a Markdown extension, and test it with qlmanage -p.

What opens your .md files right now? Run duti -x md and see.

What Obsidian Really Costs a Dev Team in 2026 (and 4 Ways to Sync a Vault)

TypeFire — Fri, 30 Oct 2026 05:13:16 +0000

Somebody on your team starts keeping docs in Obsidian. Then a few more people do. At some point a manager asks the reasonable question: do we need to pay for this?

Short answer: probably not for the license, and maybe for sync. Every figure below comes from Obsidian's own pricing page, which we checked on October 29, 2026.

The price list

What	Price	Required?
The Obsidian app	Free, for personal and work use	No
Sync	$4 per user per month billed yearly, $5 monthly	Only if you use it
Publish	$8 per site per month billed yearly, $10 monthly	Only if you use it
Commercial license	$50 per user per year	No
Catalyst (early access)	$25 once	No

Students, faculty and nonprofit staff get 40% off Sync and Publish.

Is the commercial license required?

No. Obsidian's FAQ answers this directly: you are not required to pay for commercial use. It does encourage organizations to buy the license so the app stays independent and user funded, and companies that buy one can be listed as featured organizations.

So if your team is happy with the app and syncs files some other way, the honest bill is zero. Buying licenses is a way to support a tool you rely on, and plenty of teams do it for exactly that reason. We wrote up the details on our Obsidian commercial license page.

Where the money actually goes

The recurring cost is Sync, because it's priced per person, every month, for as long as you use it. Here's what that looks like over three years:

Annual billing. The last bar includes the optional license, which more than doubles the team figure.

If you want the math as code, so you can plug in your own headcount:

const SYNC = 4 * 12;      // per user per year, billed yearly
const PUBLISH = 8 * 12;   // per site per year, billed yearly
const LICENSE = 50;       // per user per year, optional

function obsidianCost({ people, years = 3, sync = true, sites = 0, licenses = false }) {
  const perYear =
    (sync ? people * SYNC : 0) +
    sites * PUBLISH +
    (licenses ? people * LICENSE : 0);
  return perYear * years;
}

obsidianCost({ people: 10 });                   // 1440
obsidianCost({ people: 10, licenses: true });   // 2940
obsidianCost({ people: 1, sites: 1 });          // 432

Four ways to sync a vault

A vault is a folder of Markdown files, so anything that moves files can sync it. Each option below trades money against something else.

1. Obsidian Sync

The paid service. It's end-to-end encrypted, keeps version history, supports shared vaults, and works on iOS and Android as well as desktop. If your team needs notes on phones, this is the one to pay for, and nothing else here matches it on mobile.

2. Git

Free, and most dev teams already know it. You get full history, diffs and blame on your notes, and the vault can live next to your code. The community Git plugin can commit and pull on a timer, so nobody has to remember.

A few lines of .gitignore keep the noise out. Obsidian rewrites its workspace files every time you open a pane, and you don't want those in every commit:

# Obsidian: per-device UI state, changes constantly
.obsidian/workspace.json
.obsidian/workspace-mobile.json

# Obsidian's local trash
.trash/

# macOS
.DS_Store

Keep the rest of .obsidian/ committed if you want the team to share the same plugins and settings. The trade-off is that Git is a pull and push model: two people editing the same note at the same time get a merge to resolve, the same as with code.

3. A cloud folder (iCloud Drive, Dropbox, Syncthing)

Put the vault in a folder that already syncs and you're done. It's free and needs no setup beyond moving the folder. It works best for one person across their own devices; for several people writing in the same files, Git's history makes changes easier to follow.

4. TypeFire, between Macs

This one is ours, so here's exactly what it does. TypeFire opens the vault you already have, in place: the same .md files, no import and no copy, and Obsidian keeps working alongside it.

Same folder, same files. TypeFire never rewrites a file you only open.

Notes sync is part of TypeFire Pro, a one-time purchase that covers three Macs, with note version history included. It runs through your own iCloud Drive, so nothing passes through a TypeFire server. It's built for Mac to Mac. For phones, Obsidian Sync is the one to pay for. The iCloud sync docs cover what syncs and how.

Here's the Notes tab in two minutes:

While you're in the vault all day

Sync is what costs money. What saves time is getting to a note without leaving the app you're in. TypeFire's note search opens over whatever you're working in, and Enter pastes the note into it:

Search the vault from your editor, terminal or browser, and paste the answer where you are.

We wrote more about this in capturing into Obsidian from any app. For the long version of the cost breakdown, including what Sync gets you, see Obsidian pricing in 2026.

The short version

The Obsidian app is free for work, and the $50 commercial license is optional.
Sync is the real recurring cost: $4 per person per month billed yearly, which comes to $1,440 over three years for a team of ten.
Need mobile? Pay for Obsidian Sync. Desktop only? Git or a cloud folder costs nothing, and TypeFire covers Mac-to-Mac with a one-time purchase.

How does your team sync its vault, and has anyone made Git work smoothly on mobile?

15 Text Expander Snippets Every Developer Should Steal (Commits, PRs, Bug Reports)

TypeFire — Fri, 30 Oct 2026 01:39:56 +0000

You type the same things all day. The commit prefix. The PR template. "Steps to reproduce." The standup. The console.log with a label so you can find it again. Each one is ten seconds, and there are dozens of them a day.

A text expander turns each into a few keystrokes: type ;pr and the whole template lands, wherever your cursor is. Below are 15 snippets worth setting up, written in the token syntax we use at TypeFire. The ideas work in any good expander; the syntax is ours.

Type thx, get the whole reply. The tokens below work the same way.

A quick primer on the syntax

Every example uses four kinds of placeholder that fill in at the moment of expansion:

{{fill:Label}} stops and asks you for a value (a ticket number, a scope). {{fill:Label|default}} prefills it.
{{date}}, {{time}} and formats like {{date:dddd}} insert today's date, the time or the weekday. Date math works too: {{date:+1d}} is tomorrow.
{{clipboard}} pastes whatever you last copied.
{{cursor}} leaves your cursor at that spot after expanding (plain-text snippets only).

Save these as Plain Text snippets, even the Markdown-looking ones, so {{cursor}} works and the Markdown pastes exactly as written.

The full list is in the dynamic tokens docs, and this 90-second walkthrough shows fill-ins and date math in action:

A tip on naming: start every abbreviation with a character you never type at the start of a word, like ; or z. Then ;pr never fires by accident in the middle of a sentence.

Git and pull requests

1. Conventional commit, ;cc

{{fill:type|feat}}({{fill:scope}}): {{fill:summary}}

One form, three boxes, and a correctly formatted commit message every time.

2. Branch name, ;br

git checkout -b {{fill:type|fix}}/{{fill:ticket}}-{{fill:short name}}

3. Pull request template, ;pr

## What changed
{{cursor}}

## Why

## How to test
1.

## Checklist
- [ ] Tests added or updated
- [ ] Docs updated
- [ ] No new warnings

If your PR template is Markdown, preview it before you push. We wrote up four ways to preview Markdown live, including the task-list syntax this one uses.

4. Approve with a nit, ;lgtm

LGTM, thanks! One small nit (non-blocking): {{cursor}}

5. Changelog entry, ;cl

## [{{fill:version}}] - {{date}}
### Added
- {{cursor}}

Code review and bugs

6. Review checklist, ;crv

- [ ] Does it do what the ticket says?
- [ ] Edge cases: empty, huge, unicode, offline
- [ ] Errors are handled and shown in plain words
- [ ] Tests cover the change
- [ ] No secrets, no debug logging left in

7. Bug report, ;bug

**Steps to reproduce**
1. {{cursor}}

**Expected**

**Actual**

**Environment:** {{fill:browser or OS}}, reported {{date}}

8. "Can you share more?", ;more

Thanks for the report! Could you share the exact steps, what you expected, and a screenshot or the console output? That'll help us reproduce it.

Code you type a hundred times

9. Labeled log, ;log

console.log("{{fill:label}}:", {{fill:value}});

10. TODO with an owner and a date, ;todo

// TODO({{fill:owner}}, {{date}}): {{cursor}}

A dated TODO is one somebody might actually come back to.

Two more from our developer snippets page: {{clipboard}} drops in what you just copied, {{cursor}} parks the caret inside the block.

11. Markdown table skeleton, ;tbl

| {{fill:Column 1}} | {{fill:Column 2}} |
| --- | --- |
|  |  |

Team rituals

12. Standup, ;su

**{{date:dddd}}**
- Yesterday: {{cursor}}
- Today:
- Blockers: none

13. On-call handoff, ;oncall

Handing off on-call, {{date:MMMM DD}}.
- Open incidents:
- Watch out for:
- Next check-in: {{date:+1d:dddd}}

Two that run code (Mac app)

TypeFire snippets can also be shell scripts: the script runs when you expand it, and its output is pasted. These two live on the Mac app.

14. A fresh UUID, ;uuid (Shell Script snippet)

uuidgen | tr '[:upper:]' '[:lower:]'

15. Your local IP, ;ip (Shell Script snippet)

ipconfig getifaddr en0

Where they work

On the Mac, snippets expand in every app: your editor, the terminal, Slack, the browser. In Chrome, Edge and Brave, the TypeFire extension expands them on every site, so ;pr works right inside GitHub's PR form.

On the Mac, a snippet can also get its own keyboard shortcut, for the ones you never want to type at all.

If you're choosing a browser text expander, we compared the options in our guide to the best Chrome text expander. And there's a page on TypeFire for developers with more code-shaped examples.

The short version

Prefix abbreviations with ; or z so they never fire by accident.
Use {{fill:...}} for the parts that change and {{date}} for anything dated.
Start with the five you type most: commit, PR, bug report, standup, log line.

What's the one thing you type every single day that should be a snippet?

Markdown Live Preview: 4 Ways to See What Your README Really Looks Like Before You Push

TypeFire — Fri, 30 Oct 2026 01:00:51 +0000

You write a README, push it, open the repo page, and the table is a mess of pipes. The list you indented "correctly" is now a code block. The checkbox is a literal [ ].

Markdown is forgiving to write and unforgiving to render. A live preview catches all of that before anyone else sees it. Here are four ways to get one, depending on where you're writing, plus the mistakes worth looking for.

1. VS Code: the preview you already have

VS Code ships a Markdown preview, no extension needed.

Cmd+Shift+V (Mac) or Ctrl+Shift+V (Windows, Linux) opens the preview in a tab.
Cmd+K V or Ctrl+K V opens it side by side, and it scrolls along with the editor.

Good for: files that already live in a repo you have open.

2. GitHub's own Preview tab

Editing a .md file in the GitHub web editor? The Preview tab next to Edit renders it with GitHub's own flavor of Markdown, the same one your repo page uses.

Good for: quick fixes to a file that's already on GitHub.

3. `grip`: GitHub rendering on localhost

pip install grip
grip README.md
# then open http://localhost:6419

grip renders the file through GitHub's Markdown API, so what you see matches the repo page closely. It refreshes when you save.

Good for: checking a README exactly the way GitHub will show it, from the terminal.

4. A browser editor where the preview is the document

Sometimes there's no repo yet. Someone pasted Markdown into Slack, an AI tool answered with a page of ## and **, or you're on a machine where you can't install anything.

For that, we built a free Markdown live preview at TypeFire. You paste Markdown in and it renders the moment it lands, right where you pasted it. There's no second pane to keep in sync, because the rendered text is the thing you edit.

A README pasted in: the heading, inline code and the table render where you pasted them.

A few details that matter for developer work:

Paste a README or drop the .md file onto the page; tables, fenced code, task lists and links render as they land.
Pasting from a web page or a doc converts to Markdown with the headings, links and lists kept, which is handy when you're turning a Google Doc into a README.
Copy it back out either way: File > Copy > As Markdown for the source, or As rich text for an email or a chat.
Nothing is uploaded. Your text stays in the browser tab, and tabs are saved locally so a refresh doesn't lose them.

Pasted from a web page: the heading, bold, link and list arrive as Markdown.

File > Copy gives you the source or the formatted version.

The same editor also ships in TypeFire for Chrome, with your notes in tabs, a text expander and clipboard history:

Good for: Markdown that doesn't live in a repo yet, or anywhere you can't install tools. If you just need to read a .md file on a Mac rather than edit it, the Markdown viewer for Mac guide covers that.

What to look for in the preview

Whichever tool you use, these are the five mistakes a preview catches that your eyes skip in raw Markdown:

1. Tables without a separator row. The second line has to be dashes and pipes, or there's no table:

| Flag | What it does |
| --- | --- |
| `-v` | Verbose output |

Here's the same table without that row, and then with it:

No separator row: just text with pipes in it.

Add | --- | --- | and it becomes a table.

2. A numbered list that doesn't start at 1. On GitHub a bullet list can follow a paragraph directly, but a numbered list starting at 3. with no blank line above it merges into the paragraph. Add the blank line, or start at 1..

3. Nested lists indented by the wrong amount. Line nested items up under the text of the parent item. Too little indent and the child item flattens into the parent list.

4. Task lists that need the exact syntax. It's - [ ] and - [x], with a space inside the empty brackets and a space after them. -[ ] stays as literal text.

5. Fenced code without a language.

```bash

gets syntax highlighting; a bare

```

doesn't. The preview shows you which blocks you forgot to tag.

Which one should you use?

Writing inside a repo in VS Code: the built-in preview.
Fixing a file on GitHub: the Preview tab.
Want GitHub's exact rendering locally: grip.
Markdown from anywhere else, or no install allowed: a browser live preview.

What's the Markdown rendering bug that bit you last?

DEV Community: TypeFire

Why Your Mac Opens .md Files in Xcode, and How to Fix It From the Terminal

How macOS picks the app: one type, a few extensions

Fix it with duti (two commands)

The Finder way

Why it keeps reverting

Reading without opening: Quick Look

Where TypeFire fits

The short version

What Obsidian Really Costs a Dev Team in 2026 (and 4 Ways to Sync a Vault)

The price list

Is the commercial license required?

Where the money actually goes

Four ways to sync a vault

1. Obsidian Sync

2. Git

3. A cloud folder (iCloud Drive, Dropbox, Syncthing)

4. TypeFire, between Macs

While you're in the vault all day

The short version

15 Text Expander Snippets Every Developer Should Steal (Commits, PRs, Bug Reports)

A quick primer on the syntax

Git and pull requests

Code review and bugs

Code you type a hundred times

Team rituals

Two that run code (Mac app)

Where they work

The short version

Markdown Live Preview: 4 Ways to See What Your README Really Looks Like Before You Push

1. VS Code: the preview you already have

2. GitHub's own Preview tab

3. grip: GitHub rendering on localhost

4. A browser editor where the preview is the document

What to look for in the preview

Which one should you use?

3. `grip`: GitHub rendering on localhost