One of the difficulties in maintaining a user-accessible
operating system is establishing connections between data types and the applications or processes that can effectively use such data. For example, a file that contains picture data in a particular compression format can only be opened and processed in applications that are capable of handling picture data, and those applications must be able to identify which compression type was used in order to extract and work with that data. In early computer systems, file associations are maintained by
file extensions. The three to four character code following a file name instructs the system to open the file in particular applications. Beginning with
System 1,
Macintosh operating systems have attached
type codes and
creator codes as part of the file
metadata. These four-character codes were designed to specify both the application that created the file (the creator code) and the specific type of the file (the type code) so that other applications could easily open and process the file data. However, while type and creator codes extended the flexibility of the system — a particular type of file was not restricted to opening in a particular application — they suffered many of the same problems as file extensions. Type and creator codes could be lost when files were transferred across non-Macintosh systems (such as Unix-based servers), and the plethora of type codes made identification problematic. In addition, the
classic Mac OS did not recognize file extensions at all, leading to unrecognized file errors when files were transferred from DOS/Windows systems.
OPENSTEP, which formed the basis of Mac OS X, used extensions, and early versions of Mac OS X followed suit. This led to some controversy with users and developers coming to OS X from NeXT or Windows origins advocating for continued use of file extensions, and those coming from Classic Mac OS urging Apple to replace or supplement file extensions with type and creators. Other file identification types exist: for example, MIME types are used for identifying data that is transferred over the web. However, Apple's UTI system was designed to create a flexible file association system that would describe data hierarchically and allow for better categorization and searching, standardize data descriptions across contexts, and provide a uniform method of expanding data types. For instance, the
public.jpeg and
public.png UTIs inherit from the
public.image UTI, allowing users to search narrowly for JPEG images or PNG images or broadly for any kind of image merely by changing the specificity of the UTI used in the search. Further, application developers who design new data types can easily extend the UTIs available. For example, a new image format developed by a company may have a UTI of
com.company.proprietary-image and be specified to inherit from the
public.image type. Apple's
macOS continues to support other forms of file association, and contains utilities for translating between them, but will use UTIs by preference where available. ==
UTI structure==