22. Bundles and Packages
Many of Xcode’s products take the form of packages, directory trees that the Finder presents as single files. Let’s pause to consider the problem of resources. Resources are the sorts of data that are integral to an application, but for one reason or another aren’t suitable to incorporate into source code: strings, lookup tables, images, human-interface layouts, sounds, and the like.
In the original Mac OS, applications kept resources in resource forks, mini-databases kept in parallel with the data stream one normally thinks of as a file. The problem with the Resource Manager was that it did not scale well to sets of many, large, or changeable resources. The catalog written into each resource file was fragile, and any corruption resulted in the loss of every resource in the file. Modern apps use many more and much larger resources, and the tasks involved in managing them become indistinguishable from the tasks of a filesystem. Filesystems are a solved problem; they are as efficient and robust as decades of experience can make them. Why not use the filesystem for storing and retrieving resources?
One reason to avoid shipping application resources as separate files is that an application that relies on them becomes a swarm of files and directories, all more or less critical to the correct working of the application, and all exposed to relocation, deletion, and general abuse by the application’s user. Meanwhile, the user, who just wants one thing that does the application’s work, is presented with a swarm of files and directories.
OS X provides a way to have the flexibility of separating resources into their own files while steering clear of the swarming problem. The Finder can treat directories, called packages, as though they were single documents.
A Simple Package: RTFD
A package can be as simple as a directory with a handful of files in it. The application that creates and reads the package determines how it is structured: what files are required, the names of the content files, and what sort of subdirectory structure is used.
A common example of an application-defined package is the RTFD, or rich text file directory. The Apple-supplied application TextEdit, in its Info.plist file, specifies what kinds of documents TextEdit can handle; among these is NSRTFDPboardType, which is listed as having suffix rtfd and is designated as a package file type. When it catalogs TextEdit, the Finder notes that directories with the .rtfd extension are supposed to be packages and so treats them as if they were single files, without displaying the files within.
It is sometimes useful to look inside a package, however, and the Finder provides a way to do that. Right-clicking on a package file produces a popup menu containing the command Show Package Contents (see Figure 22.1). Selecting that command opens a new window showing the contents of the package directory, which can be further navigated as in a normal Finder window.
Figure 22.1 Right-clicking a package document in the Finder presents a menu that includes the command Show Package Contents, which shows the files within the package.
In the case of RTFD, the package directory contains one plain RTF file, TXT.rtf. The RTF file incorporates custom markup, such as
The icon looks like this:
pard x560 x1120 x1680 x2240 x2800 x3360 x3920 x4480
x5040 x5600 x6160 x6720pardirnatural
cf0 {{NeXTGraphic [email protected] width2400 height2400
}}
Here, the markup refers to a graphics file—in this case, [email protected]—that is also in the RTFD directory.
Note
Cocoa’s AppKit application framework provides support for package-directory documents. NSDocument subclasses handle package reading and writing by overriding readFromFileWrapper(_,ofType:,error:) and fileWrapperOfType(_,error:). The NSFileWrapper class provides methods that assist in creating and managing complex file packages.
Bundles
A bundle is a particular kind of structured directory tree. Often, bundles are shipped as packages—the most familiar type of bundle, the application, is an example—but the concepts are separate. A directory can be a bundle without being a package, or a package without being a bundle, or it can be both. Table 22.1 has examples.
There are two kinds of bundles in OS X: versioned bundles, which are used for frameworks—structured packages of dynamic libraries, headers, and the resource files that support them—and modern bundles, which are used for applications and most other executable products.
Note
“Modern” is a relative term; modern packages were in NeXTStep long before Cocoa.
At the minimum, a modern Mac bundle encloses one directory, named Contents, which in turn contains all the directories and files composing the bundle. The Contents directory contains an Info.plist file, which specifies how the bundle is to be displayed in the Finder and, depending on the type of the bundle, may provide configuration data for loading and running the bundle’s contents. Beyond that, what the Contents folder contains depends on the type of the bundle.
Application Bundles
OS X applications are the most common type of bundle (see Figure 22.2). An application directory has a name with the suffix .app. The .app directory is a file package; even though it is a directory, the Finder treats it as a single entity. This allows the author of the application to place auxiliary files for the application in a known place—inside the application bundle itself—with little fear that they will be misplaced or deleted.
Figure 22.2 The structure of a typical application bundle. The executable file is at Contents/MacOS/Application. The default structure of the application’s human interface is specified in a compiled storyboard, Contents/Resources/Base.lproj/Main.storyboardc; presumably, a French .strings file is inside Contents/Resources/fr.lproj. The custom image for a button, Login button.png, is common to all languages and therefore appears in the Resources directory itself.
The Contents directory of an OS X application bundle most commonly contains
Info.plist, an XML property list file that describes such application details as the principal class, the document types handled, and the application version. More on this file in the next section.
Resources, a directory containing the application icon file, images, sounds, human-interface layouts, and other parameterized content for the application. Common content, such as button images, may be found in the Resources directory itself; localizable files are kept in .lproj directories. There will typically be a Base.lproj directory for the default layouts and strings, with additional .lproj directories to supply customizations for specific locales. When an application seeks a resource, the Cocoa or Core Foundation bundle managers will look first in the .lproj directory that corresponds to the current language and locale.
MacOS, a directory containing the executable binary for the application, along with any other executables.
Frameworks, a directory of frameworks that are themselves versioned bundles, containing a dynamic library, resources needed by the library, and header files needed by users of the library. An application typically includes a framework because it links to the framework’s library.
Note
What about iOS apps? They’re packages—the Finder treats them as unitary files—but not bundles. Everything except the localization .lproj directories and directories you explicitly add to the application resources is in the .app bundle directory. Have a look: Hold down the Option key and select Library from the Finder’s Go menu. Pass through Developer/Xcode/DerivedData and find the name of one of your iOS projects (a long hash string will follow it). In that directory, Build/Products is where you’ll find directories for combinations of build configurations and target operating systems. Your .app files will be there. Right-click on any, and select Show Package Contents.
The Info.plist File
The Info.plist file, found in the Contents directory of any modern bundle and at the root of the .app bundle for iOS applications, is the locus of much of the information OS X and iOS need to make sense of a bundle. This file provides icon and naming information to the Finder/Home screen, flags and environment variables to Launch Services, “default” screen images in various sizes and orientations for iOS apps, and specifications for the basic structure of applications and plugins. It’s a property list (.plist) dictionary file, a format I’ll cover in Chapter 23, “Property Lists.”
The Target editor’s General and Info tabs form a specialized editor for the target’s Info.plist. They’ll give you at least a first cut at the settings you need without much trouble.
You can also edit the Info.plist file directly, using the Property List editor (see Chapter 23, “Property Lists”). Sort of. The Info.plist you will be editing is a precursor of the file that will go into the product package.
What you’re seeing is a source file that Xcode will process to generate the final property list. It’s this processing phase that allows you to use build-variable references instead of literal values for some of the keys. The handling of the target-specific Info.plists is special: They are not to be included in any build phase of your target—that will just copy the unprocessed source file into the application’s Resources directory. Instead, the name of the file is specified in the INFOPLIST_FILE build variable. The build system picks it up from there.
Note
There are a number of build settings that control processing of Info.plist. Check the “Packaging” section of the Build Settings tab of the Target editor. Among them are the option to use C-style preprocessor directives in the source file. Unfortunately, once you use them, you are committed to editing the file as XML text because the Property List editor destroys all content that isn’t property-list XML.
Most targets need their own Info.plists. A project with more than one target has more than one Info.plist file to manage. Versions of Xcode before 6 handled the potential collision by prefixing the target’s name to the precursor file’s: my framework-Info.plist. Xcode 6 insists on segregating target files in their own directories, and has dropped the target-prefix convention, but you may run into it in older projects.
Localizing Info.plist
Some Info.plist properties are localizable. A file named InfoPlist.strings should be in the .lproj directory for each localization of your application. Localizable keys can then be assigned per-locale values. For instance, InfoPlist.strings in the English.lproj directory might include the pair:
CFBundleName = "PasserRating";
CFBundleDisplayName = "Passer Rating";
The same file in the fr.lproj directory might include
CFBundleName = "Q-Effic";
CFBundleDisplayName = "Quart-Efficacité";
For users whose language preferences place French above English, the Mac Passer Rating icon will be labeled Quart-Efficacité. The name of the bundle directory, however, will still be PasserRating.app, even if the casual user doesn’t see it.
The Xcode Property List editor customizes itself for Info.plists. When the name of a file ends in Info.plist, it will fill the dictionary key column with popup menus offering the keys peculiar to that kind of property list. This means that you should avoid using Xcode to edit property lists whose names end that way (like the DirectoryInfo.plist file you’re setting up for some names and addresses) but aren’t actual Info.plists.
Info.plist Keys for Applications
Info.plist keys have proliferated as more and more OS services need to characterize the needs and capabilities of applications. In earlier editions of this book, I was able to list almost every key—even a couple whose names appeared nowhere on the Internet. That’s not possible any more.
What you’ll see here are the most frequently used keys for application Info.plists. I’ve itemized the dictionary keys, followed by the plain-English labels used by the Property List editor.
Keys for Both iOS and OS X
The keys in this section apply to application bundles on both OS X and iOS.
CFBundleExecutable (Executable file), the name of the executable file, which may be an application binary, a library, or plugin code. It corresponds to the EXECUTABLE_NAME build setting, which in turn is derived from PRODUCT_NAME (plus an optional prefix and suffix, which you’d rarely use). A bundle that mismatches this entry with the actual name of the executable file will not run. Applications must specify this key.
CFBundleIdentifier (Bundle identifier), a unique identifier string for the bundle, in the form of a Java-style reverse domain package name, such as com.wt9t.Passer-Rating. Xcode initializes this to the company ID you supplied when you chose the project template, followed by ${PRODUCT_NAME:rfc1034identifier}, and you can expect to leave it alone. All bundles must specify this key.
CFBundleInfoDictionaryVersion (InfoDictionary version), a compatibility-check version number for the Info.plist format. Xcode injects this version number when it builds bundles. I’ve never seen a version number other than 6.0. All Info.plist files should include this key.
CFBundlePackageType (Bundle OS Type code), optional on iOS, the four-character type code for the bundle. Applications are type APPL, frameworks are FMWK, plugins are BNDL or a code of your choosing. See also CFBundleSignature. OS X applications must specify this key.
CFBundleSignature (Bundle creator OS Type code), optional on iOS, the four-character creator code associated with the bundle. OS X applications must specify this key, but it’s rare for it to be anything other than ????.
NSPrincipalClass (Principal class), the name of the bundle’s main class. In an OS X application, this would normally be NSApplication; in iOS, UIApplication.
NSMainNibFile (Main nib file base name), the base (no extension) name of the application’s main NIB file, almost always MainMenu on OS X, and MainWindow on iOS (when a main NIB is used at all). Use NSMainNibFile~ipad (Main nib file base name (iPad)) to specify a separate NIB for your app when it’s launched on an iPad.
NSMainStoryboardFile (Main storyboard file base name), the base (no extension) name of the application’s main Storyboard file, usually Main on OS X. The iOS equivalent is UIMainStoryboardFile; see below.
User Information
CFBundleGetInfoString (Get Info string), Mac only, a string that supplements the version information supplied by CFBundleShortVersionString and CFBundleVersion. Formerly, this key was used for copyright strings, but that is now handled by NSHumanReadableCopyright.
CFBundleIconFile (Icon file), the name of the file in the Resources directory that contains the bundle’s custom icon, a file in .icns format for Mac, .png for iOS. You can omit the extension. An iOS application would prefer CFBundleIconFiles, an array of standardized names for the various rendering sizes of the application icon.
All of this is moot in Xcode 6. The General tab of the Target editor lets you specify images for icons, either file by file or through an asset catalog. From that, the build system will inject the necessary icon references into Info.plist.
CFBundleShortVersionString (Bundle versions string, short), a short string with the product version, such as 4.3.4, of the bundle, suitable for display in an About box or by the App Store. See also CFBundleGetInfoString. This key may be localized in InfoPlist.strings. Applications must specify this key.
CFBundleVersion (Bundle version), the build version of the bundle’s executable. In the past, this string was nearly identical to the short version string, with maybe a suffix like b2 to mark prerelease versions, or a serial number of the build that produced this binary: 2.1b4 (2133). The current practice is to use just the build serial number. iOS will refuse to install a new binary over an existing application unless the bundle version of the new binary is greater than the previous one. An integer serial number is easiest for you to generate, and for iOS to parse.
CFBundleDisplayName (Bundle display name), the name for the Finder or Home screen to display for this bundle. The value in Info.plist should be identical to the name of the application bundle; localized names can then be put in InfoPlist.strings files for various languages. The OS will display the localized name only if the name of the application package in the filesystem matches the value of this key. That way, if a Mac user renames your application, the name he intended—and not the localized name—will be displayed. Project templates will initialize this key to ${PRODUCT_NAME}. See also CFBundleName. Applications must specify this key.
CFBundleName (Bundle name), the short—16-character maximum—name for the application, to be shown in the About box and the Application menu. See also CFBundleDisplayName. This key may be localized in InfoPlist.strings; Xcode initializes it to ${PRODUCT_NAME}. Applications must specify this key.
Localization
CFBundleDevelopmentRegion (Localization native development region), the native human language, and variant thereof, of the bundle, like fr-CA for Canadian French. If the user’s preferred language is not available as a localization, this is the language that will be used.
Documents and URLs
CFBundleDocumentTypes (Document types), an array of dictionaries specifying every document type associated with the application. Use the Info tab of the Target editor for the application target to edit these; you’ll save yourself some headaches.
CFBundleURLTypes (URL types), an array of dictionaries defining URL schemes, such as http:, ftp:, or x-com-wt9t-custom-scheme:, for which the application is a handler. Use common schemes with care; if you’re a web browser, you support http:, but if you just happen to pull some resources from an HTTP server, don’t advertise yourself to the whole system as being able to service http URLs. This tag is much more useful in iOS, where your application’s custom scheme can provide a handy interapplication communications method for other applications, email, and the web. See Apple’s documentation, and the Info tab of the Target editor, for details.
UTExportedTypeDeclarations (Exported Type UTIs), an array of dictionaries that describe the types of documents your application can write, and which you want Launch Services to know about. The entries center on declaring a UTI and the chain of UTIs the principal UTI conforms to. This key is used by Spotlight to build its list of document types. UTIs take precedence over the declarations in CFBundleDocumentTypes as of OS X 10.5. Again, it’s easier to manage this list through the Info tab of the Target editor. See Apple’s documentation for the format of the dictionaries.
UTImportedTypeDeclarations (Imported Type UTIs), an array of dictionaries that describe the types of documents your application can read, and which you want Launch Services to know about. The entries are the same format as used in UTExportedTypeDeclarations. The Info tab of the Target editor provides an easy editor for this.
Keys for OS X
These keys apply only to OS X applications and cover launch configurations, help facilities, and information on the documents and URLs the application handles. The Info.plist structure antedates OS X, so many keys have fallen into obsolescence, but the OS has to support them for backward compatibility. The template you instantiate for a new application target will give you everything you need to start, and the Info tab will help you with almost everything you’d ever need to fit what you want to do, but there’s no substitute for following the OS release notes.
CSResourcesFileMapped (Resources should be file-mapped), if YES or <true/>, Core Foundation will memory-map the bundle resources rather than read the files into memory.
ATSApplicationFontsPath (Application fonts resource path), a string. If your application contains fonts for its own use, it contains the path, relative to the application’s Resources directory, to the directory containing the fonts.
User Information
NSHumanReadableCopyright (Copyright (human-readable)), a copyright string suitable for display in an About box. This key may be localized in InfoPlist.strings. Applications must specify this key.
LSApplicationCategoryType (Application Category). This is a string containing an Apple-defined UTI that describes for the Mac App Store what kind of application this is—Business, Lifestyle, Video, etc. Ordinarily, you’d set this in the General tab of the application’s Target editor, so you don’t have to bother with the UTIs. When you submit your app through iTunes Connect, you will be allowed two categories for your listing; make sure the primary one is the same as your LSApplicationCategoryType.
Help
CFAppleHelpAnchor (Help file), the base name, without extension, of the initial help file for the application.
CFBundleHelpBookFolder (Help Book directory name), the folder—in either the Resources subdirectory or a localization subdirectory—containing the application’s help book.
CFBundleHelpBookName (Help Book identifier), the name of the application’s help book. This name should match the name set in a <meta> tag in the help book’s root file.
Launch Behavior These keys control how Launch Services launches and configures a Mac application. iOS has a “Launch Services” framework, but there is no public interface for it.
LSBackgroundOnly (Application is background only), if it’s the string 1, the application will be run in the background only and will not be visible to the user.
LSEnvironment (Environment variables), a dictionary, the keys of which are environment-variable names, defining environment variables to be passed to the application upon launch.
LSGetAppDiedEvents (Application should get App Died events), indicates, if YES or <true/>, that the application will get the kAEApplicationDied Apple event when any of its child processes terminate.
NSSupportsSuddenTermination (Application can be killed immediately after launch). When you log out, restart, or shut down, OS X takes care that all running applications will be given the chance to clean up, ask the user to save files, and so on. If this key is <true/>, the system will shut down your application with a BSD kill signal instead. You can still use NSProcessInfo methods to restore the ask-first policy (such as when you are in the middle of writing a file), but the kill policy makes shutdowns much quicker.
LSMinimumSystemVersion (Minimum system version), a string in the form 10.x.x, specifying the earliest version of OS X or iOS this application will run under. Under OS X, if the current OS is earlier (back through 10.4), it will post an alert explaining that the app could not be run.
LSMinimumSystemVersionByArchitecture (Minimum system versions, per-architecture), a dictionary. The possible keys are i386 and x86_64. For each key, the value is a string containing the three-revision version number (e.g., 10.9.3) representing the minimum version of OS X the application supports for that architecture.
LSMultipleInstancesProhibited (Application prohibits multiple instances), indicating that, if <true/>, only one copy of this application can be run at a time. Different users, for instance, would not be able to use the application simultaneously.
LSUIElement (Application is agent [UIElement]), if set to the string 1, identifies this application as an agent application, a background application that has no presence in the Dock but that can present user interface elements, if necessary.
LSUIPresentationMode (Application UI Presentation Mode), an integer between 0 and 4, representing progressively greater amounts of the OS X UI—Dock and menu bar—to be hidden when the application is running. See Apple’s documentation for details.
Other Services
LSFileQuarantineEnabled (File quarantine enabled): If <true/>, Launch Services will regard the files your application creates as though they had been downloaded from the Internet and warn the user of the possible risk in opening them. You can exempt files from quarantine with LSFileQuarantineExcludedPathPatterns.
LSFileQuarantineExcludedPathPatterns (no editor equivalent) is an array of glob wildcard patterns for files (locations, extensions, etc.) that will be exempt from quarantining even if LSFileQuarantineEnabled is set.
NSAppleScriptEnabled (Scriptable), indicating that, if YES or <true/>, this application is scriptable. Applications must specify this key.
OSAScriptingDefinition (Scripting definition file name), the name of the .sdef file, to be found in the application’s Resources directory, containing its AppleScript scripting dictionary.
NSServices (Services), an array of dictionaries declaring the OS X services this application performs, which will appear in the Services submenu of every application’s application menu, subject to the Keyboard Shortcuts tab in the Keyboard panel of System Preferences. The dictionaries specify the pasteboard input and output formats, the name of the service, and the name of the method that implements the service. See Apple’s documentation for details.
Keys for iOS
These tags are unique to iOS applications. In general, if you want to customize any Info.plist key for a particular device, create a custom key composed of the base name, followed by a hyphen, then iphoneos, a tilde, and a device specifier (one of iphone, ipod, or ipad). For example: UIStatusBarStyle-iphoneos~ipad. In practice, you can omit the -iphoneos part: UIStatusBarStyle~ipad.
Structure
UIMainStoryboardFile, the base name of the storyboard package that is the root of the application. Use this, or NSMainNibFile, but never both. If you have a separate storyboard for iPhone or iPad only, add the base name to UIMainStoryboardFile~ipad or ~iphone. (ipad and iphone are all-lowercase.)
UILaunchStoryboardName (Launch screen interface file base name), the base name of a storyboard that iOS will display instead of a default screen image while your application is launching. With the proliferation of screen sizes, the use of a storyboard, which can adapt to many sizes, makes more sense than having a bitmap image for each size. You’ll find a discussion in the section “Icons and Launch Displays” in Chapter 13, “Adding Table Cells.” Note well that if you do not have a launch XIB or storyboard, iOS takes that as a sign that your app is not prepared to run on a screen like the iPhone 6 or 6 Plus. If there are only images, your app will run “zoomed” to fit the larger screen.
LSRequiresIPhoneOS (Application requires iOS environment), whether Launch Services will refuse to launch the application except on an iOS device. The tag is optional, because it should go without saying.
CFBundleIconFiles (Icon files), an array of filenames for the application icons. These are expected to be the same icon in the various sizes needed by different iOS platforms; the system will look through the files themselves to pick the proper one. If you omit the file extensions, the system will find “@2x” and “@3x” Retina Display variants automatically. Overrides CFBundleIconFile. (optional)
UIAppFonts (Fonts provided by application), an array of paths within the application bundle for application-supplied font files.
UIRequiredDeviceCapabilities (Required device capabilities), an array of strings, like telephony, wifi, or video-camera, that describe what device features your application cannot run without. This is used by iTunes and the App Store to save users who don’t have those features from buying and installing your app.
UIRequiresPersistentWiFi (Application uses Wi-Fi). The Property List editor’s summary is a little misleading. By default, iOS will shut down the Wi-Fi connection if you haven’t used it for half an hour. If this key is present and YES, the Wi-Fi transceiver will be turned on as soon as your application is launched, and it will stay on as long as it is running.
UISupportedExternalAccessoryProtocols (Supported external accessory protocols), for an array of strings naming all the external-device protocols your application supports. The protocol names are specified by the manufacturers of the accessories.
User Presentation
UIStatusBarStyle (Status bar style), the style (gray, translucent, or opaque black) of the initial status bar. The names of the styles used in the iOS API are used, the default being UIStatusBarStyleDefault.
UIStatusBarHidden (Status bar is initially hidden), if YES, the status bar is hidden when your application is launched. Before coveting those 20 extra pixels, please consider whether you want your customers to shut down your app whenever they need to check the time or see whether they’re running out of power.
UIInterfaceOrientation (Initial interface orientation), indicating the screen orientation the application starts up in. Look up enum UIInterfaceOrientation in the UIKit headers for the available values; the Info.plist entries are supposed to be the names of those orientations. The default is UIInterfaceOrientationPortrait.
UISupportedInterfaceOrientations (Supported interface orientations, Supported interface orientations [iPad], and Supported interface orientations [iPhone]), an array naming the orientations your app will support on the iOS or iPad. If you don’t specify UIInterfaceOrientation, iOS will use the device’s orientation if it is in the list; if not, it will default to one that is. ~ipad and ~iphone variants are permitted.
UIPrerenderedIcon (Icon already includes gloss and bevel effects), if YES, iOS will not add a shine effect to it. This setting is obsolete as of iOS 7, which never puts a shine effect on icons.
UIViewEdgeAntialiasing (Renders with edge antialiasing). If you draw a Core Animation layer aligned to fractional-pixel coordinates, it normally isn’t anti-aliased. You can set this key to YES if you draw that way and want to take the performance hit of making it look nice.
UIViewGroupOpacity (Renders with group opacity), if YES, allows Core Animation sublayers to inherit the opacity of their superlayers. Cooler appearance, slower performance.
UILaunchImageFile (Launch image), UILaunchImageFile~ipad (Launch image [iPad]), and UILaunchImageFile~iphone (Launch image [iPhone]), the name of the file that is shown between the time the user selects your app in the Home screen and the time when it can render its content. This worked well when there were three combinations of size, resolution, and orientation to support. Use UILaunchStoryboardName instead; a simple storyboard will do a much better job.
Besides, this key has been made obsolete by. . .
UILaunchImages (set through Target editor/assets catalog only), an array of dictionaries describing the launch images iOS may display when launching the app. Each dictionary specifies a filename, minimum OS version (so your launch image can match the iOS 7 appearance of your app), size, and orientation.
Behavior
UIApplicationExitsOnSuspend (Application does not run in background), if true, tapping the Home button on the iOS device will shut down your app, rather than putting it into the background. Think hard before publishing an app that does this.
UIBackgroundModes (Required background modes). iOS gives apps a grace period of no more than ten minutes to perform tasks from the background if they ask for it. An app can claim ongoing exceptions such as media playback, VoIP, location updates, server checks, and more. The easiest way to make the claims is by turning on Background Modes in the Capabilities tab of the Target editor. Be prepared to defend your claim in the App Store review process.
UIFileSharingEnabled (Application supports iTunes file sharing), if YES, the contents of the app’s Documents/ directory will be visible while the device is plugged into iTunes. This allows your users to move files between their devices and their computers.
UINewsstandApp (Application presents content in Newsstand), if <true/>, the app claims it is a downloader and renderer for Newsstand subscription content. iOS will present it as a title in the Newsstand group, rather than as a stand-alone application. If you are offering a Newsstand app, you must fill in other keys, such as UINewsstandIcon.
NS*UsageDescription (Privacy - 
Usage Description) “” is one of eleven privacy-related keys such as Camera, HealthShare, Location, or PhotoLibrary. The list will grow as Apple adds features to its products that have privacy implications. For each such feature your application might use, iOS will ask whether the user grants access to it. These keys are for your explanations for why you want access.
MKDirectionsApplicationSupportedModes (Maps routing app supported modes). For an application that gives routing direction, this is an array of modes of travel, indicating, for instance, that the app provides routes for road travel, foot, and subways. Use the Maps section of the Capabilities tab in the Target editor to check off the services you provide.
Localization
There are a number of Info.plist keys that advertise the app’s ability to conform its text and appearance to the user’s locale. Chapter 21, “Localization,” covers them.
Summary
This chapter explored bundles and package directories, important concepts in both OS X and iOS development. Most of Xcode’s product types are bundles. I reviewed the structure of simple packages and application bundles and examined the Info.plist file, which communicates a bundle’s metadata to the operating system.