Allow me ...
There's only the physics engine that better suits you. Just like music.
|Documentation||Manual & API Reference||Manual & API Reference|
|Arithmetics||vec = vec1 + vec2 - vec3;||vec = ccpSub(ccpAdd(vec1, vec2), vec3);|
|Optimized for||Objects of varying sizes||Objects of similar sizes|
|Special Features||Bullets (aka continuous collision integration
aka swept collisions)
|Requirements||Must use .mm extension
Objects should be sized between 0.1 to 10 units
A free and popular Objective-C wrapper alternative is the Chipmunk SpaceManager (included in Kobold2D), but it is tied into Cocos2D and whenever the Cocos2D API changes, it requires the SpaceManager code to be updated accordingly. In the past it sometimes took weeks or months before the official SpaceManager code was updated. The SpaceManager is also not well documented, providing only an introduction and the API Reference.
There's no similarly popular Objective-C wrapper for Box2D. The CCBox2D project seems promising but like SpaceManager it's not a generic wrapper but depends on Cocos2D.
Again, this depends on you. 50% of developers who swear that Box2D is easier to learn than Chipmunk fail to understand why the other 50% find Chipmunk easier to learn than Box2D.
The % are made up, but you get the point.
Some people would think the choice should mainly be based on performance. Wrong. Usability, familiarity with the programming language and documentation are far more important in choosing any library almost always. Even more so if you have little to no experience with physics engines.
There are some special cases where Chipmunk may be faster, other cases where Box2D may be faster. If you know what cases that might be you should perform some simple tests and measure the performance. Note that Chipmunk SpaceManager will always be slower than pure Chipmunk, but it makes up for being easier on you if you already know and like Objective-C.
If you know what kind of joints you are likely going to need, check the documentation for each physic engine. Chipmunk may have some joint types that Box2D doesn't have, and vice versa. This could easily be a killer argument for or against a certain physics engine.
If you are going to have very fast moving physics objects, eg "Bullets", consider using Box2D as it can do swept collisions aka continuous collision integration to prevent fast-moving objects from deeply penetrating or even tunneling through other objects.
If you find one physics engine more "accurate" or "stable" than the other, eg. stacking objects wiggle more or less, know that some of these issues can be resolved by changing the number of iterations the physics engine performs. This also affects performance. It is not unusual for iOS games to reduce the number of iterations to 1 or 2 for performance reasons. You might want to try that and see which physics engine requires how many iterations to simulate your game with the needed accuracy before introducing issues like "restless" objects.
If you prefer object-oriented development, have a history with C++ or prefer speaking variable names, you should choose Box2D. But in Kobold2D projects you will have to change the .m file extension to .mm and stick with that to compile the code as Objective-C++ code. Failure to do so even once will greet you with dozens, if not hundreds of compile errors. Don't Panic!
If you are a purist and prefer C and don't mind dealing with variable names like e, f and m then try Chipmunk or Chipmunk SpaceManager. Chipmunk code is also not as verbose as Box2D code due to its naming scheme, but then again it doesn't provide overloaded operators so all arithmetics are done more verbose and less intuitive via function calls: ccpVect vec = ccpSub(ccpAdd(vec1, vec2), vec3).