I must preface my post with the caveat that I'm not developing iPhone applications, I target OSX on the various Macs. There are enough similarities that I think my post is pertinent, but you'll need to filter that through your understanding of the iPhone SDK (I'm not familiar with Cocoa Touch, for example).
I, too, am an experienced C++ developer (from 1987, when it wasn't much yet).
I have the same viewpoint you mentioned:
If I'm trying to use as much C++ code as possible, what's the bare minimum of Objective-C I'd have to use?
To a C++ developer approaching Cocoa, the natural tendency is to plan an interface to AppKit, so that it is represented as a C++ interface to the application layer. This may be a 'facade' pattern or a 'pImpl' pattern. That approach begins to appear as a C++ framework for Cocoa development, which are sadly lacking from 3rd party sources in stable forms (they're all Carbon, Cocoa is either planned or in alpha stages).
To put this another way, if your viewpoint is to factor your application development such that C++ is your primary language, then every time you reach for a Cocoa/AppKit feature more than once, it becomes a candidate for this proposed C++ facade/implementation approach.
After a little time, you reach for Cocoa less and less, but you should seek to retain the design, because MVC is well known, predating Next and OSX, robust and flexible.
If you're familiar with boost, and in particular the function library within it, you'll have a suitable response to those that might counter that C++ isn't dynamic enough to implement Cocoa. If that's not familiar, then you'll still be able to approach the interface between your application and Cocoa from the design perspectives you're familiar with.
I've encountered a number of suggestions on various forums that recommend using Cocoa for services beyond AppKit (like files, network connections, etc). However, there's two schools of thought on the subject. There are, for example, platform independent representations for file systems in boost, as well as threads, connections, etc. If you're targeting Cocoa and intend never to target outside Cocoa, then choose what suits. On the other hand, it is obvious to a C++ developer that NSString offers limited utility in the context of C++ code, and extrapolating that realization to the rest of the development leads to similar conclusions regarding issues like filesystems and the like, where the underlying Unix base to OSX is equally applicable, and more portable, than Cocoa counterparts.
I think it noteworthy, too, that objective-C messaging (which, in C++, is analogous to member functions) can be slower than C or C++ function calls, and the memory management concepts in objective-C are also slower than shared_ptr in boost (which is expected to fold into the C++ standard library).
Since OpenGL is not objective-C oriented, you may find that performance is better in C++/OpenGL development when appropriate.
It seems there is a 'gravity' associated with objective-C++ discussions targeting Cocoa applications, where favoring objective-C solutions appears as a bias against C++. So far I've not found that bias compelling, but objective-C is unavoidable where Cocoa is required. With modern C++ techniques, that can be represented in a fashion so lightweight that, eventually, you can view Cocoa as an implementation of a C++ library, provided you're willing to develop that portion of one you're interested in using. I predict that we'll see viable C++ frameworks appear that target Cocoa; QT is in alpha on theirs now, but the application interface is QT. wxWidgets had a Cocoa in alpha for years, but it appears to have been abandoned. The problem for both is that they must implement that framework's application interface design, and so Cocoa is obscured behind that. Besides, QT is expensive for commercial development.
