Chapter 1

Get Set Up: Tools and Development on Apple’s Platforms and Technologies

In 2007, during a keynote speech at Macworld Expo, Steve Jobs (CEO of Apple) announced both a change of name to the organization (from Apple Computers, Inc., to just Apple, Inc.) and a change of product emphasis, moving from a focus on personal computers to an emphasis on mobile electronic devices. During the same announcement, Steve Jobs introduced two new devices: the iPhone and the Apple TV. The former has changed the face of the mobile landscape and consumer experience for mobile devices forever. Apple has gone on to launch its fifth generation iPhone and repeat its success with the introduction of its second-generation tablet, selling millions of devices and creating billions of dollars of revenue.

Apple's success can be attributed to the quality of the devices, the “coolness” associated with owning them, and the intuitive interface. But much more significantly than those factors is the introduction of the App Store in 2008, and the subsequent and growing availability of cheap (often free) fun and productive applications, which has skyrocketed Apple into a world leader in the mobile marketplace. Apple announced in July 2011 that the App Store now has almost half a million applications downloaded billions of times, and more important, anyone can write and submit applications for sale and distribution. So, you could make the next best-selling mobile application that everyone is playing, such as Angry Birds!

So, what's stopping you? Nothing, provided that you're familiar with development tool sets such as Apple's Xcode and its default programming language, Objective-C. For .NET developers and others, this has sometimes been a barrier for entry. After all, while everyone likes to learn something new, it doesn't mean you won't want to reuse that experience to get up and running more quickly.

In this book, you will learn how to transfer your skills from .NET to the Apple development framework, using both the tools provided and the comprehensive iOS SDK library. You also will learn about some of the third-party tools that leverage .NET and other non-Apple technology that might be more familiar and thus more comfortable to use. These third-party tools were introduced into the market to provide alternatives to the Apple-only tool set. Although using these tools is not the focus of this book, I'll introduce some of the key third-party tools, providing you with an overview on how to get up and running with them.

This chapter provides key information about the Apple development framework, as well as some of the alternative options. The following topics are covered:

• A description of how to register as an Apple Developer and why you would want to do that
• An overview of the Application development models
• An introduction to Apple's mobile operating system (iOS) and development tools
• A tour of third-party options, including the Mono family, DragonFire SDK, Titanium Mobile, Marmalade SDK, and Flash Professional CS5
• An introduction to the App Store and how to sell your new application

Registering As an Apple Developer

Before we discuss any of the software development kits (SDKs) or tools, you'll need to register as an Apple Developer. This is necessary not only to provide you with useful access to technical sources and information about developing applications that run on iOS-based mobile devices (the iPhone, iPad, and iPod touch), but also to download the tools you need, such as the iOS SDK and Xcode. These downloads are required for the Chapter 2 examples, so registering as an Apple Developer now is highly recommended.

To sign up, start up a browser session and navigate to http://developer.apple.com/programs/register, which presents you with a screen similar to the one shown in Figure 1–1.

Figure 1–1. Apple Developer registration home page

On this home page, you'll notice the option to Get Started, and register as an Apple Developer for free. Choose this link, and then proceed to follow the instructions to either create a new Apple ID or use an existing Apple ID (which you may already have through the use of iTunes, for example). Complete the steps required to register as an Apple Developer.

After successfully registering as an Apple Developer, you'll be able to gain access to a number of online resources that will provide you with some of the necessary tools and support. A couple of these resources are listed in Table 1-1.

You should now proceed to the iOS Dev Center and download the free iOS SDK, which provides the essential tools and libraries for starting to design and develop applications for your mobile Apple device. This disk image (with a .dmg extension) includes both the Xcode and the iOS SDK, so it is quite large, and you might want to make a drink while you are waiting for it to download. Alternatively, you may choose to download an older version of Xcode, which is free, although it does have limitations as to which Apple iOS versions it can target.

At this point, you may be wondering what the difference is between registering for an Apple ID and downloading the free SDK, and registering as an official iOS Developer, at a cost of $99, and gaining access to the very latest version of Xcode. Since the release of Xcode 4, Apple has mandated that you must be registered as an iOS Developer on the Apple Developer Connection (ADC) web site to gain access to it, which is covered by the annual $99 fee.

But which version do you need? Well, that very much depends on which mechanism you're going to use to write your iPhone or iPad applications. We'll be looking at writing applications using a number of different methods, but we'll focus mainly on the Objective-C language.

My plan for this book is to target the latest Apple mobile devices, and I want to showcase the latest tooling options. So, the examples here use the latest version of Xcode available at the time of writing: Xcode 4. This version is improved significantly in usability, and so productivity. Such improvements result in it comparing more closely to Microsoft's own Visual Studio. So, while older versions of Xcode might work and be free, I recommend that you pursue more recent versions and invest the fee required to get started.

Application Development Considerations

Whether you are using Apple's own native tools or a third-party tool, there are certain principles to keep in mind as you develop. These principles will help to ensure your road to writing your award-winning application is smooth, or at least smoother. Each of the options we'll discuss is developed around some overarching principles, which both guide and constrain the way they work and how the resulting applications might execute, especially in the case of the third-party options.

Generic Development Principles

The following principles are common, irrespective of whether you are using Apple's own native resources or a third-party resource:

• Design patterns: Many of the frameworks use well-known design patterns for implementing your application. For example, the Model-View-Controller (MVC) design pattern is very common, and so an understanding of how this pattern works will help you enormously.
• Licensing: It's also worth understanding how the licensing model works for the third-party applications, and any limitations or conditions that may be enforced when you sign up to use the tools these applications provide. Also be aware of any restrictions that Apple's App Store policy might enforce.
• Device compatibility: Writing an application for one device doesn't mean it will automatically run or behave the same on another device. Take some time to understand the constraints and differences, and design your application for a multi-device scenario, if applicable. These differences are highlighted in upcoming chapters when relevant. For example, the iPad has more real estate that an iPhone, and we'll explore this in Chapter 6, where we look at enhancing your user interface.

Third-Party Development Principles

The following principles are generally common to all nonnative mobile application development solutions, as described later in this chapter:

• API limits: As with many operating system abstraction techniques, the API exposed by the tool you are using to write your mobile application is very often incomplete, and so will either implement a subset of the APIs available to the native iOS SDK or even provide different API calls. Take the time to understand the API, its constraints, and how it should be used by following the documentation and guidance provided.
• Prerequisites: It's important to note that not all of the third-party products work with the latest versions of Apple's native tools. Take some time to understand any prerequisites and ensure you download the components required by your tool and as indicated in the supporting documentation. The prerequisites go for hardware, too. Some of the options run only on the Mac OS X operating system. So, ensure you have the correct hardware, especially before spending money!
• Cost: Not all of the options are free, and some of the options have limitations. You may need to buy additional “bundles” as your application development progresses.

You need to be aware of these principles and understand not only how they work, but also the types of applications they output and the application model paradigms they use.

Application Approaches

Application development can be classified as one of two application paradigms: a web application or a native application. Understanding these types will better prepare you for the development of your application. You'll want to know the constraints of each and the implications they have on stages of development, such as debugging and distribution.

Web Applications

The option to develop an application using the web paradigm still remains and is always an option. In this paradigm, the app is hosted outside the mobile device and uses the implicit features of Apple's mobile browser, Safari, to execute the code and provide the required user interface and functionality. Of course, this constrains the kind of application you can build, the richness of its features, the functionality possible, and the way in which the application is accessed and made available.

For example, a browser-based application is available only when you have online connectivity, but in some cases, this might be quite appropriate. Suppose that you wanted to target many devices without being as dependent on the functionality provided by their operating system. In that case, you might consider a web-based application. Yes, it may require online connectivity, but if your application requires capabilities typically only provided by a web browser, such as HTML or JavaScript, then a web application may do just fine. However, Apple prides itself on a rich, intuitive, and interactive user experience, which is far easier to provide when exploiting the capabilities of Apple devices and their operating systems. But note that it is fair to say that, as the browser experience grows and as new technologies are introduced, the gap between web and native is definitely closing!

Native Applications

The alternative to a web-based application is a native application, and this type is the thrust of this book. We'll be looking at applications that are downloaded to and reside on the mobile device itself, and are written using Apple's own tools (Xcode and the iOS SDK) or those from a third-party provider.

Now that we've covered the basic development principles and approaches, we'll look at some core concepts surrounding application development using Apple tools, and then take a look at the third-party options available for application development. We'll be discussing these options throughout the book, and I will guide you through creating applications using the different mechanisms.

Apple Platforms and Technologies

Apple provides a variety of development resources that allow you to target a number of its devices or platforms. These include the Mac (via the Max OS X operating system), the Safari browser, and of course, Apple's mobile devices. This section introduces the underlying concepts, and then discusses the iOS and Apple tool set in more detail.

Apple Terminology and Concepts

Let's start with some of the key terms you should recognize before starting your journey, to provide some context for subsequent details provided in later sections. I want you to be able to build up a mental picture of the key concepts provided as part of Apple's core platforms and technologies before I introduce how, if at all, third-party options interface to them.

Figure 1–2 is a diagram that presents these concepts in a logical order (as they say, “a picture paints a thousand words”). I will build on this diagram as the chapter progresses, placing each of the concepts we encounter in relation to one another, and explaining their purpose and relationship. The diagram represents the “layers” provided, and the boundaries of the boxes shouldn't be seen as the only interfaces available to you. As I introduce each of the core layers, this will become clearer.

Figure 1–2. Apple's mobile application development framework

As you can see in Figure 1–2, on top of the iOS sits both the iOS SDK and the Cocoa API with the Touch extensions. The Bridge technology is another API, which provides the framework to link these resources to non-Apple and interpreted languages such as Perl, Python, and Ruby. Finally, the Xcode suite of tools provides graphical user interfaces (GUIs) to use the program languages, APIs, and libraries supplied through an integrated development environment (IDE)—all sitting on top of your Apple Mac computer.

You should now be comfortable with some of the high-level concepts associated with developing for Apple's mobile devices, if not the approaches or patterns of development yet, and have an understanding of some of the relationships among these core components. You should have also downloaded the iOS SDK, although we won't use it until the next chapter.

Both the iOS and the associated SDK are required to build and run mobile applications. Let's take a look at them at a high level. This will help you to understand some of the intricacies of the different mobile devices and also provide further background on how the operating system's features are accessed by the APIs and SDKs above them.

Understanding the iOS

Originally developed for the iPhone and derived from Mac OS X, iOS is the operating system at the heart of Apple's mobile devices, including the iPhone, iPod touch, and more recently, iPad devices. As with most operating systems, iOS takes a layered approach to providing the necessary functionality. Each layer builds upon another and provides clean lines of abstraction between them. The layers provided within iOS are shown in Figure 1–3.

Figure 1–3. iOS architecture

Let's start at the bottom of the stack, dealing with the low-level services first and working our way up to those elements that we as humans will interact with directly and use for building iOS applications.

Core OS: This provides a layer of abstraction from the physical hardware and contains the low-level features used by the layers above it. Each element of the layer is provided as a series of frameworks: the Accelerate framework, External Accessory framework, Security framework, and System framework. A framework in this context is a collection of associated APIs that provide the framework's functionality. As we progress through the book, we'll explore these frameworks and the APIs they expose in more detail, and demonstrate examples of how to use them.

Core Services: Building on the Core OS layer, the Core Services layer contains the fundamental system services for applications. This layer is split into a set of Core Services, which combine to provide a number of essential high-level features. Some of the services provided are for programmatic support (language support, data types, and so on), data management support, and telephony.

Media: This layer, as its name suggests, provides graphic, audio, and video support. It is tasked with providing the best multimedia support available through the device being used. This layer includes frameworks that provide core audio, graphics, text, video, and MIDI support, as well as support for animation, media playing, and much more.

Cocoa Touch: This layer provides support and the key building blocks for building applications, including multitasking, touch-based input, notifications, and user-interface support. This layer also provides support for file sharing and printing, as well as peer-to-peer services for wireless connectivity.

While most of this functionality is packed into special libraries known as frameworks, this is not the case for all layers and all functionality. For example, some of the specialized libraries within the Core OS and Core Services layers are provided as dynamic link libraries (DLLs) with symbolic links used to point the iOS to the latest version on your device. Such techniques are common for managing code, and we'll look at them in more detail when talking about version control in Chapter 2.

Application Development Using Apple Components

You should now have a general appreciation for the operating system, the layers from which it is constructed, and the functionality it provides. Before we delve into the details of the iOS SDK, let's look at some of the history surrounding software development using Apple components.

When the iPhone was originally launched, you had two options: use the native tools and languages, such as Objective-C and the Mac OS X, or use web-based applications that are executed within the mobile Safari browser. The latter is naturally limited to languages such as HTML, Cascading Style Sheets (CSS), and JavaScript. Now this is still a valid development option today, but limiting in the kind of functionality and user experience possible.

The release of the second-generation iPhone introduced the iOS SDK, the Apple App Store, and the ability to use Xcode and Objective-C to write native applications. This provided virtually complete access to the iOS, and thus to the iPhone features, and also satisfied the mandated native-binaries-only option for distribution through the App Store.

Using the iOS SDK, and so Xcode and Objective-C, is still possible, and indeed favored by some individuals as the standard mechanism to use for application development. However, it is also true that developers may want to create applications that run on many mobile devices, not just Apple's. Or indeed, they may favor the Apple mobile devices but not Mac OS X, or maybe they do not like the development tools and languages mandated. For these reasons, a number of alternatives have been introduced, as we'll discuss in the book. In some cases, the options depend, at least in part, on the iOS SDK.

So, enough history. Now let's look at the options available for developing applications using the Apple-provided tools. Apple provides the following core components for developing applications:

• Xcode: This is a suite of tools, developed by Apple, for creating software both for the Mac OS X (as used in iMacs, MacBooks, and so on) and iOS.
• iOS SDK: This is the SDK released to allow developers to make applications for Apple's mobile devices and the Apple TV.

Xcode

At the time of writing, the most recent release of Xcode is Xcode 4, available from the Mac App Store for $4.99 and from the Apple Developer Connection web site for those registered as an Apple Developer, but at a cost of $99 for annual membership. Xcode version 3 is still available, free of charge (although, as you would expect, the versions of iOS supported are constrained).

Xcode comes with the following:

• IDE: Xcode is the standard IDE from Apple, which allows you to develop software for both the Mac OS X and iOS operating systems. It supports many programming languages, and provides many of the features you expect from a professional IDE, such as syntax highlighting, autocomplete, debugging, and source-code control. It's  comparable with other industry-favored IDEs such as Eclipse and Microsoft's Visual Studio.
• Interface Builder: Since the introduction of Xcode 4, Interface Builder has moved from being a separate application to being completely integrated into the Xcode IDE, but its purpose remains the same: to provide a tool to aid the creation of user interfaces. It does this through a GUI supporting frameworks such as Cocoa and presents a palette of user interface objects and controls for you to drag and drop onto your canvas as required. You can even go a step further and provide the source-code implementation for events from these controls, such as a button click.
• Compiler: The compiler is an essential component. It takes your source code and generates the binaries required for execution of your mobile device and for App Store execution. Apple's LLVM (from the LLVM.org project) is a fast, feature-rich compiler that creates optimized applications for your mobile devices. It supports a number of languages, including C, C++, and Objective-C.
• Debugger: Another contribution from Apple to the LLVM.org open source project, the debugger provided as part of Xcode is fast and efficient. It supplies an integrated debugging interface that includes the usual features, such as stack tracing and step-by-step debugging, and also comprehensive multithreading support.

iOS SDK

The iOS SDK is the SDK launched by Apple in 2008 to enable you to develop native applications for the iOS operating system. The iOS SDK is broken down into sets that match the layers provided within the iOS framework (see Figure 1–3 earlier in the chapter). This includes the following:

• Cocoa Touch
  • Multitouch events and controls
  • Accelerometer support
  • View hierarchy
  • Localization
  • Camera support
• Media
  • OpenAL
  • Audio mixing and recording
  • Video playback
  • Image file formats
  • Quartz
  • Core animation
  • OpenGL ES
• Core Services
  • Networking
  • Embedded SQLite database
  • Core Location
  • Concurrency
  • Core Motion
• OS X kernel
  • TCP/IP
  • Sockets
  • Power management
  • Threads
  • Filesystem
  • Security

Along with the Xcode toolchain, the SDK contains the iPhone simulator, a program used to emulate the look and feel of the iPhone on the developer's desktop. The SDK requires an Intel Mac running Mac OS X Snow Leopard or later. Other operating systems, including Microsoft Windows and older versions of Mac OS X, are not supported. More information can be found on the iOS Dev Center web site.

Third-Party Options

The reliance on Apple-only tooling for application development on Apple's mobile devices has long been a sore point for a number of people. This is not a reflection on the quality or features provided within the Apple options—quite the contrary. They are extremely powerful and productive tools that enable you to develop for both Apple's desktop and laptop devices (iMac, MacBook, and MacBook Pro) and mobile devices (the iPhone, iPod touch, and iPad) individually or as a team, using its team development features.

But, humans being humans, we get comfortable with what we know. We like familiarity. Those who have been brought up on different operating systems, different technologies, and different tools may be reluctant to change, and might not see the need to do so. For example, if you're a Java developer, you may love the Java programming language and the Eclipse (or similar) IDE you are using. Given you're a .NET developer, chances are you've been exposed to other languages. While this book focuses on bridging the gap between .NET and Apple's tool set, understanding the third-party options available to you is likely to provide relevant context. If you've been exposed to only Microsoft .NET, your familiarity with tools such as Visual Studio and the .NET Framework will stand you in good stead in making the transition.

Whether your experience is Microsoft-based or more mixed, you may also be more comfortable with the Windows or Linux operating system, and so are hesitant to learn a new operating system on which to develop your applications. “After all,” I hear many people argue, “it's the mobile device and its operating system that are of most relevance, not how you get there.”

So, how do you best use the experience you have and what exists to make your transition easier? My guess is you are not afraid to learn something new—after all, it's fun— but would rather reuse elements of the development environment that you are already familiar with—specifically, .NET. This hasn't gone unnoticed, and open source initiatives and commercial organizations have attempted to tackle and capitalize on the problem. There are many options available, and some scenarios may suit you more than others, such as Mono providing an open source and Apple-friendly implementation of .NET. Other options, while not .NET-focused, are relevant in helping you make the transition, even if you choose to ignore them and stick with Apple's own SDK and tools. Here, we'll take a quick look at the following third-party options:

• Mono
• Appcelerator's Titanium Mobile
• Marmalade SDK
• Flash Professional CS5

Mono Family

Mono is an open source (community-built) implementation of the .NET Framework and associated components for platforms other than Windows. The Mono environment can be classified as the Core Mono environment and additional components that offer enhanced functionality. When looking at the development of applications for Apple's mobile devices, you can think of Core Mono as the foundation with additional components, such as MonoTouch, built on top, completing the family.

The Mono family includes a number of components of significance when developing applications: the compiler, the framework, and the supporting tools. These components are called Core Mono (the compiler and runtime), MonoTouch (the .NET implementation of Cocoa Touch), and MonoDevelop (the IDE).

Core Mono

As a core part of the Mono development environment, Core Mono provides a compiler that supports a number of programming languages, including C#. It includes an implementation of the Common Language Runtime, and more important, provides a comprehensive set of APIs to implement the .NET Framework. Specifically, Core Mono includes the .NET Framework Class Library implementation, which is a set of libraries that provides the Mono implementation of the .NET Framework Class Library.

MonoTouch

MonoTouch provides a .NET-based implementation of Apple's own Cocoa Touch library. It allows developers to create C#- and .NET-based applications that run on Apple's iPhone, iPad, and iPod touch devices, while taking advantage of the iPhone APIs and reusing code and libraries built for .NET, as well as existing skills. It seems obvious now, but the introduction of MonoTouch was a touch of genius. It binds the Objective-C and C APIs from the Cocoa Touch API provided by Apple to the C#/Common Intermediate Language (CIL) APIs. In addition to the core base class libraries that are part of Mono, MonoTouch ships with bindings for various iPhone APIs to allow developers to create native iPhone applications with Mono. How does MonoTouch do this?

At the core of MonoTouch is an interoperability (interop) engine, which provides the bindings for the Cocoa Touch API, including Foundation, Core Foundation, and UIKit. This also includes graphical APIs such as Core Graphics and OpenGL ES.

Although MonoTouch provides bridges to the Cocoa Touch API, there is also an implementation of Mono targeted at allowing you to write applications for the Mac OS X operating system calling MonoMac, which uses the same principles. In fact, at the time of writing, a new version of Mono allows you to employ the same principles to write Android operating system applications using MonoDroid (although this is at a much earlier stage of its development).

MonoDevelop

While it's perfectly possible to use the command-line tools provided with Core Mono, and there are those who would argue that hard-core programmers deal only with command-line tools, I for one am grateful for a little help from enhanced tools. Nowadays, the IDE in the form of some graphical tool is ubiquitous. Those of you who have seen or used Microsoft's development tool, Visual Studio, will know how the whole experience of writing applications is made easier and faster through the use of such tools. Thankfully, Mono is no different, and the MonoDevelop tool suits our needs nicely as a great IDE.

As shown in Figure 1–4, MonoDevelop runs on the Mac OS X operating system. In fact, it runs on a number of operating systems, including various Linux distributions and Windows.

Figure 1–4. A MonoDevelop application running on Mac OS X

In Chapter 3, we'll look at MonoDevelop, along with the Mono framework and MonoTouch. You'll get a tutorial on how to install, use, and develop your own application for Apple's mobile devices using these components and the .NET Framework.

MonoTouch (including Core Mono) can be downloaded from http://www.monotouch.net, and MonoDevelop is available from http://www.monodevelop.com.

DragonFire SDK

We've looked at both Apple's native development environment and the support Mono provides for application development using the .NET Framework, but this may still be limiting for you. For example, what if your programming language of choice is C or C++. While Objective-C is provided as part of the Mac operating system, syntactically, it's quite different, and again, you may not want to be restricted to Mac OS X. The DragonFire SDK product was created for this very purpose.

DragonFire's target is Windows developers who wish to write native iPhone applications using Visual C++, its debugger, and the C/C++ language. It doesn't require a Mac of any description nor familiarity with Objective-C. As it says on the web site, “Bring your App idea to life in standard C/C++ and never leave your Windows platform.”

Figure 1–5 illustrates how the Dragonfire SDK compares with Apple's existing mobile application development framework.

Figure 1–5. DragonFire SDK framework

The goal was to allow 2D games to be written and debugged in Windows, and be fully compliant for distribution via Apple's App Store. Although this is great if you're writing a game, you may find the API lacking in other areas. For example, as an API, it's not as complete as Apple's own API—for example, it lacks complete support for the Location-based API—but it is constantly being enhanced. The DragonFire SDK Enterprise Edition is being launched (at the time of writing, it is suggested that this version will launch toward the end of 2011), and this version will feature database support, as well as more drag-and-drop functionality and options for displaying text and graphics.

The unique aspect of DragonFire's SDK is that once you have written your application using its API and tested it using the on-screen simulator (all on the Windows operating system, remember), then you package up your application as instructed and upload this via the web site for compilation, and if requested, iTunes App Store bundling.

The DragonFire SDK is commercially available from its own web site at http://www.dragonfiresdk.com/. It's relatively inexpensive and aimed at “weekend projects,” according to its authors. I'll let you decide if you like it, but it certainly removes some of the complexity of the other options. And it is the only option that allows full iPhone, iPod touch, and iPad development on the Windows platform.

Appcelerator's Titanium Mobile

Appcelerator's Titanium Mobile is an open source application development platform. In the same way as the DragonFire SDK can be used to write native iPhone applications using C/C++, Appcelerator's Titanium Mobile product allows you to write iPhone, iPad, and Android applications using languages other than Objective-C (iPhone and iPad) and Java (Android).

Titanium Mobile has an approach similar to Mono, in that it takes well-known languages (in this case, various languages including HTML, CSS, and JavaScript) and provides an API that binds these languages to native APIs (in this case, the iOS SDK). Figure 1–6 illustrates its architecture in comparison to the other options.

Figure 1–6. Titanium Mobile framework

Titanium Mobile differs from Mono in the process that it takes with your bespoke code in the language you love. Your original code is processed and eventually converted into native, executable code through a series of steps that involve preprocessing and compilation against first its own API into native code, and then native code into a native executable. These steps are illustrated in Figure 1–7, which shows the life cycle from written code to an executable ready for testing and, eventually, distribution via the App Store.

Figure 1–7. Titanium Mobile processing stages

Appcelerator's Titanium Mobile is available from its own web site at http://www.appcelerator.com/. It's free for individuals using it personally or within small organizations (fewer than 25 employees), and has editions for corporate users of 25 and over and 100 and over. It has versions not only for mobile development, but also for desktop, commerce, analytics, and more.

Chapter 3 provides a tutorial on how to download, install, and use the product to create an iPhone application. In that chapter, we'll take a closer look at what the Titanium Mobile package can do, and discuss its advantages and disadvantages.

Marmalade SDK

As I start to introduce the Marmalade SDK, you'll see a theme emerging in the way these application development platforms—whether commercial or open source—are implemented. Marmalade is similar to the Mono and Titanium Mobile packages in many ways, except that it supports only C++. However, it does support development on both the Windows and Mac OS X operating systems, and allows you to create native mobile applications for the iOS operating system. In fact, the product lets you compile for other operating systems, such as Android, Symbian, Windows Mobile 6.x, and game consoles!

The Marmalade package consists of two major components:

• Marmalade System: The Marmalade System is an operating system abstraction API, together with the associated runtime libraries and application build system. It provides the binding between the native operating system API and the code you write, in the same way as Mono and Titanium Mobile do.
• Marmalade Studio: This is a suite of tools and runtime components, focused on high-performance 2D/3D graphics and animation.

The package allows you to use Visual C++ on Windows or Xcode on Mac OS X to write your application using the API provided. It then supports a two-stage deployment process. In the first stage, you compile your application for debugging. This creates a DLL (.dll file), which requires the Marmalade Simulator to execute. Then when you are happy with your application, you can compile your code into a native executable for distribution.

Figure 1–8 illustrates the Marmalade architecture in relation to the other packages we've discussed so far.

Figure 1–8. Marmalade SDK framework

In order to use the SDK, you must register an account on the web site, at which point you will be supplied with an evaluation license. Any registered user can then download a fully functional evaluation version of the Marmalade SDK. The evaluation version allows deployment to all platforms, but does not allow public distribution of applications. You can purchase the latest version of the Marmalade SDK from http://www.madewithmarmalade.com.

Flash Professional Creative Studio 5

Last, but definitely not least, is Adobe's Flash platform, which is arguably the most complete solution given here, in part due to its maturity in both the market and its work to support the iPhone back in 2010, when Apple lifted its restriction on its third-party developer guidelines. It allows you to build stand-alone applications for the iPhone, iPod touch, and iPad using the updated Packager for iPhone, which is included with Adobe Flash Professional Creative Studio (CS) 5 and with the AIR SDK on Adobe Labs.

Flash Professional CS5 works in a similar way to the other packages, allowing you to develop your application using the language you are familiar with (in this case, ActionScript). You compile this against the included APIs (the AIR and Flash Player APIs) into native iPhone applications, which are then ready for testing and deployment.

Figure 1–9 shows the Flash Professional CS5 architecture, again relative to the others we've discussed in this chapter.

Figure 1–9. Adobe Creative Suite 5 framework

This option is by far the most comprehensive solution, but at a cost—both financially, as Adobe's Creative Studio is not cheap, and in complexity, as the product and its extensive API are not trivial to understand. For this reason, this option is not covered in this book. But after looking at the other options available, you should be well prepared to try out Flash Professional CS5 should you desire.

Overview of the App Store

The App Store is a digital application distribution platform for iOS devices, developed and maintained by Apple. Through the iTunes Store, accessed from either the Internet or the device itself, Apple allows service users to browse and download applications, paying for them as required. Applications can be downloaded to the device directly or to a desktop and subsequently transferred, if appropriate.

The App Store is accessible from a number of devices, including the iPhone (shown in Figure 1–10), iPod touch, and iPad. For Mac laptop and desktop users, the Mac App Store was launched more recently to cater to nonmobile applications.

Figure 1–10. App Store on the iPhone 4

The App Store has been tremendously successful for both Apple and application producers, with the billionth application download boundary broken back in 2009. As mentioned, the concept has been mimicked by other organizations, most notably the other major mobile service providers. Figure 1–11 shows the global revenue share among these platforms. Apple's dominance is obvious.

Figure 1–11. Global mobile application store revenues

Selling Apps at the App Store

The App Store revenue model is to split the proceeds from any sale: 30% to Apple and 70% to the app publisher (this is subject to change at any time). The model has proven immensely profitable for both Apple and many application producers. The term app (short for application) has also been used more broadly, and despite Apple being awarded a trademark for the term, it has been used in a similar context by others, such as Google (Google Apps) and Amazon.

More recently, Apple announced its new subscription-based service that allows application publishers to set the length and price of a subscription. Previously, this wasn't possible, and you were forced to sell each release on a per-release basis. The new service allows publishers to sell their content through their apps, and users can receive new content over a specified period of time.

A more significant change is that not only is the traditional model of selling through iTunes available, but Apple is also allowing app publishers to distribute their subscriptions directly from their own web sites, where the iTunes revenue model doesn't apply and so no revenue is shared with Apple. This obviously has the advantage of removing the obligation of contributing some of your application earnings to Apple, but it does mean that you lose the benefits of the App Store, such as audience reach and accessibility, and must rely on your own marketing campaigns.

Submitting an App to the Store

Here are the steps for submitting an app to the App Store:

1. Complete the development and testing for your app.
2. Create the supporting info.plist file for your app (more on this later).
3. Write a description for your app.
4. Choose a unique numeric SKU for your app.
5. Assemble your screenshots to be displayed on the App Store.
6. Prepare your iTunes artwork.
7. Submit through iTunes Connect.

Any application submitted is subject to approval by Apple, as outlined in the SDK agreement, for basic reliability testing and other analysis. Apple has a process for appeals, but it ultimately has the final decision. If your app is rejected, you can still distribute it ad hoc by manually submitting a request to Apple to license the application to individual iPhones (although Apple may withdraw the ability for you to do this at a later date).

The official App Store Review Guidelines for developers is a good source of material. We'll also discuss the details of submitting an application for approval and distribution rights in Chapter 9.

Summary

This chapter introduced the concepts of developing applications for Apple's mobile devices, specifically the iPhone, iPod touch, and iPad. We've looked at how to register as an Apple Developer, and why this is recommended, as well as some of the principles surrounding mobile application development. We then discussed the iOS operating system, which powers these mobile devices, and the iOS SDK and Xcode.

Following the introduction of these concepts, we took a look at some of the different options available to develop applications. These include not only Apple's own native languages and tools, but also a number of other third-party options, both open source and commercial.

We concluded with an introduction to the App Store—its purpose, revenue model, and support of various devices. You learned the mechanics of submitting a new application to the App Store for review and if approved, publication.

The next chapter provides a crash course in creating a simple application using Apple's native tools, the iOS SDK and Xcode. By the end of that chapter, not only will you have created your first iPhone application, but you will also have a better appreciation for some of the fundamental concepts in developing a mobile application, which you can reuse when you look at some of the other options available.

In Chapter 3, you will learn more about the third-party tools, such as the Mono family. After that, we'll focus again on the Apple tools and use these throughout the rest of the book to demonstrate how to apply your .NET knowledge and experience to creating compelling apps.