Snow Leopard's abandonment of Creator Code metadata, used to open a file with its creating application, has some users are worried that Apple has killed off a core Mac-centric feature. Instead, Apple has invented a superior alternative for the old Creator Code in order to support a variety of new features. Here's why, and what the new Uniform Type Identifiers offer.

What is a Creator Code?

Back in the early 80s, Apple developed a variety of unique conventions to make the Macintosh intuitively easy to use, almost to a magical extent. One example pertains to invisible file metadata that helped the system identify documents using Type and Creator Codes.

Each file was tagged with both a Type and a Creator, allowing the system to distinguish between applications that could open a file and the default application that should open the file. The Finder could also use this invisibly associated file metadata to present custom file icons for different files of the same type but created by different applications, such as two JPEGs, one saved by Graphic Converter and the other by Photoshop.

The Finder maintained simple associations between applications and files, so that any document created in Word would open automatically with Word, and each of several different text documents would each open with the application that was used to create it. In the days when users had a few simple, monolithic applications, this Type/Creator convention made sense.

On DOS and Windows, the operating system could only determine how to open a file based on its file type extension, which was explicitly part of the the file name: myfile.doc. DOS and Windows were helpless to offer the user any assistance in knowing what application originally created a given file, unless the file were saved to a proprietary format that only one app could possibly open. In that sense, Mac Creator Codes encouraged the use of common, interoperable file types while still associating certain files with a specific app.

Leaving the Mac island

The Creator Code convention worked well until documents began moving to and from other platforms, such as being saved to a DOS disk or a Unix-based file server, or via email or the web. DOS and Unix ignored the Mac metadata, so they didn't know how to open the files received from Mac users, as those files typically lacked the simple file extension that those other systems required to interpret the file's type.

Additionally, since those platforms also scrubbed away the Mac metadata, files copied to and from a non-Mac savvy platform couldn't be correctly identified or opened on the Mac anymore either. With Apple's magic removed, the files just sat there with blank generic icons, and the Finder acted just as helpless with them as Windows. The problem for Mac users was eventually solved by packaging the Creator Code information to withstand transport on a non-HFS formatted disk. That didn't help Mac users who needed to send their files to users on other platforms however.

The common solution to that issue came to be to assign Mac files redundant information: both Type and Creator codes as well as a file extension. On NeXT and later Windows, files were given file extensions only, as there was no underlying file system support for Mac-style metadata for Unix or DOS. NeXT's impact on Apple was particularly evident in the shift away from Creator Codes and toward file extensions.

Old time Mac users often looked at file extensions as an ugly and unnecessary feature required only to allow Macs to interoperate with the filthy masses. So, when Mac OS X arrived with support for the old Mac metadata but with new guidelines from Apple mandating that developers also use NeXT-style file extensions to express type, there was consternation that the Mac was losing the things that made it special.

Complaining about the end of the road for Creator Codes fit in with unrest about other changes afoot at Apple, such as the loss of the Spacial Finder (the idea that you shouldn't be able to view a folder in the Finder in multiple views at once; that files should be locked into the view you last saved and stay there until you modify it).

Why Creator Codes Died

However, Apple didn't schedule a deprecation of Creator Codes just for fun, or just to be lazy, or just to fit in with lowest common denominator operating systems. Type and Creator Codes simply weren't good enough to support new OS features Apple had on the drawing board. Rather than trying to get by with doing less, Apple was set on doing more, and Creator Codes weren't up to the task.

There are lots of places where the operating system needs to handle advanced data type management which transcends the basic file Type and Creator Code system developed for identifying documents on the original Macintosh nearly 30 years ago. The system must also do this in a way which remains compatible with the file type extensions in use on other platforms.

Type and Creator Codes each used four-character labels, limiting the potential for expansion. That was an improvement upon the DOS idea of 8.3 names, which truncated documents, executables, and JPEGs to cryptic, three letter .doc, .exe, and .jpg file extensions. However, creating a new Type or Creator Code required registering with Apple, because there was a finite number of expressive codes available between 0000 and ZZZZ.

Today, the app used to create a file is not necessarily the one that most users want to open it with; the Creator Code system didn't offer any simple way for users to modify the creator after the fact, either individually, collectively for a selection of files, or across all files of a given file type. The complexity of what users expect to do (and what kinds of data they are working with) in 2009 is vastly different than it was back in the early 80s when Apple conceptualized the rather simple Type and Creator Codes.

MIME talkin

To support new kinds of features, Apple invented a flexible new system for expressing file and creator information in a system called Uniform Type Identifiers. The idea of rich file typing wasn't entirely unique; the BeOS began using MIME types as its mechanism for expanding upon the concept of File Type and Creator Codes during the 90s. However, MIME had its own issues.

MIME types are used by web servers and in email to express the type of file being served or attached. For example, a web server might identify a graphic as "image/jpeg" in addition to the file's .jpg or .jpeg file type extension. MIME also allows developers to make up their own types, either by registering a specific name with the IANA (the root DNS naming authority) or making up ad hoc names, an improvement upon Apple's registered Type and Creator Codes.

The BeOS copied a page from the web browser, which allowed users to define which helper app should be used to open a file of a given MIME type. If it encountered a specialized MIME type that it didn't recognize (such as "text/xml"), it could try opening it with the program designated to open plain text files. This "type/subtype" system offered a two bucket approach to defining file type, allowing specialized files to be opened by more general apps if necessary.

However, MIME was originally created just as simple way to push international characters and binary attachments through the Internet's SMTP email system (which only understands plain ASCII text). MIME only offers simplistic, rudimentary support for identifying the kind of data being transmitted. Apple wanted a much more rich and robust system for detailing more than just the basic document type of some binary data.

On page 2 of 3: Data typing beyond files, Introducing UTI.

Data typing beyond files

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.

On page 3 of 3: UTI definitions, The features of UTI.

UTI definitions

For example, the "public.html" UTI defines itself as conforming to "public.text," allowing any apps that know how to use text to also access HTML formatted text, even if they never anticipated editing HTML. They could also work with a new vendor-specific UTI such as "com.editmax.htmlplus" that defined itself as conforming to "public.html."

In turn, "public.text" conforms to both "public.data" and "public.content," so any process that knows how to work with files or content in general terms can also work specifically with HTML files, or any new specialized forms of HTML files invented in the future.

UTI definitions also include a human readable (and localizable) description of what that file type is; identify the icon that should be used to represent that file; and outline alternative ways to express that file type. For example, the "public.html" UTI associates itself with the legacy "HTML" Type Code and a variety of file extensions that HTML files may use, such as .html, .htm, .shtml, and .shtm. It also associates itself with the MIME type of "text/html," making UTI the uber-type of data typing.

Developers can make up their own new UTIs, defining them in relation to more general, existing UTIs, without needing to formally register anything. Vendor-specific UTIs use 'reverse DNS' naming just like preference files, preventing different companies from inadvertently using the same label. In the world of file extensions, there's nothing unique about "file.doc," as both WordPerfect and Word used the .doc extension. With UTI, Microsoft uses "com.microsoft.word.doc" to express a unique data type for its files.

As a side note, "reverse DNS" is used because DNS itself is backward. Web URLs like "www.apple.com/mac/features.html" go from most specific to least specific (in server name hierarchy), then hit a slash and begin getting more specific (in web server file hierarchy). This is like writing the number 1,234.567 as 4321.567: nutty. So "reverse DNS" is an attempt to fix a big mistake made in web URLs everywhere else that a similar naming hierarchy might be useful. It's too late to fix the web.

Features of UTI

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.

In addition to using UTI to manage what app to use when opening a file in the Finder (via Launch Services) and in determining how to perform copy and paste, drag and drop, and Application Services (via Pasteboard Manager), Mac OS X also uses UTIs within Spotlight importers, Automator Actions, and Quick Look previews, as well as in Navigation Services to narrow down the relevant files presented in open and save dialogs.

For Launch Services, Apple tells developers to define UTIs for the documents their applications create, and include these within their application. A vendor-specific UTI works like an old fashioned Type and Creator, although developers don't have to register their definitions with Apple in advance. So rather than Adobe registering the "8BIM" creator and "8BPS" type for its Photoshop files, the UTI "com.adobe.photoshop-​image" expressively and uniquely identifies these files as entities that open with Photoshop.

Other applications can also open Photoshop documents. Conceptually, other apps could even create versions of Photoshop documents that open by default using their own app simply by adding a new UTI that defines itself as a specialized version of the existing "com.adobe.photoshop-​image" UTI. This allows the system to do everything it already knows how to do with Photoshop files (copy and paste, index for search, use in Automator Actions, Quick Look) to new documents defined by the specialized "Photoshop+" UTI. Type/Creator Codes can't do that.

The Pasteboard's use of UTI was introduced above. It shouldn't be surprising that iPhone 3.0 also uses UTI in its new copy and paste support. If you were wondering why Apple "took so long" to bring that feature to the iPhone, it's because the platform opted for a long term, robust solution rather than a quick and dirty kluge impacted by security issues.

For Spotlight searching, Apple instructs developers to provide UTI definitions for the types of files their importer plugin can index. The system then uses the most specific and specialized importer available to index files matching that UTI.

For Automator Actions, developers specify the UTIs their Action knows how to input data from and what UTIs the Action will spit out. Automator Actions are essentially a modular string of Services that are compiled together to copy data from one file or selection, transform it, and spit out a result.

For Quick Look, plugins specify UTIs for the files they can view. Again, this allows the system to select the most specialized plugin to use in displaying a given file type. In other words, a developer could create a specific plugin for viewing a fancy text UTI (such as XML) with more features (such as color-coded markup tags) than Apple's own basic text Quick Look plugin offers. Quick Look is also an application of UTIs that allows the system itself to open a file for quick viewing without affecting the user's desired default launching app.

The fix for Creator Code junkies

UTIs provide a standardized way for defining data anywhere in the system, one that transcends the Type/Creator Code's limited concept of a single app that creates given file types. Developers who complain that Snow Leopard doesn't support Creator Codes need to brush up on UTI, which has been in place for several years now. It offers all the benefits of Creator Codes while enabling lots of other modern new features.

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. Any application that has been updated since 2005's Tiger, but which does not yet support UTI, has opted not to support an important feature of the Mac platform.

Everyone else, including many of us who didn't ever understand why the system launched files using a specific app rather than the one we had defined for that given file type, 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.

Daniel Eran Dilger is the author of "Snow Leopard Server (Developer Reference)," a new book from Wiley available now for pre-order at a special price from Amazon.

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.

Believe nothing, no matter where you heard it, not even if I have said it, if it does not agree with your own reason and your own common sense.Buddha

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.

From Apple ][ - to new Mac Pro I've owned them all.Long on AAPL so biased"Google doesn't sell you anything, Google just sells you!"

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.)

UTIs are types. Creator Codes specify the application that created the document; it's not a type.

Most files on your Mac are identified by file extension, which is then mapped to a UTI. About the only place you'll see UTIs is in the Info.plist files of application bundles where it says what the application supports.

As far as I know, there is no replacement for creator codes, which is a shame.

While the background information presented here is reasonable, the third page assume functionality that is neither present nor documented as in Mac OS X. Thus, every conclusion drawn is not just wrong, but dangerously wrong.

Furthermore, even if this article was correct (which, again, it isn't), the UTI does not replace creator codes. The concepts don't overlap at all... which the astute reader will notice if they read the article for facts rather than spin.

UTIs replace file type codes, and do so well. However, unless the data being generated is in a proprietary format that only a single application will support, they do not replace creator codes.

While the background information presented here is reasonable, the third page assume functionality that is neither present nor documented as in Mac OS X. Thus, every conclusion drawn is not just wrong, but dangerously wrong.

Furthermore, even if this article was correct (which, again, it isn't), the UTI does not replace creator codes. The concepts don't overlap at all... which the astute reader will notice if they read the article for facts rather than spin.

UTIs replace file type codes, and do so well. However, unless the data being generated is in a proprietary format that only a single application will support, they do not replace creator codes.

Actually, if used properly, they do replace creator codes. Note

Quote:

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

I properly implemented by the developer the UTI identifies the creator and the hierarchy identifies the 'file type' in the sense that 'com.adobe.pdf' should be identified as degrading to 'public.pdf'.

UTIs can not be assigned by an application. There's no mechanism for saying "This file has an extension of .txt, but is com.mycompany.product.import, which conforms to public.txt. This other file has an extension of .txt, but is com.mycompany.product.export, which which conforms to public.txt. This file has an extension of .txt, but is com.mycompany.otherproduct.import."

If I'm wrong, please let me know. I searched Apple's documentation for this some time ago for quite a few hours but never found anything.

The casual reader may get the impression that we Mac users can once again ignore the dot-extension that seem to so bother some people.

The fact is, the dot-extension will be with us forever. As long as we exchange files with other platforms (Windows or unix), we'll have (and need) extensions because you can be sure those platforms don't have the slightest bit of interest conforming to Mac standards.

I'm also under the impression that Apple adopted UTI more for a consistent exchange of data (between apps, between files, etc), than it was adopted to replace Creator Types. I suspect this article is somewhat misleading in that regard. After all, all apps (including Apples) still enforces extensions on the end of files.

I don't see what the problem is. If a file doesn't open with the app I want it to I simply get info on that file and set it to the app I prefer. After that it always opens with my preferred app.

If your workflow consist of creating and reopening for editing a big bunch of files with an extension associated with a default viewer (say, if you code all day .html files in a text editor), going thru the info panel can become extremely cumbersome. I guess you'd give up early and end up dragging them to the editor icon in the dock or right click and select "open with..." - which is a pain too.

I guess one could create some automator actions to automatically do that for you as you save the file, or app developers could start to integrate that in their save dialogs.

But it is an hacky solution in the end. For example, the mechanism for associating a single file to a non-default app involves referencing the path to said app. Which means, if you happen to move the app all those associations don't work anymore. Definitely not mac-like...

Pre snow leopard, instead, the default behaviour of honoring the creator code could be overridden easily in a single step.
If you found annoying that Fooapp .html files with FAPP creator code would open in Fooapp instead that in the defauly browser, you only had to select one of those, get info, change app to browser, and click "modify all". A dialog would inform you that all Fooapp files with .html extension would be opened in the browser, and you'd be set forever.

I can understand that the average user had troubles grasping the logic of that system - especially because Apple took care to keep the creator code mechanism well hidden.
They also never made any effort to reference the creator code existence via some UI clue - say, a badge on the file icons, or some wording in the info panels. The habit of substituting the document icons with content previews didn't help either.

If you were unaware of the creator code existence by yourself, you'd be puzzled that files that had the same extension and looked the same could behave differently.
And even if you knew how it worked, you couldn't access infos about the creator code of a file without installing some obscure third party utility.

Even for the experienced user, this could lead to hassles and uncertainity, especially with files you didn't create yourself - the typical example is receiving a jpg or pdf file from a coworker, double clicking it to open in Preview, and watching your mac crawl while it launched fat-ass Photoshop or Acrobat. =)

ANYWAY, the creator code app binding mechanism was still great in many respects, and Apple could have worked to make it more intuitive UI-wise, instead of merely axing it without replacement.

This Appleinsider piece is a great introduction to UTI, but it's completely misleading in presenting the UTI scheme as a replacement for creator code binding. UTIs are a completely different thing.

THEY ARE NOT DOCUMENT METADATA, the com.whatever.thing is not written on the disk with each file and associated to it, as the article could seem to imply. You can't replace the creator association of any single files with them.

UTIs are a very forward thinking way to solve other issues.
Basically, without UTIs, you'd have to declare each and any data type, mime type, or document extension that your application can handle if you want to make the OS aware that your app can make use of it.
With UTIs, you just can say that your app can handle public.text to let the OS know that it can feed any document that conforms to that generic type and expect to handle it, be it html, xml, js, txt...
Conversely, you can write an application that saves files, say, with .markdown extension and let the OS know that it's just a plain text file that it can feed to quicklook to preview or let any application that process public.text open it.
And as the article correctly point out, this is not limited to files but it's generalized to any data chunk.

UTIs are declared in plist files in the bundles of apps, plugin, spotlight importers, quicklook generators, whatever.
When the OS encounter a file, it can determine the proper UTI by looking at its estension and data type.

As you see it's a clever scheme but it has nothing to do with associating files to the applications that created them. That functionality depended upon creator codes only and has not been replaced by anything else.

THEY ARE NOT DOCUMENT METADATA, the com.whatever.thing is not written on the disk with each file and associated to it, as the article could seem to imply. You can't replace the creator association of any single files with them.

UTIs are a very forward thinking way to solve other issues.
Basically, without UTIs, you'd have to declare each and any data type, mime type, or document extension that your application can handle if you want to make the OS aware that your app can make use of it.
With UTIs, you just can say that your app can handle public.text to let the OS know that it can feed any document that conforms to that generic type and expect to handle it, be it html, xml, js, txt...
Conversely, you can write an application that saves files, say, with .markdown extension and let the OS know that it's just a plain text file that it can feed to quicklook to preview or let any application that process public.text open it.
And as the article correctly point out, this is not limited to files but it's generalized to any data chunk.

UTIs are declared in plist files in the bundles of apps, plugin, spotlight importers, quicklook generators, whatever.
When the OS encounter a file, it can determine the proper UTI by looking at its estension and data type.

As you see it's a clever scheme but it has nothing to do with associating files to the applications that created them. That functionality depended upon creator codes only and has not been replaced by anything else.

Quote:

Originally Posted by sdfisher

The part of the article you quoted is the incorrect part.

UTIs can not be assigned by an application. There's no mechanism for saying "This file has an extension of .txt, but is com.mycompany.product.import, which conforms to public.txt. This other file has an extension of .txt, but is com.mycompany.product.export, which which conforms to public.txt. This file has an extension of .txt, but is com.mycompany.otherproduct.import."

If I'm wrong, please let me know. I searched Apple's documentation for this some time ago for quite a few hours but never found anything.

Both of these don't quite hit the nail on the head. While the UTI itself is NOT metadata, metadata is where the UTI of the file is stored - in the kMDItemContentType entry of the meta data. In the finder use 'mdls <file>' to see both the UTI and the UTI tree (degrading readability) of a file created with a newer application. A unique UTI can be associated with a preferred application, serving the role of the creator code. For example here is a part of the mdls listing for a .pdf file.

If you found annoying that Fooapp .html files with FAPP creator code would open in Fooapp instead that in the defauly browser, you only had to select one of those, get info, change app to browser, and click "modify all". A dialog would inform you that all Fooapp files with .html extension would be opened in the browser, and you'd be set forever.

Yeah, but then you had to do that for every single file type that FooApp supported, as well as every type for every other app that set creator codes on its documents.

Not that it matters, since creator codes would have been going away even if the Finder still respected them in Snow Leopard, simply because Carbon has been deprecated, and the Carbon developers all seem to be moving toward Cocoa, and in Cocoa apps, the creator code never gets set unless the developer specifically bends over backwards to do so. And if the developer overrides the dataOfType:error: method to do the saving (which is the default), it's not possible to set the creator code at all. So regardless of whether the Finder supported it or not, the next versions of Word, Photoshop, etc. would all be dropping creator code support anyway. So it's mostly a dead horse.

If your workflow consist of creating and reopening for editing a big bunch of files with an extension associated with a default viewer (say, if you code all day .html files in a text editor), going thru the info panel can become extremely cumbersome. I guess you'd give up early and end up dragging them to the editor icon in the dock or right click and select "open with..." - which is a pain too.

When I do this I click the button once in the getinfo window and from that point on all those file types will open with my preferred app. In failing that I right-click on the file -> open with [select 'always open with appname'] and I'm done. Sometimes the correct file type icon still doesn't show up but it doesn't affect the opening process. A reboot always fixes the icon issue. This is with SL.

When I do this I click the button once in the getinfo window and from that point on all those file types will open with my preferred app. In failing that I right-click on the file -> open with [select 'always open with appname'] and I'm done. Sometimes the correct file type icon still doesn't show up but it doesn't affect the opening process. A reboot always fixes the icon issue. This is with SL.

What's the problem?

The discussion above is actually about something more sophisticated than what you are thinking. The mac users were used to creating say an RTF in iwork, another RTF in word and another in textedit and having the file remember which app created it so when they open it or send it to another user, the user's system will automatically open it in the application it was created on. this is far more complex than say opening all RTFs with textedit.

The discussion above is actually about something more sophisticated than what you are thinking. The mac users were used to creating say an RTF in iwork, another RTF in word and another in textedit and having the file remember which app created it so when they open it or send it to another user, the user's system will automatically open it in the application it was created on. this is far more complex than say opening all RTFs with textedit.

No it's not. If the app opens with the correct app on your machine it will do so on another. If they don't have that same app then it's a mute point.

Before you send the app to someone else you will know what app it opens with. If it's incorrect you do what I do above. You can also choose to have it open with a non default app.

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.

There is no official way of changing the type/creator code either, you needed third-party software for this.

UTIs replace file type codes, and do so well. However, unless the data being generated is in a proprietary format that only a single application will support, they do not replace creator codes.

If the file type is specific enough, eg, an Acorn-Photoshop-jpeg, the file will open in Acorn if Acorn is present, if Acorn is not present but PS is, in PS, and if none are present in the default app for jpegs. Can you tell me what more you could achieve with Creator Codes?

EDIT: Reading more comments, there seems to be some credence to the view that UTIs are a one-way street only, in that you can declare a proprietary extension (like .markdown or .acorn) and applications themselves to conform to eg, acorn.photoshop.jpeg.image.... but you cannot declare a file with an extension of .jpeg to have a UTI of acorn.photoshop.jpeg.image....
The article suggest otherwise but I am wondering whether this is one of those in-theory-yes-in-practice-no situations.

...and then you don't address my point at all. How do I, as an application, save a document with a common file extension and a specific UTI, changing the UTI but not the extension for different documents to fit the needs of the user?

No, it's a no-always-no situation. The author of the article had a particular article he wanted to write, and the facts don't matter to that.

You don't understand what I mean with theory.
In theory, the UTIs could be used as file metadata, as an extended form of the type metadata. This would fit into the idea of UTIs. And that is what I mean with theory: fitting into the idea.

No, it's a no-always-no situation. The author of the article had a particular article he wanted to write, and the facts don't matter to that.

I don't get what people think is missing from the UTI implementation. If you set the file's metatdata kMDItemContentType to a specific 'application', e.g. com.adobe.pdf, it can be associate with adobe reader (or other like preview) as the user desires while public.pdf is associated with other applications (or not). If you create your on pdf and put the UTI com.myspecialpdf.pdf in the metatdata it will always be opened with your specialpdf app. Or, the user can say I don't like specialpdf and associate that UTI with Preview or Adobe Reader, or whatever.

You don't understand what I mean with theory.
In theory, the UTIs could be used as file metadata, as an extended form of the type metadata. This would fit into the idea of UTIs. And that is what I mean with theory: fitting into the idea.

Actually, I did understand. Apple's missing an important piece of the puzzle that prevents it from working.

I don't get what people think is missing from the UTI implementation. If you set the file's metatdata kMDItemContentType to a specific 'application', e.g. com.adobe.pdf, it can be associate with adobe reader (or other like preview) as the user desires while public.pdf is associated with other applications (or not). If you create your on pdf and put the UTI com.myspecialpdf.pdf in the metatdata it will always be opened with your specialpdf app. Or, the user can say I don't like specialpdf and associate that UTI with Preview or Adobe Reader, or whatever.

...and then you don't address my point at all. How do I, as an application, save a document with a common file extension and a specific UTI, changing the UTI but not the extension for different documents to fit the needs of the user?

ignore<I did address your point. You set the kMDItemContentType in the files metadata to your UTI 'com.myspecialpdf.pdf' and set the file extension to .pdf and away you go. Are you asking how the end-user changes the UTI of a given file? If so, why would they want to do that? If an end user wants to assign a given UTI to a given application see the preference pane shown above. If and end user want to set a specific file to open with a specific app then use the Finder's built in controls.>

I though the kMDItemContentType could also be set by the program at file creation time.

ignore<I did address your point. You set the kMDItemContentType in the files metadata to your UTI 'com.myspecialpdf.pdf' and set the file extension to .pdf and away you go. Are you asking how the end-user changes the UTI of a given file? If so, why would they want to do that? If an end user wants to assign a given UTI to a given application see the preference pane shown above. If and end user want to set a specific file to open with a specific app then use the Finder's built in controls.>

I though the kMDItemContentType could also be set by the program at file creation time.

Apple's docs on kMDItemContentType:

kMDItemContentType: The UTI pedigree of a file. A CFString.

For example, a jpeg image file will have a value of public.jpeg/public.image/public.data. The value of this attribute is set by the MDImporter. Changes to this value are lost when the file attributes are next imported.

So it can be written to, but the value will be discarded by Spotlight. Not quite read only, but effectively so.

There is no official way of changing the type/creator code either, you needed third-party software for this.

Untrue.

SetFile -c "R*ch" -t "TEXT" ~/Desktop/somefile

Will give somefile BBEdit's creator code and a text file type. (SetFile is still present in Snow Leopard, ironically enough, though of course it can set other attributes, such as visibility, which are still supported.)

Will give somefile BBEdit's creator code and a text file type. (SetFile is still present in Snow Leopard, ironically enough, though of course it can set other attributes, such as visibility, which are still supported.)

What I meant is that there is no Apple-provided GUI for this, which means that Apple thinks you should not really need to change it.

Thanks for the article and all the responses.
I hope there is a work around for this or Apple fixes it. I have a hundreds of .eps files from clients & myself that were created with different applications, e.g., photoshop, illustrator, freehand, quark. Up until 10.6, in the Finder I could easily tell which application created it. Now, forget it. They all show up as belonging to the ONE application that I indicate. This is a step back.
I am not a programmer (console is voodoo to me) just a designer who has been using the mac platform since 1988...

UTIs are types. Creator Codes specify the application that created the document; it's not a type.

Very true. The article makes it sound like UTIs mechanism is supposed to replace both file type and application association but in reality UTIs - and this is by design - do not even try to solve the document-application association problem, which old creator code did very nicely.

Snow Leopard does not respect the creator code and does not provide a suitable replacement - what genius came up with that idea?

The Pasteboard's use of UTI was introduced above. It shouldn't be surprising that iPhone 3.0 also uses UTI in its new copy and paste support. If you were wondering why Apple "took so long" to bring that feature to the iPhone, it's because the platform opted for a long term, robust solution rather than a quick and dirty kluge impacted by security issues.

iPhone OS is descended from desktop OS X so surely UTI support would have already been built in?