Important: This document may not represent best practices for current development. Links to downloads and other resources may no longer be valid.
Anatomy of a Plug-in
On disk, a CFPlugIn is laid out as a file package just like a CFBundle. What makes a CFPlugIn special is the addition of a few keys in the plug-in’s information property list. These keys are documented in Plug-in Registration Because bundles and plug-ins share the same structure on disk, it is tempting—though incorrect—to think of a CFPlugIn as a CFBundle. At runtime, however, it is correct to say that a CFPlugIn has a CFBundle.
CFPlugIns and CFBundles come in pairs. Every CFPlugIn has a CFBundle, but each CFBundle (an application or framework bundle for instance) does not necessarily correspond to a CFPlugIn. You should never attempt to directly access a plug-in as a CFBundle. You should use the function
CFPlugInGetBundle if you need to access a plug-in’s resources with the CFBundle API.
If your plug-in will be manually installed by users it is a good idea to define OS X style creator/type codes (and perhaps a filename extension as well, though this is not required) for your plug-ins so that they will display the appropriate icon in file system views.