[而不是使用应用程序委托，以便UIApplication单例可以在预定义的时间调用委托方法，仅对UIApplication进行子类化的优点和缺点是什么？ （更新：为什么iOS体系结构使用应用程序委托而不是让人们通过子类化UIApplication并覆盖其各种方法来编写应用程序？）
这是因为当我们创建新的UIView控件时，我们将UIView子类化（update：或我们也将UIViewController子类化）。那么，为什么对于应用程序，我们不继承UIApplication的子类，而是使用委托呢？
同样，来自文档：
子类注释] >>
[您可能决定子类化UIApplication来覆盖sendEvent：或sendAction：to：from：forEvent：实现自定义事件和操作调度。但是，很少有有效的需要扩展此范围类;应用程序委托（UIApplicationDelegate就足够了在大多数情况下。如果要对UIApplication进行子类化，请确保您要使用子类完成的任务。
开发人员通常不这样做的原因是因为没有必要。在大多数情况下，UIApplication均可按需工作。它只需要一些提示就可以在某些预定义的情况下该做什么（这就是为什么它有一个委托）。另一方面，UIView非常通用，我不认为它会被原样使用。它可能是所有iOS世界中最定制的类。
委托是一种核心设计模式。它允许程序各部分之间的职责分离。这个想法是，例如，您绘制到屏幕上的程序部分可能不应该与数据库对话。造成这种情况的原因有很多：
UIView子类可能需要做很多专门的事情。考虑一下UIScrollView，UIImageView，UIWebView等，以及它们的内部工作必须有多么大的不同。但是，它们仍然必须参与视图层次结构，因此子类化才有意义。
我将添加其他未提及的内容：当通过委托方法实现而不是具有重写方法的子类重写/增强/添加行为时，委托消除了对super的调用。我已经看到许多开发人员简单地忘记了调用super来回答自己的Stackoverflow问题（甚至在某些人甚至发布了可能的答案之后）。较新的方法装饰器NS_REQUIRES_SUPER通过警告开发人员（希望他们不会忽略它）来帮助开发人员（希望他们不要忽略它！），但是当调用super的顺序很重要时，它无济于事。我认为Apple认为让开发人员改为实现委托对象是没有错误的，它没有调用超级要求，并且他们甚至还辛苦地将UIResponder方法从UIApplication转发到委托对象。