I am reaching out to seek clarification on the usage of exit(0) within an iOS application under specific circumstances, as I have not been able to find concrete guidance on this in the App Store Review Guidelines Context of Our Application: We are developing a mobile game using Cocos2d-JS (Cocos2d-x JavaScript bindings). The game is built in C++ with JavaScript used for game logic, and it runs on both Android and iOS. Occasionally, due to an unrecoverable fatal JavaScript error (e.g., corrupted state or unexpected runtime crash), the game’s screen goes completely black. When this occurs, the rendering engine halts, user interaction becomes impossible, and the app enters a non-functional state. From this point, the only way to return to a working state is to manually terminate and relaunch the app. We are exploring a user-friendly solution where, upon detecting such a critical failure, we present a native UIAlertController to the user explaining the issue and informing them that the app needs to restart. Upon confirmation (i.e., tapping “OK”), we call exit(0) to gracefully close the app, so the user can relaunch it in a working state. Our Question: Is it acceptable to use exit(0) in this very limited and clearly explained context? The intention is to improve the user experience during unrecoverable fatal states that cannot be handled through standard UI or engine resets. I understand that the use of exit(0) is generally discouraged, but in our case: The user explicitly initiates the exit via a native prompt. The app is not quitting on its own or in response to a policy violation. We are not using exit(0) to bypass App Review or circumvent system behavior. There is no mention in the App Review Guidelines explicitly stating whether or not exit(0) is disallowed in such edge cases. Please confirm whether this approach aligns with Apple's policies, or suggest an alternative method for cleanly handling such irrecoverable errors on iOS? Looking forward to your guidance.