---

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 Mac OS 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.

---