Honestly, as both a developer and user, I find this kind of internecine backbiting very disheartening. The APE guys have been attacked for so long, and lumped into the same camp as the SIMBL/InputManagers guys that Slava and Rosyna do a “gasp!” “don’t mention InputManagers to us!” thing in a kind of knee-jerk dance every time the topic comes up. I can understand the chip on their shoulders–they’re outlaws, after all, unsupported (thwarted?) by Apple and frowned upon by “official” Mac bloggers, who seem to feel they are the only legitimate Mac OS X evangelists out there. Those guys have never blessed APE, so APE is bad.

Bull****. Their ire is equally great at InputManagers and SIMBL. Those who are actually coders will also rant about the dangers of code-posing and method swizzling, both of which are legitimate features of Cocoa. Can APEs, InputManagers, and other “outlaw” enhancements to Mac OS X be used for malware? Certainly, but so can a text editor!

APE is probably the most secure of the bunch, since all third-party APEs must adhere to Unsanity’s carefully developed API, and they plug in to the APE framework. One of the best things about that framework from a user perspective is the ease with which you can turn the whole bunch off when trying to identify a system problem. Equally great is how easy it is to disable an APE in a given application. And this functioinality comes with the framework… it’s not something an APE developer need worry about.

InputManagers are definitely rogue fellows. They adhere to a loose, old Apple API that was intended more for uses like TextExtras than Inquisitor. However, what they provide–and the reason why I as a user love them–is some serious, across-the-board enhancements to my Cocoa applications that I’m not getting from Apple.

By the way, SIMBL is an API that attempts to bring some order to InputManagers by providing a common framework and unifying some commonly used methods. However, to both users and “gasp! SIMBL!” writers it can appear mostly confusing. (Is it an InputManager, or not?) The guy who developed SIMBL had a great idea, and initially there was some good adoption of SIMBL. But it probably needed continued development and more support to become the “APE” of InputManager-dom.

In that sense, they arise from the same impulse that drives Unsanity’s haxies… and it’s why the two types of “system add-ons” are lumped together. The guys who develop InputManagers (or SIMBL plugins) are trying to provide system-level functionality that will work in all applications. There is no other way to do this than through APE or InputManager that I know of. Well… you could go below APE and use “mach inject”, which is what APE does below the surface. That is, it injects code at the mach level, whereas InputManagers inject code at the Cocoa level. One of the biggest differences, functionally, between the two methods is that InputManagers have no effect on Carbon-based apps like Finder, iTunes, or Photoshop, because only Cocoa apps are able to load them.

One thing I find amusing about the whole anti-InputManager crowd (including Unsanity) is that there’s a lot of similarity between InputManagers and two other system-level add-ons that you don’t hear folks worrying about from a security perspective: Contextual Menu Items, and PreferencePanes.

Actually, what I said earlier about there being no way other than InputManagers or APE to add system-level functionality to applications on OS X was incorrect. Both Contextual Menu Items and PreferencePanes share with InputManagers the fundamental Cocoa building block known as NSBundle. These are all bits of code that get loaded into the Cocoa framework in order to do things. The main differences are that

1. CMs must use a context menu interface. But they aren’t limited to that functionality.
2. Preference Panes have a defined API and user visibility that the other two types of NSBundles do not. Typically, preference pane apps can be turned on and off, just like regular apps. But they aren’t regular apps beneath the hood.
3. Unlike the other two types, InputManagers can show up pretty much wherever the developer chooses in the interface. Typically, they appear in the main menubar or a submenu, but some, like Inquisitor, are restricted to run only in a given application. I suspect that the relative “invisibility” of InputManagers makes them more likely targets for the “anti-system-add-on” evangelists.

With respect to security, Apple has indeed made InputManagers more secure this time around, but I think they can and should go further… without destroying the positive virtues of InputManagers and other system enhancements. In Leopard, InputManagers must be installed at the system level folder, with strict permissions that only allow write access by the root user. This alone helps ensure that none gets installed without the user’s permission.

One thing that never gets said in these discussions, however, is that if a malware writer wanted to wreak havoc among helpless Mac users, it would be a simple matter to write a badly formed Cocoa application, put up a pretty website, and invite users to try it out. The app could do all sorts of nasty things before the bad code consumed all your memory and crashed the system. On rebooting, you don’t necessarily restart the app, but it’s installed a daemon process that runs automatically, again leading to a system meltdown in 10-15 minutes.

This is purely hypothetical, but very feasible. Ultimately, your system security depends on the user applying some common sense and on the developer community having rational, realistic discussions with Apple about some of the risk factors.

No one wants to destroy the creativity that drives people to the Apple platform–developers as well as users. Make the platform too locked up, and it won’t be any fun to develop on. But make it too thin, and it’s dangerous for everyone.

Both APEs and InputManagers/ContextualMenuItems/PreferencePanes have their place at this table, and I for one hope the backbiting stops. No, APEs aren’t InputManagers. We get that. But their purposes have a lot in common, and the purposes of both are good.

If I were to propose an improvement for InputManagers to Apple, I’d suggest they add features to the System Preferences API. I think it would be a big improvement if InputManagers could be turned on and off in a System Preference pane, which gets installed with much user visibility. I’d support taking away the InputManagers folder if as a developer I could provide the same functionality through a System preference pane. The key difference, as I understand it, is that as an InputManager, I get to load into every application that passes by, actually becoming part of them. It’s understandable that some developers would find that notion a bit quease-producing… if you’re prone to anthropomorphizing your apps anyway.

So why bother defending the “evil” InputManager? Because here’s a list of ‘em I couldn’t live without… nearly all of which are free, by the way:

1. Inquisitor. A terrific enhancement for Safari’s web search field. (Here’s a short review from my Software Addicts section of Mars.)
2. SafariBlock. An ad blocker for Safari.
3. TextExtras. Adds a slew of useful text-input options in all your apps. (Note for developers: Source code available as well.)
4. StepMenus. Enables tear-off menus for your application’s main menu, and is a model of how I’d like all InputManagers to work: It provides a System Preference pane for use in turning it on and off and configuring it. (Note for developers: Source code available as well.)
5. HotService. Puts the Services Menu in your main menubar, which makes it much easier to use. Only when you do this do you begin to realize the power of application services.
6. OCSmartHacks. Provides many functions, but I use it mainly for popping up main menus in apps that don’t have them, and for easily resizing and dragging windows. It’s one of the few here that I actually had to pay for, and I also devoted quite a few keystrokes and brain cells to it when I finally decided it was worth the dough.
7. MenuExtraEnabler. An InputManager from Unsanity that overcomes limitations in Statusbar menu extras that Apple introduced in Jaguar (Mac OS X 10.2). Lets me use menu extras like MenuMeters. From what I can tell, it does the same thing that the open source MenuCracker bundle does, though MenuCracker can work outside of the InputManagers folder. MenuCracker comes built in to some great Menu extras like MenuMeters.
8. Edit in WriteRoom. If you use WriteRoom, you know how useful this is… it adds a menu item so you can switch to WriteRoom’s full-screen editing interface from any app where you’re entering text. It seamlessly puts the edited text back where it came from when you’re done. How cool is that? (WriteRoom itself is a text editor, but it includes the InputManager as an optional module. Here’s my review of the software if you’d like more info.
9. SafariStand. The best Swiss-Armyknife for Safari that exists.(Saft? bah!) and Stand is free, too. It runs as a SIMBL plugin. This software is so great I devoted a whole article to it last fall.
10. SetAlphaValue. Lets you customize window transparency uniquely for any app… I’m currently morphing that code, which I’d earlier customized for my own ShapeShifter theme, Crystal Clear, into a new plugin called CrystalClear Interface. It will do the transparency thing and a lot more besides.
11. Visor. From Blacktree (the Quicksilver guys), it’s just a way-cool interface to your Terminal window. Runs as a SIMBL plugin. (Here’s my review from last year.)
12. MegaZoomer. A freebie SIMBL plugin that lets you zoom the entire window if you want. (Note for developers: Source code available as well.)
13. SafariScript. Adds an AppleScript menu to Safari, utilizing Jay Tuley’s open source CocoaScriptMenu framework. The developer website also hosts a great repository of Safari-related scripts you can use.
14. SIMBL. Of course, you need the SIMBL InputManager if you want to run any SIMBL plugins! (Note for developers: Source code available as well.)

Those are the ones I currently have active. Others (including ones in the SIMBL family) that I’ve used in the past and enjoy are:

1. CocoaSuite. Includes many useful enhancements–including gestures, mnemonics, and menu shortcuts. It isn’t free, but it does have a new Leopard-compatible version available as well as an “InputManagersManager” application that you can use to disable CocoaSuite in specific apps. (Update 11/1/07: As I’d hoped, InputManagersManager provides an API so that other developers of InputManagers–including SIMBL plugins–can utilize it. Why do this? Quite simply, it provides two excellent benefits to users: First, with it developers can make their InputManagers self-installable, and Second, both developers and users can utilize it to restrict InputManagers to specific applications or to disable them in specific apps. Developers interested in learning more can read about this remarkable new tool here. If you’re an InputManager user, just download the software, follow the simple instructions, and begin taking advantage of it to organize your InputManagers collection!)
2. GreaseKit (formerly Creammonkey). This little InputManager plugin lets you run some Greasemonkey scripts in Safari. A new version was just released, but I’m getting two GreaseKit menu items in Leopard.
3. MaxiMice. A nice add-on that enhances your mouse, but it’s not free. (Note: I reviewed MaxiMice along with a dozen other such apps in the May 2007 article, “Window Tricks: Extending Your Power Over Mac Applications.”)
4. TabExpose. An inexpensive add-on to Safari that lets you see all tabs, Expose style, as Shiira does.
5. SafariTidy. A terrific add-on that runs Tidy on any web page source code and displays the results in Safari. It was recently updated for Leopard. If it’s working again, I’ll be moving it to the “active” list for sure.
6. AcidSearch. A SIMBL plugin that I was in love with until it stopped working in WebKit and Safari 3.0… And then Inquisitor came along…
7. Graffiti. A SIMBL plugin simply too cool for words… and a great parlor trick. It lets you flip over any window in your Cocoa apps and write on them. Like, notes and stuff. You can even save what you write before quitting the app! If you want more words from me on Graffiti, here’s a short review.(Note for developers: Source code available as well.)

OK, so that’s a quick rundown on some really useful and/or fun InputManager/SIMBL apps that I’ve enjoyed, and I’m sure there are others out there as well. (Not to mention the ones I’ve tried and simply didn’t enjoy or find useful.) But not to leave APE’s out of the party… and again to demonstrate the similarity in the intent behind them, here are the APE’s I currently have running in Tiger. (Though not, of course, in Leopard — envision smoldering anger here, since the same thing happened in May 2005 when Tiger came out. I’m sympathetic to Unsanity and hugely appreciative — in dollars as well as pleasure — of the work Unsanity’s engineers have done with their fine products. However, they always seem to be the last developers to get their products ready for a new OS release. Since I actually was in the developer program this year and got all the seeds, it’s not clear to me why that had to be the case. My suspicion is that they suffered a bad surprise in some earlier OS update and now have a policy of ignoring everything but the final release. Silly, when you think about it, since 10.5.0 will soon be followed by 10.5.1… Anyhoo… Here are the APEs I can’t use right now but would like to. Not all are from Unsanity, of course.)

1. FruitMenu. A marvelously rich tool for customizing your Apple menu as well as your contextual menus. Plus it puts an icon in the menubar instead of the application name, and that’s the most-asked question I get when I publish screenshots of my desktop. How did you do that?
2. MenuMaster. Despite Apple’s improvement in the Keyboard Shortcuts preference pane, and despite many competing solutions that exist, I still find MenuMaster to be the easiest and most reliable way to add keyboard shortcuts to menu items in my applications.
3. WindowShade. Yep, it’s cool. Why hasn’t Apple taken Unsanity’s lead and brought this one back? WindowShade adds a number of other great ideas to the concept as well, including one of my favorites: Customizing your window shadows.
4. ShapeShifter. Nobody’s ever made money from building themes for Mac OS X, but ShapeShifter and its sidekick, ThemePark (now free), have certainly provided a rich playground for us design-control freaks out there. (And we know who we are!) Not to mention all the time wasted and visual pleasure derived from this activity by Mac users who download and install our themes. We don’t hate Aqua, you know. We just think we can do better.
5. WindowDragon. I wrote a review of this one recently, and I’m happy to see the developer has put out an update since then. WindowDragon is a great, free add-on that gives you more power over moving and resizing your windows. (Note for developers: Source code available as well.)
6. DesktopSweeper. This free APE is how I (used to) keep my desktop free of icons, except when I wanted to see them.
7. Slider. This freebie just does a cool visual trick with your windows: It basically animates them in and animates them out, giving you some control over how much effect you want.
8. ICeCoffEE. This great APE does many useful tricks, but my favorite is letting you launch a URL by Cmd-clicking it, even if the URL is not formed as a hyperlink. It’s also useful for managing your application services. It’s one of the first things I’ll install once Unsanity releases a Leopard-compatible Application Enhancer.
9. Smart Scroll X. Here’s another fine shareware APE I reviewed and recommended last year. Once you get used to whizzing through documents and web pages with this tool’s “Super Wheel” feature, you’ll not want to install Mac OS X without it. Unfortunately, if you’re on Leopard, you’ll have to wait a little while yet. The developer promises a Leopard-compatible version on November 3.

Of course, there are many more “haxies” that are available for Unsanity’s APE framework, including quite a few from Unsanity itself. Taken together, the universe of useful “system enhancements” is quite large, and it would be even larger if there wasn’t so much fear-mongering about them.

It’s a complicated issue, because if I’m a software developer trying to help a customer troubleshoot a problem that appears to arise from my application, it’s tempting to blame the system enhancers she has installed instead of looking at my own code. On the other hand, it might very well be the system enhancer that’s causing the problem.

Certainly, a lot of finger-pointing does no one any good. What’s needed are better logs and crash reports. Unsanity’s tried to help out there with its–you guessed it!–InputManager bundle, Smart Crash Reports. Unsanity has done the whole developer company a huge service with this effort, but adoption requires that we get our minds around the idea that InputManagers can be good for you! Despite that resistence, Unsanity now has 300 developers signed up for using the reports, which come with an amazing web interface. If Apple and more mainstream developers would adopt something like Smart Crash Reports, it would be easier for developers to pinpoint software problems. No more finger pointing! One of the Unsanity developers published a long (a very long) article on this whole subject on the company’s blog last year… well worth the read.

So that’s it… I’ve been sick of the bad press InputManagers, SIMBL plugins, and APEs have gotten for a long time now, and that discussion on the Unsanity website the other day kind of set me off. Good to get it all written down, and I hope somebody else finds it useful, or at least interesting!

And by all means, if you know of a great system enhancement that’s not listed here, add a note in the comments below. When I have time, I’d like to document all the System Preferences and Contextual Menu Items that I use as well, but that would double the length of this article, and I’m frankly now out of time! Back to coding Crystal Clear Interface…