（追記）前提条件が抜けていました。UIViewController での話です。
（追記 6/29）assign はやめて retain にしました。下記を参照のこと。
Cocoaの日々: UIView上のコントロールへの IBOutlet接続は retain で（assign改め）
※以下、内容が古くなってます。
プロパティ見本
@property (nonatomic, assign) IBOutlet UILabel* label;多分これでいいと思う。dealloc時の開放は不要。親の UIViewが Ownershipを持つので、親が relelaseされるタイミングで relelaseされる為。
retainしたら
もし retain した場合、dealloc の他、親 UIView が破棄されるタイミングで releaseが必要になる。後者は didReceiveMemoryWarning が該当する。※通常 retain は不要。
参考
Memory Management Programming Guide: Memory Management of Nib Objects
ここで言う Top-Level Object とは Interface Builder のウィンドウに表示されるレベルのオブジェクトを指す。これは通常 Super View を持たない。
- - - -
結局検証せず。多分これでいいと思うが..
匿名
2010年6月29日 4:48
Memory Management Programming Guideを見ると、アウトレットの動作はプラットフォームに依存するので、OSXはassignに、iPhoneOSはretainに、と書いてあるように読めますが、勘違いでしょうか？
匿名
2010年6月29日 4:48
Memory Management Programming Guideを見ると、アウトレットの動作はプラットフォームに依存するので、OSXはassignに、iPhoneOSはretainに、と書いてあるように読めますが、勘違いでしょうか？
xcatsan says:
2010年6月29日 9:59
指摘の通り、Guideの最初に書いてありますね。これはメモリ不足などで親Viewが突然 releaseされることがあり、その場合でもOutlet先のコントロールを有効にしておくためだと思われます（例：例えば入力途中に親Viewが releaseされた場合でも、その上の UITextFieldの値を viewDidUnload で退避することができる）。
先に示した assign でも上記のような退避用途がなければ動くのですが、親Viewが releaseされたタイミングでうっかりアクセスしてしまうことはありうるので良くないですね。となると retain ＆ viewDidUnload で releaseがよさそうです。
あとで（新エントリで）書き直します。
指摘ありがとうございました。
xcatsan says:
2010年6月29日 9:59
指摘の通り、Guideの最初に書いてありますね。これはメモリ不足などで親Viewが突然 releaseされることがあり、その場合でもOutlet先のコントロールを有効にしておくためだと思われます（例：例えば入力途中に親Viewが releaseされた場合でも、その上の UITextFieldの値を viewDidUnload で退避することができる）。
先に示した assign でも上記のような退避用途がなければ動くのですが、親Viewが releaseされたタイミングでうっかりアクセスしてしまうことはありうるので良くないですね。となると retain ＆ viewDidUnload で releaseがよさそうです。
あとで（新エントリで）書き直します。
指摘ありがとうございました。