It's complicated, I think. What does "exit" mean to the user of the app? iOS and tvOS apps typically don't have this concept.
One UI-level problem with the Cancel/Exit approach is that it's modal. Maybe the user didn't really want to stop using your app but wanted to jump out for a moment to do something in another app then come back. Having an alert takes away that option.
At the other end of the scale, your app's process can be terminated if (for example) your app goes into the background, due to some other system-level behavior. If your app had necessary things to do at "exit" time, how would you ensure that happens? (You do have some control of what your app does shortly after it goes into the background, but I'm asking more of a conceptual question at a higher level.)
How would you feel about doing both of the following things, instead of trying to introduce a concept of "exiting" into your app:
-
Implement full state restoration (starting documentation here for UIKit or here for SwiftUI), so that from the user's point of view your app always maintains its state. This more or less looks to the user like your app is running continuously, even in the background, though that's not what is going on under the hood.
-
When your enters the inactive or background state, suspend or pause activities that your app is carrying out, when they're inappropriate for a non-foreground app, such as pausing playback. When your app re-enters the foreground, either resume the suspended activities automatically, or provide UI that the user can use after deciding whether to resume. Mode-less UI is better than modal UI here, in that case. (Choosing whether to deal with this at inactivation or backgrounding depends on the activity, to some extent.)
My guess is that you're asking your question because your app doesn't currently implement state restoration, or at least doesn't implement it completely enough. Exploring this direction might make the question unnecessary.
