views:

27988

answers:

15

I am programming an iPhone app, and I need to force it to exit due to certain user actions. After cleaning up memory the app allocated, what's the appropriate method to call to terminate the application?

+9  A: 

Have you tried exit(0)?

Alternatively, [[NSThread mainThread] exit], although I have not tried that it seems like the more appropriate solution.

Brett
exit(0); worked like a charm, thanks for the quick response.
As doing this is an Apple no-no (may cause your app to be refused in the app-store for non-standard interface), consider August's answer as "the right one." FYI, this answer (Brett's) is correct for ALL C programs, and NSThread for all Cocoa programs.
Olie
progrmr
[[NSThread mainThread] exit] causes your application to crash, because exit is not an instance method. exit(0) will send the app to the background in iOS 4. Calling exit(0) again will crash it. At least in the simulator.
Pumbaa80
I have an app which should only be run continuously in the background (closely monitoring location) under certain circumstances, and it will drain the battery very fast otherwise. Turning off the GPS and all client-server communications don't seem to improve battery life when the app is in the background, so it seems like in my case exit(0); is the only option. In fact, under iOS4 the behavior will look identical to the user - app still goes to quick-launch area.
Eric
+1  A: 

In addition to the above, good, answer I just wanted to add, think about cleaning up your memory.

After your application exits, the iPhone OS will automatically clean up anything your application left behind, so freeing all memory manually can just increase the amount of time it takes your application to exit.

Chris Jefferson
+57  A: 

On the iPhone there is no concept of quitting an app. The only action that should cause an app to quit is touching the Home button on the phone, and that's not something developers have access to.

According to Apple, your app should not terminate on its own. Since the user did not hit the Home button, any return to the Home screen gives the user the impression that your app crashed. This is confusing, non-standard behavior and should be avoided.

August
Even if the user has pushed an exit button in the app and confirmed their selection?
As I said, it's non-standard behavior and should be avoided. iPhone apps are not desktop apps. Don't treat them as such.
August
If you plan to submit your app to the AppStore, you may get a note from ITC saying that an "exit button" is non-standard interface. That's what the big button below the screen is for :)
Olie
I can understand Apples opinion but I have a similar situation, my application requires internet access, if it isn't available they should be able to leave the app instead of just having an error message
tigermain
No, not really.Think of the iTunes app. If it doesn't find a connection it tells you. You then navigate away from the app to close it.
August
We have apps that helps people sleep. They want the app to terminate after a set period to reduce battery drain. I think this case is acceptable - as the user is hopefully asleep and can't exit the app manually.
KiwiBastard
I'd still disagree. When they wake up, the app is "gone" leaving the user to wonder what happened. Instead, set a timer in your app, then when the time is up, idle the app -- no activity. An app doing absolutely nothing won't drain the battery.The Springboard is an app, too -- it doesn't shut down just to save energy. Instead, it simply waits for user input.
August
I'm making an exit button to deal with the case when we are unable to initialize the phone on first launch. If there is insufficient free space, I can't build the database I need and the user can't use the app. I can't call applicationWillTerminate because that does lots of work for normal shutdowns and I think it's an ugly hack to instruct the user to push the home button.
Carl Coryell-Martin
My client wants to show a minimal EULA in a UIAlertView upon first launch (with Decline / Accept options). If they decline, the app is to shut down immediately. Otherwise, it proceeds. They only see this once, after installation. What about then? Is it still non-standard?
Joe D'Andrea
@KiwiBastard: The proper way to handle this situation is to turn off the idle timer so that the device doesn't turn itself off and your app continues to run. When your app's internal timer expires, re-enable the idle timer and let the device turn itself off.
Steve Madsen
@jdandrea: Customers have already implicitly accepted Apple's standard EULA or your clients' substitute EULA. I'd expect a rejection from Apple with a EULA dialog at app start-up.
Steve Madsen
@jdandrea Is this app a free app? If not, how do you return the money to those users who reject the "minimal EULA"?
Andrew J. Brehm
This doesn't really answer the question. It's 100% accurate, but I think ideally would have been a comment either on the OP's question or on the accepted answer.
quixoto
+1  A: 

Hm, you may 'have to' quit the application if, say, your application requires an internet connection. You could display an alert and then do something like this:

if ([[UIApplication sharedApplication] respondsToSelector:@selector(terminate)]) {
    [[UIApplication sharedApplication] performSelector:@selector(terminate)];
} else {
    kill(getpid(), SIGINT); 
}
Rob
No, you don't have to terminate it. The iTunes app, for example, when it can't detect a proper connection simply puts up a screen that says they're not connected. It doesn't quit, it simply informs the user of what's going on. The user then quits by tapping the home button.
August
The compass app quits if it's unable to function, though.
jleedev
+5  A: 

After some tests, I can say the following:

  • using the private interface : [UIApplication sharedApplication] will cause the app looking like it crashed, BUT it will call - (void)applicationWillTerminate:(UIApplication *)application before doing so;
  • using exit(0); will also terminate the application, but it will look "normal" (the springboard's icons appears like expected, with the zoom out effect), BUT it won't call the - (void)applicationWillTerminate:(UIApplication *)application delegate method.

My advice:

  1. Manually call the - (void)applicationWillTerminate:(UIApplication *)application on the delegate.
  2. Call exit(0);.
softRoch
+9  A: 

Its not really a way to quit the program, but a way to force people to quit.

UIAlertView *anAlert = [[UIAlertView alloc] initWithTitle:@"Hit Home Button to Exit" message:@"Tell em why they're quiting" delegate:self cancelButtonTitle:nil otherButtonTitles:nil];
[anAlert show];
A: 

Hi,

[[UIApplication sharedApplication] terminateWithSuccess];

It worked fine and automatically calls - (void)applicationWillTerminateUIApplication *)application delegate.

to remove compile time warning add this code @interface UIApplication(MyExtras) - (void)terminateWithSuccess; @end

shiva
using this private API will get your app rejected...
William Denniss
This is a private method, Diego Mercado has explained above that his app got rejected, then why take such a risk.
RVN
+1  A: 

to remove compile time warning add this code @interface UIApplication(MyExtras) - (void)terminateWithSuccess; @end

Oh yeah, using an undocumented interface -- great idea. That's always going to work in future versions of the SDK, right?

Max Tardiveau
+1  A: 

Oh yeah, using an undocumented interface -- great idea. That's always going to work in future versions of the SDK, right?

Yes, and since there are no any recommended way, let's use "-(int) terminate {return 1/0;}" instead - it will work in ALL future versions, seriously.

macroscopic
how do you know for sure? Some CPUs let you set flags so that division by zero won't cause an exception...Also this generates a crash log every time... very bad idea.
William Denniss
Might generare a crash log, but it is the only way available that does not involve using an undocumentd API. Unless doing a division is an undocumented API! (:
corydoras
+2  A: 

My App has been rejected recently bc I've used an undocumented method. Literally:

"Unfortunately it cannot be added to the App Store because it is using a private API. Use of non-public APIs, which as outlined in the iPhone Developer Program License Agreement section 3.3.1 is prohibited:

"3.3.1 Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs."

The non-public API that is included in your application is terminateWithSuccess"

Diego Mercado
+2  A: 

Check the QA here.

http://developer.apple.com/iphone/library/qa/qa2008/qa1561.html

Manu
+2  A: 

From the Apple docs: "Applications calling exit will appear to the user to have crashed" Sorry, I call BS on this one. What if I put up an alert and say:

"You sure you want to quit?" -> "Yes" - "No"

And then quit based on key hit. This is how applications have been quitting since forever. Apple is all of a sudden smarter than that? Give me a break!

linuxaos
+1  A: 

Your ApplicationDelegate gets notified of intentional quitting by the user:

- (void)applicationWillResignActive:(UIApplication *)application {

When I get this notification I just call

        exit(0);

Which does all the work. And the best thing is, it is the useres intent to quit, which is why this should not be a problem calling it there.

On my Audio-App it was necessary to quit the app after people were syncing their device while the music was still playing. As soon as the syncing is complete I get a notification. But quitting the app right after that would actually look like a crash.

So instead I set a flag to REALLY quit the app on the next backgrounding action. Which is okay for refreshing the app after a sync.

L'g
A: 

Are you ok with displaying "more apps from us" or something like that when ur app quits ?

If so, you can launch a URL :) whenever you want to quit the app. The app quits and opens up safari. Apple is not going to stop you from doing that :)

Nikhil
A: 

can you tell me adout how to configure logout in iphone app

apple
This should be a separate question. Please delete this "answer" and read the FAQ.
Alexander Gladysh