Bon alors je ne suis pas un expert en théorie, donc je vais sûrement me faire reprendre de volée par les puristes genre tatouille & cie mais tant pis.
Voilà comment je procède de manière perso si ça peut t'aider, mais ça n'engage que moi :
- je commence par lister les fonctionnalités voulues de l'appli en rentrant assez dans le détail, sur papier ou document texte, peu importe.
- une fois terminé, je refais le tour de ce que j'ai listé, et si je vois que c'est allé trop loin sur certains trucs, je les supprime ; pas pour ne pas me casser la tête, mais parce que trop de fonctionnalités tendent à complexifier l'appli et son interface, et je préfère éviter.
- quand c'est fait, j'ai déjà une petite idée de l'interface générale en tête : soit c'est très simple et je me passe de maquettes, soit je fais des petits dessins sur papier avec l'interface schématisée et les liens entre les différents écrans, soit ça se passe dans les règles de l'art et c'est écran par écran en faisant des maquettes sous Photoshop (des éléments d'interface sont facilement trouvables en PSD) : ça permet de se rendre compte tout de suite si un truc ne va pas (écrans mal enchaînés, répétition d'infos, etc.).
Au niveau du code ensuite, je pense qu'il ne faut pas tant se casser la tête que ça pour respecter le pattern MVC car Cocoa EST MVC.
- les views, ça passe évidemment par les .xibs, avec les outlets linkés aux controllers correspondants.
- les controllers, la classe UIViewController est là pour ça ; un truc très simple pour se rendre compte si on respecte bien MVC, c'est de garder à l'esprit que depuis les applis universelles, on peut utiliser un UIViewController pour deux xibs : un pour iPhone, un pour iPad. Si on se rend compte qu'on peut avoir deux interfaces différentes s'appuyant sur le même controller, je pense qu'on peut dire que c'est bon.
- le modèle, souvent c'est là que je triche un peu : pour le modèle de données en lui-même, encore une fois Core Data est là pour aider et on peut difficilement se tromper. Pour les traitements des données, j'ai souvent tendance à les inclure dans les classes des ViewControllers lorsque ce sont des traitements simples (mauvaise façon je pense), ou je passe par un NSObject à part (ce qui permet d'effectuer les mêmes traitements depuis plusieurs ViewControllers).
Après, encore une fois, je ne garantis pas que ce soit la bonne procédure.
Cela dit, à mon avis, le plus important sur une appli c'est surtout le travail à faire sur le listage des fonctionnalités et la clarté et simplicité de l'interface ; si tu as ça, lorsque tu attaqueras l'appli au niveau du code, tu te rendras vite compte si tu pars dans la bonne direction ou pas, en fonction du nombre de galères que tu te frapperas.
Quelques petites remarques, qui encore une fois n'engagent que moi :
- l'habitude ça ne s'invente pas, plus tu coderas et plus tu gagneras en vision d'ensemble, tu sauras direct les erreurs à ne pas faire et les contraintes liées à ce que tu souhaites coder, et plus vite tu utiliseras les composants standards (une UITableView par exemple, au début c'est un peu déroutant, mais avec l'habitude ça se code très vite).
- l'optimisation, les tests et le travail sur la stabilité, c'est très important ; perso, je remarque une baisse générale de la qualité des applis, il suffit de regarder Facebook qui me claque dans les mains au moins 5 fois par jour depuis les dernières mises à jour pour se rendre compte que c'est juste insupportable ; alors surtout, travailler sur l'optimisation, la tolérance aux pertes de réseau, la mémoire, les bugs... une appli stable c'est quand même bien agréable.
- enfin c'est très personnel, mais je préfère une appli au design épuré qui tourne très rapidement et qui fait ce que je lui demande, plutôt qu'une appli au design tellement travaillé qu'il faut l'utiliser plusieurs fois pour en saisir toutes les possibilités, voire qui en devient lourde. Bien sûr ça dépend du calibre de l'appli, mais généralement la plupart des lourdeurs qu'on voit sont évitable si il y avait eu un peu plus de travail en amont.
Enfin bonne chance, car le plus dur est devant toi, ça prend quand même pas mal de temps pour faire le tour de Cocoa et pour savoir quel composant utiliser à tel endroit, et surtout pour savoir les utiliser de la bonne façon ; tu peux avoir un schéma MVC aux petits oignons, si au final l'appli est codée salement, elle ne sera jamais top.
[Edit]
Désolé, les termes que j'emploie font surtout référence à Cocoa Touch pour iOS, mais rien dans ton post n'indique que tu te portes plus sur iOS que sur OS X... cela dit, j'imagine que la logique d'ensemble reste la même entre les deux.
