Inside Snow Leopard's UTI: Apple fixes the Creator Code

Type metadata isn't just useful for documents. It's also used to identify data that isn't saved in a file, such as clipboard data. When you copy and paste, the Mac OS has to keep track of the type of data you copy. An operation might start with a copy selection from a Word file with special formatting, but you might want to paste that data somewhere that only recognizes RTF (like TextEdit) or plain text (such as a search field or the name field in a Save As dialog).

The application involved has to supply as many different representations as possible to allow for different paste destinations. For example, Word may provide the pasteboard with Word-formatted text, RTF and simple plain text. The document selection copied to the clipboard might also contain graphics and text, or even embedded video. For copy and paste to work intuitively for users, the system has to accommodate pasting rich data into places where only basic data is supported; it has to know how to degrade gracefully. This requires a sophisticated data typing mechanism for identifying the different representations of copied data.

Starting in Mac OS X Panther, Apple began labeling pasteboard data (the internal clipboard used to store information between copy and paste operations) using a flexible, sophisticated tagging system that identified data in both general and specific terms. The system maintained records of how the tags fit into a hierarchy of increasingly more specific data types.

Introducing Uniform Type Identifiers

In Tiger, Apple began introducing these UTI tags as a way to identify file types as well. As with the pasteboard, a file might be tagged with the UTI of a proprietary document type, but that UTI can identify itself to the system as also conforming more generally to be rich text, as well as plain text, or most simply as a file. This UTI hierarchy of type identification allows the system to work with the data in both general and specific ways.

UTI's added layer of sophistication in data typing is similar in some respects to Leopard's introduction of NT-style ACLs (Access Control Lists) for use in file permissions, on top of the older Unix-style permissions. Rather than three buckets of read and write file access rights (user, group, other), ACLs allow a file to be tagged with any number of individual and very specific per-user permissions.

Similarly, with UTI, rather than two buckets of file type identification data (Type and Creator, or MIME's "type/subtype"), there can be a wide range of increasingly specific type information connected to a file or copy selection in order to richly express how it can be used.

The UTI model

What does this extra magical layer of sophistication provide? First off, it harmonizes the pasteboard data types with file types. It's also used in drag and drop, which is essentially a one-step copy and paste operation. It's also used in Application Services, which is a fancy form of copy and paste where the data is transformed in between being copied and pasted, usually ending up being modified in place.

With UTI established as a uniform method of identifying a very specific data type of a file or a selection of data, the operating system can maintain a single model of how a given bit of data can be used by other apps. This also allows applications to use data tagged with a UTI they don't recognize, but which the system knows is compatible with a type that application does know how to use.

Mac OS X can also translate existing Type/Creator Codes, MIME types, and file name extensions into its unified UTI model, bridging legacy into its new world.

Just a quick point: It should read 'The quick brown fox jumps (not jumped) over the lazy dog' otherwise there is no 's'. Anyway, these type of articles are the Ai ones I enjoy the most. Ones that explain stuff.

This helps explain why selecting Preview from a Print dialogue in Snow Leopard now launches Adobe Acrobat instead of Preview, but how do I fix it so it launches Preview again? SL should be able to distinguish PDFs made by Preview from PDFs made by Acrobat, right?

Just a quick point: It should read 'The quick brown fox jumps (not jumped) over the lazy dog' otherwise there is no 's'. Anyway, these type of articles are the Ai ones I enjoy the most. Ones that explain stuff.

I agree, plus the history of events is wonderful. Having started in business in the late 1970's as a computer dealer for both Apple and IBM PCs it has been fascinating to read the behind the scenes stuff that I experienced for real but often didn't know the whys and wherefores.

So, rather than just defining a file in terms of the app that created it and its general type, developers can now assign their files a UTI that identifies a very specific creator and type, and then inform the system of how that specific new UTI label relates with other more general file types that other apps (and system features) already know how to interact with. Developers can also still indicate that their unique UTI-tagged files should open with their "creator" app, a feature the end user can override via a Finder preference.

Can anyone describe how it's possible to assign the UTI for individual files (other than changing the file extension, or the 32-bit type)? If there's no way to do this, then it seems like the idea of Apple "fixing" creator codes is incorrect.

All well and good, and I'm convinced that UTIs are a better solution than type/creator codes in a number of ways. But it misses the point of complaints about the change in handling of creator codes in Snow Leopard. This article would apply equally to leopard. The complaint about snow leopard is that whereas leopard still honoured creator information in a UTI world, Snow Leopard no longer bothers. I agree fully that going forwards developers should use UTI, but I've been using a mac for about 20 years and have many many files that embed type and creator information: I want them to continue to behave as they did before. The new behaviour is a downgrade, and diminishes the feeling of "macness".

Quote:

Users who miss being able to automatically open a file using the app that originally created it can pester their app's developer to get on the ball with UTI ... Everyone else ... can continue using the Finder's Open With menu, drag and drop app launching, or set a permanent per-item default "creator" app for opening a selection of documents by using the Get Info panel

.

How is this a fix? Pestering the developer is a long term solution at best, and no help day to day. Using the Open With menu or drag and drop is a work around for the problem, not a fix: work arounds shouldn't be necessary. Setting a per-item creator app for each of thousands of files is quite unrealistic.

I hope for good things to come, and SL is still worth it to me, but meanwhile, it drives me NUTS that my Dreamweaver and TextWrangler-created HTML documents no longer open in the app I created them with... they all open in Safari!

I want downloaded HTML pages to open in Safari, DW-created pages to open in DW, and hand-crafted pages to open in TextWrangler. And various other specialized ASCII documents to open in other creator apps. Pre Snow Leopard, that all worked--completely automatically.

An omelette requires breaking eggs, but I wish they'd broken this one a little later.

(It's still interesting to know the reasons behind the change, though.)