Can someone give me a quick, one-to-few paragraph(s) overview of the structure of iPhone apps. I'm working my way through a book, but I can't really understand the purpose of App Delegates, MainWindow.xib vs. individual views' nib files, actions vs. outlets, etc.
I'm looking for a high-level description, because all I can find are really detailed accounts of this stuff.
You can find out more about Objective-C design patterns like delegation in Apple's documentation. Here's a quick overview of the things you mentioned:
Objects communicate with other options in various ways, one of which is delegation. An app delegate is an object that receives certain messages from the application.
XIB files contain a description of your user interface and connections. MainWindow.xib contains the UI information for your main window, but you should have individual XIB files for other view controllers for the sake of efficiency (you should load the XIBs lazily when the user tries to instantiate a certain kind of view controller, and cache the XIB to prevent reloading it; see UINib for detail).
Actions and outlets are ways of connecting code to UI elements in your XIB. An action is a message sent by a UI element to an object. For example, a button press can send an action to your view controller. An outlet would be a reference to that button.
For more about Objective-C in the context of iOS development, consult the documentation:
The physical structure of an iPhone application consists of a directory that acts as a bundle for the main executable and all resources used (images, property lists, interface files, etc.).
When run, the executable first performs the main() function. That function either programmatically instantiates an application delegate or loads the main interface file (which specifies the application delegate). The application delegate acts in response to application-level events, such as termination or entering and exiting the background.
The construction of your interface can either occur programmatically or through the use of Interface Builder .xib files. If programmatically, your application delegate will construct the initial overall interface, then hand things off to individual view controllers to manage the display of specific views. If done via Interface Builder, you'll define interface files that compile into freeze-dried objects that are deserialized into your interface at runtime.
Overall, Cocoa applications tend to follow the Model-View-Controller design pattern, where these three areas of your application are separated in code. Views are generic reusable display elements, your model contains application data (often persisted using Core Data or SQLite), and your controllers provide the application-specific logic that glues everything together.