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:
Antitrust App Store Apple Business Children Garmin Google Google Play Store iOS iOS 18 Legal Match Group Meta Spotify
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:
Artificial Intelligence Business Developer Tool Help Scout Web Web API
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:
Update (2025-05-05): Mark Rowe (Mastodon):
From the log snippet shared in the linked article, the delay during launch is clearly due to syspolicyd doing malware scanning.
Jeff Johnson:
Oakley seems to be claiming, with no empirical evidence, that Macs have a cache of SHA-256 hashes of all bundled files of all apps that have been launched. But where exactly is this cache??? I’ve never seen it or heard of such a thing.
[…]
I think the evidence suggests that what is cached is the result of a malware scan, which for practical purposes would make a lot more sense than a bunch of hashes.
Howard Oakley:
Although I believe there’s convincing evidence that those checks are prolonged to recompute hashes and CDHashes, others are adamant that they are in fact ‘malware scans’. This article considers new evidence.
[…]
Next, the XProtect scan here takes 0.126 seconds, rather than 0.030 seconds in Ventura. This is the result of the huge growth in the number and complexity of the Yara rules used for this scan over the last two years. The Ventura scan was performed using version 2168 of those rules, with a Yara file of 147 KB size and around 218 rules. By version 5296 used in the Sequoia scan, file size had risen to 947 KB with about 381 rules.
Jeff Johnson:
As I see it, there are two main points: (1) the syspolicyd malware check is taking most of the CPU time during the slow app launches, as evidenced by samples, spindumps, and the like; (2) there is no on-disk cache of SHA256 hashes of app bundled files, and thus regenerating the alleged cache cannot explain the slow app launches.
Mark Rowe:
One thing that is interesting is that the AppleSystemPolicy kernel extension has two separate up-calls it can make during an application’s launch. One requests a gatekeeper evaluation (also referred to as an “exec evaluation”), while the other requests a malware scan (also referred to as a “changetime scan”). If it determines the malware scan is needed it does this instead of the normal gatekeeper evaluation. Some applications seem to trigger these malware scans repeatedly.
I’m not entirely clear what the differences are between the two types of scans. The major things I have noticed are that the changetime scan appears to be slower than the exec evaluation, and the evaluation of the yara rules happens inside of syspolicyd when handling a changetime scan (rather than via the XProtect service).
It’s worth noting that AppleSystemPolicy / syspolicyd have additional logging that can be enabled via sudo sysctl -w security.mac.asp.logging_mode=1. Set that, kill syspolicyd, and then look at sudo log stream --debug --signpost --predicate 'sender = "syspolicyd" or sender = "AppleSystemPolicy"' while launching some infrequently-used applications.
Rich Trouton:
But what subsystems in macOS are currently configured to send logging to the unified system log and how are those subsystem configured? For more details, please see below the jump.
See also this 2024 post from Jeff Johnson (Hacker News):
I finally got fed up with slow launches [of FileMerge] and decided to investigate by taking a spindump from Activity Monitor. Spindumps are a nice way to see what exactly is consuming resources on your Mac, because they show the “CPU Time” used by each process on your system and each thread in the process.
From the spindump I discovered that the slow launches are caused by the syspolicyd process, specifically DispatchQueue “com.apple.security.syspolicy.yara”. The backtrace showed syspolicyd calling the yr_rules_scan_file function.
[…]
FileMerge is much smaller, only 2 MB. Why does that take so long? My theory is that syspolicyd also scans the launched app’s linked libraries.
[…]
Here’s a mystery: I see frequent slow launches and malware scans with Google Chrome but never with Google Chrome Beta, despite the fact that the Google Chrome beta app is about the same size as the Google Chrome app. I don’t yet have an explanation for the difference in behavior.
[…]
I’ve now confirmed that disabling SIP does indeed eliminate the syspolicyd malware scan. Xcode launches so fast, it’s beautiful.
Activity Monitor Code Signing FileMerge Gatekeeper Google Chrome Launch Services Mac macOS 15 Sequoia Malware Notarization os_log Security System Integrity Protection
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:
Jettison Mac Mac App macOS 15 Sequoia Storage
