Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've heard a rumor that you cannot have an explicit quit button on your app when it goes to the Apple App Store, can anyone verify this? It seems that most applications do not have one, and there is no explicit quit. How to developers handle quitting in general on iOS applications?

Note: I am using Unity, C#, and Xcode to develop my game for the iPad.

share|improve this question
    
I think this question is off-topic for this site; the main query seems to be about the acceptability of a quit button. Perhaps you could edit the question to be more about how to handle iOS-specific termination in Unity, if that's what you're really after. That would have more of a game development focus. –  Josh Petrie Sep 25 '11 at 23:57
    
Yes. Specifically I want to know how to handle iOS Specific termination in Unit, which I believe I addressed in my last question and @JoshPetrie answered. –  Phoenix401 Sep 26 '11 at 13:33

3 Answers 3

up vote 5 down vote accepted

There is no mention of such in the app store review guidelines; however you are strongly encouraged to comply with the iOS HIG which, among other things, suggests never quitting programmatically and always being ready to stop in response to the Home button (iOS Developer account required to view those links, I think).

Because of the above, I would not be surprised if Apple rejected an app with an explicit "quit" button. Even if they didn't I would suggest not implementing one: it's redundant UI, and UI space is at a premium on such a small screen. I've never seen an application with a quit button, and would probably be annoyed by it, because it would suggest to me a lazy developer who did not take the time to understand his or her platform properly.

Users quit an application via the Home button. iOS will send your application delegate various "about to become inactive" messages, as well as "about to terminate" messages when the OS is going to kill your app for good (as a result of multitasking load balancing, for example). The default templates created by Xcode for iOS applications already implement some of these message selectors.

Since you're using Unity, you may not have direct access to these selectors. You may need to hook something from Unity's scripting API to find out when you are being suspended, or Unity may just expose this via's it's normal "application is quitting" code path -- whatever that is. Unity's got a section in their documentation detailing some iOS specifics.

share|improve this answer

Sure, any application can have one. But the real question is, should it have one? And the iOS Human Interface Guidelines (as mentioned earlier), suggest that no, it shouldn't have this ability.

That said, you will have to manage the game's state when the user switches to another app, turns off the phone, or it just dies. Obviously you don't want to touch and resume a game, and have it throw you directly into active gameplay.

My own approach would be to detect when the game is no longer active, and then to have it automatically pause the game, complete with a "Game paused, touch to continue" prompt on screen.

I also would spend a lot of time checking out iOS apps and games that were similar to what I had in mind, and look at how they handle this case. I think you'll find few (if any) apps have an explicit "quit" option which ought to tell you a) what users are used to, and b) what makes an app fit Apple's acceptance standards.

share|improve this answer
    
Yes, in fact I am already doing this [responding to suspend actions] and there isn't right now any reason why the game cannot be sent a quit action by iOS and simply close out (no saving necessary), but I think I would like to look more into the interface standards just to cover all the bases. –  Phoenix401 Sep 26 '11 at 13:36

No.

There are no built in programmatic mechanisms to exit an application by design. I think this is Apple's way of creating a consistent experience across apps.

That said if you have to do it in your app you can do so by causing a crash for example by calling.

free(1);

To the user the app just closes as this is Apple's way of controlling user experience for crashes.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.