Archive for January 15, 2026

Thursday, January 15, 2026

Closing Setapp Mobile Marketplace

Tim Hardwick:

The service will officially cease operating on February 16, 2026. Setapp Mobile launched in open beta in September 2024.

In a support page, MacPaw said Setapp Mobile is being closed because of app marketplaces’ “still-evolving and complex business terms that don’t fit Setapp’s current business model,” suggesting it was not profitable for the company.

[…]

These alternative app marketplaces, as Apple calls them, are a relatively new frontier for app distribution on iOS, but they face hefty challenges, such as navigating Apple’s controversial Core Technology Fee, and competing with its established App Store ecosystem.

Epic Games currently pays the Apple fees that EU developers incur when distributing their apps through the Epic Games Store. However, Epic CEO Tim Sweeney has said it is “not financially viable” for Epic Games to pay Apple’s fees in the long term, but it plans to do so while it waits to see if the European Union requires Apple to further tweak its rules for third-party marketplaces under the DMA.

Steve Troughton-Smith:

Clear indicator that Apple’s DMA implementation never actually met its obligations under the DMA in the first place. Apple scared developers away from ever signing up to their poison pill Core Technology Fee terms, so alternative app stores simply have no apps to offer.

It’s kind of the same situation as BrowserEngineKit. Apple is going to say that they did all this work and there was no adoption, so that proves the EU was wrong; there’s no demand because customers prefer Apple’s “protections.” The developers will say that Apple designed third-party browsers and marketplaces to fail, or at least didn’t care very much about solving the reported problems; they tried their best in spite of this, but it wasn’t enough. I guess at some point the EU will decide whether it thinks there was malicious compliance.

Previously:

Update (2026-01-22): Guy English:

A third party App Store closes shop and everyone wants to read the tea leaves to confirm their priors.

John Gruber (Mastodon):

The core problem with these mandates from the EU is that they’re not based on demand from users. Users don’t care about third-party browser rendering engines. Users don’t even know what third-party browser rendering engines are. Users, by and large, not only are not asking for third-party app marketplaces for iOS, they in fact prefer the App Store’s role as the exclusive source for third-party software.

I think this is true in the narrow sense that there really isn’t much demand right now. But that could be because the users don’t know what they’re potentially missing. They have no basis for comparison. It’s like the apocryphal Henry Ford quote; they think a faster horse is just great. Users initially weren’t clamoring for something like the iPhone, either, because they didn’t imagine that such a thing could even be possible.

But if you look at a platform like the Mac, where there’s choice, Chrome has more market share than Safari even though Safari is bundled with the operating system. The Mac also had massively popular, innovative apps like Dropbox that would not have been possible in an App Store–only world. I think the App Store monopoly is holding back all sorts of innovation on iOS and long-term pushing more development to the Web.

Steve Troughton-Smith:

If users don’t care about alternative app distribution methods and things like third-party web browsers, we should remove them from macOS too, see how that goes

The fact of the matter is Apple’s rules precluded any chance of a mainstream alternative marketplace people might care about, like Steam, from ever existing.

If iOS were as open as macOS to app stores like Steam, enabling things like cross-buy and save sync of all your favorite games between Windows, Mac, Steam Deck and iOS, you bet your ass millions of people would want to use it

Sam Clemente:

Removing Chrome support in macOS may just kill the Mac

Which really just proves how insane it is that they’ve managed to go this far without expanding past WebKit on iOS

Previously:

Update (2026-01-23): Juli Clover:

The European Commission is gearing up to blame Apple for Setapp’s EU shutdown, according to information viewed by Bloomberg. “Apple has not rolled out changes to address the key issues concerning its business terms, including their complexity,” the EC reportedly plans to say.

Apple says that it has not simplified its EU business terms as expected because of the European Commission’s refusal to let it implement the changes.

Tahoe Broke Resizing Finder Column View

Jeff Johnson:

At the bottom of each column is a resizing widget that you can use to change the width of the columns. Or rather, you could use it to change the width of the columns. On macOS Tahoe, the horizontal scroller covers the resizing widget and prevents it from being clicked! Compare with macOS Sequoia, where the horizontal scroller and scroll bar are below the column and allow access to all of the resizing widgets.

[…]

Notice what happens when you use the default value: not only do the scrollbars disappear, the resizing widgets also disappear.

You can still resize the columns, though, by hovering over the horizontal column border lines. Thus, it appears that the Finder team did not even test with the combination of columns view and always show scroll bars.

That’s the problem with settings like Show Scroll bars: Always and the accessibility display options. They’re there because a vocal minority wants them and Apple feels it has to offer them in order to check a box, but it’s clear that its heart isn’t in making them great. Another one I’d put in this category is Natural scrolling. There’s nothing wrong with its behavior, as far as I know, but you can tell from the name that Apple doesn’t want you to turn this off. The Smooth scrolling checkbox was removed long ago, though thankfully the user default to turn it off still works in most cases.

Previously:

Update (2026-01-23): John Gruber (Mastodon):

I joked last week that it would make more sense if we found out that the team behind redesigning the UI for MacOS 26 Tahoe was hired by Meta not a month ago, but an entire year ago, and secretly sabotaged their work to make the Mac look clownish and amateur. More and more I’m wondering if the joke’s on us and it actually happened that way.

Jeff Johnson:

Another change from Sequoia to Tahoe, brought to my attention by Gruber, is that the Finder scrollbar on Tahoe is darker than on Sequoia, the latter shown below.

I believe the difference is due to the lack of a scroller hover state on Tahoe. On Sequoia and earlier, the scroller becomes darker when you hover the mouse pointer over it.

[…]

Both Gruber and the tipster mentioned to me that my inaccessible column resizing widget bug is “fixed” on macOS 26.3.

[…]

Returning to the inaccessible resizing widget issue, on further investigation it turns out that the issue does not occur on macOS 26.2 if you hide the path bar and hide the status bar in Finder.

He also discusses the new Resize columns to fit filenames option, which unfortunately only considers the filenames that are currently in view, not all the ones in the folder.

Previously:

Update (2026-01-26): John Gruber (Mastodon):

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.

[…]

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.

Update (2026-01-27): John Gruber notes that there’s a hidden preference to auto-resize columns on macOS 14 and 15.

Update (2026-01-30): Adam Engst:

It’s not quite “currently visible,” since the column will resize appropriately for long-named items that are one or two items outside the current view, but I think I understand why the feature works this way.

You have long been able to drag a column divider manually to expand it enough to read a heavily truncated filename, and if you Control-click a column divider, you can choose from Right Size This Column, Right Size All Columns Individually, and Right Size All Columns Equally. Even better, double-clicking any column divider is the same as choosing Right Size All Columns Individually. That command has no limit on column width, and it too expands columns only enough to display the currently visible items without truncation. This approach makes perfect sense, since the user is invoking the command to adjust what they’re looking at.

However, when “Resize columns” is working globally on all column-view windows, limiting column expansion to the visible items makes less sense.

[…]

I think Apple is trying to thread the needle between a global feature that works automatically and one that users can trigger on demand. When applied globally, it makes some sense to tread carefully around unknown extremes; when invoked manually, it should just do what the user expects.

Update (2026-02-05): Marcin Wichary:

Apple decided not to ship the auto-sizing columns a few years ago, hiding it under a “defaults write” incantation as a sort of a beta, but then seemingly just launched it this year without any changes. There are some charitable explanations – perhaps the beta was hard crashing Finder and the released one no longer does? – but in the current zeitgeist I’m feeling that it’s something more like this: the people with taste who were stopping it from getting launched in the bad state were either sidelined or are no longer there.

Update (2026-02-20): Jeff Johnson (MacRumors):

In today’s macOS 26.3 update, Apple implemented a “fix” for an issue I blogged about a month ago, macOS Tahoe broke Finder columns view.

[…]

The scrollbar unfortunately still covers up files in the columns. However, the vertical scrollers have been shortened, so the resizing widgets are now accessible above the horizontal scrollbar.

Problem solved, right? Well, not exactly. Try hiding the path bar at the bottom of the window[…]

John Gruber (Mastodon):

It was downright broken in earlier versions of MacOS 26 — you literally could not resize the columns. So now it’s not broken. But as Johnson says, it looks silly and amateurish.

This is the sort of detail that Apple used to strive to get pixel-perfect, all the time, for all settings. “Whatever, good enough” instead of “insanely great”.

Marcin Wichary:

But it also felt embarrassing how it broke. It feels clear there’s some manual calculation going on somewhere, and someone forgot to add this new change to it. One of the tricks I learned over time is that a well-designed system designs itself, but it takes effort and imagination to make a system resilient in this way. Here, if there was some abstraction of “adding stuff to the bottom,” then you wouldn’t have to worry about adding extra math. The system would take care of itself in many of these corner cases you will forget about.

I don’t want to shame (see, that word again!) individual people at Apple because I don’t know if it’s the lack of talent, or the whole system being wired in a way that doesn’t reward forward thinking or the kind of invisible work that needs to happen in those spaces. But the embarrassment should be there – if it doesn’t exist inside Apple, then that’s perhaps the sign of a real problem.

Previously:

How Markdown Took Over the World

Anil Dash (Hacker News, Mac Power Users):

If mark_up_ is complicated, then the opposite of that complexity must be… mark_down_. This kind of solution, where it’s so smart it seems obvious in hindsight, is key to Markdown’s success. John worked to make a format that was so simple that anybody could pick it up in a few minutes, and powerful enough that it could help people express pretty much anything that they wanted to include while writing on the internet.

[…]

After being nagged about it by users for more than a decade, Google finally added support for Markdown to Google Docs, though it took them years of fiddly improvements to make it truly usable. Just last year, Microsoft added support for Markdown to its venerable Notepad app, perhaps in attempt to assuage the tempers of users who were still in disbelief that Notepad had been bloated with AI features. Nearly every powerful group messaging app, from Slack to WhatsApp to Discord, has support for Markdown in messages. And even the company that indirectly inspired all of this in the first place finally got on board: the most recent version of Apple Notes finally added support for Markdown.

Alas, Apple Notes’ Markdown support does not extend to AppleScript. So there’s still no built-in way to automate getting your data out of the app in a good format.

But it’s not just the apps that you use on your phone or your laptop. For developers, Markdown has long been the lingua franca of the tools we string together to accomplish our work.

[…]

Because Markdown’s format was frozen in place (and had some super-technical details that people could debate about) and people wanted to add features over time, various communities that were implementing Markdown could add their own “flavors” of it as they needed. Popular ones came to be called Commonmark and Github-Flavored, led by various companies or teams that had divergent needs for the tool. While tech geeks tend to obsess over needing everything to be “correct”, in reality it often just doesn’t matter that much, and in the real world, the entire Internet is made up of content that barely follows the technical rules that it’s supposed to.

I’m pleasantly surprised at how ubiquitous Markdown has become, though strangely it’s still not built into WordPress. I actually don’t love it for blogging—since it can’t express a cite attribute and also I’m starting with chunks of text that are already HTML. I don’t see much benefit in mixing the two, so I continue to use plain HTML. I also continue to use reStructuredText for my product manuals. But pretty much everywhere else I use Markdown.

Previously:

Copyright © 2000–2026 Michael Tsai.