How does Xcode sets rootViewController implicitly via storyboard? - ios

Question

Xcode with the project file and Info.plist locates the main.storyboard and finds out the initial ViewController. But I was hoping to see some boiler plate code in AppDelegate for the ViewController.
AppDelegate looks blank: (No reference to ViewController)
#implementation AppDelegate
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
return YES;
}
...
#end
StoryBoard is xml:
Question
Does Xcode what magic code to refer storyboard xml and find the controller ?
After the compilation, main() brings up AppDelegate which should either have reference to ViewController directly or have a proxy storyboard object to get to the ViewController.
What am I missing ?

Answer 1

I think my book (which you already found) explains it fully. main calls UIApplicationMain() and it follows certain rules. If you have a main storyboard designated in your Info.plist — and you do — then:
UIApplication pulls the initial view controller instance (the one with the Entry Point arrow) out of the storyboard. That's the ViewController instance.
It also instantiates the UIApplication class.
It also instantiates the app delegate class (specified in the UIApplicationMain call), and assigns it to the UIApplication's delegate property.
It makes a window and assigns it to the app delegate's window property, then assigns that view controller to the window's rootViewController property.
Then it shows the window (and calls applicationDidFinishLaunching... on the app delegate`).
That completely explains the launch process.

Answer 2

A picture is worth a thousand words.. However, here's a short description: "It's in your project's settings/info.plist".
In the picture below "Main" is the name of my initial storyboard. Also, initial view controllers have a flag in the interface builder that says "Is Initial View Controller" to tell it that's the view controller you wish to run first.
P.S. Clicking on the images enlarges them :)

Answer 3

The short answer is that the dynamic nature of Objective-C allows UIApplicationMain() to bootstrap your application solely from the textual information stored in your application's info.plist file and your main NIB or main Storyboard. There's no need for the compiler to generate boilerplate code.
The longer answer:
UIApplicationMain does the following things to through the Objective-C runtime:
In all cases, UIApplicationMain() instantiates the NSPrincipalClass key in your plist, typically UIApplication but can be a custom subclass.
In an old-style NIB-less application, UIApplicationMain() will instantiate the AppDelegate class that was specified in main.m. It will wire the AppDelegate to UIApplication, and then hand off to the AppDelegate to create the app window, root view controller, etc.
In a NIB-based application, UIApplicationMain does not know the name of the AppDelegate. Instead, it loads your main NIB file NSMainNibFile, as specified in the plist. The NIB is responsible for instantiating your AppDelegate and wiring to UIApplication, along with creating your main window and root view controller.
In a Storyboard application, UIApplicationMain instantiates the NSPrincipalClass and the app delegate as specified in main.m, just like a NIB-less application. It then loads the main storyboard, which knows who the initial view controller is. It creates a window, instantiates the initial view controller, and assigns it as the root view controller for the window.

Answer 4

That's the reason behind it :-
and if you remove that mark You'll get a blank screen.