What is the need of File's owner in xcode xib files? Can i do the same things without file's owner?
A NIB represents an archived object graph. You can load it and that object graph will be reconstituted. The thing, you usually want/need the newly-loaded object graph to be hooked into the already-existing object graph of your program. You don't want it to be standing apart, disconnected from everything else.
There are a few ways that the newly-loaded object graph can get connected to the rest of the program's object graph. One way is the set of proxy objects available in a NIB. There's one for the application object. Another such proxy object is File's Owner. A proxy object is a thing which has a representation in the NIB but is not actually contained in the NIB. Unlike the other objects in the NIB, the objects represented by the proxies are not created when the NIB is loaded, they exist before the NIB is loaded. The proxies allow connections between these pre-existing objects and the objects in the NIB. That's how the new object graph from the NIB can be connected to the existing object graph of your program.
The MainMenu NIB is unusual. It is automatically loaded at application startup by Cocoa, which means there isn't (can't be, really) much in the way of pre-existing objects. That NIB also usually contains an instance of the app delegate, which is a kind of coordinating controller. Usually, though, other types of NIBs would not contain coordinating controllers. (They do contain mediating controllers, like NSArrayController, but that's different.) Rather, coordinating controllers are typically created in code and, often, they are responsible for loading NIBs.
For example, you would use an NSWindowController as the coordinating controller for a window. The window would be defined in a NIB. The window controller would be instantiated in code – whichever code decides that a window should be created – and it would load the NIB. It would be the File's Owner of the NIB, too. It would manage the window and the top-level objects of the NIB.
If you are setting the File's Owner to nil, then a) you probably are dealing with very simple NIBs at this point, and b) you may be leaking top-level objects from the NIBs that you load.
File's owner is the file that contains all the IBOutlets and IBActions for that view. For example, if you have a class "ViewController" and it contains an IBOutlet UIButton *button and -(IBAction)changeViewWhenButtonPressed: (id) sender, the only way you can connect the outlet and action is through setting "ViewController" as your view's File's Owner.
I am relatively certain that Class Identity is synonymous with File's Owner.
Also, these links might be helpful:
What are File Owner and First Responder in iPhone SDK - xCode?
The “file's owner” is the way that objects in the nib can refer to objects outside the nib, and vise versa. (There are also some more complex ways to do that, but they're not used as often.) If you don't need to do that, you don't need to use file's owner.
For the main app, the file's owner is the Application object. You might not have a need to make connections to it, if all your application logic is in a custom class also instantiated in the nib and if you use “first responder” for action messages sent to the application. This is OK.
If you have a document window or popover or something, frequently the file's owner is the object being viewed, and so it's useful to be able to attach ui to it. You might load the same nib many times, each 'owned' by a different instance of that class — a different document or inspected-object or something.
(Fundamentally, the file's owner is just whatever object was passed to the "owner:" parameter in the nib-loading method.)