If you want to change what your host application is dependent on, without having to rebuild it, you can use the install_name_tool app for changing this:
install_name_tool -change oldreference newreference appname
install_name_tool -change /usr/lib/libItsAllAboutMe.dylib @executable_path/../Frameworks/libItsAllAboutMe.dylib MySuperApp
This is pretty useful for cases where you might have a dynamic library located in a static location, but you want to bundle it with your application instead of having to use PackageMaker to install the library on the users local filesystem.
2016-10-26 Update
When I wrote this posting, I had not yet worked with @rpath, which is what you should be using in your Xcode project.
There is a good article that illustrates how to do this at dribin.org
And, if the library you are linking against does not use @rpath like …
$otool -L libSomeWeakLookingLib.dylib
libSomeWeakLookingLib.dylib:
/Users/weaklibnightly/build_bot/slave/mac-64-trunk/weaklibbuild/bin/libSomeWeakLookingLib.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
Then you can change that long path to a @rpath using
$install_name_tool -id /Users/weaklibnightly/build_bot/slave/mac-64-trunk/weaklibbuild/bin/libSomeWeakLookingLib.dylib @rpath/libSomeWeakLookingLib.dylib ./libSomeWeakLookingLib.dylib