If your class has nothing to do with views (which might be changed), but implement some logic, than I don't think there's any necessity to separate the class. Here is a link that might help: stackoverflow.com/questions/7315551/…
–
superMApr 30 '12 at 13:13

That link gives me even more doubts: stackoverflow.com/a/7315777/807239. Since an iPad app gets more used than an iPhone app, I should rethink all the process behind the UI and how the controllers manage them... Is that correct?
–
Daniel RibeiroApr 30 '12 at 13:16

Basicly, the from device to device UI changes much more than the logic. If your app isn't 'heavy' than I wouldn't re-design the whole processing. I've very little experience in developing for ios (more with android), but I've rarely seen that the logic is implemented separatly for different devices. The same is with android ))
–
superMApr 30 '12 at 13:21

2 Answers
2

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

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.