Additional questions: 1. What does “timely” handling of VoIP pushes mean? After receiving a VoIP push in: -(void)pushRegistry:(PKPushRegistry *)registry didReceiveIncomingPushWithPayload:(PKPushPayload *)payload forType:(PKPushType)type withCompletionHandler:(void (^)(void))completion; If the app does not promptly present a CallKit incoming call or does not call the completion handler in time, it may be considered a violation. My questions are: What exactly counts as “timely”? Does CallKit need to be reported within the same runloop, or within a specific time window (for example, within 1 second)? Does the completion handler also have a similar timing requirement? 2. Cold launch delay When the app is not running, a VoIP push will cause the system to launch the app before calling didReceiveIncomingPushWithPayload. If the app launch process is slow, there may be a long delay between app launch and the push callback. Could this delay potentially cause the system to treat the push as improperly handled, resulting in a VoIP push restriction? 3. Ending CallKit quickly when the app is in the foreground When the app is already in the foreground, our current flow is: Receive VoIP push Report the call to CallKit After a very short delay (around 0.5 seconds), programmatically end the CallKit call Present the custom in-app call UI Could this behavior potentially be considered misuse of VoIP push or CallKit by the system? 4. Recovery after VoIP push restriction If the system determines that the app has violated VoIP push rules and VoIP pushes stop arriving, the only workaround we are currently aware of is: The user uninstalls and reinstalls the app Are there any other ways to recover from this state while preserving user data? Also, if the user does nothing, will the system automatically remove the restriction after some time? Thanks!