Home > 2011 Fall DPS913, iOS, iOS Cocoa Touch > Model objects for iOS apps – introduction

Model objects for iOS apps – introduction

September 19, 2011 Leave a comment Go to comments

This note will help you design useful and simple model objects for your iOS app. It is intended for the entry-level iOS app developer. A future post will enable you to improve the design of your model object, to accommodate more complex requirements.


This post was most recently updated in November 2011.

It is the first in a two-part series on “model objects for iOS apps”.


The Model-View-Controller (MVC) app design pattern

We introduced the Model-View-Controller (MVC) app design pattern in the course’s first lecture session.

The Cocoa frameworks, perhaps more than any other platform that you’ve worked on so far, enforce the MVC design pattern. The pattern enables you to write an app in a modular and maintainable way. It promotes the separation of concerns:

  • The model code defines state and behaviour for your app’s data
  • The view code is concerned only with the presentation of the data and app state to the user; it doesn’t include any app logic
  • The controller code includes the app’s logic, and it mediates between the model and the view


Read the Model-View-Controller article in the Cocoa Core Competencies documentation collection, and then return here.


The apps that you created in the first two weeks of the course included a view and a controller. There typically was no model.

However, the apps that you will create now and in the future will also include a model.

The simple apps will often create a model in a view controller, and the model objects will typically be simple-to-understand types (e.g. strings, or an array of strings).

Apps that are more complex will include model classes that you define. Some of your model objects may also use frameworks (e.g. Core Data) or facilities (e.g. web service) that provide the structure and definition of the model, and ways to access and maintain the model objects.


For more information…

The following are links to additional readings about using the MVC app design pattern. You will find the readings useful later in the course, and in the future as you create iOS apps.

Cocoa Fundamentals Guide – The Model-View-Controller Design Pattern

Cocoa Fundamentals Guide – Design Guidelines for MVC Applications

Model Object Implementation Guide


Model object design: the assumptions

At some point in the near future, you will decide that you are ready to design your own model object. How do you get started? Follow the guidance in the rest of this post.

The following are the assumptions about the design and functionality of a model object:

There may be one or more model objects in an app. Our code examples will typically have only one.

A model object may use any of the available persistence schemes, including property lists, archiving, and Core Data.

The model object is responsible for communicating on the network. Async (non-blocking) communication must be used.

Model objects use key-value observing (KVO), and notifications to communicate their state (to the rest of the app).


Model object design: class code structure/organization

A model object provides the user/consumer with access to a “collection” of “items”. Typically, at least one of the model object’s accessors will deliver an array (NSArray) of results, so that it can be used in a table view (UITableView).

The “item” can be simple, and one of Cocoa’s types (e.g. NSString, NSDictionary). Or, it can be a type of your own design.

The following code elements are part of a model object’s design:

Instance variables (maybe)

Declared properties


Methods (which are public/visible)

These methods will be designed to help with the model object’s maintenance; examples…

Get all items (returns the collection)

Get one item (by query)

New item

Modify an item (by query)

Delete an item (by query)

( etc. )

Persistence code (e.g. save, load)

Communication code (e.g. notification, delegation)


Using a model object in your app

The following will help guide you to use a model object in your app.

For an iOS app, you typically initialize your model object in the app delegate.

Optionally, I suppose, you can create a property in the app delegate, for your model object.

If you study the Core Data stack implementation pattern, you will see that the app delegate as a property for the managed object context.

However, you will also notice that the property’s value is passed on to the first view controller. This is the pattern that you want to follow.

Ideally, you want to avoid using the app delegate as a singleton, because it creates a dependency. However, I suppose that it would be acceptable, with careful and disciplined design, to rely on the idea that your app delegate has a model object property. Then, when needed in a controller, you can get a reference to it.


Then, you pass on a reference to the model object, to the app’s first view controller.

(later revisions of this post will include a discussion of communications and conforming to NSCopying.)





  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: