Matthew Lindfield Seager

Frequent Updates are an Anti-feature

Dear Mac Developer/Product Manager,

Having to update and relaunch Mac apps constantly sucks.

Your product is not a web app. I don’t get the new version “for free” [written with the scariest of scare quotes] the next time I open your site or navigate to a new page after deploying.

I know you look down on the whole notion of app review, and having to go through Apple to release a new version, and that’s one reason you aren’t in the Mac App Store… but sometimes friction is a good thing. Without friction, it’s very hard to change direction or stop, and you may just run over your valued customers with your ever-growing momentum.

I love that coding agents are empowering you to build features more quickly and tackle bigger challenges; but maybe use a quarter of the time you save on could to stop and think about should.

Is a new feature for 5% of your customers today worth 100% of them having to download, install and relaunch your app, right as they’re about to start work?^

^Yes, less-intrusive Sparkle updates and installing updates on quit are welcome changes. But they don’t completely negate the fact that overly frequent updates are annoying. ¿Por qué no los dos?

Embrace constraints. If they aren’t being forced on you anymore, perhaps you need to impose some self-restraint?

You don’t need to go all the way back to boxed software and only shipping a new version every 2 years… What if you gave yourself a rule that you won’t ship updates any more often than say every 2 weeks (emergency bug fixes excepted)? Would your “velocity” really suffer because your customers have to wait a week or two to see that awesome new feature you dictated to Claude while you were in the shower?

We love you, but we want you to make better choices.

Sincerely,
Your Customers
(Or maybe just one grumpy customer 🤷‍♂️)

P.S. This letter is open to all developers; I addressed it to Mac developers because historically they’ve been the most likely to actually care about quality and customer experience.

It looks like Anthropic’s Claude Code team has taken inspiration from Apple’s Siri team:

 > Thinking a bit longer… still working on it…

Thankfully (so far), Claude Code has actually succeeded each time after that message. Siri usually fails after telling me it’s still working on it 😜

Pasting (Confluence) HTML as Markdown

Confluence does not have an export to Markdown feature. For long-term conversion I will download as .docx and convert to Markdown with Pandoc but for quick uses (e.g. copying reference documentation for an LLM) that’s overkill.

This morning I iterated with Claude on a script that works very nicely. I use an Alfred workflow to trigger it on my Mac with ⌘ ⌥ M (for Markdown) but you could just as easily trigger it with FastScripts, RayCast, Keyboard Maestro or probably even Shortcuts (or adapt it for use on Linux or Windows).

The script assumes you have Pandoc installed and that you’ve just pressed ⌘ C on some selected HTML text.

osascript -e 'the clipboard as «class HTML»' \
  | perl -ne 'print chr foreach unpack("C*",pack("H*",substr($_,11,-3)))' \
  | perl -pe '
      s/<span class="Apple-converted-space">[^<]*<\/span>/ /g;
      s/ (data-[\w-]+|style)="[^"]*"//g;
      s/<span class="code"[^>]*>(.*?)<\/span>/<code>$1<\/code>/g;
    ' \
  | pandoc -f html -t gfm --wrap=none \
  | perl -pe '
      s/<div[^>]*>//g;
      s/<\/div>//g;
      s/<[^>]+>//g;
      s/^``` code-block$/```/gm;
    ' \
  | perl -0777 -pe '
      s/^[^\S\n]+$//mg;
      s/\n{3,}/\n\n/g;
    '

I plan to update this post as I use it more and make small tweaks. It cleans up Confluence HTML nicely but I haven’t yet tested it with other sources.

If I remember, I’ll also write another post explaining the evolution from pbpaste -Prefer rtf | pandoc -f rtf -t markdown --wrap=none (which doesn’t work) to the monstrosity above.