Bundle creator OS Type code ??? in Xcode 4

Question

I just realized that Bundle Creator OS Type code in my iOS app's Info.plist value is ????? in Xcode 4. What is the value supposed to be?

Solution 1

It's used to identify your application. You don't have to change it for an iPhone application.

Take a look at these links:

• Information Property List Key Reference

• Mac Creator and File Type Codes

• Data Type Registration

Solution 2

It's not really used anymore. It's a holdover from the Classic Mac OS days when it was a datapoint used mainly to determine what apps could create or edit or read file types. Back then you had to register them with Apple. I don't think they even provide that service any more. OS X and some apps might still use it in rare cases under the hood but its very legacy. As you can imagine, the severely limited possible permutations made it untenable long term.

UTIs are the preferred approach now. The system then uses a combination of these and file extensions and magic numbers. Though on ios that may not be true as much as OSX.

Solution 3

It is just the four letter code to identify the bunder creator... for example for apple it is APPL... It can be ???? or if your app name is "myApp" you can give "MYAP"... If you have many apps you can give first 2 characters with your app name and next 2 characters with company name...

For example apple uses CF for core foundation, AV etc

http://developer.apple.com/library/ios/#documentation/general/Reference/InfoPlistKeyReference/Articles/CoreFoundationKeys.html

Solution 4

Just to give the historical perspective on extensions and file type and creator codes.

File extensions were part of the file system in CP/M and were intended to function something like what file types and creator codes actually did in MacOS. At the time, it was expected that each application would use a unique extension and only the one application would ever edit its own files. In the file system, the file name and extension were stored in two different areas, so the extension was not part of the name. Remember, at that time most systems had only a few applications, and file contents were specific to an application. They were never intended to be visible to end users, but due to an error in the directory command in CP/M, they were shown displayed as if they were part of the file name. MS-DOS picked up the convention, and the rest, unfortunately is history.

Apple's initial file system design saw the shortcomings of the extension concept, the primary one being that some file types were likely to be used by more than one application and with standardization of file formats, having more than one application that could operate on a file would be common. Therefore Apple split the file creator - the app that created the file - from the file type. By default if a file was double clicked, the originally creating application would open it. However, if a user did a file open from within an application, then all compatible files were supposed to be listed, even if that app was not the creator. Also, it would be possible to list all the applications that could open a file. Semantically, as intended in CP/M, the type and creator codes were separate from the file name itself.

Developers that properly registered their applications with Apple got their own creator codes. The problems with this concept came about from two sources: 1. Developers that hijacked other's or Apples own creator codes. 2. Unix systems, which never had a formal filename extension (all file names were a single string) began adopting the convention to end the file name with a dot and some additional letters to indicate file type. In the Unix convention, the extension is part of the file name itself, unlike CP/M and MS-DOS.

View more solutions

Comments

[Nevin]

it's fine to me. I haven't change it and the app got approved.

[JMD]

That's the definition of "Bundle OS Type code". The OP asked about "Bundle creator OS Type code". (An easy oversight that Apple should have preempted with better naming.)

[Mazyod]

FWIW, nor do you have to change it for a Mac app... Although, it's tempting to set a 4 letter useless word to something fun. Use your imagination.

[uchuugaka]

You should not set it at all. It might actually conflict in extremely rare, undocumented circumstances with some app that did legitimately register it in the 90's and where the OS might actually still have facilities to check that. Microsoft and Adobe, and anybody else on the Classic Mac OS likely had registered.

[uchuugaka]

I would caution AGAINST setting the Creator Type Code at all. It is more likely to cause harm that good. There is a good reason this was dropped with OS 9. It was a source of many hijinks and frustrations toward the end of the 1990's and was never reliable.

[uchuugaka]

You should ignore it for all applications.

[Cerniuk]

Actually quite the opposite. It was a very robust way of identifying the creator of a file that did not rely on an unreliable and arcane, and exceptionally limited in functionality Windows style file name extension.

[uchuugaka]

You're kidding right? Apps frequently hijacked creator codes and the OS couldn't really differentiate. What's more, it required registration with Apple and had a severely finite set of codes. The modern means uses all sorts of heuristics. Not just file extensions.

[Cerniuk]

Not kidding. Remember creator code & type code provide a unique combo in the system identifying each file type. Common chars are from space (32) to tilde (126). Mathematically this is (126-32)^8 different file types. In practical terms it is (126-32)^4 different apps each with (126-32)^4 different types of files the app "own". Is that limited? (126-32)^8 is over 1.4 million times the number of machines on the general public internet (IPv4 address space = 2^32, hence ((126-32)^8)/(2^32)). Best, users can't "corrupt" a file by changing its name (removing it's extension) if using Type/Creator.

[uchuugaka]

But in reality, especially in the 90's there were a handful of commonly used file types and apps would frequently hijack the "creator" status, even trying to be helpful. It was a messy thing for the less technical folks who could not understand why their intended app no longer opened when they double clicked something. What we get today is a better model with the Cocoa Document architecture + *nix style of anything. IMHO, the combination of heuristics (beyond magic file), extensions (somewhat) and user preference.

[Cerniuk]

RE: the hijack, respectfully disagree. Now its a free for all w/ ".jpg", ".png" & all other file extensions. The default app like Preview keeps getting all ".jpg"s created by Pixelmator and Adobe Photoshop. Users now have to manage file relationships to apps individually and manually via Finder's "Get Info" and set "Open with" so the zip file created with "Zipster" opens w/ "Zipster" instead expanding w/ "Archive". Worse, when a user to removes the extension via "Get Info", they have very effectively corrupted the file from a general user perspective, Finder supported, no extra app needed.