The CSS Working Group resolved to use cursor: pointer for buttons and other clickable form controls in the new appearance: base styles. That happened on October 21, but I posted about it yesterday and, uh, people have feelings about cursors. I wrote about buttons and cursors back in 2022, when a post titled "Buttons shouldn't have a hand cursor" was making the rounds. I admitted I didn't have a strong opinion either way, then argued that not using the hand cursor had become the new anti-pattern anyway. The web isn't an operating system, and people expect clickable things to show a hand. The issue is Cursors For Base Appearance in CSS Forms Level 1. The group adopted the rules from this comment, and the part that's triggering half the Web is: select, option, input[type=checkbox], input[type=radio], button, input[type=button], input[type=submit], input[type=reset], input[type=color], input[type=image], ::file-selector-button { cursor: pointer; } It seems like we have a tabs vs. spaces sort of debate. Again. Nicole Sullivan pulled cursor data from a bunch of design systems and, in September, 27 of the 33 systems that set a cursor used pointer. After she added more systems, it was closer to a 50/50 split. Elika Etemad made the usability case in the meeting. Per the minutes, she said the hand "makes it clear, as soon as you're hovering an interactive control, you're supposed to click on it," and called it a "usability benefit even if not historically done on some platforms." "But the hand means it's a link" Haz had an interesting reaction: The debate is over, and evil has won. His point is that he can't tell whether ⌘-clicking something will open it in a new window anymore. He feels more confident clicking a button when he knows it won't change the URL, like when it just opens a popover or a panel. He's not wrong about that.* I replied that I've been on team evil since 2022 (albeit without a strong opinion, just following what users seem to expect). Touch screens don't have a cursor at all, and on desktop, browsers show a link's URL in the corner when you hover it. That's some type of hint, at least. Haz pushed back that he'd have to watch the bottom-left corner with his peripheral vision, which is fair. He also said he never cared which cursor buttons got, he just wanted links to have their own. I can appreciate that. "But desktop apps don't do it!" Jacob Paris liked the standard cursor on buttons because it makes web apps feel more like desktop apps than websites. My opinion hasn't changed, though. People have already learned that a hand cursor means clickable on the Web. It's by no means mandatory, but it's familiar and satisfying, so it stuck. Either way, nothing changes today. The resolution only covers appearance: base, which browsers haven't shipped yet. Buttons and selects still use appearance: auto, and their cursor is still default. If your CSS reset, design system, or web components already set cursor: pointer on buttons, keep it. When appearance: base ships, controls that opt in will get the same cursors by default. But remember, these are only defaults! You can still add whatever cursor you want to whatever element you want. Nobody's gonna stop you. In 2022, I said I'd keep changing the cursor on buttons until there's a good reason to stop. In 2026, I still haven't found one…and neither has the CSS Working Group. *Thinking about this more, if 50% of design systems opted to add cursor: pointer to buttons already, isn't this already a moot argument? **In general, I think the Web should be more personal and expressive so who even cares about a default? This is especially true for personal and fun sites. Just don't go too crazy, especially when it affects accessibility and the overall user experience.

As software engineers, we take pride in hand-written code and knowing how everything we build works in detail. While there are many developers out there who build good software, there are many, many more who don’t. Yet we balk at the idea of vibe coding, even when it yields decent results. You don’t need a scientific study to realize the mean quality of human-authored software leaned towards slop even before AI was around. How many times have you been frustrated by an app or website that just didn’t work right? (This is especially true for software produced by big companies.) The quality of software humans can build is absolutely incredible. But the quality of software humans actually do build is usually not. So no, AI can’t build perfect software. Maybe that will improve in the future, or maybe it will remain just as messy as the human-authored code LLMs have been trained on. I don’t think any of that matters, because if AI can build software that’s at least as good as the mediocre code that came before it, that will be acceptable for most industries. Customers don’t care about the craft, they care about the result. And if the result is faster, cheaper, and good enough…well, that’s a better combination than anything they’ve ever had before. Why wouldn't they choose it?

I launched ColorCopy on May 18. It was my second macOS app, but the first one I launched on the Mac App Store. Today, I decided to pull it. The app isn't a new idea, but it bakes four color tools into a single menu bar app: an eyedropper, a color picker, a palette manager, and a contrast checker, each one a hotkey away. I made it available for free, with a one-time in-app purchase to unlock unlimited use. No subscription, no recurring fees. It's simple, stable software with the lowest possible barrier to entry…exactly the kind of utility the App Store seems made for. I wasn't sure what to expect, so I ran an experiment to answer some questions: Is there any real benefit to having your Mac app on the App Store? Is the Apple tax worth it? Will customers just come flooding in? For ColorCopy's release, I did zero marketing. No Product Hunt launch. No Hacker News post. The only things I published were this blog post and a tweet. If the App Store delivers on its promise of discoverability, that should be enough to see some kind of traffic…right? You be the judge. In nearly three months on the App Store, ColorCopy got a little over 1,000 impressions, 149 product page views, 85 first-time downloads, three in-app purchases, and $21 in proceeds. Not per day. In total. Broken down over 81 days, that averages out to: 13 impressions per day 1.8 product page views per day 1 download per day 0.04 in-app purchases per day (about one per month) $0.26 in proceeds per day Extrapolated to 12 months, ColorCopy would have earned about $95…not even enough to cover Apple's $99 annual developer fee. If discoverability isn't a part of the App Store deal, what exactly is the benefit? Why limit your Mac app to the sandbox?* Why spend hours in App Store Connect filling out metadata, screenshots, and localization information? Why wait an arbitrary number of days for someone to review your app with the consistency of a coin flip? It doesn't seem worth it for Mac developers. Adios, App Store 👋 As of today, ColorCopy is self-distributed and sold through Polar (the new Stripe, which I highly recommend). This is the same way I sell TongueType, which makes pretty much everything easier on my end: one dashboard, real customer relationships, no finicky review process, and updates ship the moment they're ready. The move required swapping out in-app purchases from StoreKit to Polar, and updates now ship through Sparkle instead of the App Store's built-in update mechanism. Both are tried and true solutions for self-distributed Mac apps. To be fair, you can't really do this on iOS. Most users aren't jailbroken…walled garden and all. But on Mac, where self-distribution is still a first-class option, there seems to be zero incentive to be in the App Store, especially if you're counting on discoverability. In three months, the App Store sent me barely a trickle of customers. Had I marketed the app myself, the traffic would have flowed the other way. I would've been sending my customers to Apple and paying a tax for the privilege.** Self-distribution gives me the freedom and control over my apps that the App Store's sandbox never will. If it's on me to drum up all of my own traffic, I'm going to send it to my own website. *I originally used a third-party library for the eye dropper because NSColorSampler is meh, but the sandbox forbids it so I was forced to remove it. Yes, I had to make my app shittier in order to put it on the App Store. **I fully acknowledge this may not be the case for every app, but it was my experience and worth sharing. Your mileage may vary. Aside: ColorCopy was available in 10 languages on the App Store. For some reason, the listing always showed FR as its primary language (it wasn't). The app is available in many languages, including English.

I built the dictation app I wanted. It's called TongueType, and my daughter did the voice over for the video. (Family business.) It hasn't gotten much traction yet, and I think I know why: dictation has been bad for so long that most people stopped paying attention. I don't blame them. But I don't think most people realize how good local models have gotten. The thing that was flaky and frustrating five years ago is genuinely good now, and it runs entirely on your Mac. Downloads are low. But the conversion rate is great. The people who actually try it tend to stick around, which tells me the problem isn't the app, it's getting someone to give dictation one more honest chance. The real hurdle is the habit The hard part isn't accuracy. It's that talking instead of typing is a new habit, and new habits are awkward before they're automatic. For the first week it feels strange. You catch yourself reaching for the keyboard out of muscle memory. Then one day it clicks, and you realize how slow typing was making you for certain things. I still write code by hand. That's thinking, not transcribing, and I want my fingers on it (plus saying HTML tags and attributes out loud seems counterintuitive 😂). But for almost everything else, I talk. I prompt LLMs I send emails I reply on Slack I write commit messages I do most other text with my voice The common thread is that the thinking is already done and the only thing left is getting the words out. That turns out to be a surprising amount of my day. My desk setup On the go, the MacBook's built-in mic works just fine. You don't need fancy hardware to get good results. But when I'm at my desk, my laptop is docked, so I pair TongueType with a Tula mic. It's small, portable, sounds great, and looks the part! (Kuru Toga mechanical pencil positioned for size comparison.) One tip: use a wired mic if you can. Bluetooth adds latency, and latency is the enemy of a tool you reach for dozens of times a day. A wired connection makes the whole thing feel instant. Honest caveat: it's probably not a great look in a co-working space. 😂 "Why is this better than macOS dictation?" More accurate. Less flaky. More customizable. More fun. I could list the features, but the honest answer is the same one I'd give for most things: just try it and you'll feel the difference immediately. It's free to start. What's your experience been with dictation? If you wrote it off years ago, I'd genuinely love for you to give TongueType a shot and tell me what you think.

I just launched my first macOS app called TongueType. It's voice dictation that runs entirely on your Mac. Hold a key, speak, release, and your words appear wherever your cursor happens to be. I build small, simple, stable software. TongueType fits that description, and it scratches an itch I've had for a while. Why I made it I type fast, but I often think faster than I type. When an idea is fully formed in my head, the bottleneck is my fingers. macOS has had built-in dictation forever, but I never liked relying on it. Accuracy aside, I didn't love the idea of my voice taking a trip to a server and back just to write a sentence. There are many dictation apps in the wild, but I want one that's privacy focused, doesn't send data to the cloud, doesn't charge a monthly subscription, and gets out of the way. TongueType uses OpenAI's Whisper model running locally on Apple Silicon. Nothing is uploaded. Nothing is logged. There's no account to create. Zero telemetry. Your voice never leaves your Mac. How it works The whole interaction is one key. By default it's the Right Option key, because it's sitting right there and your thumb isn't doing anything important. Hold it, talk, let go. The transcribed text is inserted at your cursor…in your editor, your email, a chat box, a search field, anywhere text goes. You can also drop in an audio or video file — WAV, MP3, MP4, MOV — and get a transcript back. Handy for meeting recordings and voice memos. A few things I sweated the details on: A grace period so a quick accidental tap doesn't start recording. Double-tap to latch for when you want to keep talking without holding the key down. Cancel phrases — say "scratch that" at the end and the whole thing gets discarded. You will use this more than you expect. Spoken symbols — say "new line" or "question mark" and you get the symbol, not the words. Post-processing — for common terms that seldom get dictated properly. TongueType speaks twelve languages and includes automatic detection, so you don't have to tell it which one you're using. How I actually use it Building the app was one thing. Using it every day turned out to be another. A couple months in, it's quietly worked its way into most of what I do at the keyboard: Prompting LLMs. Talking to an AI assistant is conversational by nature, and typing out a long, detailed prompt is tedious. Speaking it isn't. I get more context into a prompt because I'm not rationing my words to save my fingers. Email. Replies that used to sit in my drafts now get spoken out in a single pass. I still read them before sending, but the blank-page friction is gone. Code comments and commit messages. The parts of coding that are just writing. It's faster to explain why a change exists out loud than to stop and type it. Direct messages. Quick replies in chat without breaking flow. Hold the key, say it, done. The common thread: TongueType is best wherever the thinking is already done and the only thing left is getting words out. That's a surprising amount of my work day. A fun personality TongueType is minimal and fun. It lives in the menu bar. The recording overlay is small and out of the way, and you can configure its position on screen. There are twenty accent colors including Rainbow Mode. None of these extras were necessary, but all of it was fun to build. Accessibility I want to call this out specifically. Voice dictation isn't only a convenience. For some people it's the difference between using a computer comfortably or not. If typing is painful or difficult for you, TongueType is built to be a genuine alternate input method, not an afterthought. That mattered to me, and it shaped a lot of the decisions above. Pricing TongueType is free to try, and the free tier includes every feature. You get 30 minutes of live dictation each month and short file transcriptions. If you want unlimited, TongueType Pro is a one-time $19.99 purchase that covers up to five Macs and unlocks unlimited dictation and full-length file transcription. No subscription. Buy it once, keep it forever. Requirements TongueType needs macOS 14 or later on an Apple Silicon Mac (M1 or newer). The local model is the whole point, and that's what makes it run so well. If any of this sounds useful, give it a try at TongueType.app. It's free to start, and I'd genuinely like to hear what you think.