I haven't used state preservation & restoration so I don't know what issues it has with your model being a singleton (if you elaborate on that problem I might have some ideas to help), but I've found that on apps where the data model is simple, like you have indicated, a singleton is usually easier. That said, if it just isn't an option you'll want to pass the model object between controllers. Basically put a property on each controller, then in your segues you pass that object to the destination controller.
When you pop controllers off the navigation stack you'll want to update the view as well, in case any data changed. If you're using storyboards and have a small number of scenes (the individual 'screens' within the storyboard) it's pretty easy to wire up the Unwind segue, which calls a method on the parent controller to notify it the child is getting popped off the stack - that is where you would grab the object off the child, store it on the parent controller, and refresh its view.
There are several ways to persist data in an iOS app. My favorites are Core Data and serialization. If your model is really simple (one or two object instances and just a few properties on each object) serialization is pretty easy - use NSCoding to encode/decode your object and save that data to a file in your applications data directory. If your model is more complicated (such as having relationships between objects, or a large number of object instances) Core Data is a good way to go. It manages the object 'graph' in memory and handles persisting that to disk for you; it even handles upgrading your persistent store if you need to evolve your model in the future. It is extremely powerful, but has a bit of a learning curve.