『初めてのiOSアプリケーション』というアップルのドキュメントを読んでいるのですが、次の部分がわかりません。わかりやすく教えて下さい。

フレームワークを用いる場合、そのフレームワーク内の所作を理解していないと 作れません。 それが 大変なんだと思います。

＞「フレームワーク内の所作」というのはどのようなことなのでしょう？

フレームワーク内でどのように 動いてるのかということです。



＞ん、それともデリゲーションではオーバーライドよりも簡単で、メソッドの既定の動作を全て継承（？）した上での追加事項のみを記述するだけで良い、ということでしょうか。

質問の文章からは そこまでは わかりませんが・・・。
一応、オーバーライドとかしなくていいから 「Delegation」パターンが よく使われているよ ということですね。

あと
http://marupeke296.com/DP_Delegate.html
こちらも よく読んでみてください。

拡張されることを意識したフレームワークであれば、サブクラス化してオーバーライドでもそれほど難しさは変わらないとは思います。ただ、必ずしも適切にそのような設計ができるとも限りません。

フレームワークのクラスとして、マウスのクリックを制御するonClickメソッドが実装されていたとします。
フレームワークとしては、onClickメソッドで、クリックされた領域が特定の領域ならウィンドウそのものをドラッグするし、また、別な特定の領域ならウィンドウ内の何かの動きを制御するし、また、他のところであれば、アプリケーションを終了する。というような処理をしていたとします。
ここで、あるアプリケーションでは特定の状況では、終了処理をできないようにしたいとします。

このような変更を想定をしたフレームワークを設計すると、とりあえず思いつくのは、
canFinish();メソッドみたいなのを用意しておいて、親クラスでは、必ずtrueを返しておき、必要があれば、サブクラス化してcanFinishをオーバーライドすればよいという方針です。
ただ、もう一方で、終了可能か判定するDelegateオブジェクトを登録する仕組みにしておくこともできます。この場合は、canFinishの実装が外に出ただけと言ってもいいでしょう。
で、Cocoaは後者のアプローチを使うことが多いよっていうのが、ここでの主張なのかと思います。
オーバーライドするのと、デリゲーションとどちらがよいかはケースバイケースなので、絶対にこちらが優位ということはないです。

強いてデリゲーションを使うメリットを挙げるとすると、プロトコルごとにオブジェクトにまとめることができるためにオブジェクトの意図が明確になるとともに、同様のケースでそのオブジェクトの再利用がしやすい可能性があります。この意図が明確というのは、この例でいえば、アプリケーションの終了だけを意識すればよいということです。親クラスで扱う操作は、アプリケーションの初期化や、その他様々な処理のオーバーライドをすることができますが、そういった要素に対する制御はこのDelegationオブジェクトは持ちえないので、意識しないでよいということです。

逆に言えば、これはサブクラス化の利点とも言ます。デリゲーションではプロトコルの境界を越えて制御することが難しいけれども、サブクラス化をした場合は、その辺りの自由度は高いと言えるでしょうね。自由度と複雑さはある種のトレードオフです。

質問に端的に言うならば、UIapplicationに登録できる特定のDelegationのプロトコルに実装を与えればよく、そのプロトコル以外のことは意識せずに実装できることが利点だと言ってるのでしょうね。