Xamarin - Documentation

iOS

change platform

  1. Xamarin
  2. iOS
  3. Getting Started
  4. Introduction to MonoTouch

Introduction to MonoTouch

Getting Started - 1

Brief

This article is the first in a series of five Getting Started with MonoTouch articles and introduces the MonoTouch platform. It is the first step in learning how to build MonoTouch applications for iOS and covers the fundamental concepts of what the platform is, what it can do, as well as general information on building for iOS.

This article is intended for those who are brand new to iOS and/or the MonoTouch platform, but have at least a basic familiarity with C# and .NET programming.

Time to Complete:

30 Minutes

Related Articles:

Getting Started 2 – MonoTouch Installation

Overview

When considering how to build iOS applications, many people think that Objective-C with Xcode is the only choice. However, over the past few years, an entire new ecosystem of platforms for building iOS applications has emerged. These new solutions include MonoTouch, Unity, AppCelerator, Flash, etc., just to name a few.

Each of these platforms has a different feature set and each varies in its ability to write native applications – that is, applications that compile down to native code and that interop fluently with the underlying Objective-C subsystem. For example, some platforms only allow you to build apps in HTML and JavaScript (such as AppCelerator), whereas some are very low-level and only allow C/C++ code. Some platforms (such as Flash) don’t even utilize the native control toolkit, known as UIKit.

MonoTouch is unique in that it combines all of the power of Objective-C and adds a number of quite a few powerful features of its own, including:

  • Complete Binding for iOS Objective-C API – MonoTouch contains bindings for nearly the entire iOS SDK. Additionally, these bindings are strongly typed, which means that they’re easy to navigate and use, and provide robust compile-time type checking. This leads to fewer runtime errors and higher quality applications.
  • Objective-C and C/C++ Interop – MonoTouch provides facilities for directly invoking Objective-C, C, and C++ libraries, giving you the power to use a wide array of 3rd party code that has already been created. Additionally, MonoTouch includes a utility called BTouch that does a lot of the heavy lifting in generating wrappers for Objective-C libraries. This lets you easily take advantage of iOS libraries written in Objective-C.
  • Modern Language Constructs – MonoTouch applications are written in C#, a modern language that includes features such as Type-Safety, Dynamic Constructs, Functional Constructs such as Lambdas, LINQ, Automatic Garbage Collection, and more.
  • .NET Base Class Library (BCL) – MonoTouch applications use the .NET BCL, a massive collection of classes that have comprehensive and streamlined features such as powerful XML, Database, Serialization, IO, String, and Networking support, just to name a few. Additionally, existing C# code can be compiled against MonoTouch for use in your applications, which provides access to thousands upon thousands of libraries to do things that aren’t already covered in the BCL.
  • Modern Integrated Development Environment (IDE) – MonoTouch uses MonoDevelop, a modern IDE that includes features such as code auto completion, a sophisticated Project and Solution management system, a comprehensive project template library, and integrated source control, and many other features.
  • Mobile Cross Platform Support – MonoTouch is a sibling to Mono for Android, which allows for C# applications to be written for the Android platform. MonoTouch and Mono for Android allow iOS and Android applications to be written that share common backend application code. Additionally, because both MonoTouch and Mono for Android utilize C# and the .NET BCL, the same application code can be shared with Windows Mobile 7 applications as well! This can significantly reduce development costs as well as time to market for mobile developers that target the three most popular mobile platforms.

Because of MonoTouch’s powerful and comprehensive feature set, it fills a void for application developers that want to use a modern language and platform to develop cross-platform mobile applications.

Let’s dig into MonoTouch a bit to examine how it works.

How Does MonoTouch Work?

MonoTouch is a commercial product built on top of Mono, which is an open-source version of the .NET Framework based on the published .NET ECMA standards. Mono has been around nearly as long as the .NET framework itself, and runs on nearly every imaginable platform including Linux, Unix, FreeBSD, Mac OSX, and others.

MonoTouch was originally created by Novell and released in 2009, however in 2011, most of the Mono (and MonoTouch team) went to a new company (Xamarin) as part of Novell’s restructuring. Novell then granted Xamarin a perpetual license to all things Mono and handed the MonoTouch reins over to Xamarin, who supports and continues to develop new MonoTouch releases.

MonoTouch allows you to write native iOS applications using C# and the .NET Base Class Library (BCL). Via the magic of Mono’s compiler, applications built on the MonoTouch platform compile down directly to native ARM assembly code. This contrasts with compilers for traditional .NET applications that create Intermediate Language (IL) code that compiles at run time. Even things like generics, which used to rely on Just In Time (JIT) compilation are available via Mono’s Ahead Of Time (AOT) compiler.

MonoTouch is a sibling to Mono for Android, which allows for C# applications to be written for the Android platform.

MonoTouch.dll

MonoTouch applications are built against a subset of the .NET BCL known as the Mobile Profile. This profile has been created specifically for iOS and packaged in the MonoTouch.dll. This is much like the way Silverlight (and Moonlight) applications are built against the Silverlight/Moonlight .NET Profile. In fact, the MonoTouch profile is equivalent to the Silverlight 4.0 profile with a bunch of BCL classes added back in.

For a full list of available assemblies and classes, see the MonoTouch Assembly List.

In addition to the BCL, MonoTouch.dll includes wrappers for nearly the entire iOS SDK (such as UIKit, Location Framework, Core Graphics, etc.) that allow you to invoke iOS SDK APIs directly from C#.

Note: MonoTouch applications are compiled against the MonoTouch profile, just like Silverlight/Moonlight apps are compiled against theirs. This means that you cannot use off-the-shelf .NET assemblies without recompiling the C# source against the MonoTouch profile

MonoTouch Applications in the App Store

There are hundreds of MonoTouch applications in the App Store. In fact, some of the most popular applications in the store have been built with MonoTouch!

icons-transparent.png

For a partial list of MonoTouch applications in the App Store, check out the MonoTouch Showcase.

Requirements

Before we get too far into learning MonoTouch, an important requirement needs to be mentioned; in order to do MonoTouch development, you must have an Apple Macintosh computer running at least OSX Snow Leopard (Lion is preferable). Although MonoTouch applications are based on the .NET BCL and are written in C#, MonoTouch requires the iOS SDK and Xcode in order to compile. Additionally, the iOS Device Simulator is part of the iOS SDK, and therefore only available on Mac

All the tutorials presented here are based on the latest MonoTouch and MonoDevelop versions. Installation is covered in the next tutorial.

Additionally, if you want to deploy to a device, rather than just the iOS Simulator, you’ll need a non-evaluation version of MonoTouch, which can be purchased at the Xamarin Store.

Finally, in order to download the iOS SDK, you must be a member of Apple’s Developer Program, which is free, unless you want to distribute your apps via the App Store, which requires an upgraded membership that costs $99 USD/year.

Developing for iOS

Developing applications for iOS is very different from developing traditional desktop applications. MonoTouch goes a long way toward bridging this gap, but the reality is that iOS applications run on mobile devices and therefore have very specific requirements and limitations. Let’s examine some of these restrictions.

Multitasking

There are two significant challenges to multitasking (having multiple applications running at once) on a mobile device. First, given the limited screen real estate, it is difficult to display multiple applications simultaneously. Therefore, in iOS only one app can be in the foreground at one time. Second, having multiple applications open and performing tasks can quickly eat battery power.

Because of these reasons, multitasking is very tightly controlled in iOS, and there are a number of rules and behaviors that your application must conform to when another application comes to the foreground, otherwise your application will be terminated by iOS.

Form Factor

iOS runs on two different mobile device form factors, the iPhone (and iPod Touch) and the iPad. Developing for these two form factors is nearly the same (they use the same APIs, programming models, etc.), however, designing applications for them can be very different. The iPhone has very limited screen space, and the iPad, while bigger, is still a mobile device with less screen space than even most laptops.

Because of this, iOS’s UIKit has been designed specifically to be effective on these mobile form factors.

Device-Specific Resources

Additionally, within a particular form factor, hardware can vary greatly between different models. For instance, some devices have a rear-facing camera, some also have a front-facing camera, and some have none.
Some older devices (iPhone 3G and older) don’t even allow multitasking.
Because of the differences between device models, it’s important to check for the presence of a feature before attempting to use it.

Limited Resources

iOS devices get more and more powerful all the time, but they are still mobile devices that have limited capabilities in comparison to desktop or notebook computers. For instance, desktop developers are used to having both physical and virtual memory in copious quantities, and in iOS you can quickly consume all available memory by loading even a handful of high-quality pictures.

Additionally, processor intensive applications such as games or text-recognition can really tax the mobile CPU and adversely affect device performance.

Because of considerations like these, it’s important to code smartly and to deploy early and often to actual devices in order to validate responsiveness.

OS Specific Constraints

In order to make sure that applications are responsive and secure, iOS enforces a number of rules that applications must abide by. In addition to the rules regarding multitasking, there are a number of event methods out of which your app must return in a certain amount of time, otherwise it will get terminated by iOS.

Also worth noting, apps run in what’s known as a Sandbox, an environment that enforces security constraints that restrict what your app can access. For instance, an app can read from and write to it’s own directory, but if it attempts to write to another app directory, it will be terminated.

Distribution

MonoTouch and Objective-C apps are distributed in exactly the same way:

  • Apple App Store – Apple’s App Store is a globally available online application repository that is built into Mac OSX via iTunes. It’s by far the most popular distribution method for applications and it allows developers to market and distribute their apps online with very little effort.
  • Enterprise Deployment – Enterprise deployment is meant for internal distribution of corporate applications that aren’t available publicly via the App Store.
  • Ad-Hoc Deployment – Ad-hoc deployment is intended primarily for development and testing and allows you to deploy to a limited number of properly provisioned devices. When you deploy to a device via Xcode or MonoDevelop, it is known as ad-hoc deployment.

Limitations of MonoTouch

Because of the security design of the CPUs on iOS devices (and per Apple’s rules about code that runs on them), JIT compilation is not allowed. There are a few small consequent limitations on MonoTouch applications.

Specifically, things that require JIT compilation such as the Reflection.Emit method are unavailable. For a list of current limitations, see MonoTouch Limitations.

Summary

In this tutorial, we got a good background on MonoTouch, including what it is, how it works, and what it can and can’t do. We also examined general considerations for building iOS applications, including app design factors, and distribution.

In the next tutorial, we’ll run through installing MonoTouch and it’s pre-requisites, including Mono, the iOS SDK, etc.