How to make your app’s Dock tile highlight

2007-07-23 06:22:19 UTC

So, no matter what you do, your Dock tile doesn’t highlight when you drag a document onto it. You’ve hexadecuple-checked your CFBundleDocumentTypes list, and everything looks correct, but Dock is not co-operating and you just want to kick it.

Finally, you decide to remove the LSItemContentTypes key, and it works just fine! How can this be?


Well, since Tiger, LSItemContentTypes shuts out all the other document-type tag keys. Your CFBundleTypeOSTypes, your CFBundleTypeExtensions—all of those are ignored when LSItemContentTypes is present; it looks at nothing but the LSItemContentTypes list. Taking out LSItemContentTypes forces LS to look at your OSTypes and extensions lists instead.

More to the point, your problem is that the set of UTIs you’ve specified does not contain the UTI of the would-be document that you’re dragging.

You could be forgiven for expecting that having com.apple.application in your set of UTIs would allow you to open applications as your documents. This is not true, because a standardly-constructed Mac OS X application is of type com.apple.application-bundle. That type does conform to com.apple.application, but it is not equal to com.apple.application, so the Dock refuses your drag with a dismissive wave of its kerchief bundle and an AIFF file of a sharp “hmph!”.

So how do you find out the true UTI of your document?

The easy way is mdls. Ask for the kMDItemContentType property:

% mdls -name kMDItemContentType Foo.app
Foo.app -------------
kMDItemContentType = "com.apple.application-bundle"

But this only works on a volume with a Spotlight index; for example, it doesn’t work on disk images or RAM disks (same thing). Another way is Nicholas Riley’s launch, with its -f option:

% launch -f Foo.app
Foo.app: Mac OS X application package 
        type: 'APPL'    creator: …
        architecture: PowerPC, Intel 80x86
        bundle ID: …
        version: …
        kind: Application
        content type ID: com.apple.application-bundle
        contents: 1 item
        created: 2007-07-23 07:12:31
        modified: 2007-07-23 07:12:31
        accessed: 2007-07-23 07:12:41 [only updated by Mac OS X]
        backed up: 1903-12-31 17:00:00

Either way, put that UTI into your list. Then drags will work.

In summary, the Dock checks for equality of the prospective document’s UTI to the UTIs listed under LSItemContentTypes, not conformity. You need to list every UTI you support in your Info.plist, including those that conform to the ones you expect. It’s either that or give up on UTIs entirely.

(Summary suggested by wootest.)

UPDATE 08:44: ssp suggested mdls instead of launch.

5 Responses to “How to make your app’s Dock tile highlight”

  1. ssp Says:

    If it’s not an application you are developing but just one you want to use, Command-Option dragging may help as well.

    Perhaps just using the mdls command is an even easier way to learn a file’s UTI, btw.

    ‘mdls -name kMDItemContentType PATHTOFILE’

  2. Peter Hosey Says:

    launch actually works in circumstances where mdls doesn’t. For example, I performed the above example on a RAM disk. Here’s what mdls says:

    % mdls -name kMDItemContentType Foo.app
    Foo.app -------------

    For those who haven’t seen it before, here’s the normal output, as determined by cding into my /Applications folder and mdlsing one of the applications there:

    % mdls -name kMDItemContentType Adium.app
    Adium.app -------------
    kMDItemContentType = "com.apple.application-bundle"

    So mdls doesn’t work on volumes without a Spotlight index. launch works anywhere.

  3. Jesper Says:

    I feel I should add that 10.5 (“Leopard”) will improve on this by adopting UTIs everywhere, but it doesn’t mean you can add them to your existing apps because 10.4 will still fuck this up.

    And Peter started looking into this because I was having trouble supporting a feature in an upcoming ThisService release, where you should be able to drag any script file to its dock icon to trigger opening it (but implementing the opening behavior as simply placing it in the script file picker). Right now, I think I’ll either stick to one entry containing all extensions for common scripts (+ AppleScript’s OS types) or to one catch-all entry (which would be bad since it’ll show up in Open With in the Finder.

    Command+Option is a clear workaround but I should be able to do this using just two UTIs, in my opinion: `com.apple.mach-o-binary` (for compiled UNIX pass-through filters) and `public.script` (underlying both AppleScripts and command-line style scripts like shell scripts and PHP/Perl/Ruby/Python/etc.).

  4. Peter Hosey Says:

    Actually, I had resigned the problem yesterday, but came back to it while working on an application of my own that I’m going to release later today.

  5. Jeff Johnson Says:

    Hi. Just wanted to let you know that there seem to be typos in http://feeds.feedburner.com/domainofthebored where it’s referring to http://boredzo.org/blog/archives/2007-07-24/configure-application-dock-tile, which doesn’t exist, rather than to http://boredzo.org/blog/archives/2007-07-23/configure-application-dock-tile.

Leave a Reply

Do not delete the second sentence.