MyFirstiOSProjectViewController.xib is the file that contains the view of the application. XIB files are basically XML files with a specific structure that Xcode can read. The files contain information about the user interface, such as the type of controls it contains, their properties, and Outlets.

When we create a new interface with Interface Builder and save it, it is saved in the XIB format.

MyFirstiOSProjectViewController.cs is the file that implements the view's functionality. These are the contents of the file when it is created:

using System;
using System.Drawing;
using MonoTouch.Foundation;
using MonoTouch.UIKit;

namespace MyFirstiOSProject
{
    public class MyFirstiOSProjectViewController : UIViewController
    {
        public MyFirstiOSProjectViewController () : base ("MyFirstiOSProjectViewController", null)
        {
        }

        public override void DidReceiveMemoryWarning ()
        {
            // Releases the view if it doesn't have a superview.base.DidReceiveMemoryWarning ();
            
            // Release any cached data, images, etc that aren't in use.
        }

        public override void ViewDidLoad ()
        {
            base.ViewDidLoad ();
            
            // Perform any additional setup after loading the view, typically from a nib.
        }
}
}

The code in this file contains the class which corresponds to the view that will be loaded, along with some default method that overrides. These methods are the ones that we will use more frequently when we create view controllers. A brief description of each method is listed as follows:

MyFirstiOSProjectViewController.designer.cs is the file that holds our main window's class information in C# code. Xamarin Studio creates one .designer.cs file for every XIB that is added in a project. The file is autogenerated every time we save a change in our XIB through Interface Builder. This is taken care of by Xamarin Studio so that the changes we make in our interface are reflected right away in our code. We must not make changes to this file directly, since when the corresponding XIB is saved with Interface Builder, they will be lost. Also, if nothing is saved through Interface Builder and if changes are made to it manually, it will most likely result in a compilation error.

These are the contents of the file when a new project is created:

//
// This file has been generated automatically by MonoDevelop to store outlets and
// actions made in the Xcode designer. If it is removed, they will be lost.
// Manual changes to this file may not be handled correctly.
//
using MonoTouch.Foundation;

namespace MyFirstiOSProject
{
    [Register ("MyFirstiOSProjectViewController")]
    partial class MyFirstiOSProjectViewController
    {
        void ReleaseDesignerOutlets ()
        {
        }
    }
}

This file contains the other partial declaration of our MyFirstiOSProjectViewController class. It is decorated with the Register attribute.

The Register attribute is used to expose classes to the underlying Objective-C runtime. The string parameter declares by what name our class will be exposed to the runtime. It can be whatever name we want it to be, but it is a good practice to always set it to our C# class' name. The attribute is used heavily in the internals of Xamarin.iOS, since it is what binds all the native NSObject classes with their C# counterparts.

The AppDelegate.cs file contains the AppDelegate class. The contents of the file are listed below:

using System;
using System.Collections.Generic;
using System.Linq;
using MonoTouch.Foundation;
using MonoTouch.UIKit;

namespace MyFirstiOSProject
{
    // The UIApplicationDelegate for the application. This classis responsible for launching the
    // User Interface of the application, as well as listening(and optionally responding) to
    // application events from iOS.
    [Register ("AppDelegate")]
    public partial class AppDelegate : UIApplicationDelegate
    {
        // class-level declarations
        UIWindow window;
        MyFirstiOSProjectViewController viewController;
        //
        // This method is invoked when the application has loaded and is ready to run. In this
        // method you should instantiate the window, load the UI into it and then make the window
        // visible.
        //
        // You have 17 seconds to return from this method, or iOS will terminate your application.
        //
        public override bool FinishedLaunching (UIApplication app,NSDictionary options)
        {
            window = new UIWindow (UIScreen.MainScreen.Bounds);
            
            viewController = new MyFirstiOSProjectViewController ();
            window.RootViewController = viewController;
            window.MakeKeyAndVisible ();
            
            return true;
        }
    }
}

The first part is familiar to .NET developers and consists of the appropriate using directives that import the required namespaces to use. Consider the following code:

using System;
using System.Collections.Generic;
using System.Linq;
using MonoTouch.Foundation;
using MonoTouch.UIKit;

The first three using directives allow us to use the specific and familiar namespaces from the .NET world with Xamarin.iOS.

The MonoTouch.Foundation namespace is a wrapper around the native Objective-C Foundation Framework, which contains classes that provide basic functionality. These objects' names share the same NS prefix that is found in the native Foundation Framework. Some examples are NSObject, NSString, NSValue, and so on. Apart from the NS-prefixed objects, the MonoTouch.Foundation namespace contains all of the attributes that are used for binding to native objects, such as the Outlet and Register attributes we saw earlier. The MonoTouch.UIKit namespace is a wrapper around the native Objective-C UIKit Framework. As its name suggests, the namespace contains classes, delegates, and events that provide us with interface functionality. Almost all the objects' names share the same UI prefix. It should be clear at this point that these two namespaces are essential for all Xamarin.iOS apps, and their objects will be used quite frequently.

The class inherits from the UIApplicationDelegate class, qualifying it as our app's delegate object.

The AppDelegate class contains two fields and one method:

UIWindow window;MyFirstiOSProjectViewController viewController; 
//..
public override bool FinishedLaunching (UIApplication app, NSDictionary options) {

The UIWindow object defines the main window of our application, while the MyFirstiOSProjectViewController object is the variable that will hold the app's view controller.

The FinishedLaunching method, as its name suggests, is called when the app has completed its initialization process. This is the method where we must present the user interface to the user. The implementation of this method must be lightweight; if it does not return in time from the moment it is called, iOS will terminate the app. This provides faster user interface loading time to the user by preventing developers from performing complex and long-running tasks upon initialization, such as connecting to a web service to receive data. The app parameter is the application's UIApplication object, which is also accessible through the static property UIApplication.SharedApplication. The options parameter may or may not contain information about the way the app was launched. We do not need it for now.

The default implementation of the FinishedLaunching method for this type of project is as follows:

The window is displayed on the screen with the window.MakeKeyAndVisible() call and the method returns. This method must be called inside the FinishedLaunching method, otherwise the app's user interface will not be presented as it should be to the user. Last but not least, the return true line returns the method by marking its execution completion.

Inside the Main.cs file is where the runtime life cycle of the program starts as shown in the following code:

namespace MyFirstiOSProject
{
    public class Application
    {
        // This is the main entry point of the application.
        static void Main (string[] args)
        {
            // if you want to use a different Application Delegate class from "AppDelegate"
            // you can specify it here.
            UIApplication.Main (args, null, "AppDelegate");
        }
    }
}

It is much like the following call in a .NET System.Windows.Forms application:

Application.Run(new Form1());

The UIApplication.Main method starts the message loop or run loop that is responsible for dispatching notifications to the app through the AppDelegate class with event handlers that we can override. Event handlers such as FinishedLaunching, ReceiveMemoryWarning, or DidEnterBackground are only some of these notifications. Apart from the notification dispatching mechanism, the UIApplication object holds a list of all UIWindow objects that exist, typically one. An iOS app must have one UIApplication object, or a class that inherits from it, and this object must have a corresponding UIApplicationDelegate object. This is the AppDelegate class implementation we saw earlier.

The Info.plist file is basically the app's settings file. It has a simple structure of properties with values that define various settings for an iOS app, such as the orientations it supports, its icons, supported iOS versions, what devices it can be installed on, and so on. If we double-click on this file in Xamarin Studio, it will open in the embedded editor specifically designed for this file. Our file in a new project looks like the following screenshot:

We can also access Info.plist through the project's options window under iOS Application.

Xamarin.iOS-supported assemblies can be found at http://ios.xamarin.com/Documentation/Assemblies.