xcode project setting

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


CFBundleDocumentTypes


CFBundleDocumentTypes (Array - iOS, OS X) contains an array of dictionaries that associate one or more document types with your app. Each dictionary is called a type-definition dictionary and contains keys used to define the document type. Table 2 lists the keys that are supported in these dictionaries.


Table 2  Keys for type-definition dictionaries
Key
Xcode name
Type
Description
Platforms
CFBundleTypeExtensions
“Document Extensions”
Array
This key contains an array of strings. Each string contains a filename extension (minus the leading period) to map to this document type. To open documents with any extension, specify an extension with a single asterisk “*”. (In OS X v10.4, this key is ignored if the LSItemContentTypes key is present.) Deprecated in OS X v10.5.
OS X
CFBundleTypeIconFile
“Icon File Name”
String
This key contains a string with the name of the icon file (.icns) to associate with this OS X document type. For more information about specifying document icons, see Document Icons.
OS X
CFBundleTypeIconFiles
None
Array
An array of strings containing the names of the image files to use for the document icon in iOS. For more information about specifying document icons, see Document Icons.
iOS
CFBundleTypeMIMETypes
“Document MIME types”
Array
Contains an array of strings. Each string contains the MIME type name you want to map to this document type. (In OS X v10.4, this key is ignored if the LSItemContentTypes key is present.) Deprecated in OS X v10.5.
OS X
CFBundleTypeName
“Document Type Name”
String
This key contains the abstract name for the document type and is used to refer to the type. This key is required and can be localized by including it in an InfoPlist.strings files. This value is the main way to refer to a document type. If you are concerned about this key being unique, you should consider using a uniform type identifier (UTI) for this string instead. If the type is a common Clipboard type supported by the system, you can use one of the standard types listed in the NSPasteboard class description.
iOS, OS X
CFBundleTypeOSTypes
“Document OS Types”
Array
This key contains an array of strings. Each string contains a four-letter type code that maps to this document type. To open documents of any type, include four asterisk characters (****) as the type code. These codes are equivalent to the legacy type codes used by Mac OS 9. (In OS X v10.4, this key is ignored if the LSItemContentTypes key is present.) Deprecated in OS X v10.5.
OS X
CFBundleTypeRole
“Role”
String
This key specifies the app’s role with respect to the type. The value can be Editor, Viewer, Shell, or None. This key is required.
OS X
LSItemContentTypes
“Document Content Type UTIs”
Array
This key contains an array of strings. Each string contains a UTI defining a supported file type. The UTI string must be spelled out explicitly, as opposed to using one of the constants defined by Launch Services. For example, to support PNG files, you would include the string “public.png“ in the array. When using this key, also add the NSExportableTypes key with the appropriate entries. In OS X v10.5 and later, this key (when present) takes precedence over these type-identifier keys: CFBundleTypeExtensions, CFBundleTypeMIMETypes, CFBundleTypeOSTypes.
iOS, OS X
LSHandlerRank
“Handler rank”
String
Determines how Launch Services ranks this app among the apps that declare themselves editors or viewers of files of this type. The possible values are: Owner (this app is the creator of files of this type), Alternate (this app is a secondary viewer of files of this type), None (this app must never be used to open files of this type, but it accepts drops of files of this type), Default (default; this app doesn’t accept drops of files of this type). Launch Services uses the value of LSHandlerRank to determine the app to use to open files of this type. The order of precedence is: Owner, Alternate, None. This key is available in OS X v10.5 and later.
iOS, OS X
LSTypeIsPackage
“Document is a package or bundle”
Boolean
Specifies whether the document is distributed as a bundle. If set to true, the bundle directory is treated as a file. (In OS X v10.4 and later, this key is ignored if the LSItemContentTypes key is present.)
OS X
NSDocumentClass
“Cocoa NSDocument Class”
String
This key specifies the name of the NSDocument subclass used to instantiate instances of this document. This key is used by Cocoa apps only.
OS X
NSUbiquitousDocumentUserActivityType
None
String
This key specifies the activity type of the NSUserActivity object associated with this document.
iOS, OS X
NSExportableAs
“Exportable As Document Type Names”
Array
This key specifies an array of strings. Each string contains the name of another document type, that is, the value of a CFBundleTypeName property. This value represents another data format to which this document can export its content. This key is used by Cocoa apps only. Deprecated in OS X v10.5.
OS X
NSExportableTypes
None
Array
This key specifies an array strings. Each string should contain a UTI defining a supported file type to which this document can export its content. Each UTI string must be spelled out explicitly, as opposed to using one of the constants defined by Launch Services. For example, to support PNG files, you would include the string “public.png“ in the array. This key is used by Cocoa apps only. Available in OS X v10.5 and later.
OS X
The way you specify icon files in OS X and iOS is different because of the supported file formats on each platform. In iOS, each icon resource file is typically a PNG file that contains only one image. Therefore, it is necessary to specify different image files for different icon sizes. However, when specifying icons in OS X, you use an icon file (with extension .icns), which is capable of storing the icon at several different resolutions.


This key is supported in iOS 3.2 and later and all versions of OS X. For detailed information about UTIs, see Uniform Type Identifiers Overview.


Document Roles
An app can take one of the following roles for any given document type:


Editor. The app can read, manipulate, and save the type.
Viewer. The app can read and present data of that type.
Shell. The app provides runtime services for other processes—for example, a Java applet viewer. The name of the document is the name of the hosted process (instead of the name of the app), and a new process is created for each document opened.
None. The app does not understand the data, but is just declaring information about the type (for example, the Finder declaring an icon for fonts).

The role you choose applies to all of the concrete formats associated with the document or Clipboard type. For example, the Safari app associates itself as a viewer for documents with the “.html”, “.htm”, “shtml, or “jhtml” filename extensions. Each of these extensions represents a concrete type of document that falls into the overall category of HTML documents. This same document can also support MIME types and legacy 4-byte OS types.

Mach-O,short for Mach object file format, is a file format for executables, object code, shared libraries, dynamically-loaded code, and core dumps. For unix users this is like a.out but with improvements. This is the format used in Mac OS X and iPhone OS libraries for executable files.

As you know iOS devices (iPhone, iPad etc.) have different architectures ARMv6 (iPhone 2G + 3G, iPod Touch) and ARMv7 (iPhone 3GS, iPod Touch 2G + 3G) but the simulators used in Xcode runs mostly on i386 platform. This means the that the library clients have to setup separate targets for the simulator and device. The separate targets duplicate most information, and only differ in the static libraries included. So if you are getting a Mach-O linker error what it means is that xcode is having trouble linking to one of the libraries for that target device; as a result of which compilation fails.

Now your definitions - 

1. Executable - compiled machine targeted program ready to be run in binary format. 
2. Dynamic Library - are linked during runtime -- a program with references to a dynamic library will load and link with the library when it starts up (or on demand).
3. Bundles - and bundle identifier let iOS and OSX recognise any updates to your app. It gives it a unique presence in the app.
4. Static Library - files are linked at build time. code is copied into the executable. Code in the library that isn't referenced by your program is removed. A program with only static libraries doesn't have any dependencies during runtime.
5. Relocatable Object File - is another word for a dynamic library. When you link with a dynamic library, the addresses of the functions contained within are computed, based on where the library is loaded in memory. They are "relocatable" because the addresses of the contained functions are not determined at link time. (In a static library, the addresses are computed during link time.)