Archive for April 30, 2025

Wednesday, April 30, 2025

Coalition for a Competitive Mobile Experience

Hartley Charlton:

The “Coalition for a Competitive Mobile Experience” is a coordinated effort by [Meta, Spotify, Match Group, and Garmin] to influence federal and state legislation amid mounting pressure to implement digital safeguards for minors. The coalition intends to lobby lawmakers, engage with federal regulators, and support ongoing antitrust enforcement actions against Apple and Google.

The group’s immediate concern is a growing legislative push to require age verification for users downloading mobile apps that may be unsuitable for minors. A law enacted in Utah in March requires app stores to verify a user’s age and obtain parental consent before allowing minors to download certain applications. Additional proposals are reportedly being drafted at the federal level.

The coalition’s members argue that Apple and Google, as gatekeepers of the iOS App Store and Google Play Store respectively, are best positioned to implement uniform age verification protocols across devices and markets.

The name doesn’t really seem to match what they’re asking for here. I do think it makes sense to handle age verification at the OS or store level, rather than separately for each app, but Apple already seems to be going along with this and it’s not clear to me what more they want.

The group does list other goals, however:

Smartphone gatekeepers should not be permitted to discriminate against competing software, apps, or hardware (e.g. earbuds, watches, health wearables) by degrading or throttling the consumer experience. Devices and technology from different manufacturers – and the apps that ride on them – should be able to work seamlessly.

[…]

App store providers should promote competition and choice in the app economy through equal treatment of competing app stores on their operating systems, by providing flexibility in pricing and payment options, avoiding unreasonable interference that limits consumer choice, and not preferencing their own offerings over others.

Previously:

Whither Help Scout?

Daniel Jalkut (Mastodon):

Over the past few weeks, many Help Scout customers have received notice that our plans will change to a new pricing model. Customers who haven’t received notice yet probably will soon. The new system is based on a rolling average of customer interactions. As they cleverly frame it: “the number of contacts you help each month.” Once notified, customers are granted six-months notice before the changes take effect.

The problem, for most Help Scout customers, is that the new system increases their monthly costs. A little for some, and a whole lot for others. The closest approximation to my current $22/month plan starts at $50/month and covers an average of 100 customer interactions per month. They’re obviously sensitive to the sticker shock this will produce, so they’re offering a two-year “Loyalty Discount” of about $20/month, reducing my monthly cost to $28.60/month. That’s still a 30% rise, but coming out to $6, it’s something I can live with.

For larger customers, the cost increase could be much worse. Imagine my company employed a three-person support team, handling customer interactions for 500 unique customers per month. Under current Help Scout pricing, I would pay $66/month. Exactly three times the amount I pay today. But under the new pricing structure, the minimum cost is $266/month.

[…]

[The] big problem with the free tier is that it removes access to the Help Scout API, and the ability to “Export” your data. Restricting data export is very 2005, and I wonder how it will play out in Europe.

I agree that pricing based on the number of customers helped is not a very attractive model, primarily because it isn’t very predictable. Even the old model of $22/month seems like a lot for e-mailing his average of 43 customers per month. My support load, even in a month without a big release, is several times that. Yet they don’t even quote plans with more than 100 contacts per month. This seems strange. For a small company, I don’t really see what value this is really adding, unless the AI tools are amazing.

Previously:

Why Some Apps Sometimes Launch Extremely Slowly

Howard Oakley:

I can now try to explain why some apps may launch extremely slowly, occasionally taking more than 30 seconds, and on some Macs several minutes.

[…]

Log entries don’t provide any information as to what SecTrustEvaluateIfNecessary is likely to perform on these frameworks that can take anything from 0.03-9.96 seconds for each framework.

[…]

The most likely activity to account for these long checking times is computation of SHA-256 hashes for the contents of each item in the app’s Frameworks folder. Thus, these occasional extremely long launch times are most probably due to time taken ‘evaluating trust’ by computing hashes for protected code in the Frameworks folder in the app bundle, when those hashes have been flushed from their cache.

[…]

The only strategy that does appear to stop long launch times in most cases is to disable SIP and, in the case of Apple silicon Macs, to set the security mode to Permissive.

I think it used to be that, once an app passed the initial Gatekeeper check and was no longer quarantined, that was the end of the security checks. Now, Oakley has a chart showing how even code that is no longer quarantined will be rechecked if Launch Services no longer has a record of it, or if the app has been moved. Even if Launch Services does know about it, macOS will do malware and notarization checks if it doesn’t find the app in the cache.

I’m often in Activity Monitor, and a lot of what I see going on is security checks, both when launching apps and also continually checking that apps have proper access to the files they’re working with and the processes they’re sending Apple events to. Sometime I’d like to try turning off SIP and see whether everything feels snappier.

Previously:

Jettison 1.9.2

St. Clair Software (tweet):

The second big thing in this release is a change to accommodate macOS Sequoia 15.4’s increased security around ejecting disks when your login account doesn’t have administrator privileges. I’m not sure why Apple made this change, but errors saying “Higher privileges required by Jettison” began occurring in 15.4. So Jettison now uses a helper application (which does require an admin password to install) so it can still eject your disks despite this somewhat nonsensical restriction.

Version 1.9.1 also improves error reporting when disks can’t be ejected. It uses additional diagnostics to catch situations where an app is keeping a disk busy and includes more information in the resulting error messages. It also preemptively terminates the system’s AMPDevicesAgent process, which can prevent an external disk from ejecting if it houses your Apple Music library.

The first issue hasn’t been a problem for me because I run an admin account. However, I’ve had lots of other problems with Sequoia being unable to eject volumes, and recent versions of Jettison seem to almost entirely fix this.

Previously: