Sarah Perez, writing for TechCrunch:

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. To work around the issue, Spotify iOS users will instead be directed to use the volume slider in the Spotify Connect menu in the app to control the volume on connected devices.

The company notes that this issue doesn’t affect users controlling the volume on iOS Bluetooth or AirPlay sessions, nor users on Android. It only applies to those listening via Spotify Connect on iOS.

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

Kieran Kelly, reporting for LBC:

New cars that are sold in Europe from this week will host automatically-installed speed limiters, following the introduction of a new EU law.

Even though the rule to install the technology does not apply in the UK, many of the cars will have been made in Europe and so will feature the Intelligent Speed Assistance (ISA) anyway.

The technology allows the car to automatically restrict its speed based on GPS location, speed-sign recognition and cameras within the vehicle. This is not done simply by applying the brakes, which could be dangerous, but by gradually reducing the engine’s power. However, drivers will first get a warning that they are driving too fast and be told to slow down before the measure takes affect.

When a friend sent me this link, I thought at first that LBC was some sort of Onion/Babylon Bee-style parody site. But no, this is real. Any politician in the U.S. seeking to end their career should propose similar legislation here.

In the EU, drivers will be able to turn off the system every time they start their car. It cannot be permanently shut off.

I take back my complaint that the EU no longer innovates in technology. They brought the EU cookie-consent web experience to cars. Nonstop pointless nagging and annoyance.

Speaking of nifty new Safari extensions from Christian Selig, Achoo is an iOS 15 Safari extension that gives you a good “View Source” command for inspecting (and editing) the code for any web page. $1, cheap!

The design of Safari 15 on the iPhone has gone to a better place, but Stephen Hackett reminds us that trouble on the Mac and iPad remain:

The ordering of the UI elements at the top of the screen… divorces the tab — which includes the name of the current webpage — from the webpage itself. Maybe everyone at Apple prefers their bookmarks in the Sidebar instead, but for those of us who are used to the more traditional location, having the Favorites Bar split the tab and its content makes skimming what tabs are where more work than it should be.

To make matters worse, it’s hard to tell at a glance which tab is active and which is inactive. Previous versions of Safari didn’t struggle with this, but Apple has seem to fit to bring the age-old “which iPad app has focus” problem to the browser. Using the Monterey beta, I almost always end up trying to tab to or away from the wrong tab because I can’t quickly register which one is active when looking at the tab bar.

I think Apple has improved the legibility of the selected tab a bit in recent betas, enough that it’s usable, but it’s not as good as it could be.

As to the placement of the Favorites Bar — there’s really no excuse. It breaks the entire metaphor of tabs by placing non-tab-specific content beneath tabs, and divorces the tabs from the URL bar. I’d like to believe that this is a design oversight that Apple will correct at some point, but my fear is that Apple simply doesn’t think the Favorites Bar is a relevant feature in a world where you can browse your favorites from a Safari Start Page.

I like the Start Page a lot, and on the iPad I frequently navigate to favorite sites via the Start Page. But on the Mac I use the Favorites Bar all the time. It’s a valid and valuable Safari feature, and it deserves better than the bad placement it has in the current Safari 15 betas.

Go to the linked site.

Read on Six Colors.

I’ve used AgileBits’s 1Password for more than a decade. I’ve recommended it to friends and family alike. Over time, password management has become more common, and this fall’s operating-system updates will improve Apple’s built-in password management so much that it’s all most people will ever need.

That said, 1Password offers many features Apple doesn’t, and the company has become increasingly active in competing in the enterprise space, with an influx of investment to help it grow rapidly.

Which brings us to this week, when AgileBits announced the beta version of 1Password 8 for the Mac—and walked into a storm of criticism from Mac users. You see, AgileBits chose to build the new version of its Mac app using Electron, a system based on web technologies that’s used by numerous cross-platform apps, including Slack, Skype, and Discord.

I think it’s fair to say that most users don’t care about the tools that a developer uses to write the apps we use. But using a system like Electron does have consequences: Electron apps have a reputation for being slow, eating up a lot of system memory, and—perhaps most offensively—failing to behave like proper, “native” apps on whatever platform they operate.

Just as there are good and bad Catalyst apps, there are good and bad Electron apps. I’m sure that the very best Electron app isn’t as good a Mac app as one written using Apple’s AppKit frameworks—but that doesn’t mean that it can’t be good. And AgileBits has pointed out that it’s using Rust, a robust programming language, to power everything except the user interface, so performance should be more than you’d expect from “just a web app.”

I’m going to withhold judgment of 1Password 8’s interface, mostly because it’s still in beta and I’m sure AgileBits is going to get plenty of feedback about all the ways it fails to measure up to the standards of Mac users. I hope they’re listening and will adjust accordingly.

What’s really causing all this consternation, I think, isn’t 1Password moving to Electron. Electron is a bit of a bogeyman. The root problem is this: 1Password, originally a Mac-forward software developer, has simply decided that the Mac isn’t important enough.

I know that those are harsh words, and that the people at AgileBits would argue with them. But in a blog post by Michael Fey, AgileBits’s VP of Engineering for Client Apps, the company laid out its entire development strategy. It’s a post meant to explain what the company is up to and tamp down a lot of angry hot takes (and probably should’ve been posted the moment it announced the Mac beta).

Fey’s post clearly spells out AgileBits’s priorities. Android and iOS apps are built with native platform frameworks in order to create the best app experience possible on mobile. For iOS, AgileBits decided to use Apple’s new SwiftUI framework rather than the venerable UIKit, in order to skate “to where the puck was going.” Their plan was to use SwiftUI on the Mac, too. In doing so, AgileBits was buying into the vision Apple has for SwiftUI as a tool to build interfaces across all of Apple’s platforms. Unfortunately, it seems that SwiftUI didn’t measure up on the Mac:

Despite the fact that SwiftUI allowed us to share more code than ever between iOS and macOS, we still found ourselves building separate implementations of certain components and sometimes whole features to have them feel at home on their target OS.

I have to read this as a (gently stated) indictment of the current state of SwiftUI. AgileBits was willing to put in the extra work for iOS, because it’s an important platform and SwiftUI is clearly the future there. But implementing it on the Mac required a lot of duplicate work—and what’s worse, SwiftUI apps aren’t compatible with older versions of macOS. AgileBits was planning on covering the older versions with an Electron version, but once it decided the SwiftUI implementation for the Mac was too much work, it pulled the plug—and now plans to ship an Electron version to all Mac users.

I appreciate that AgileBits was originally planning two separate Mac implementations. That’s a sign that the company cared enough to expend extra resources to have a good experience on the Mac, rather than doing what it did to Windows users in deciding Electron was good enough.

And yet as a longtime Mac user, I find AgileBits’s decision-making process incredibly sad. Because as Fey’s post makes clear, at no point did the company consider keeping the Mac-only version of 1Password alive. AgileBits, once a major Mac developer, decided (for legitimate business reasons, of course) that the Mac’s not a platform that deserves its own bespoke app. Or as Fey put it:

We could support as many versions of macOS as we wanted using Apple’s AppKit framework, but that meant adding another frontend toolkit to the mix.

Translation: The Mac’s important, but not important enough to build a version of the app that only works there.

I get it. 1Password has to cover Mac, Windows, Android, iOS, and the web. The Mac is a small platform compared to Windows, and “desktop” is a small platform compared to “mobile.” If I were an engineering manager asking for resources for a bespoke Mac app, I would have a hard time justifying it, too.

And yet, here we are. A banner Mac app and app developer has abandoned a platform-native app for the same web-app wrapper it’s using on Windows. Even if it’s the best Electron app you’ve ever seen, it won’t be the same—and more than that, it says something painful about the future of Mac software.

Apple shares the blame, though. If today’s SwiftUI was truly the One True Tool to unify Apple’s platforms that it’s meant to be in the future, the Mac version of 1Password would be presented in SwiftUI. And perhaps in a year or two, that will happen—after all, the SwiftUI version of 1Password is right over there on iOS, ready to make the move when it’s feasible.

Just because these are decisions made with the cold, hard reality of business priorities and budgets and the current state of developer tools doesn’t make me any less sad, though. A long-running and beloved Mac app is getting thrown in the trash and replaced with a web app. It’s not the first—and unfortunately, it won’t be the last.

Facebook’s ad, helpfully transcribed (and photographed) by MacRumors:

Apple vs. the free internet

Apple plans to roll out a forced software update that will change the internet as we know it — for the worse.

Take your favorite cooking sites or sports blogs. Most are free because they show advertisements.

It’s an unfortunate quirk of the English language that free as freedom and free as in beer are very different meanings of free. But when you see an ad headlined “Apple vs. The Free Internet” most people would jump to the conclusion that this is about free as in freedom.

Not Facebook. They’re arguing about free as in beer.

There’s nothing “forced” about the software update Facebook is talking about either, which is I think is going to be iOS 14.4. It’s actually quite interesting that Apple does not force software updates, or perform them in a sneak hard-to-disable-or-detect manner. What’s “forced” isn’t the software update, but Facebook’s compliance with new rules that they firm

Apple’s change will limit their ability to run personalized ads. To make ends meet, many will have to start charging you subscription fees or adding more in-app purchases, making the internet much more expensive and reducing high-quality free content.

Are we talking about apps or websites? This is a very short ad — I haven’t omitted a word in my blockquoted text — to suddenly go from “cooking sites or sports blogs” to “in-app purchases” without explaining how you got there. But it just goes to show how Facebook has nothing to stand on here.

Apple clearly has no control over anything related to the advertising on websites, other than whatever privacy controls are built into Safari. Apple isn’t limiting the ability of apps on iOS to show personalized ads, either. They’re also not limiting the ability of ad-tracking technology to track users. What they’re doing is giving users awareness of and control over that tracking. In broad terms, changing tracking from opt-out to opt-in.

This may well have the effective of diminishing the effectiveness of personalized advertising. If so, so be it! The information used for tracking belongs to the users whose behavior and interests is being tracked, not to Facebook and the companies, no matter how small and noble, who advertise with them.

Beyond hurting apps and websites, many in the small business community say this change will be devastating for them too, at a time when they face enormous challenges. They need to be able to effectively reach the people most interested in their products and services to grow.

Here come the coronavirus water works. Boo-fucking-hoo. I give some credit to Facebook for putting it so plainly that they’re claiming they need to invade our privacy without our awareness or permission.

Forty-four percent of small to medium businesses started or increased their usage of personalized ads on social media during the pandemic, according to a new Deloitte study. Without personalized ads, Facebook data shows that the average small business advertiser stands to see a cut of over 60% in their sales for every dollar they spend.

Well if Facebook says so, it must be true. If only anyone could remember a time when advertising wasn’t based on privacy-invasive tracking, we could know whether there were any successful small businesses back then.

This whole ad reads more like an ad for Apple’s privacy initiatives than against them. Apple’s response to this campaign is simply to show the very simple easily-understood opt-in dialog box that Facebook is objecting to. Apple’s entire statement:

We believe that this is a simple matter of standing up for our users. Users should know when their data is being collected and shared across other apps and websites — and they should have the choice to allow that or not.

It’s illustrated with this example permission dialog:

That’s what Facebook is objecting to. Given that their privacy nutrition label looks like this, you can almost sympathize.