Architecture
With the release of version 1.1.0, Zoom moved from being an interpreter for Z-Code games to being a platform for the presentation of Interactive Fiction. Since this version, Zoom has support for extending the range of formats that it can run through plug-ins.
Zoom has a client/server architecture: the main application provides a server UI, and plugins can provide client applications that perform the actual job of running interactive fiction games. This architecture has a few advantages: in particular, bugs in particular interpreters will not crash the main application. Perhaps more importantly, any plugin will immediately get all of the features of the main Zoom application: skeins, metadata support, integration with IFDB, text-to-speech and so on. The block diagram below shows the major components:

It is possible to take any component and re-use them in another application: for example, the ZoomView framework provides pretty much a Z-Machine in a can and can be used to create a new interpreter application in moments. Similarly, the GlkView framework provides instant access to interpreters written using the Glk standard.
New interpreters are usually written using the ZoomPlugIn framework, however. The easiest way to create a new plug-in is to use the glk standard and build the interpreter against the GlkClient framework, then build a plug in bundle using a subclass of the ZoomGlkPlugIn class. This makes it possible to port an interpreter with a good glk implementation in a matter of a couple of hours (this is roughly how long it took me to port SCARE).
It is also possible to write a plug in that provides a completely custom display by providing your own NSDocument implementation. This is not generally recommended as you will need to implement very much more in the plugin bundle to get all of the features that a glk plug in would have. However, this does make it possible to display games in a style not possible through CocoaGlk.