Is there any advantage on separating iPhone and iPad classes on a Universal app?

Question

I have a Universal (for both iPhone and iPad) application.

Are there any advantages on separating the iPad from the iPhone classes in the folder structure?

Here is an example of what I mean:

- MyApp
    - Resources
    - Classes
        - iPad
            - SomeUniqueClassOnIPad.h
            - SomeUniqueClassOnIPad.m
        - iPhone
            - SomeUniqueClassOnIPhone.h
            - SomeUniqueClassOnIPhone.m
    - SomeUniversalClass.h
    - SomeUniversalClass.m

Is that common in objective-c projects?

Answer 1

One of the rules within coding is never to have duplicate code, so if your views are doing different things or if data should be handled differently depending on if its an iPad or iPhone (e.g. different data sources?) it should definitely be in different classes, if not.. then no. Use one and the same class.

One thing that is common and which you could implement in such case is a kind of helper, a delegate class if you will, which handles all the common methods and actions that take place in your code.

Golden rule: Write as little code as possible! Less code == more maintainable and has a higher quality. So write as little code as possible yet without affecting your requirements. Also, split up code so its easier to (unit)test and thereby easier to re-use.

I hope that answered your question.

Update
I know there was a terminology for this, just could think of it. Having duplicate code is called "a DRY-violation". DRY stands for Don't Repeat Yourself which is a principle of software development aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures.
More information: DRY on Wikipedia

Answer 2

For me, it depends on the commonality between the iPhone and iPad views. If there are separate xib files but they both contain the same elements it's easy to decide to use the same class.

If the iPhone and iPad xib files have unique elements, then separating the classes could be better.

Another option is to create a base class that is shared by the iPhone and iPad classes for cases you do wish to separate them. The base class would contain the code that is common between them, for example, initiating data requests or a common custom view.