SDK并没有提供终止应用程序的方法。要想终止应用程序，苹果推荐的唯一的方式是按下Home按钮。
但是Foundation框架中集成了Darwin框架，从而我们可以使用C函数exit(0)来终止Application。当然这只是对于企业开发者而言。对于个人开发者，你这样做的唯一结果就是，你的应用将会被苹果商店拒绝。
UIApplication的openUrl方法则是退出应用程序的另一种方法。当你在代码中调用OpenURL方法时，你的App进程会被终止（挂起），另一个App则被唤醒。
当然两种退出App的机制和最终效果并不相同。当你使用exit(0)退出程序时，你的App并不仅仅是退出前台，程序所占用的内存也被清除了——这是不可恢复的。如果再次Launch这个App，iOS将重新从磁盘中读取二进制——这是一份全新的App映像。
openURL则不同，它仅仅是把你的程序挂起，这是可恢复的——你的App仅仅是从前台退出，但后台中仍然存在着。用户可以在某个时候“唤醒”它，于是你的App又回来了，此时应用程序的状态仍然唤醒之前的状态。当然，万一你运气不好，iOS也会将你的App彻底从内存中回收，一如exit(0)所做的一样——这一般是系统内存紧张的时候。
这两种方法在某些时候可能需要并存。例如，我们想在App退出之前，唤醒另一个App，比如Safari。同时我们希望自己的App是真正的“退出”，回收App的所有内存。
这是一个“悖论”。因为无论exit(0)还是openURL，一旦执行之后，操作系统就会终止进程的执行。只要执行二者中的任何一句语句，另外一个语句就无法执行——因为进程已经终止了。
但在某种情况下，通过对iOS多任务机制的巧妙利用，这个悖论却是真实成立的。
例如，我们可以利用如下O-C代码来实现这个目的：
[self performSelector:@selector(exitApp)withObject:nil afterDelay:0.5];
[[UIApplication sharedApplication]openURL:
[NSURLURLWithString:@"appScheme://"]];
exitApp方法实际上就是一句代码exit(0)。
这样二者就实现并存了。
首先，我们让exit(0)延迟0.5秒再执行，而在此之前openURL当然早就执行完了。
performSelector:afterDelay方法将会调度一个任务在某个时间后执行。当然，这个时间不能太长，因为iOS允许app在进入后台之后仍然有一段“存活”时间，但是这个时间不能太长，这样即算后面的openURL方法执行后，App仍然处于存活状态，也就有机会去执行所调度任务（即exit(0)）。
这段代码在iOS 5以后都工作得很好。但不幸的是，Swift语言来了。
在Swift中，performSelector方法不再存在。
当然，我们立即想到了另一个替代方案，即GCD：
var dispatchTime: dispatch_time_t =dispatch_time(
DISPATCH_TIME_NOW,Int64(0.5 * Double(NSEC_PER_SEC)))
dispatch_after(dispatchTime,
dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,0),
{
exit(0)
})
UIApplication.sharedApplication().openURL(NSURL(string:"appScheme://")!)
然而，这段代码根本不能工作。原因未知，很能是一个新的Bug，但我至今没有看到有人向苹果Radar过这个问题。
经过一番探索，我发现了让上述代码工作的方法，那就是将上述代码包裹在新的GCD异步块中：
dispatch_async(dispatch_get_main_queue(),{()->Voidin
var dispatchTime: dispatch_time_t = dispatch_time(DISPATCH_TIME_NOW,Int64(0.5 * Double(NSEC_PER_SEC)))
dispatch_after(dispatchTime, dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_BACKGROUND,0), {
exit(0)
})
UIApplication.sharedApplication().openURL(NSURL(string:"appScheme://")!)
})
原文：http://blog.csdn.net/kmyhy/article/details/42393125