static関数として記述する。}}呼び出し順序は次の通り。Frameworkがロードされた時に1度だけ呼び出される。関数名はエクスポートしない(ビルド設定の「書き出されないシンボルのファイル」で指定する)。複数定義することができる。呼び出し順はコンパイラが遭遇した順番となる。アプリケーションプログラム実行時の引数を参照することもできる。終了時処理を用意することができる。同様に複数作成できる。エクスポートしないようにする。Framework内のすべてのシンボルをエクスポートする。Frameworkでエクスポートされているすべてのシンボルを読み込む。この事は外部に公開する必要の無い内部的な関数やメソッドも対象となることを意味する。この為、シンボル数が多くなりロード時間の増加、所要メモリの増加といった問題が生じるケースもある。これを避けるためにXcodeでは公開するシンボルを明示的に指定してリンクさせることができるオプションが用意されている。エクスポートするシンボルを書きだしたテキストファイル(*.txt)を用意する。コマンドで一覧したものを使う。:これらを元に次のようなファイルを作成する。付けた場合は無視される。ターゲットの情報を開きビルドタブ内の「書きだされるシンボルのファイル」にこのファイル名を指定する。逆に一部のシンボルのみ公開したくない場合はその一覧が記載されたテキストファイルを作成し「書き出されないシンボルのファイル」に指定する。とそれ以外の2つに分けられる。/Library/Frameworksシステムで標準に用意されているディレクトリ。複数のアプリケーション間で共有して利用する場合はこのディレクトリへ配置する。メリットは、コンパイル時および実行時に標準で検索対象となること。/Network/Library/Frameworks、その他自由に配置することができる。Frameworkなどはこれらのディレクトリへ配置する。自由に配置できる反面、(1)標準の検索対象にならない(2)起動時間が遅くなるといったデメリットがある。(1)については、アプリケーションプログラム側でビルドする時に設定する必要がある。(2)については、ネットワーク上の他のサーバに上記ディレクトリが存在する場合はそれを利用するアプリケーションの起動に時間がかかる場合があることを意味している。/System/Library/FrameworksFrameworkの配置場所として実はもう一つこのディレクトリが存在する。Framework検索順序は次の通り。開発から配布・利用までの運用パターンを考えてみる。用意して開発時にヘッダファイルを使用し、実行時にリンクして使用する。インストールする必要がある。複数のアプリケーション(プロセス)で共有することができる。(embed)することもできる。Frameworkがインストールされている必要は無い。メリットは、配布が簡単で確実に実行できること。場合は開発時のみ使われる。静的ライブラリはアプリケーションバイナリの一部として構成され一緒に配布される。動的ライブラリを配置することはできない。この為、開発時のみに使う静的ライブラリとヘッダファイルのプレースホルダ的な使い方となる。Introductionソフトウェア配布のガイド。Frameworkの配布方法についても触れられている。Guidelinesソフトウェア起動時間に関するガイド。Tipsも記載されている。