Archive for September 5, 2024

Thursday, September 5, 2024

Default Folder X 6.1

I missed reporting on last year’s Default Folder X 6:

[Quick Search] gives you keyboard-based access to Recent and Favorite Items, including recently-launched applications and recently-used Finder windows. Note that it does NOT search your whole Mac, it searches the files, folders and apps that Default Folder X remembers for you. In most cases, it will find exactly what you want without showing all the extra stuff you don’t want.

[…]

In Save As dialogs, the box where you type the filename is way too small. How ’bout we fix that?

[…]

You can now drag and drop files and folders onto Default Folder X’s icon in your menu bar. When you do, it will pop up its menu so you can select a destination for them.

[…]

Automatically perform actions on a file after you save it. This can be as simple as immediately opening the saved file or attaching it to an email, or as complex as using AppleScript, Automator or Shortcuts to process the saved file in some customized way.

Default Folder X 6.1 (release notes):

In addition to Sequoia compatibility, Default Folder X 6.1 also opens favorite URLs from its Quick Search window, can open folders in the Warp terminal app, and fixes a number of bugs that cropped up in version 6.0.8.

It’s $39.95 to buy or $9.95 to upgrade. I used Default Folder a lot back in the day, but since Mac OS X I’ve mostly been using LaunchBar to help with open/save panels. Now I’m considering whether I should level up.

Spotify Connect Can No Longer Use iPhone Volume Buttons

Sarah Perez (MacRumors):

Spotify claims Apple may again be in violation of European regulation, the Digital Markets Act (DMA), which requires interoperability from big technology companies dubbed “gatekeepers.” This time, the issue isn’t about in-app purchases, links or pricing information, but rather how Apple has discontinued the technology that allows Spotify users to control the volume on their connected devices.

When streaming to connected devices via Spotify Connect on iOS, users were previously able to use the physical buttons on the side of their iPhone to adjust the volume. As a result of the change, this will no longer work.

Spotify sees this an anti-competitive because Apple gets to use its own protocol with HomePod and can access the buttons, whereas if Spotify uses its protocol it can’t. The buttons would work if Spotify used AirPlay 2, but for whatever reason Spotify doesn’t want to do that. How can they try to offer something better if they’re stuck using the same technology as Apple?

The technology Spotify was using for Connect was already degraded before being discontinued, the streamer claims. Spotify said that the experience using the iPhone volume buttons was often unstable, resulting in bugs like volume spikes during sessions.

It’s unclear to me what technology Apple discontinued that used to make this possible. And why is it happening so late in the iOS 17 cycle? Did Apple make a change recently or is Spotify just finally giving up since it had gotten so buggy?

William Gallagher:

Spotify has reportedly asked Apple to allow it to control the volume when using Spotify Connect to send music to HomePods. However, Apple has said that it requires Spotify’s app to add integration with HomePods.

Emma Roth (Sonos):

The Sonos app has also stopped letting iPhone users change the volume of their devices using physical buttons for similar reasons.

Update (2024-09-06): John Gruber (Mastodon):

Who should get to decide the rules for how the hardware volume buttons work on iPhones and iPads? Apple, or the European Commission?

If Apple is arbitrarily blocking access, making the user experience worse, as some kind of power play to prop up HomePod…maybe the EC?

Steven:

Also, they’d have to integrate with HomePods to get access to the new API, not just “support airplay”. Even Sonos, which supports AirPlay 2 doesn’t get access.

BenRiceM:

Spotify is definitely being obstinate, but given that camera apps had to wait 15 years for an API to detect volume presses (without ridiculous workarounds), I do think Apple could stand to be a little more open here.

Update (2024-09-09): See also: Dithering.

Marco Arment:

My guess is this API, which has been deprecated for a decade.

It’s the only way we’ve ever been able to programmatically set the iPhone volume, so it’s how apps would intercept volume buttons: observe it for changes, and upon a change, immediately set it back, then perform the custom action.

The only other known method is subview-diving on the MPVolumeView, but I don’t think that was ever reliable enough to actually write changes to the volume.

Alex Pretzlav:

I bet they were doing it this way.

Karl Baron:

What broke in 17.3 was listening to private API NSNotifications for the hardware buttons (_UIApplicationVolumeDownButtonDownNotification) like in this code. [Signal] had to go back to observing an MPVolumeView in our camera app to let you use the volume buttons to shoot (causing volume to randomly change when the hack failed) until last year they finally gave us a real API for it.

I keep hearing about more apps that were using this private API. The real API seems to be only for camera use.

Jonathan Z Simon:

The Harmony (Logitech remote control system) app uses the iPhone volume keys as the remote control volume. For me this is an extremely valuable feature, and also totally natural: as a user, it “does what I mean”.

Jimmy Callin:

I do see an argument that by bundling custom volume button actions with HomePod, they are forcing apps to support (and maintain) HomePod and thus are misusing their strong market power in iOS to unnaturally boost their position in a separate product category.

John Gruber (Mastodon):

I believe Spotify has subsequently edited their support page, because the above text no longer appear here, where it now reads:

Apple has discontinued the technology that enables Spotify to control volume for connected devices using the volume buttons on the device. While we work with them on a solution, you can use the Spotify app to easily adjust the volume on your connected device.

They deleted the part that said, “Apple has told us that they require apps to integrate into Home Pod in order to access the technology that controls volume on iPhones.”

Why? This is the biggest mystery about this whole story. I never understood what that meant. There does not seem to be a new (non-camera) API that Apple could offer to Spotify in return for supporting HomePod, so my assumption was that Spotify was being rejected on policy grounds and that Apple would allow them to continue using the private API if they cooperated. But it now seems clear that Apple changed/broke the private API. So what could be the carrot that Apple was supposedly offering?

I don’t know whether Spotify was misleading us or whether this was a clumsy way of saying that the volume buttons would work with HomePod (automatically) if Spotify Connect supported AirPlay. But the main Spotify app already supports AirPlay, and it doesn’t really make sense for Spotify Connect:

I was wrong yesterday to say — in the headline of the post, of all places — that Spotify could solve the problem by adopting AirPlay 2. Spotify Connect is, and needs to be, its own separate thing. Spotify users who use Connect love it. Here’s what one DF reader wrote to me: “AirPlay is a per-device feature, while Spotify Connect synchronizes Spotify sessions across devices. I can initiate playing on my iPhone, then control it from my iPad, Mac, or Watch. I can change the destination speaker from any device. It’s so good that I’m forever wedded to Spotify until Apple or someone else comes up with an equivalent experience. I think if AirPlay offered equivalent functionality, but Spotify refused to adopt it, Spotify would be open to more criticism, but from the perspective of a Spotify user, it’s lost functionality and even supporting AirPlay 2 would not fix what is now a diminished experience. So I think Spotify is doing the only thing they can, which is complain.”

John Gruber:

Apple’s own Remote app uses the iPhone volume buttons to control the TV’s volume. Which I don’t think should be illegal, but clearly demonstrates the use case for being a public API.

Google Drive Blocks Unverified Apps

Binarynights:

Recently, Google has limited or blocked direct connections to Google Drive through ForkLift. Depending on whether users have previously connected to Google Drive through ForkLift, they may encounter one of two warnings when trying to connect via the Connect Panel.

[…]

Google now requires apps like ForkLift to undergo the Cloud Application Security Assessment (CASA). This assessment ensures that apps meet strict security standards to protect user data and maintain secure integrations.

Undergoing the CASA process helps ForkLift identify and fix any security issues, safeguarding user data and ensuring our security practices are transparent. However, meeting these requirements can be a lengthy process. Even if ForkLift meets all standards immediately, the assessment can take up to six weeks. If significant changes are needed, it could take much longer.

I don’t like this trend of Google making it harder for users to access its services via third-party apps, and the security benefits seem questionable.

Previously:

Founder Mode

Paul Graham (Hacker News):

The theme of Brian’s talk was that the conventional wisdom about how to run larger companies is mistaken. As Airbnb grew, well-meaning people advised him that he had to run the company in a certain way for it to scale. Their advice could be optimistically summarized as “hire good people and give them room to do their jobs.” He followed this advice and the results were disastrous. So he had to figure out a better way on his own, which he did partly by studying how Steve Jobs ran Apple. So far it seems to be working. Airbnb’s free cash flow margin is now among the best in Silicon Valley.

[…]

In effect there are two different ways to run a company: founder mode and manager mode. Till now most people even in Silicon Valley have implicitly assumed that scaling a startup meant switching to manager mode. But we can infer the existence of another mode from the dismay of founders who’ve tried it, and the success of their attempts to escape from it.

[…]

The way managers are taught to run companies seems to be like modular design in the sense that you treat subtrees of the org chart as black boxes. You tell your direct reports what to do, and it’s up to them to figure out how. But you don’t get involved in the details of what they do. That would be micromanaging them, which is bad.

As he says, if this term catches on it will be misused like “agile.”

Shubhangi Goel:

A prime example of a tech titan embracing founder mode is Nvidia cofounder and CEO Jensen Huang, who has 60 direct reports and still eats in the company cafeteria.

[…]

Chesky spoke about how conventional advice on building and scaling up a startup is broken. He said, as he has before, that investors and outside managers just don’t have the insights that founders do. He said that splitting companies into organizational chart tiers — isolating founders from anyone but their direct reports — often kills the business.

[…]

There are also notable exceptions to positive founder mode: Sam Bankman-Fried and Elizabeth Holmes were both founders who operated with autonomy, then ignominy.

On the other hand, Satya Nadella and Tim Cook are both outside managers touted with turning their companies around — in both cases, building on the legacies of strong founders.

Tim Cook wasn’t CEO during the Apple turnaround.

See also:

Previously:

Update (2024-09-06): See also:

Update (2024-09-09): See also: Kent Beck (via Hacker News).

Update (2024-09-17): See also: Patrick Collison.