Look at your main.c file, it should contain an instruction like this:
int retVal = UIApplicationMain(argc, argv, nil, nil);
where UIApplicationMain is defined as:
int UIApplicationMain ( int argc, char *argv[], NSString *principalClassName, NSString *delegateClassName );
So you just do:
int retVal = UIApplicationMain(argc, argv, nil, <YOUR_DELEGATE_CLASS_NAME>);
and your program will use this delegate class, not the one defined in nib.
Also consider editing the info.plist file, where you must delete all entries about the main nib files that you find there, otherwise your program will fail if you delete xib files from the project.
EDIT: I realized late that you are also asking about how to distinguish an iPad from an iPhone ... and hope this does not include checking if UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPad .
AFAIK, UI_USER_INTERFACE_IDIOM is the official way to do this. Indeed, if you check the definition of this macro, you will see that it is based on the UIDevice class, which returns information about the device on which you run the program. So, I do not see anything wrong with that.
An alternative approach could be to use the UIDevice itself or the UIDevice-Extension , which is an extension of the UIDevice framework.
EDIT 2:
For the questions you ask in the comments:
1) If there is .xibs, I do not need to specify UI_USER_INTERFACE_IDIOM (according to Kotan's message above). Should I choose between feathers and this if ?
I think so; either you do it at the xib level, or programmatically.
2) Do you suggest putting an if to track the device in main.m ? It is true, he works there. Note the change in Xcode 4.2:
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
If you do this programmatically, you should do it where you need it.
The app delegate is probably part of the app, which is device independent, so you won’t need to create an instance for iphone and another for ipad. What I pointed out is that if you do not provide a thread, you must specify a delegate that simply defines a high-level entry point for your application.
In your – application:didFinishLaunchingWithOptions: (entry point to the application) you have to create your user interface that creates this set of objects that you would otherwise define in nib (controllers, views, whatever, a thread is just a mechanism for visually “create” and connect objects, if you don’t do it visually, you do it programmatically) and connect them; Now some of these objects are device-dependent (i.e., views), while others are not. For the former, you can choose which class to create them from using the UI_USER_INTERFACE_IDIOM check.
In addition, you can have two different classes of delegates: one that creates the iphone interface, and the other the ipad interface; it is also a very reasonable approach. It mainly depends on the complexity of your application and what trade-offs you are willing to accept.
This is more or less how I see things, I apologize for being possibly pedantic, but I hope that I can understand.
If you have a lot of if around your application, you can also define a “decorator” function (for example: decoratedClassNameFromGenericClassName:(NSString*) , not to mention verbosity) to hide UI_USER_INTERFACE_IDIOM or any other “decoration” in it in the future. ..