Following on from my Helper Applications sample project, I’ve created another sample which focusses on how to do code-injection.

In particular this sample makes and installs a helper application who’s job is to inject some code into another application (by default the Finder).

The injected code adds a menu to the application’s menubar, with a single item in it that just logs stuff to the console.

Once again the project is based on existing examples, but attempts to present things in a slightly cleaner / simpler way.

It uses Wolf Rentzsch’s mach_star to do the heavy lifting for the injection task.

You can find it on github.

Once again I should point out that this example pretty much ignores security when it comes to the inter-process communication between the host application, the injection helper, and the injected code. Which isn’t to say that it’s not useful, simply that you’d have to batten it down far tighter if you want to avoid opening up some potentially horrible security holes.

In the sample, the helper is launched on demand, and only does the injection in response to a command from something else. In a real-world scenario, I guess it would make more sense for it to watch for the target app to launch and do the injection then. It would also make more sense if the various parameters were embedded into the helper to lock it down. However, in it’s current form, I guess the sample could form the basis of some sort of application-enhancer style system allowing multiple client applications to inject code into multiple targets.

I’ve recently been looking at how to set up a helper application (one that either runs all the time as a background task, or on demand, potentially with system permissions).

Apple has a few samples in this area, but they’re not all that complete, sometimes not cocoa-centric, and I found them a bit confusing.

After a fair bit of puzzling it out I’ve created my own sample (a modified version of a couple of theirs), and I’ve put it up on github in the hope that it might help someone else.

I’m very pleased to announce that Neu 1.2 is now live on the Mac App store, as well as available for download from this site.

This version has quite an extensive list of changes and improvements, including reorganised preferences, some new substitutions, and a substantial overhaul of the main UI.

Check out the release notes for full details.

Ambientweet 1.0.2 is now available from the Mac Application store.

This is a minor revision, with a fix to a bug that caused it to stall and stop refreshing tweets after an hour or so.

Let’s say that you are building with a modern SDK, but you are targeting some older platforms. For example, you’re using the iOS 5.0 SDK, but you want your app to run on iOS 4.2.

When you do this, you have to take care not to call routines which are only implemented on iOS 5. You can set your deployment target to 4.2, but that won’t prevent you from calling 5-only routines, they will simply be weak linked and will be nil on platforms that don’t support them.

Occasionally I slip up on this, and during testing I discover that I’m using a routine that doesn’t exist everywhere.

The simple solution when this happens is to stop using the routine in question, and find some workaround, but that’s a bit rubbish. After all, the routine has probably been added precisely because it’s useful.

Also, the routine, when it does exist, might be better than your workaround. Apple wrote it, so it must be good right? So you’d prefer to only use the workaround where necessary.

Finally, this is a temporary problem that will probably go away at some point. The routine is present on new systems, and eventually time will move on and you’ll stop supporting the ones where it is missing.

So rather than changing your code, how about finding a way to add the missing implementation when necessary? Luckily, Objective C is wonderfully dynamic, so this is entirely feasible.