IK can be described in terms of it's opposite, forward kinematics. IK is perfect for animation. Why? Because any task should be driven by it's goal(s), and that is exactly what IK does. While forward kinematics requires you to position each joint in a limb sequentially, from the base to the tip, in order to get the exact tip placement and orientation you want, IK allows you specify the position of the tip (say a fingertip) and get the sequence of transformations you need on all the joints involved in that tip placement (shoulder, elbow, wrist, finger). This is why IK came about, otherwise you'd have to use FK with trial and error, or store a vast database of precalculated, quantised positions that map to the exact transformations required to get that tip position -- plain silly. In answer to your question then, yes: this is the only really sensible way to go about positioning a character in various poses.
(EDIT) IK is typically used for animation. That means physics don't affect IK motion, because they can't be allowed to or they would interfere with the IK solver's logic (there may be exceptions to this). In physics engines, there are two types of bodies: kinematic and physics-driven. Kinematic means "transform this object in the way I say, ignoring the limitations of traditional physics". Grab one of the boxes in this online demo to see what I mean. You can apply theoretically infinite force with that kinematic object under your mouse. Generally speaking, this is what IK does in physics engines. "What happens when an unstoppable force hits an immovable object?" Well, one has to give -- either the specified animation, or the physics. In this case, the physics.
So your choices depend on what you want to achieve. If the character is first posed using IK (in "frozen" state), and then physics simulation is activated, no problem -- write an IK solver, let it do it's thing with user input, and then turn the physics on to see what happens to the character... it now becomes a ragdoll, from the original pose you set. If you want, however, to have kinematic motion, such as the character standing up (kinematic) while his arms are swinging freely in realtime (pure physics), or the character falling while waving at the user, you will need both kinematic and physical bodies as part of your ragdoll in the physics simulation; you will also likely need to lock joints on kinematic limbs so that they stay at some fixed angle (that is not actual kinematics though). Lastly (the hardest option), if you want to be able to position body parts as the character is eg. falling through space, well, you're going to need kinematic body parts that are positionable on the fly using IK, while other parts of the body might be left as physics-driven, thus floppy/ragdoll-like. In other words, IK can be applied in a physics engine, but you need kinematic bodies (+joints?) to do this, and you will need to make sure the limbs stay rigid after you've positioned them this way, or else gravity will take over. Fortunately, most if not all physics engines support kinematic bodies.
Lastly just to add -- the reason you can't just tug an arm in pure physics mode /ragdoll mode and expect thing to work is that this applies force to the whole connected body, ultimately. You would have great difficulty in positioning say, just one arm, without the rest of the body falling all over the place. So IK is the answer, since it will usually move just that limb. If you let the IK chain length go all the way down to the torso, then the torso will also bend to accommodate the hand position.
Transformations of 3D objects are the first, and larger matter you'd need to achieve here. For that you'll need to be familiar with vector math, matrix transformations, quaternions. Collision detection on transformed planes is really not too difficult, the Graphics Gems books have tons of these, and you can find tons more for free here; vector math is usually enough for this.
I would suggest Collada or FBX, as they both support a good subset of the most commonly used features. Tou will need to locate the spec online for either one. AFAIK, the FBX spec is not that clear. I'm guessing Collada is much better in that regard. You will also need to write a parser to import the files into your application.
Physics You'd need to integrate something like Bullet, PhysX, ODE or whatever. Depends on what sort of physics you need, overall.
To avoid implementing much of the above from scratch in Objective-C, use Unity3D. It runs on iOS, imports a range of different model formats, and instead of doing everything yourself (which I don't recommend!), you have access in Unity to your models' bone structures and so on and can manipulate these as you wish, while getting all your 3D rendering and physics requirements sorted as well. For collision boxes in Unity, I believe the integrated Nvidia PhysX may accommodate that, otherwise you could bring them in as part of your actual model, on a separate layer or something of that sort. You'd need to ask further questions about your needs over at the Unity forums, and do a bit of browsing there as well for IK stuff, but I think this will fulfill your needs.
The big guy over at the Unity community for IK stuff is Rune Skovbo Johanssen. He's done some really awesome stuff with this, that you can in fact pick up in the Unity store IIRC.