I've read several books on iOS development and Objective-C, however what a lot of them teach is how to work with interfaces and all contain the model inside the view controller, i.e. a UITableViewController based view will simply have an NSArray as it's model. I'm interested in what the best practices are for designing the structure of an application.

Specifically I'm interested in best practices for the following:

  • How to separate a model from the view controller. I think I know how to do this by simply replacing the NSArray style example with a specific model object, however what I do not know how to do is alert the view when the model changes. For example in .NET I would solve this by conforming to INotifyPropertyChanged and databinding, and similarly with Java I would use PropertyChangeListener.
  • How to create a service model for my domain objects. For example I want to learn the best way to create a service for a hypothetical Widget object to manage an internal DB and also services for communicating with remote endpoints. I need to learn the best ways to do this in a way that interface components can subscribe to events such as widgetUpdated. These services should be singleton classes and some how dependency injected into model/controller objects.

Books I've read so far are:

I've also purchased the following updated books but not yet read them.

I come from a Java and C# background with 15 years experience, I understand that many of the ways I would do things in these languages may not fit to the ObjC way of developing applications.

Would someone be able to provide me with the book on this topic containing this specific subject matter?

  • To the closers of this question: I think you'll find the most debate and argument is surrounding questions like this being closed. I try to do the right thing and not open these questions on SO as the rules in the FAQ mentioned, do allow subjective questions. That said, where CAN I ask this sort of question? What evidence is there of un-constructive answers? I found both responses useful and voted both, none marked answered as I await a little more time for more responses.
    – Brett Ryan
    Dec 11, 2012 at 16:08
  • I am voting to reopen this question as I think the question contains enough details that it is not asking for a broad list of books, but rather a specific book containing specific information. Per our meta discussion on books, this is allowed.
    – Rachel
    Dec 12, 2012 at 13:05
  • Looks like the question has already been adequately answered anyway. I see the question as Too Localized; it's so specific that it's unlikely to be of interest to anyone else but the OP. Book questions are problematic, regardless of their scope, because the purpose of SE is to gather information useful to others, not serve as a referral service to outside sources of information. See also: meta.stackexchange.com/questions/8231 Dec 12, 2012 at 18:17

2 Answers 2


Cocoa Design Patterns by Erik Buck and Donald Yacktman is a good resource for understanding how various design patterns are used in Cocoa. Although the book is a couple years old and written for Cocoa rather than Cocoa Touch, the two frameworks are conceptually very similar, and the additions in iOS 5 and 6 do little to change the underlying ideas, especially the ones you're asking about.

How to separate a model from the view controller. I think I know how to do this by simply replacing the NSArray style example with a specific model object, however what I do not know how to do is alert the view when the model changes.

The model generally won't talk to the view directly -- it should go through the controller. You have a number of options in this respect, including but not limited to:

  • Have the view controller observe relevant parts of the model using Key Value Observing.

  • Use notifications.

  • If the model is changing due to user input, the view controller may know to expect some aspects of the model to change.

  • Use delegation. Define a delegate protocol for your model and adopt it in your view controller. Set the view controller as the model's delegate.

How to create a service model for my domain objects...

From your comment I see that you're looking for a way to manage your graph of model objects. The Core Data framework provides object graph management and persistence -- it makes it easy to work with your data as objects without having to worry about how to store it all in database tables. It's fast and performs well even with relatively large amounts of data.

  • 1
    Thanks Caleb, I shall purchase and give it a read. The specifics for cocoa touch don't worry me, though as an oder book it wouldn't cover newer programming techniques such as blocks, though this can be easily applied. I have also been eyeing off Pro Objective-C Design Patterns for iOS, any comments on this particular book? These are the only two books I've been able to find on Amazon.
    – Brett Ryan
    Dec 11, 2012 at 6:13
  • Thanks for the updates. Will be buying this book. With respect to the services I may have a different term, essentially I'm interested in a class that manages the persistence in a database or backing store, the controller will refer to this to populate the model, some call a service a DAO, I've just always preferred the service name, I.e a ProductService will manage all product records that controllers or even models could depend on.
    – Brett Ryan
    Dec 11, 2012 at 7:08
  • I see. In that case take a look at Core Data, an object graph management/persistence framework.
    – Caleb
    Dec 11, 2012 at 7:27

Great question. I've struggled with finding the best way to build objective-c apps which adhering to MVC and I find that the using delegates is often the cleanest approach to synchronize views with models.

So, if your model is loading something over the network, the delegate might look like this:

@protocol XXItemLoadDelegate <NSObject>
- (void) willLoadItemWithIdentifier:(NSString*)identifier;
- (void) didLoadItem:(XXItem*)item;
- (void) didFailToLoadWithError:(NSError*)error;

And I think it's clear how a view might show/hide a busy indicator and then update once the item loaded.

The main disadvantages to the delegate pattern are:

  • forgetting to set the delegate
  • forgetting to call the delegate events in the model
  • overwriting the delegate (when multiple views want to be notified)
  • reseting the delegate (e.g. if a view is reused, the delegate should be nil first)
  • painful to refactor if you decide you need multiple observers
  • giving the the protocol and delegate methods consistent names

Despite all these drawbacks, I prefer the explicitness of delegates to other approaches.

NSNotifications are great for keeping completely unrelated pieces of code synchronized. But I've found they should be used sparingly, as it makes code incredibly hard to trace and debug.

KVO is also an option for syncing views to models, but I don't have much experience with using it in larger projects.

I didn't much care for the Cocoa Design Patterns book. It seemed out-of-date, and didn't have as much practical information as I would have hoped.

Instead of books, I'd also recommend reading through larger iOS projects on github. You can always see some design patters in action - and learn a few good tricks. For example:

App Sales Mobile

Not the answer you're looking for? Browse other questions tagged or ask your own question.