Share data object between UIVIewControllers

This approach is fine. In anything but the simplest app, you'd more than likely want to persist some or all of your data model between launches, so there'd likely be code to load the data model from somewhere, and to save it periodically.

One common variation is to make the data model object be an instance property of your app delegate object. (The app delegate is a convenient place because you are going to have a custom delegate class anyway, and it's global to your app.)

The only real issue to consider is that it's often wiser to avoid creating global data when possible. With global data, your code often develops "tentacles" that reach across class boundaries to tie bits of code together that aren't really related. That can make revising your app design more difficult later, because you have to consider the global side effects of any local changes you make.

To solve that problem, you could (for example) choose to make one of the view controllers the creator of the data model, with the data model reference kept in an instance variable. The other view controller would then need to "find" the first one, then query its data model property. This is a "less global" arrangement, although some care is needed if the model object reference property is shared across thread boundaries.

Singleton can work in some situations. You can also pass objects around like hot potatoes using segues, or if you aren't using storyboards you could have a view controller that accepts a certain type of object as its model:

@interface DisplayFruitViewController : UIViewController

-(instanceType)initWithFruit:(Fruit*)fruit;

@property (nonatomic,readonly) Fruit *fruit;

@end

If you are doing segues, you have to make the Fruit property readwrite and set it in prepareForSegue: instead of handing it off when creating the view controller programmatically.

Have a view controller accept a type of object in this fashion can make the controller more reusable, since the VC does not have to be tied to a specific singleton object. If you give it a fruit, any fruit, it knows how to display it (perhaps edit it too).

I always find that view controllers seem to always end up being not as reusable as you'd like though. So spending too much time making things as generic as possible can make you overthink things sometimes. But I'd go with the master-detail hot-potato approach first, unless you feel like you really *need* a singleton to accomplish what you need to accomplish.