a glob of nerdishness

Someone posted a lengthy article today (here, and cross-posted here) claiming that even though Snow Leopard ignores creator codes, applications can use Uniform Type Identifiers to match a file in a generic format to a specific editor. As far as I can tell, someone is wrong on the internet.

There are two potential problems with expecting UTIs to take the place of creator codes as the article claims. The first is that applications are not encouraged to make their own app-specific UTI if one already exists. Consider the case of a JPEG file, which is a common format that many apps can open. With creator codes, an app that creates a JPEG file could make it easy for the user to re-open it later in the same app by setting its creator code. In common practice, an application would just be using the predefined “public.jpeg” UTI when dealing with JPEG files, instead of an app-specific code, as Apple had never encouraged otherwise.

Using an application-specific UTI even when a predefined one exists is a clever idea. Update: no it’s not. Doing so would mean no other app could open your app’s files. That would be bad, too. Or it would be, if not for the second problem. A file’s UTI is determined by Launch Services, and there isn’t a good way for an app to set one itself. (I would love to be wrong on this!) When Launch Services needs to know a file’s UTI, it looks at the file’s extension and picks just one of potentially many matching system and application defined UTIs.

Launch Services’ behavior in this regard is no better than file extensions. It’s worse, in fact. Consider a “.log” file: This common extension could be used for a system log, an application history, a GPS tracklog or any number of file types. If an application lets a user open any file with the “log” extension, it will be able to open its own files just fine. If, on the other hand, an application wants to use the new, shiny, recommend UTI system and offers to open files with UTIs of “com.example.tracklog” instead, it sets itself up for failure. If Launch Services has decided that the “.log” extension means “public.systemlog”, all .log files will have that type and the user won’t even be able to open a file from within our tracklog application itself.

Uniform Type Identifiers are a neat concept, and I recommend you use them. They do offer many advantages, including the potential to eventually replace creator codes in a future version of OS X. But you must use them with care. The main pitfall is Launch Services. You can use UTIs and UTI concepts so long as you always keep in mind that a file may have a completely different UTI on a user’s machine than it does on yours. When creating an open dialog, include the extensions you may be able to open in addition to UTIs. When defining a document type in your Info.plist, use the old (deprecated!?) CFBundleTypeExtensions instead of LSItemContentTypes. Otherwise, another application on your user’s system could end up overriding your extension’s UTI and your application will be unable to open its own files.

Launch Services should really report a different UTI based on which application is requesting a file’s type, or report a set of all potentially matching UTIs instead. This would affect some file-handling parts of the Cocoa framework as well. I reported this problem with the current way file UTIs are assigned in rdar://problem/6590416 this past February. I hope it can be fixed, because Uniform Type Identifiers are a win in the long run.