Looks like you were probably inspired by https://github.com/wumke/react-native-exit-app. Therefore I have to withdraw my concerns from previous comments.

Just because react-native-exit-app does something doesn't mean it's correct... do we have some special reason to trust that package, other than the fact that we use it in the app today?

In D5618#167167, @ashoat wrote:

Just because react-native-exit-app does something doesn't mean it's correct... do we have some special reason to trust that package, other than the fact that we use it in the app today?

On one hand, as stated in my comments, my concern was that usage of exit(0) to programatically close the app might be rejected during Apple review. On the other hand we have been using react-native-exit-app for some time and I don't recall it being rejected during apple review. The question here is how intrinsic apple review is - do they look into the code of libraries used. If they do then using exit(0) should be fine, but if they don't we might get ourselves into trouble. @ashoat do you think it is reasonable to submit our app for mock apple review to validate this code? We did similar thing when we changes Podfile to enable forbidden API compilation in NotificationService.

I did some research, so few conclusions (about iOS because it seems like the only problem):

In stack overflow posts and any other forums, there is a citation from Apple's Human User Guidelines saying that

Don’t Quit Programmatically
Never quit an iOS application programmatically because people tend to interpret this as a crash. However, if external circumstances prevent your application from functioning as intended, you need to tell your users about the situation and explain what they can do about it. Depending on how severe the application malfunction is, you have two choices.
Display an attractive screen that describes the problem and suggests a correction. A screen provides feedback that reassures users that there’s nothing wrong with your application. It puts users in control, letting them decide whether they want to take corrective action and continue using your application or press the Home button and open a different application
If only some of your application's features are not working, display either a screen or an alert when people activate the feature. Display the alert only when people try to access the feature that isn’t functioning.

which says that any app termination is not agreed by apple, which means that no matter we will use exit(0) or something like UIApplication.shared.perform(#selector(NSXPCConnection.suspend)) appp should not pass apple review. On the other hand, there is this post saying exactly about exit function: https://developer.apple.com/library/archive/qa/qa1561/_index.html#//apple_ref/doc/uid/DTS40007952 but it's really old and not sure it's still applicable.

As far as I know, Apple does not check source code but decompiled binary bundle and is looking for certain symbols. This fact makes it riskier because previously there was library code in the bundle, now terminating code is part of the main workflow in native code, which in my opinion increase the risk of app being rejected.

However, I've searched through the newest Human Interface Guidelines as well as App Store Review Guidelines and I couldn't find anything about this, which means apple does not check this anymore or I didn't dive deep enough (it's a lot of information to search through).

@ashoat do you think it is reasonable to submit our app for mock apple review to validate this code?

I think like this is the best what we can do for now (if this is possible) because I am not sure we can rely on posts from stack overflow that are based on outdated apple documentation and looks like it always be risky because apple in the past was rejecting any way of termination.

Let's not think too much harder about this, I think it's fine to land this now and revisit if review rejects us. No reason for mock review, we'll be submitting regularly for regular review anyways