We can terminate our application using exit(0) or [[UIApplication sharedApplication] terminate];
I just want to confirm that is this a recommended approach? Like I heard someone was saying Apple may reject your application if there is a case of suicide in your app; (:
The only thing recommended when it comes to terminating through code is to not do it. Cases are rare where it's warranted and you may get rejected if it's not. But exit(0) should be fine.
If you do not want your application to remain in the background when it is quit, you can explicitly opt out of the background execution model by adding the UIApplicationExitsOnSuspend key to your application’s Info.plist file and setting its value to YES.
When an application opts out, it cycles between the not-running, inactive, and active states and never enters the background or suspended states. When the user taps the Home button to quit the application, the applicationWillTerminate: method of the application delegate is called and the application has approximately 5 seconds to clean up and exit before it is terminated and moved back to the not-running state.
Thats seems great;
So its means using exit(0) has chances of rejection from Apple?
Infact i got a project for code review and I found exit(0) at two three places in code; So I want to make sure this thing before suggesting my client about possible work arounds;
Thats seems great;
So its means using exit(0) has chances of rejection from Apple?
Infact i got a project for code review and I found exit(0) at two three places in code; So I want to make sure this thing before suggesting my client about possible work arounds;
exit(0) is a big NO NO by Apple.
Check this out about terminating apps in Apple's iOS Human Interface Guidelines
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.
Just to reiterate, it depends on the situation. I've got several apps into the store that do it. The case is the initial EULA screen with agree/decline buttons, the latter of which would terminate using exit(). Though I don't like the approach personally, especially since App Store provides a way to add an additional EULA if needed.
Just to reiterate, it depends on the situation. I've got several apps into the store that do it. The case is the initial EULA screen with agree/decline buttons, the latter of which would terminate using exit(). Though I don't like the approach personally, especially since App Store provides a way to add an additional EULA if needed.
Additional EULA eh...
Could you please give me more details on this one... wud like to get as much possible details on EULA as possible.. It would be great if you could help me with this...