Why some apps launch very slowly

For at least the last couple of years, folk have complained that launching some apps takes forever. It has been common for some to take several seconds of bouncing icon time in the Dock, and in a few cases larger apps can take more than 30 seconds to launch. This has been ascribed to ‘security checks’, with some claiming it’s because of delays in online checks of certificates, others attributing it to XProtect, or something else. This article, based on log extracts generously provided by Kristian, demonstrates what’s really holding up these apps.

App launch in Sonoma & Sequoia

I have written at length in previous articles about what happens during app launch in Sonoma 14.6.1 and Sequoia (links at the end). Although there are significant differences, I concentrate here on 14.6.1, as the crucial log records from Kristian are from Sonoma, and its analysis has been more extensive. Key steps are summarised in the diagram below.

For the sake of simplicity here, I’ll confine this article to launching known apps that aren’t in quarantine, and look in particular at Pages, which isn’t notarized, so will behave slightly differently.

Slow Pages

Launch starts with the click action triggering LaunchServices to start launching the app
16.924 Finder sendAction:
16.927 com.apple.launchservices LAUNCH: Opening <private> with 0 items on behalf of 436 role=e flags=8000001 (null)
and LaunchServices then hands the launch over to RunningBoard
16.941 com.apple.launchservices LAUNCH: _LSLaunchThruRunningboard: com.apple.iWork.Pages / <private>

Security checks start early, with amfid
16.966 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
16.969 amfid SecTrustEvaluateIfNecessary
Then, in accordance with system security policy, a Gatekeeper assessment is started
17.031 com.apple.syspolicy.exec GK process assessment: <private> <– (<private>, <private>)
17.031 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>

The security system recognises that the code has already been evaluated, so uses the results from that, and its Gatekeeper scan result returns within 0.01 seconds
17.041 com.apple.syspolicy.exec Code already evaluated, using results.
17.041 com.apple.syspolicy.exec scan returning quickly for code: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: (null)), (bundle_id: (null))
17.041 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null)), 0, 0, 1, 0, 9, 2, 1
17.041 com.apple.syspolicy.exec Allowing evaluation due to package installation: PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 43847487), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null))

So around 0.075 seconds after starting the security assessment, and only 0.117 seconds after double-clicking to launch the app, it looks like it has approval to proceed. But that doesn’t take into account the frameworks the app bundle contains. There are 17 of those that need to be evaluated before launch can proceed. Each is reported with distinctive lines like
17.564 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
17.567 amfid SecTrustEvaluateIfNecessary
the last of which isn’t reported until 20.593 seconds elapsed time, that’s 3.55 seconds after we thought security evaluation was complete, and over 3.6 seconds since the double-click.

From then until Pages opens its preferences with the log entry
20.998 Pages Loading Preferences From User CFPrefsD
is another 0.3 seconds, making a total launch time of just over 4 seconds, of which almost 90% was spend checking frameworks.

Performing the same launch in a VM running macOS 14.7.5 on 4 P cores with 16 GB memory on an M4 Pro host is a little faster, and only takes 2.5 seconds to check its frameworks.

Fast Pages

Launching Pages in a Mac mini M4 Pro running Sequoia 15.4.1 is, as you’d expect, significantly quicker. Tracing corresponding log entries reveals where much of the time is saved.

00.513 Finder sendAction:
00.715 amfid Entering OSX path for /Applications/Pages.app/Contents/MacOS/Pages
00.741 com.apple.syspolicy.exec GK process assessment: <private> <– (<private>, <private>)
00.741 com.apple.syspolicy.exec Gatekeeper assessment rooted at: <private>

00.751 com.apple.syspolicy.exec Code already evaluated, using results.
00.751 com.apple.syspolicy.exec scan returning quickly for code: PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: (null)), (bundle_id: (null))
00.751 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null)), 0, 0, 1, 0, 9, 2, 1
00.751 com.apple.syspolicy.exec Allowing evaluation due to package installation: PST: (path: c1e18d07e864cabb), (team: 74J34U3R6X), (id: com.apple.iWork.Pages), (bundle_id: (null))

Framework checks start with
00.772 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/TSKit.framework/Versions/A/TSKit
00.773 amfid SecKeyVerifySignature
and progress through to
00.843 amfid Entering OSX path for /Applications/Pages.app/Contents/Frameworks/AppleMediaServicesKit.framework/Versions/A/AppleMediaServicesKit
00.843 amfid SecKeyVerifySignature
with Pages opening its preferences at the end
01.087 Pages Loading Preferences From User CFPrefsD

Here, framework checks took a mere 0.07 seconds, and the total time from double-click to preferences was only 0.574 seconds.

Slow Calibre

Pages is an example of an app that completed its security checks without error or problems. Many of the apps that can be slowest to launch have additional problems, as shown in Calibre.

Progress through early checks proceeds briskly:
31.505 Finder sendAction:
31.567 com.apple.syspolicy.exec GK process assessment: <private> <– (<private>, <private>)
31.576 com.apple.syspolicy.exec GK evaluateScanResult: 3, PST: (vuid: 0EE388E2-7032-42CB-9BC1-D1E5EC01AD18), (objid: 937222), (team: NTY7FVCEKP), (id: net.kovidgoyal.calibre), (bundle_id: (null)), 0, 0, 1, 0, 4, 4, 0

But when its frameworks come up for checking, there’s a problem reported in every one of them
31.614 kernel AMFI: constraint violation /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib has entitlements but is not a main binary
31.614 amfid Entering OSX path for /Applications/calibre.app/Contents/Frameworks/calibre-launcher.dylib
31.615 amfid SecTrustEvaluateIfNecessary

AMFI runs a total of 68 checks on those frameworks in the app bundle before reaching the last
35.988 kernel AMFI: constraint violation /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib has entitlements but is not a main binary
35.989 amfid Entering OSX path for /Applications/calibre.app/Contents/PlugIns/platforms/libqcocoa.dylib
35.989 amfid SecTrustEvaluateIfNecessary

And preferences are opened 4.635 seconds after the double-click
36.140 calibre Loading Preferences From User CFPrefsD

Workarounds

Many different workarounds have been proposed blindly to tackle a problem that doesn’t appear to have properly diagnosed in the first place. I believe that it is possible, although difficult, to disable AMFI, but that’s like going out, leaving your front door wide open, and telling everyone you meet to go in and help themselves. Without AMFI’s protection, your Mac is a sitting duck.

As these framework checks are occurring outside Gatekeeper, and without XProtect even being thought about, mutilating any other part of your Mac’s security systems isn’t going to achieve anything other than exposing it to increased risk. Some report subjectively that moving apps around can bring relief, but it seems temporary, as ultimately AMFI will get those frameworks whatever you try to do with them. And so it should, if you want your Mac to remain secure.

I’ve seen no evidence that this is a bug, nor that it’s ‘fixed’ in Sequoia, which it isn’t. At first I suspected it might have been exacerbated or unmasked by launching apps using other apps, rather than in the Finder, but that’s not true either. What is abundantly clear from my results above is that a faster Apple silicon Mac does the trick, but please don’t misinterpret that as designing security to encourage users to upgrade to newer models, which simply doesn’t follow.

Conclusions

Significant delays in launching apps can result from security checks of their frameworks.
Known apps that aren’t in quarantine don’t normally undergo online certificate checks or XProtect scans, and normally complete Gatekeeper checks swiftly.
The most likely cause of delayed launching of a known app that isn’t in quarantine is protracted security checks of its frameworks.
Those delays are usually negligible in more recent Apple silicon Macs.
There doesn’t appear to be any lasting workaround to expedite launch.
Investigating delayed launches requires careful log analysis.