2026-01-26 01:04:18
My thanks to Meh for sponsoring last week at DF. Meh puts up a new deal every day, and they do with panache. As they say, “It’s actual, real, weird shit you didn’t know existed for half the price you would’ve guessed.”
Don’t tell any of my other sponsors, but Meh is my favorite longtime DF sponsor. I love the way their orange graphics look against DF’s #4a525a background. And I always love their sponsored posts that go into the RSS feed at the start of the sponsorship week. I’ll just quote theirs from this week in full:
Everything sucks. The whole world’s going to shit, especially our part of it, and it can feel like anything fun or silly is sticking your head in the sand.
And yet. It doesn’t help to just be miserable. If you’re going to last, you’ve got to find your little moments of joy, or at a break from the misery.
Buying our crap at Meh is not how you solve the world’s problems. We’re not that crass. But maybe a minute a day of reading our little write-up, and a couple minutes of catching up with the Meh community, of making a few new online friends, and yes, of occasionally picking up a weird gadget or strange snack you’ve never heard of is just a few minutes you get to take a break, not giving in to how bad everything else is.
Of course we would say that. Of course we benefit from that. But it is also part of why we have a quirky write-up. Why we have a community. Why we’re selling whatever weird thing is over at Meh today.
2026-01-25 08:14:52
A few weeks ago there were a rash of stories claiming that iOS 26 is seeing bizarrely low adoption rates from iPhone users. The methodology behind these numbers is broken and the numbers are totally wrong. Those false numbers are so low, so jarringly different from previous years, that it boggles my mind that they didn’t raise a red flag for anyone who took a moment to consider them.
The ball started rolling with this post from Ed Hardy at Cult of Mac on January 8, “iOS 26 Still Struggles to Gain Traction With iPhone Users”, which began:
Only a tiny percentage of iPhone users have installed iOS 26, according to data from a web analytics service. The adoption rate is far less than previous iOS versions at this same point months after their releases. The data only reveals how few iPhone users run Apple’s latest operating system upgrade, not why they’ve chosen to avoid it. But the most likely candidate is the new Liquid Glass look of the update. [...]
Roughly four months after launching in mid-September, only about 15% of iPhone users have some version of the new operating system installed. That’s according to data for January 2026 from StatCounter. Instead, most users hold onto previous versions.
For comparison, in January 2025, about 63% of iPhone users had some iOS 18 version installed. So after roughly the same amount of time, the adoption rate of Apple [sic] newest OS was about four times higher.
Those links point to Statcounter, a web analytics service. A lot of websites include Statcounter’s analytics tracker, and Statcounter’s tracker attempts to determine the version of the OS each visitor’s device is running. The problem is, starting with Safari 26 — the version that ships with iOS 26 — Safari changed how it reports its user agent string. From the WebKit blog, “WebKit Features in Safari 26.0”:
Also, now in Safari on iOS, iPadOS, and visionOS 26 the user agent string no longer lists the current version of the operating system. Safari 18.6 on iOS has a UA string of:
Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/18.6 Mobile/15E148 Safari/604.1And Safari 26.0 on iOS has a UA string of:
Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1This matches the long-standing behavior on macOS, where the user agent string for Safari 26.0 is:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Safari/605.1.15It was back in 2017 when Safari on Mac first started freezing the Mac OS string. Now the behavior on iOS, iPadOS, and visionOS does the same in order to minimize compatibility issues. The WebKit and Safari version number portions of the string will continue to change with each release.
In other words, Safari now reports, in its user agent string, that it’s running on iOS 18.6 when it is running on iOS 18.6, and reports that it’s running on iOS 18.6 when it’s running on iOS 26.0 or later. And it’s going to keep reporting that it’s running on iOS 18.6 forever, just like how Safari 26 on MacOS reports that it’s running on MacOS 10.15 Catalina, from 2019.
Statcounter completely dropped the ball on this change, and it explains the entirety of this false narrative that iOS 26 adoption is incredibly low. (Statcounter has a “detect” page where you can see what browser and OS it thinks you’re using.) The reason they reported that 15 percent of iPhone users were using iOS 26 is probably because that’s the amount of web traffic Statcounter sees from iOS 26 web browsers that aren’t Safari (most of which, I’ll bet, are in-app browser views in social media apps).
Nick Heer, at Pixel Envy, wrote a good piece delving into this saga. And then he posted a follow-up item pointing out that (a) Statcounter’s CEO has acknowledged their error and they’re fixing it; and (b) Wikimedia publishes network-wide stats that serve as a good baseline. The audience for Wikipedia is, effectively, the audience for the web itself. And Wikipedia’s stats show that while iOS 26 adoption, in January 2026, isn’t absurdly low (as Statcounter had been suggesting, erroneously, and writers like Ed Hardy at Cult of Mac and David Price at Macworld foolishly regurgitated, no matter how little sense it made that the numbers would be that low), they are in fact lower than those for iOS 18 a year ago and iOS 17 two years ago. Per Wikimedia:
So, no, iOS 26 adoption isn’t at just 15 percent, which only a dope would believe, but it’s not as high as previous iOS versions in previous years at this point on the calendar. Something, obviously, is going on.
David Smith, developer of popular apps like Widgetsmith and Pedometer++, on Mastodon:
I noticed iOS 26 adoption had entered a ‘third wave’ of rapid adoption. So I made a graph of the relative adoption versus iOS 18 at this point in the release cycle.
While lower than iOS 18 at this point for my apps (65% vs. 78%), the shape of this graph says to me that Apple is in full control of the adoption rate and can tune it to their plans. The coordinated surges are Apple dialing up automatic updates.
If this surge were as long as previous ones, we’d hit the saturation point very soon.
What’s going on, quite obviously, is that Apple itself is slow-rolling the automatic updates to iOS 26. For years now Apple has steered users, via default suggestions during device setup, to adopt settings to allow OS updates to happen automatically, including updates to major new versions. Apple tends not to push these automatic updates to major new versions of iOS until two months after the .0 release in September. This year that second wave was delayed by about two weeks, and there’s now a third wave starting midway through January. It’s a different pattern from previous years — but it’s a pattern Apple controls. A large majority of users of all Apple devices get major OS updates when, and only when, their devices automatically update. Apple has been slower to push those updates to iOS 26 than they have been for previous iOS updates in recent years. With good reason! iOS 26 is a more significant — and buggier — update than iOS 18 and 17 were.
People like you, readers of Daring Fireball, may well be hesitant to update to iOS 26, or (like me) to MacOS 26, or to any of the version 26 OS updates, because you are aware of things (like UI changes) that you are loath to adopt.
But the overwhelming majority of Apple users — especially iPhone users — just let their devices update automatically. They might like iOS 26’s changes, they might dislike them, or they might not care or even notice. But they just let their software updates happen automatically — and they will form the entirety of their opinions regarding iOS 26 after it’s running on their iPhones.
2026-01-24 11:38:53
The main reason I’m sticking with MacOS 15 Sequoia, refusing to install 26 Tahoe, is that there are so many severe UI regressions in Tahoe. The noisy, distracting, inconsistent icons prefixing menu item commands, ruining the Mac’s signature menu bar system. Indiscriminate transparency that renders so many menus, windows, and sidebars inscrutable and ugly. Windows with childish round corners that are hard to resize. The comically sad app icons. Why choose to suffer?
But the thing that makes the decision to stay on 15 Sequoia a cinch is that I honestly struggle to think of any features in Tahoe that I’m missing out on. What is there to actually like about Tahoe? One small example is Apple’s Journal app. I’ve been using Journal ever since it debuted as an iPhone-only app in iOS 17.2 in December 2023. 785 entries and counting. With the version 26 OSes, Apple created versions of Journal for iPad and Mac (but not Vision Pro). Syncing works great via iCloud too. All things considered, I’d like to have a version of Journal on my main Mac. But I’m fine without it. I’ve been writing entries without a Mac app since 2023, so I’ll continue doing what I’ve been doing, if I want to create or edit a Journal entry from my Mac: using iPhone Mirroring.
That’s it. The Journal app is the one new feature Tahoe offers that I wish I had today. I’m not missing out on the latest version of Safari because Apple makes Safari 26 available for MacOS 15 Sequoia (and even 14 Sonoma). Some years, Apple adds new features to Apple Notes, and to get those features on every device, you need to update every device to that year’s new OS. This year I don’t think there are any features like that. Everything is perfectly cromulent running iOS 26 on my iPhone and iPad, but sticking with MacOS 15 Sequoia on my primary Mac.
But now that we’ve been poking around at column view in the Tahoe Finder, Jeff Johnson has discovered another enticing new feature. On Mac OS 26, the Finder has a new view option (accessed via View → Show View Options) to automatically resize columns to fit the longest visible filename. See Johnson’s post for screenshots of the new option in practice.
Column view is one of the best UI innovations from NeXTStep, and if you think about it, has always been the primary metaphor for browsing hierarchical applications in iOS. It’s a good idea for the desktop that proved foundational for mobile. The iPhone Settings app is column view — one column at a time. It’s a way to organize a multi-screen app in a visual, spatial way even when limited to a 3.5-inch display.
Thanks to Greg’s Browser, a terrific indie app, I’d been using column view on classic Mac OS since 1993, a few years before Apple even bought NeXT, let alone finally shipped Mac OS X (which was when column view first appeared in the Finder). One frustration inherent to column view is that it doesn’t work well with long filenames. It’s a waste of space to resize all columns to a width long enough to accommodate long filenames, but it’s frustrating when a long filename doesn’t fit in a regular-width column.
This new feature in the Tahoe Finder attempts to finally solve this problem. I played around with it this afternoon and it’s ... OK. It feels like an early prototype for what could be a polished feature. For example, it exacerbates some layering bugs in the Finder — if you attempt to rename a file or folder that is partially scrolled under the sidebar, the Tahoe Finder will just draw the rename editing field right on top of the sidebar, even though it belongs to the layer that is scrolled underneath. Here’s what it looks like when I rename a folder named “Example ƒ” to “How is this possible?”:
On MacOS 15, if you attempt to rename an item that is scrolled under the sidebar in column view, the column containing that item snaps into place next to the sidebar, so it’s fully visible. That snapping into place just feels right. The way Tahoe works, where the column doesn’t move and the text editing field for the filename just gets drawn on top of the sidebar, feels gross, like I’m using a computer that is not a Macintosh. Amateur hour.
I wish I could set this new column-resizing option only to grow columns to accommodate long filenames, and never to shrink columns when the visible items all have short filenames. But the way it currently works, it adjusts all columns to the width of the longest visible filename each column is displaying — narrowing some, and widening others. I want most columns to stay at the default width. With this new option enabled, it looks a bit higgledy-piggledy that every column is a different width.
Also, it’s an obvious shortcoming that the feature only adjusts columns to the size of the longest currently visible filename. If you scroll down in a column and get to a filename that is too long to fit, nothing happens. It just doesn’t fit.
Even a future polished version of this column view feature wouldn’t, in and of itself, be enough to tempt me to upgrade to Tahoe. After 30-some years of columns that don’t automatically adjust their widths, I can wait another year. But we don’t yet have a polished version of this feature. The unpolished version of the feature we have today only reiterates my belief that Tahoe is a mistake to be avoided. It’s a good idea though, and there aren’t even many of those in Tahoe.
2026-01-24 08:59:23
Ken Case, on The Omni Group blog:
The features noted above already make for a great upgrade. But as I mentioned last year, one of the interesting problems we’ve been pondering is how best to link to documents in native apps. We’ve spent some time refining our solution to that problem, Omni Links, which are now shipping first in OmniOutliner 6. With Omni Links, we can link to content across all our devices, and we can share those links with other people and other apps.
Omni Links support everything we said document links needed to have. Omni Links work across all of Apple’s computing platforms and can be shared with a team. They leverage existing solutions for syncing and sharing documents, such as iCloud Drive or shared Git repositories. They are easy to create, easy to use, and easy to share.
Omni Links also power up Omni Automation, giving scripts and plug-ins a way to reference and update content in linked documents — documents that can be shared across all your team’s devices.
There’s lots more in version 6, including a modernized UI, and many additions to Omni Automation, Omni’s scripting platform that works across both Mac and iOS — including really useful integration with Apple’s on-device Foundation Models, with, of course, comprehensive (and comprehensible) documentation.
It’s Omni Links, though, that strikes me as the most interesting new feature. The two fundamental models for apps are library-based (like Apple Notes) and document-based (like TextEdit). Document-based apps create and open files from the file system. Library-based apps create items in a database, and the location of the database in the file system is an implementation detail the user shouldn’t worry about.
OmniOutliner has always been document-based, and version 6 continues to be. There are advantages and disadvantages to both models, but one of the advantages to library-based apps is that they more easily allow the developer to create custom URL schemes to link to items in the app’s library. Omni Links is an ambitious solution to bring that to document-based apps. Omni Links let you copy URLs that link not just to an OmniOutliner document, but to any specific row within an OmniOutliner document. And you can paste those URLs into any app you want (like, say, Apple Notes or Things, or events in your calendar app). From the perspective of other apps, they’re just URLs that start with omnioutliner://. They’re not based on anything as simplistic as a file’s pathname. They’re a robust way to link to a unique document, or a specific row within that document. Create an Omni Link on your Mac, and that link will work on your iPhone or iPad too — or vice versa. This is a very complex problem to solve, but Omni Links delivers on the age-old promise of “It just works”, abstracting all the complexity.
I’ve been using OmniOutliner for at least two decades now, and Omni Links strikes me as one of the best features they’ve ever added. It’s a way to connect your outlines, and the content within your outlines, to any app that accepts links. The other big change is that OmniOutliner 6 is now a single universal purchase giving you access to the same features on Mac, iPhone, iPad, and Vision.
2026-01-24 07:36:58
Free Mac utility by Zendit Oy:
A macOS app that enhances control over Elgato lights, offering features beyond the standard Elgato Control Center software.
Features:
- Automatically turn lights on and off based on camera activity
- Turn lights off when locking your Mac
- Sync light temperature with macOS Night Shift
Lolgato also lets you set global hotkeys for toggling the lights and changing their brightness.
I’ve had a pair of Elgato Key Lights down at my podcast recording desk for years now. Elgato’s shitty software drove me nuts. Nothing seemed to work so I gave up on controlling my lights from software. I set the color temperature and brightness the way I wanted it (which you have to do via software) and then after that, I just turned them off and on using the physical switches on the lights.
I forget how I discovered Lolgato, but I installed back on November 10. I connected Lolgato to my lights, and set it to turn them on whenever the Mac wakes up, and off whenever the Mac goes to sleep. It has worked perfectly for over two months. Perfect little utility.
2026-01-23 23:44:11
Dr. Drang:
For weeks — maybe months, time has been hard to judge this past year — Trump has been telling us that he’s worked out deals with pharmaceutical companies to lower their prices by several hundred percent. Commentators and comedians have pointed out that you can’t reduce prices more than 100% and pretty much left it at that, suggesting that Trump’s impossible numbers are due to ignorance.
Don’t get me wrong. Trump’s ignorance is nearly limitless — but only nearly. I’ve always thought that he knew the right way to calculate a price drop; he did it the wrong way so he could quote a bigger number. And that came out in yesterday’s speech.
Trump sophistry + math pedantry = Daring Fireball catnip.