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?

Answer 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

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

Answer 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

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