Obtruder is a system by which bundles may be loaded into applications to modify their behavior. It currently requires MacOS X on PowerPC but should eventually support other chips. Obtruder has two primary components and relies on external code to be useful.

Obtruder is a dynamic library which is set to load in every application that launches for a particular user. It in turn loads other bundles and dynamic libraries that the user has installed. It also provides some basic functionality such as patching routines and sending messages.

Obtrusion is the preference pane which allows a user to control which Obtruders are loaded into which applications. It also allows for basic configuration of specific Obtruders and simple version monitoring. This management component is not essential to the running of Obtruder.

The core of Obtruder is the third party Obtruders that it allows to load. In itself it does nothing appreciable for an end user and has minimal impact on the system.

Writing an Obtruder is incredibly simple. Create a bundle or dynamic library with an exported symbol named ObtruderEntry and place it in the Obtruders folder. As every application launches ObtruderEntry is invoked and may patch traps, install listeners and handlers, observers and monitors, and otherwise modify the behavior of any application.

Obtruders have a robust support suite that they may take advantage of. There are many alternatives to ObtruderEntry which invoke code at specific times and under specific circumstances. Basic configuration of defaults and handling of support is provided by the Obtrusion preference pane so no additional user interface may be required. Keys in the bundle dictionary provide fine tuned control over which applications to load in, which traps to automatically patch, which system versions are supported, which methods to call and how to get support and check versions.

Many Obtruders will be designed to target a single application while others will change a particular behavior across some or all applications. Obtrusion will give the user fine tuned control over which Obtruders are loaded into which applications. As each application is launched obtruder will match information about it with requirements from the Obtruders and limitations from the user to determine which Obtruders to load. Those which are not desired will never be loaded into a particular host. In the event that an Obtruder has a conflict with a particular application it will be easy for the user to work around.

Obtruders have the option of listing the methods they will patch as part of their bundle dictionary. As an added bonus those methods may be patched automatically by obtruder. By listing the intended patches of each obtruder it will be easier to provide an end user with the means of tracking down conflicts. Listing intended patches is optional but highly recommended. Objective C methods are extremely easy to patch but should also be listed for the sake of conflict management, as there are also prone to conflict.

The closest thing to an SDK is currently obtruder_keys.h which lists the supported bundle dictionary keys. Dynamic libraries are limited to using ObtruderEntry unless a property list is embedded in the load commands. There is also the concept of a platform patch which provides raw assembly instructions for a patch. This can be useful for simple behavior modification but no external linkage occurs.

Obtruders are roughly equivalent to the System Extensions of bygone days and are also very similar to Application Enhancers. Obtruders have a richer set of tools at their disposal and fewer limitations both in development and deployment. Obtrusion does not require a root password and uses documented methods of being loaded into all applications. The Obtrusion system provides both the developer and the user with the tools they need.

obtrude might be taken to mean imposing ideas on applications. Conversely it might be taken to mean applications imposing ideas on you, in which case obtruder provides a means of retort.