I can't instantiate it in any of the viewControllers since any of them may disappear at some point in the program and my data along with it.
False. Any view controller using the model object should have an ownership claim on the object. That is, the controller should retain the model for as long as it needs it, and release it when it no longer needs it. As long as at least one controller has ownership, the object will continue to exist.
Most programs will always have at least one controller.
Would it be proper to instantiate the data model in the AppDelegate?
That way the data model lives for the life of the entire app.
Do I make the data model an instance variable of the AppDelegate or just allocate an instance in the -applicationDidFinishLaunching method , and then initialize the data by calling the init method of the data model?
That's one way to do it. There is no single answer that's "proper" in all situation. You have to know enough about your design to know when and where to create model objects (plural because some things are better modeled by multiple objects), and when and where it's appropriate to let them die. This implies that you have a design, rather than a bunch of cobbled-together controllers trying to communicate with one another.
Now might be a good time to step back from the
hacking coding and work out a suitable Model design. Resist the temptation to continue hacking or doing makeshift code. You're really only going to learn about model objects by doing it (and failing at it, then fixing the failure, then redesigning for an unforeseen shortcoming, then failing, fixing, etc.).
The goal is to make a design that works the same as what you have now, but has an actual model object (or objects). Since you have code that works now (presumably), you can do an A/B test to confirm that the evolving yet still buggy model-based code works the same as the one you have now. As long as there are any differences in behavior, you haven't successfully completed the transition to the model-based code. If you have unit tests, or really any kind of tests, even manual ones, then this is the time to use them to confirm behavioral identicality between two versions of the program. If you don't have any tests or specs or written down description of behavior, now might be a good time to do that, before starting a major rework of factoring out an actual model object.
When the app quits then I could just release it in the AppDelegate's dealloc method. ?
The entire program's memory, which includes all objects, will be discarded when the app quits. It's not necessary to release something whose lifetime is the entire program.