I am working on an app that I feel would enhance the user experience if it provided an option for users to quit the app. This option would only be available from one of its screens.
I have researched this idea and I am fully aware of the following:
Technical Q&A QA1561
Quit iOS Application Programmatically with UIAlertView
Is it possible to quit iOS app after we do some checks
However, what I am proposing is a situation where one of the screens provides users with a range of options via a number of buttons. Each button has an icon and is clearly labelled.
Since the Quit App option would allow users to manually quit the app, the user will not then think the app has crashed. And, because the function of the button is to quit the app, then this isn't a case where the app was unable to provide its intended function. In fact, it's the exact opposite as the intended function is to quit the app.
My question is:
If this is a user-selectable option that is clearly labelled in terms of what it does, will Apple still reject it? If so, would it make any difference if the app provided a 'confirmation alert' after the user selects the option?
I am hoping that someone can either:
share their experience of having tried the same approach
refer me to an existing app that does this (as an example that it would be approved)
Actually about this Apple provide detailed answer in this link.
Kindly follow it.
Basic Snapshot :
In iOS, the user presses the Home button to close applications. Should
your application have conditions in which it cannot provide its
intended function, the recommended approach is to display an alert for
the user that indicates the nature of the problem and possible actions
the user could take — turning on WiFi, enabling Location Services,
etc. Allow the user to terminate the application at their own
discretion.
Apple is says gave the Warning to developer to do not call exit methods forcefully.
Warning: Do not call the exit function. Applications calling exit will
appear to the user to have crashed, rather than performing a graceful
termination and animating back to the Home screen.
If during development or testing it is necessary to terminate your application, the abort function, or assert macro is recommended.
Hope this will help you.
Related
I've been developing iOS apps for enterprise use for several years now. It was an adjustment from having spent many (!) years developing desktop apps. One of the first things I learned very early on was that it is frowned upon for an app to kill itself. The posters in the Apple dev forum were downright hostile about it, which is a reason I never go there anymore.
Now I have an app that has very critical functions, and it requires that the user accept the terms and conditions before using the app, and that the app will not function if the terms have not been accepted. The choice is there to accept or to decline, but it seems like the best thing to do when the user actively declines is to kill the app entirely.
My question is, under those circumstances, would there be anything wrong with that? Will I be damned to developers hell for eternity?
You can change the interaction here.
Instead of accept (and use the app) or decline (and never be able to use the app) change it to accept (and use the app) or nothing.
If the user does not accept then they cannot use the app. They do not have to decline anything. Absence of acceptance is all you need.
If they don't accept then don't do anything. They can always come back later and accept and start using the app.
Why kill an app on a declying? I would rather just leave a user at the same screen with no actions before he puts acceptance checkbox, disabling all buttons
If you make the app kill itself, Apple won't let you post it on the App Store.
You should adjust your User Experience to the case of the user declining the terms and conditions.
For example, show a screen saying that the app can't be used unless terms are accepted, with a button saying "Take me back" that takes the user back to the terms screen.
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"
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.
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
Is there a way for an app which does this (and requires no UI) to be accepted by Apple's App Review process?
I know that simply putting exit(0) in applicationDidFinishLaunching:withOptions: will be rejected, but what if the exit(0) is called only upon completing a TCP transaction? Does Apple reject any attempt to exit your app?
Here's what I'm looking for. I make a file in some iOS app (a picture for instance) and I open it up in my app with "Open In...". I'd like for my app to perform a function which requires no user input (i.e., sending it to a preconfigured network location). Then I would like for my app to quit, returning to the app from which I used the "Open In..." feature.
I take it that if I am completely forbidden from exiting, then the most optimal possible workflow is probably the 4-finger swipe back to the calling app. It is also not very clear what my app would do when opened regularly (from the home screen), but that's not really a big problem.
What you want to do can't be done plus there is no point. Apple will never approve such an app. All apps must have a useful purpose in their own right. If the only use of your app is to send files from other apps to some server, it is of no use by itself. Apple expects each app to have a fully functional and useful user interface.
But all of that aside, here is why this can't be done - You are given no way to relaunch the calling app. When your app is launched, ultimately the UIApplicationDelegate method application:openURL:sourceApplication:annotation: will be called. This tells you what file to process and it gives you the bundle id of the requesting app. But there is no information that allows you to launch the app that launched yours. There is no API that let's you return to the previous app.
The only possibility is if the calling app explicitly launches your app and provides a return URL. But this eliminates and general use. Any app that would work with your app would need specific code in place to support your app. Obviously this is far from a general purpose solution.
BTW - having your app simply exit is of no benefit as that doesn't return the user to the previous app.
Assuming you own both apps, you don't have to exit your app at all. In fact, doing so wouldn't bring the other app back to the foreground anyway.
Just use the standard linking technique in both directions.
I have an in-app subscription product. When the app is loaded, I present a "subscribe now" screen to initiate the buy process. If the user cancels, the application MUST close/move to background/terminate since they have refused the service. What is the best method to use to do this?
This situation is addressed in the iOS Human Interface Guidelines, under "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
For example, consider the iTunes Store or App Store apps, which are useless without a network connection. If you put your device in Airplane Mode and then launch either one, they will display a large Wi-Fi icon with a message saying an Internet connection is required. (I think an alert offers to disable Airplane Mode, but if you tap Cancel you'll see what I mean; the app will not quit.)
Be assured, if you simply force-quit the app, Apple will reject it.
I don't know if it's allowed.. but you can use
Exit(0);
OR:
[[NSThread mainThread] exit];
The application will close.
Best not to do that. You could just display another screen after they hit cancel explaining why they can't continue and give them a button to try again.
I know Apple frowns upon closing the app because the user might think it crashed.
So how do I make it quit intentionally with an exception that doesn't get caught when the user goes back to the home screen? Also, would this be rejected by the App Store?
I wrote this answer to another question. It an extract from the Apple Human interface guidelines and should help you understand why you shouldn't quit programatically.
You shouldn't force close an app as the standard way to terminate an application is to press the home button (or use the multitasking bar)
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.
Source
Apple will most likely reject it as a violation of the human interface guidelines, so it really doesn't matter how to do it.
So how do I make it quit intentionally with an exception that doesn't
get caught when the user goes back to the home screen?
You don't. If your app is "done," just go back to the initial state. Reset all your variables, release your view controllers, whatever. Pretend that the app actually did terminate, and that the user started it up again. You'll be happy, your users will be happy, and Apple will be happy.
An alternative, if your app truly can't continue for some reason, is to display a message that explains the situation to the user and tells them how to resolve the problem. Leave that message visible until the user leaves the app by pressing the Home button. This can be the only reasonable way to deal with situations where some resource such as network access is missing.
Also, would this be rejected by the App Store?
Nobody can say that for certain other than Apple, but I think the probability of rejection is high.
Please see the answer to this question:
Forcing a background application to terminate in iOS simulator
It will tell you how to setup your application to terminate instead of backgrounding when the user hits the home button.
If you don't want to do that, I recommend you should instead release resources when your delegate's applicationDidEnterBackground fires. I think that is your safest bet. More than one of us say what you're wanting to do is not ideal.