@executable_path
Useful for frameworks embedded inside applications, because it allows you to specify the location of the framework relative to the application's executable:
Linker puts all this together to figure out that the framework binary can be found at:/Applications/Foo.app/Contents/MacOS/../Frameworks/Foo.framework/Versions/A/Foo
@loader_path
Available from Mac OS X 10.4 Tiger onwards; useful for frameworks embedded inside plug-ins, because it allows you to specify the location of the framework relative to the plug-in's code (remember, plug-ins may not actually know where they are going to be installed, relative to the application, so knowing @executable_path doesn't help us in this case):
Linker puts all this together to figure out that the framework binary can be found at:/Library/Application Support/Foo/Plug-Ins/Bar.bundle/Contents/MacOS/../Frameworks/Foo.framework/Versions/A/Foo
Note that if the "loader" is an application rather than a plug-in, the @loader_path ends up being equivalent to @executable_path. @rpath
New in Mac OS X 10.5 Leopard is @rpath. Key points:
@rpath instructs the dynamic linker to search a list of paths in order to locate the framework
critically, this list is embedded in the loading application
this means that a single framework with @rpath/Foo.framework/Versions/A/Foo can be made to work in a number of different ways; that is, you are effectively no longer limited by the choice of specifying your "install path" using either @executable_path or @loader_path
the down side: you now have to pass additional linker flags when building the host application (eg. -rpath @executable_path/../Frameworks or/Library/Frameworks; note that specifying both will cause the dynamic linker to try looking in both locations)
Docs for using PFiddlesoft Frameworks (I've never used these, but the manual itself makes some nice general points about using frameworks): http://pfiddlesoft.com/frameworks/downloads/Assistive_Application_Programming_Guide.pdf