@doxzhao amfid: https://discussions.apple.com/thread/6692859 amfid -- The mobile file integrity daemon. amfid amfid is a daemon that checks the integrity of files running on the system. It is not intended to be invoked directly. It seems to block running unsigned code, no idea why it appears in our logs, but that sounds similar with not finding "application-identifier nor keychain-access-groups entitlements"...

I have the same logs when installing and starting the app built and installed directly from XCode, with more repetition on iOS15(15.6.1) than on iOS16(16.0.2 20A380) as well. default 10:00:17.569111+0200 SpringBoard [Main] dispatch event: <SBTransitionSwitcherModifierEvent: 0x281f83f00; type: MainTransition; transitionID: -- a UUID --; phase: Animate; animated: YES; fromAppLayout: 0x0; toAppLayout: <SBAppLayout: 0x28386f8c0; primary: com.myapp.apps:default; environment: main>; fromEnvironmentMode: home-screen; toEnvironmentMode: application; pendingTermination: {( )}; activating: <SBAppLayout: 0x28386f8c0; primary: com.myapp.apps:default; environment: main>; dosidoTransitionDirection: 0> default 10:00:17.569169+0200 securityd trustd[127]/1#12 LF=0 copy_parent_certificates Error Domain=NSOSStatusErrorDomain Code=-34018 "Client has neither application-identifier nor keychain-access-groups entitlements" UserInfo={numberOfErrorsDeep=0, NSDescription=Client has neither application-identifier nor keychain-access-groups entitlements} default 10:00:17.569524+0200 securityd trustd[127]/1#12 LF=0 copy_parent_certificates Error Domain=NSOSStatusErrorDomain Code=-34018 "Client has neither application-identifier nor keychain-access-groups entitlements" UserInfo={numberOfErrorsDeep=0, NSDescription=Client has neither application-identifier nor keychain-access-groups entitlements} default 10:00:17.570209+0200 SpringBoard adding status bar settings assertion: <SBAppStatusBarSettingsAssertion: aHexValue> { settings = <SBAppStatusBarSettings: aHexValue; alpha: 0>; level = app switcher; reason = kSBMainAppSwitcherStatusBarReason; } default 10:00:17.570281+0200 trustd cert[0]: IssuerCommonName =(path)[]> 0 default 10:00:17.570503+0200 amfid Trust evaluate failure: [leaf IssuerCommonName LeafMarkerOid SubjectCommonName] default 10:00:17.572022+0200 amfid elided platform fast path for key: -- the key -- default 10:00:17.572043+0200 amfid Authoritative I also suspect that it slows down the startup of the app, leading to prevent PushKit delivering a VoIP notification in time on slow devices, as callservicesd kills the app before reaching didFinishLaunchingWithOptions: https://developer.apple.com/forums/thread/717403 The project has 4 targets, App, NotificationContent, NotificationServ and Stickers (and Test), the 3 first have App Groups and Keychain Sharing capabilities and Entitlement Files with entries for the these 2 capabilities. KeyChainAccess is used in the project with SwiftPackageManager.

Thanks for your answer crystal_matrx All is done in the main thread, init and queue. As I wrote, the VoIP token and the PushKit notification are not delivered in the app in time, so CallKit cannot be called (and that before it happens too many times and PushKit stops waking up the app). After more research and speaking with Apple Developer Technical Support there seems to be 2 problems, linked with the app startup time: 1 - Too much time spent in AppDelegate didFinishLaunchingWithOptions Delaying all services creation (firebase etc.) to later (like in viewDidAppear of initial UIViewControler) helped to display CallKit more often, but not always because of the second point. 2 - Too much time to reach AppDelegate didFinishLaunchingWithOptions Using profiling and AppLaunch, on my old device dyld can take a lot of time and sometime according to logs the app doesn't even reach didFinishLaunchingWithOptions before being killed by callservicesd. This part is still not clear, that can be due to being in a debug environment, making build configuration as "Release" and disabling as many options as possible did not help. So even if point 1 helped, on a slow device unplugged with locked screen, the app being killed and a few heavy apps started before, sometime VoIP pushes still do not reach the point to display CallKit. Maybe a full release build will solve the problem of point 2., something I could not try yet using TestFlight due to VoIP backend not being in prod yet.