Building Applications from Templates - Xcode 4 - page 53

CROSS-REFERENCE
For more about editing, see Chapter 4. For an introduction to UI design, see Chapter 7.
Looking inside the Application templates
Most applications are built using Cocoa or Cocoa Touch. You can start with a minimal windowed application,
or you can select a more complex template that includes one or more supporting views. The Cocoa and Cocoa
Touch templates always include the following:
Class implementation files that define the basic elements of the application: For Cocoa and Cocoa
Touch applications, the elements always include an application delegate that receives and processes applica-
tion management messages from the OS—for example, one message is sent when the application finishes
loading, another when the application is about to quit, and so on. Depending on the template, the default
classes may also include at least one UI view controller, which receives and processes user actions generated
by the UI.
Class header files to support the implementation files: The headers include #import directives for
the essential UI framework on each platform. In templates with more than one class, the headers are impor-
ted correctly complete throughout.
One or more nib files with a .xib extension: Nib files are OS X and iOS resource files that define the
basic properties of a window, and optionally of a UI view. These files have a dual purpose. They define the
look and feel of the application UI. You can edit them to add UI objects such as images, buttons, sliders,
and other controls. OS X applications include the menu tree in their nib files. Internally, nib files are treated
as a general purpose inventory of objects to be loaded and initialized when the application runs. It's one of
the open secrets of Cocoa development that you can add any object or class to a nib file.
CROSS-REFERENCE
For more information about creating, editing, and using nib files, see Chapters 7 and 8.
Links between the nib files and the class files: In Apple development, code can control and respond to
UI objects only when these links are defined. They appear in two places: in the nib file, and in special dir-
ectives within the class headers and the implementation code.
A prefix header file with #import directives for the essential application frameworks: When you
build an application, the headers added to this file are pre-compiled only once.
A plist (property list) file that includes a dictionary of application settings: You can edit this diction-
ary to implement standard user preferences for the application. For details, see Appendix B.
An English localization folder. This includes a strings file that is used to localize the application so it
supports other languages in addition to English: The strings file includes pairs of strings. One string is
used as a key in the application. The other string defines the text that appears when that string is used. Each
language you support has its own strings file, with different output strings for each key. The templates con-
tain English localization only.
A main.m file: This is a short block of boilerplate startup code that loads the application and creates a
memory pool for it. You can usually ignore this file.