Reputation: 6410
I'm implementing support for JACK (http://www.crudebyte.com/jack-ios/) in my app (http://audulus.com if you're curious).
The JACK app has UI to quit other apps (such as mine) that are connected to it. When I receive the notification from JACK, I'm supposed to quit my app programmatically.
Should JACK instead have UI for disconnecting an app, rather than quitting it?
Relevant information:
http://developer.apple.com/library/ios/#qa/qa1561/_index.html
http://developer.apple.com/library/ios/#documentation/userexperience/conceptual/mobilehig/Introduction/Introduction.html see "Don't Quit Programmatically"
Upvotes: 0
Views: 152
Reputation: 2422
No, it is not OK to quit your app programmatically. Apple's docs are quite clear:
https://developer.apple.com/library/ios/#qa/qa2008/qa1561.html
Upvotes: 0
Reputation: 1374
abort()
is not strictly illegal: Apple's reviewers scan your code for prohibited API calls and abort()
is not among them, speaking from experience. Also consider the language of the QA you link: it speaks only of "discouraging" and "recommending" against the use of exit()
and abort()
.
Along those lines, that QA, and the HIG, seem to suggest that the use of exit()
/abort()
would be improper when it makes for a poor user experience: "put users in control", the HIG says. But if JACK really does present a UI that clearly explains that your app will be closed, and the user chooses to close your app based on that UI, you are actually maintaining control by programmatically quitting the app.
That said, I don't think that's much of a benefit to the user. If you simply disconnect, your app's resources will still be reclaimed if necessary--but if your app doesn't get terminated, then it will start up faster the next time the user launches it. I'd venture that disconnecting would satisfy appearances in JACK, and the user would have check the app switcher bar to even see if you had terminated.
Upvotes: 2