You should look into Delegates. You can cause things to happen without breaking MVC by defining a delegate protocol which the acting object conforms to. You can then call a delegate method by a call to the method defined in the delegate protocol. The effect is kind of like having a pointer to the object and calling one of its methods directly but it's not the same - the objects are still decoupled and by defining the protocol you define just what you can do so that you don't end up with classes hopelessly intertwined.
The object causing the action - call it A - defines a delegate property. It is set to some object, B, conforming to the delegate protocol. B needs to include the delegate specifier in its header to indicate that it conforms to the protocol, and it needs to implement every method defined in the protocol (except those defined as optional). A can then call methods in B as long as the protocol exposes them. You don't end up with A having a pointer to B and b having a pointer to A. This is exactly how a UITableView works, you have probably used delegates already.
In your case, looks like the controller will create a store observer. It will also implement delegate methods for any notifications the model must send back to the controller. The model's delegate is set to the controller and the controller can be notified of changes to the model (which it correctly has access to) in order to update UI.