More from A Beautiful Site
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.
I believe artificial intelligence is a powerful and valuable tool that can significantly improve how we create, solve problems, and bring ideas to life. I didn't always feel this way.. But these days, I use AI regularly in my work and I expect that to continue. We may not have chosen this reality, but it's the reality we're in. The tools and their benefits — costs be damned — can no longer be ignored. That said, when people ask "was this made with AI?" the honest answer is rarely simple. AI can speed up many parts of the process, but it doesn’t replace human judgment, creativity, or responsibility. What appears effortless on the surface rests on deliberate human direction, critical thinking, and careful review. Getting good results from AI requires active guidance and oversight. The nuances of context, ethics, user needs, and real-world application are simply too varied given the current technology. Moreover, AI doesn’t generate meaningful ideas or elegant solutions on its own. Strong human vision, architecture, and decision-making are still essential. There is no prompt, model, or service that can deliver finished, trustworthy work without substantial human input. My commitment to you is this: everything I create will be driven by human ideas, architecture, verification, and final review. I will use AI as an assistant to do what I would have done anyway, but more efficiently. I will not let AI replace my intelligence, but I will use it to turn my intelligence into code faster. — Cory LaViska
More in programming
A decade ago, a little bit of history was made. I didn't realize it, but a colleague made a great point, one of those real mind-changing points that seem too obvious to admit same-day. But, the next day, calver.org was born. At the time my team maintained the Python infrastructure for eBay and PayPal, and we were stuck deciding whether we were really ready for a "major" 1.0 release. Semantic Versioning was the only game in town and "major" means "big", right?! Thankfully, a wiser colleague mentioned: Ubuntu and Twisted don't struggle with version number debates. They slap a date on it and keep shipping. In fact, their date-based versions were even better because you always knew where it stood, in terms of updatedness and support. The only problem is that no one really knew about it. Somehow, this problem solving versioning alternative, arguably as old as history itself, had gone nameless for millenia, conspiring to make me feel foolish in an office meeting. Never again! Ten years of adoption Fast forward 10 years, we've seen CalVer adopted by Apple, Nvidia, JetBrains, and countless others. (We have a timeline!) The site may have more inbound links than any other project of mine. Apple made the biggest jump, at WWDC 2025: iOS went from 18 to 26 macOS from 15 to 26 watchOS from 11 to 26 and visionOS from 2 to 26 All landing on one, consistent number like a car's model year. I still remember the texts from the Venn diagram fanbase of my friends who love Apple and reasonable versioning. No such texts from when NVIDIA announced calendar versions across the GPU Operator, RAPIDS, and its monthly NGC containers, but still very cool. Open source, too: Home Assistant, pip, CockroachDB, and yt-dlp all ship on dates, with plenty more on the users page. The conversation even reached the language core; PEP 2026 proposed versioning CPython as 3.YY, and it almost happened, too. And it's never too late, time marches on! Fixing the notation But I don't think I got every detail right from day 1. That's the main motivator for CalVer 26. It's high time to start righting a couple idiosyncratic token design choices, starting with some additions: Meaning Before 26.0 26.0 Full year YYYY YYYY Short year (6, 16) YY YY Zero-padded year (06, 16) 0Y 0Y Short month (1 ... 12) MM M Zero-padded month (01 ... 12) 0M 0M Short week (1 ... 52) WW W Zero-padded week (01 ... 52) 0W 0W Short day (1 ... 31) DD D Zero-padded day (01 ... 31) 0D 0D Seeing double First, the doubled letters. From the first version (16.6), MM and DD meant the unpadded month and day, which reads backwards to anyone who knows date formats (ISO 8601's YYYY-MM-DD, Java, moment.js, day.js), as some community members correctly pointed out. I was ready to flip them, until I checked what people actually use: most projects with a YY.MM.MICRO badge (conda, Twisted, Ansible's tooling) don't pad, and more than a dozen other version management tools (like bumpver and bump-my-version) implement the old meaning. So, it's too late to flip MM's meaning. Instead, 26.0 deprecates it and offers a more explicit and hopefully clearer option: M is the short month, 0M the padded one, and MM is a technically-retired synonym for M. In case you're wondering, the explicit 0M was me being overinspired by Ubuntu's approach, perhaps: 6.06 pads its month but not its year, and YY.0M says exactly that. To pad or not to pad I think it's worth a detour into why padding is even a thing anyways. It's become important now that new ecosystems have emerged that enforced SemVer formatting semantics, and I wanted clear guidance about on the spec site. SemVer forbids leading zeros outright, so Cargo rejects 26.04.0 and Go modules reject v26.04.0. Even Python's packaging spec normalizes leading zeros away, so you can tag 2026.08.19 if you want, but PyPI will still show 2026.8.19. NVIDIA's GPU Operator docs put it this way: "Zero padding is omitted for month to be still compatible with semantic versioning." CalVer was always intended to drop in where SemVer was used. So 26.0 recommends unpadded (YYYY.M.D) as a sane "pure" default for software libraries. But libraries are not the only objects of versioning schemes. The exception is a version that becomes a filename, an image tag, or an object-store key that gets listed lexically. There, padding keeps 26.10 sorted after 26.09, which is why Ubuntu, NixOS, and NVIDIA's own NGC containers pad. More evidence of teams designing their versions. We love to see it. Our FAQ has a longer discussion of the padding issue, as well. Optional segments There was never any rule against them, but 26.0 makes optional trailing segments more explicit with square brackets. Now, yt-dlp's scheme can finally be written down: YYYY.0M.0D[.MICRO]. For the CalVer badges I could find on GitHub, they all stay valid for now. I've got a note on the deprecated spellings and a new copy-paste badge section for new ones. What else is new? It's always a great time to add more citations to the site. A spec changelog; the spec now versions itself: 16.6, 19.7, 26.0. A FAQ: breaking changes, same-day releases, and padding. The users page, rebuilt by category, with past users of note (schemes change; that's fine) and tooling. Case studies: Apple and NVIDIA in, yt-dlp replacing youtube-dl. Much of the thinking behind these changes happened in the GitHub issue tracker over the years, and 19 or so issues close with this release. That's where ideas for CalVer should go, so by all means, open an issue, and we'll get it sorted! In due time, of course. In closing, I can't believe I still love belaboring these numbers so much. Thanks to all (but especially Mark, Glyph, Hugo, issue reporters, translators, and maintainers) for the discussion, and ultimately making the most timely versioning system a timeless classic. See also 2016 announcement Designing a version My Yap on Why CalVer beats Semver
Four sincere attempts at OKRs, four failures, and every time: "you didn't do it right." Maybe the framework doesn't fit you -- so how do you find one that does?
Multiple concurrent writers. Multiple processes. Same SQLite. No modifications.
Brilliant jerks, ZIRP-era managers, and how psychological safety lost the plot. Part 3 of my conversation with Dr. Cat Hicks.
Say you're deploying an AI assistant that processes online order returns. For it to work, it would need access to your store's purchase policy, item…