This is the second part of the blog post I wrote about TDD in XCode. Make sure you've followed that tutorial before continuing here, or at least have a project of your own with OCUnit tests ready.

The server which we'll use is called Hudson and is very popular in the Java community. It does not readily support XCode projects but it does allow shell commands, so we'll use that to make our Calculator project compatible. We also want to fetch new versions of the source code as soon as it's checked in. We'll be a bit fancy and use Git as source control software. Here's a summary of what we want to do:

1. Download and install the Hudson continuos integration server
2. Download, install and setup the Git source control software as well as the Git plugin for Hudson
3. Download and install a script that converts OCUnit test results to JUnit format
4. Setup a new job in Hudson that checks out our XCode project and builds and tests it
5. Set up a notification and try it out

Downloading and Installing Hudson

In order to keep the instructions in this tutorial simple, we will have the source code repository and the build server itself on localhost. In real life you'll probably want to setup a dedicated machine.

Head over to the Hudson web site and download your copy of the server. Follow their included installation instructions, it's quite simple. Once you have Hudson up and running you can visit http://localhost:8080 to see the welcome screen. By the way, when you're ready to install Hudson on a real remote server I recommend running it as a Servlet inside Apache Tomcat instead.

Downloading and Setting Up Git

Next we want to install Git. There are several ways to install it. The simplest might be to use the OS X installer, but I personally prefer MacPorts. Either way, go ahead and install it and make sure that you can use the "git" command from Terminal.app when you're done.

In the Terminal, change directory to your XCode project folder and type:

		git init
	

You now have a working source code repository in your project folder. Neat. Before you continue create a text file called .gitignore and let it contain:

		build/*
		*.pbxuser
		*.mode1v3
		.DS_Store
		test-reports/*
	

That's a listing of the files and folders that should not be version controlled, since they are temporary or just used for XCode. Feel free to add any other files that you think only should be present locally. Now add all files (that aren't ignored) using:

		git add *
	

and finally commit them to a first version using:

		git commit -m "Initial import"
	

Fetching the Script

We need to fetch one more thing, ocunit2junit.rb, which is a little Ruby script that I wrote. Since you now have git, you can also download it using git (or clone the repo, which is the correct term). Change directory to /tmp and then type like this:

git clone git://github.com/ciryon/OCUnit2JUnit.git

Copy the script from /tmp/OCUnit2JUnit/ anywhere, like to /usr/local/bin/. Make sure it's executable by typing chmod +x ocunit2junit.rb.

The script will parse output from xcodebuild (the console command for building your XCode project) and look for output from OCUnit. The test results (success, failure, time passed etc) will be saved in the "test-reports" folder in the same XML format that JUnit uses. This also happens to be a format that Hudson understands.

Setting Up Hudson

Now head back to your Hudson welcome screen. Select Manage Hudson, Manage plugins and check "Hudson GIT plugin" under Available. Hudson will automatically download and install the plugin. Afterwards just restart Hudson.

We're ready to create a job in Hudson for our project. From the main screen select "New job", Build a free-style software project and call it "Calculator". There are some settings which you should fill in:

• Select to use git as source code management tool. The URL should be the file path to your project, like:

  /Users/youruser/XCodeProjects/Calculator/

• Select to poll SCM with Schedule:

  * * * * *

  That means it'll check every minute if there are changes. If you want to check less often, do that.

• Add new build step and select to execute shell. Use this command (make sure to point to the version of the iPhone SDK you want to use):

  xcodebuild -target "UnitTests" -sdk /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.1.2.sdk/ -configuration "Debug" | /usr/local/bin/ocunit2junit.rb

• Select to also publish a JUnit test result report and the Test report XMLs reside at

  test-reports/*.xml

Trying it out

This is the moment of truth. Try to change your CalculatorTest.m so that one of the test cases fail. Type:

	git -a commit CalculatorTest.m "Broke the test, on purpose"

and see what happens. If all goes well, and you have entered everything correctly, Hudson should automatically notice there's a new version available, build it and try to run the test suite. Check the results and how it reports the test failure. Nice, eh? Fix the error and commit the test class again to see how Hudson reacts.

There are many settings, plugins and cool things to try out in Hudson. Go into Manage Hudson-> Configure system and setup your email settings, to allow Hudson to send mail. Then go back to configure your Calculator job and at the bottom select E-mail Notification. Enter your own email address and see how it works after you commits a file that breaks the build. If you don't want a mail, you can get an instant message, or perhaps have the server play a loud annoying sound? Everyone in your team should be aware of when a build fails, so it can be fixed right away. This is one of the great advantages of having a continuos integration server.

1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.

That means that test cases are written before any production code. Not all tests are written up front, it's rather that a small test is written, then a small piece of production code is written that only allows that test to pass. This is repeated in many small iterations: test, fail, code, pass, test, fail, code, pass...

Many people consider TDD to encourage clean code, simple architectures and a stable system that's actually testable. Plus, it's also fun! We've previously written about various aspects of TDD, but in this tutorial we'll focus on how it works for XCode projects, where you write apps for Mac and iPhone. We will create a simple XCode project, do some special configuration steps and then demonstrate how TDD can be used to write your app. We're going to use OCUnit and its framework SenTestingKit, which nowadays is included with Apple's XCode tools.

Creating the Calculator project

Let's start by creating a new project in XCode. You can pick any template, since we aren't going to touch the generated code. I picked a Window-based iPhone project. Name the project Calculator. Select New Target from the Project menu. Under Cocoa select Unit test Bundle. Call it UnitTests (I've had problems with space in the target name so avoid that) and add it to the project. We now need to change some small settings for this target. Select the UnitTests target and hit Command-I for Info. Select the Build tab and locate Other Linker Flags. Replace Cocoa with Foundation. Also remove the entry for GCC_PREFIX_HEADER.

Now it's time to create your test suite. Create a new group in your project and call it "Test Classes". Add a new File to this group and make sure it's a Cocoa->Objective-C test case class. Name it CalculatorTest.m. Uncheck "Also create CalculatorTest.h" since we don't need a header file. Don't add it to the Calculator target, but check it to be included in UnitTests. Open CalculatorTest.m file and above the @implementation declaration add:

#import <SenTestingKit/SenTestingKit.h>
#import "Calculator.h"
@interface CalculatorTest : SenTestCase
{

}
@end

This is just because we don't want a rather empty header file. All your test classes will look like this.

Following TDD, we should build right away. First make sure that the active target is "UnitTets" and then press the "Build" button. This will not only do a normal build, but also perform some shell script magic and actually execute the unit tests. Now the build fails of course, since Calculator.h can't be found.

So let's add a file which represents production code. Create a new empty Cocoa Touch Objective-C class called Calculator.m (also create the .h file), this is the class that we want to test. Don't forget to check that they should be included in both your targets. Notice that we mix Cocoa and Cocoa Touch, that's is fine - all code is executed on your Mac. Build again, and this time you'll see in the build log that everything built and the test suite was executed, but contained 0 test cases. Let's remedy that.

Writing test cases

Next we want to write our first test case. Open up CalculatorTest.m and add the following method:

-(void)testAdd
{
        Calculator* calculator = [[Calculator alloc] init];
        int result = [calculator add:5 to:6];
}

All methods that start with "test" will be recognized as being a test case, and automatically run when building the target. Try and build and you'll unsurprisingly get the erro "unrecognized selector sent to instance...". That's all good. Let's add the add method to our Calculator class. In Calculator.h add:

-(int)add:(int)a to:(int)b;

Then in Calculator.m add:

-(int)add:(int)a to:(int)b
{
        return 0;
}

That should be enough to let it compile and run, right? Try it out! You'll see that it indeed build and executes the tests.

Now we change the test so that it actually checks that we get the expected value back. We want to "assert" that the returned value is what we expected. Change the test case to look like this:

-(void)testAdd
{
        Calculator* calculator = [[Calculator alloc] init];
        int expected = 11;
        int result = [calculator add:5 to:6];
        STAssertEquals(expected, result,
                @"We expected %d, but it was %d",expected,result);
}

Build and you see that the test runs and fails since our calculator always returns 0 regardless of the input. Change the production code so that it returns a+b and rerun the test. Nice, we have a successful build and our test works! Notice the fast cycle of test, code, fix, rerun. The point of TDD is to write tests and production code in small iterations so that you always have something stable (= the tests pass). If you follow the rules of TDD you'll have a growing amount of test cases and you'll right away know when something breaks.

Let's write one more test. Now we want to add the functionality to allow one number to be divided by another. Start up like before with a new test case like this:

-(void)testDivide
{
        Calculator* calculator = [[Calculator alloc] init];
        float expected = 2.5;
        int result = [calculator divide:5 by:2];
        STAssertEquals(expected, result,
                @"We expected %d, but it was %d",expected,result);
}

You see, this time we expect to get back a float. Add the corresponding divide method to Calculator.h and Calculator.m. If you need help see the full code listing at the end of this article. You might notice that just returning a/b gives you 2.0. Type cast the return value to (float)a/b and you'll be fine. Go ahead when you got it working.

What happens if you try to divide something with zero? Well, why not add a test case for this scenario? If you're into maths you know that the result of this operation is undefined. How do you expect something to be undefined? This is tricky. Start off by just expecting any number and see what you get back. As you see, the float value "inf" is returned. It seems like Objective-C treats the zero as "a value approaching zero" and that will indeed result in infinity in a division. But, hey, that might not be what we want our calculator to do. Let's change the test case to expect an exception to be raised instead:

-(void)testDivideByZero
{
        Calculator* calculator = [[Calculator alloc] init];
        STAssertThrows([calculator divide:5 by:0],
                @"We expected an exception to be raised when dividing by 0");
}

Build and notice the error message when no exception was raised. Now change the production code to something like this:

-(float)divide:(int)a by:(int)b
{
        float result =  (float)a/b;
        if (result==INFINITY) {
                [NSException raise:@"Cannot divide by zero!"
                            format:@"Not possible to divide %d with %d", a,b];
        }
        return result;
}

Rerun and smile as the test passes! There are many different variants of asserts you can do with SenTestingKit. Compare objects with STAssertEqualObjects. STAssertTrue to check that a returned boolean is true. Open up SentTestCase_Macros.h if you want to see what you can play around with. By the way. You might have tried using NSLog in your test cases (just to experiment). This is nothing you would do in real life, as you want all necessary information in the fail message and output nothing if the test passes. Anyway, since the tests are actually run using a separate shell script for the UnitTest target you won't see the log in your console as usual. Instead check the build log and click the "text" icon to the right for the "Run test suite" step.

Wrapping up

Finally, if you look at your test class you might notice that we're allocating a new Calculator for every test case, and we never release them. That's no good. Luckily there are setUp and tearDown methods that will be launched automatically before and after each test case. Change your implementation to look like this (this is the final listing):

#import <SenTestingKit/SenTestingKit.h>
#import "Calculator.h"
@interface CalculatorTest : SenTestCase
{
        Calculator* calculator;
}
@end

@implementation CalculatorTest

- (void) setUp
{
        calculator = [[Calculator alloc] init];
}

-(void)tearDown
{
        [calculator release];
}

-(void)testAdd
{
        int expected = 11;
        int result = [calculator add:5 to:6];
        STAssertEquals(expected, result,
                @"We expected %d, but it was %d",expected,result);
}

-(void)testDivide
{
        float expected = 2.5;
        float result = [calculator divide:5 by:2];
        STAssertEquals(expected, result,
                @"We expected %f, but it was %f",expected,result);
}

-(void)testDivideByZero
{
        STAssertThrows([calculator divide:5 by:0],
                @"We expected an exception to be raised when dividing by 0");
}
@end

For completeness, here's the listing for Calculator.h:

#import 

@interface Calculator : NSObject {

}

-(int)add:(int)a to:(int)b;
-(float)divide:(int)a by:(int)b;

@end

and for Calculator.m:

#import "Calculator.h"

@implementation Calculator

-(int)add:(int)a to:(int)b
{
        return a+b;
}

-(float)divide:(int)a by:(int)b
{
        float result =  (float)a/b;
        if (result==INFINITY) {
                [NSException raise:@"Cannot divide by zero!"
                            format:@"Not possible to divide %d with %d", a,b];
        }
        return result;
}

@end

Next blog post we'll see how to automate the running of test cases on a build server called Hudson!

Introduction

Just recently, iPhone sales figures surpassed all windows mobile phones combined and in several markets the iPhone has been a top selling phone model. Together with the launch of App Store, Apple has managed to create a service delivery platform that attracts not only the hardcore users, but also the average Joe. A testament to this is the fact that App Store has had over one billion application downloads with over 50 000 applications available. This large potential customer base, combined with the advantage of having virtually no device fragmentation, makes it quite an attractive platform for mobile application developers. The business model is also lucrative, with Apple offering 70% of revenues from the store to instantly go to the seller of the app without having to pay for distribution or anything else than a one time fee. In this regard, the iPhone has certainly helped Apple put the Objective-C language in the limelight.

For the developer, the transition from higher level languages such as Java may
not be so simple as Objective-C has quite a unique syntax. The goal of this
article is to remedy that by going through the main concepts of Objective-C
from a Java perspective. Hopefully this will help you to get a quicker start in your
iPhone development. You should however be aware that it is equally important
to understand how to use the iPhone’s application frameworks in order to create
applications, this article only scratches the surface of the language you will use.

Objective-C from a Java perspective

If you are used to both working in C/C++ and Java you might soon recognize
Objective-C as a middle-ground language, meaning that it provides lower-level
mechanisms than Java while being a more manageable and higher-level language
than C/C++. The language is a strict superset of C, which means it’s possible
to write and compile normal C code using the Objective-C compiler. We also
use pointers (signified in code with an asterisk, *) to objects and not references,
like in Java. For object orientation Objective-C uses a syntax similar to that of
Smalltalk, which might take a little time to get used to if you haven’t seen it
before. Objective-C is a highly dynamic language, much like Ruby and Python,
where it’s possible to change the behavior at runtime. The compiler is quite
forgiving and before getting used to this you will likely discover more problems
during runtime than when using Java.

While some of the features in Objective-C are unique, many of them are
similar to those of Java only named differently. In order to ease the transition,
we will use Java terminology as much as possible and step by step build up a
small example in Objective-C that covers the basic features. In some cases the
examples will keep code from previous examples and in some only the change
will be presented to save space. Regardless, the new code is always in bold font.
Let’s get started.

Classes

Unlike Java which uses a single .java file, Objective-C separates class declaration
and definition into two files: .h and .m. The .h file is called the interface, which
shouldn’t be confused with Java interfaces (more on this later). Most importantly,
the interface file lists the methods and member variables that the class contains.
A minimal compilable .h file would look like this:

@interface MyClass {
}
@end

This piece of code simply declares an empty interface named MyClass which
you preferably should put in a file named “MyClass.h”. The space between the
“{}” signs is where we will put our member variable declarations and the space
right before the @end tag is where method declarations go. The .m file looks like
this:

#import ”MyClass.h”
@implementation MyClass
@end

It’s between the lines starting with @implementation and @end that we will
put our actual method implementations. Notice that there are no “{}” signs
since member variables are declared in the interface file. This minimal example
obviously doesn’t do much but it will compile and it it gives us something to
start with.

Similarly to Java, Objective-C has a superclass that most classes inherit from:
NSObject. But while we in Java are used to an implicit inheritance from this
class, we must here explicitly declare this in our .h files. To inherit a class, we
simply add a colon after the class name in our .h file followed by the name of
the class we wish to inherit:

@interface MyClass : NSObject {
} 

Conceptually, NSObject has similarities to java.lang.Object. But it is also more
powerful in the sense that it provides some features that are only possible with the
reflection API in Java. As an example, NSObject allows you to take advantage of the
runtime and determine which methods are implemented. It also contains methods
that are needed for proper memory management such as retain and release which
we will look closer at later on.

Naming conventions

Objective-C does not provide any type of namespace functionality like Java does
with packages. Instead, to avoid name clashes, the best way is to use prefixes.
You will see this used heavily throughout the official APIs. NSString (a Foundation
class) and UITextField (of the UIKit framework) are two examples. This makes
it easy to see which classes are written by Apple. We recommend that you use
an abbreviation of your company as two upper case characters and prefix your
classes with that. If your company name is Acme, you could use AC as a prefix.

When programming in Objective-C it is advisable to follow the guidelines from
Apple about naming classes, methods and other building blocks. Typically we
want naming to be very expressive and also highly consistent. This contrasts
Java where, for example, some collection classes use addElement(...) and
sometimes add(...) to add new objects. Consistency makes it a lot easier to
learn the frameworks because they follow the same conventions. We also want
to be expressive and really explain in naming what the class or method does.
Java enforces conventions through JavaBeans standards, but Apple goes far
beyond that. For example, ACPeopleTableViewController would be a suitable
name for a Controller (MVC pattern) class that controls a TableView (standard
component) which contains People. When it comes to methods getters should
not be prefixed by “get” but rather have similar name as the property they are
fetching. If there is a property called defaultColor then the method to get it
is called -(NSColor*)color; not getColor();. There are many other naming
conventions and you’ll rather quickly get used to the standard ones.

Access Control

There are three types of access control you can set on your member variables:
private, protected, and public. They have the same effect as in Java. The syntax
for doing this is a bit different tough. Let’s add two member variables to our
header file and make these private:

@interface MyClass
{
    @private
    int firstNumber, secondNumber;
}
@end 

We simply use the compiler directive “@private” and everything beneath it will
be private until either a “}” or another directive is found.

So how do I make my instance methods private? The answer is that you don’t
have to worry about that, since the language doesn’t formally support changing
the access type on methods. All methods are public!

Methods

The equivalent of calling methods in Java is defined as sending messages in
Objective-C. This is one of the big differences between the languages. On the
surface it may appear as we are doing the same thing only with different syntax:

Java:         myObject.doSomething(myParameter);
Objective-C:  [myObject doSomething:myParameter]; 

But there is in fact a big underlying difference. The doSomething method in
the Java example must exist at compile time or the compilation will fail. The
same does not apply in the Objective-C case. The notion of sending a message
to an object implies that we will send something regardless of whether there is
a receiver or not and how the message together with parameters are handled is
determined at runtime.

Now let’s declare a method in our header file that will add two numbers:

@interface MyClass {
  @private
  int firstNumber, secondNumber;
}
-(int)add:(int)a to:(int)b; 

The syntax may seem confusing at first but the elegance is displayed once the
method is used to pass a message:

[myObject add:5 to: 2];

Notice the readability of that method. Instead of guessing or reading
documentation for method signatures we know right away which parameter
goes where. Now lets add the implementation in the .m file:

-(int)add:(int)a to:(int)b
{
    return b + a;
} 

Constructors

Objective-C doesn’t have the same concept of constructors as Java. Instead,
object creation is divided into two parts: allocation and initialization. There is
no special syntax reserved for object creation (i.e. new in Java). The methods
handling this are regular methods and are named alloc and init respectively. The
two calls are usually nested to allocate and initialize an object on a single line:

MyClass *myObject = [[MyClass alloc] init];

Notice the star in front of myObject. This is regular C syntax for declaring
a pointer. Now pointers are usually something that Java people like to avoid
since it can be the source of all kinds of troubles. Fortunately, if you stick to
using Objective-C you almost never have to use the star or any dereference
mechanism when actually using the objects. Just keep in mind that it has to be
there in the declaration.

The alloc method is a static method that resides in NSObject and should never
be overridden. It allocates memory and returns a new instance of the receiving
class. The init method on the other hand is an instance method and should be
overwritten. In fact, the default implementation does nothing but return itself.
The simplest form of init implementation usually looks like this:

- (id)init
 {
     if ((self = [super init])) {
         /* class-specific initialization goes here */
 }
     return self;
 } 

We always call the parent’s init method and make sure we get something back.
Then we execute our initialize code and return self which is the Objective-C
equivalent of Java’s this.

Just like you often have multiple constructors in Java, you will likely have
more than one initializer in your Objective-C class that takes different types of
arguments. According to convention you should start the name of these methods
with “initWith”. Here’s an initializer that takes two numbers as parameters:

- (id) initWithNumberA:(int)numberA numberB:(int)numberB
 {
     if ((self = [super init])) {
        firstNumber = numberA;
        secondNumber = numberB;
     }
     return self;
 } 

The convention also says that only one initializer should make the call to super.
It is often convenient to do this in the initializer with the most arguments, and
let the other initializers call that one. Let’s change the first initializer so it looks
like this:

- (id)init
 {
     return [self initWithNumberA:0 numberB:0];
 } 

Protocols

Protocols are essentially the same thing as Java interfaces but with added flexibility.
A class is not always required to implement all methods just to conform to the
protocol, some can be marked as optional. Furthermore, a class can conform to a
protocol by just implementing the required methods, even if it hasn’t explicitly
declared that it is implementing it. Let’s create our own protocol to indicate that
the example class can calculate something, and suitably call it Calculator. We
enter the following in a new .h named CalculatorProtocol.h.

@protocol Calculator
@required
-(int)calculate;
@end 

The protocol declaration is pretty straight forward. The @required attribute
signifies that the method is mandatory to implement. We could also have written
@optional if we don’t want to force an implementation. It’s also possible to mix
required and optional methods. Now to show that our example class conforms
to this protocol we first change the .h file:

#import ”CalculatorProtocol.h”
@interface MyClass : NSObject 
{ ... 

And then we add the implementation of our getCalculation method in the .m
file:

-(int)calculate
{
    return [self add:firstNumber to:secondNumber];
} 

Where’s my garbage collector?

Unlike Java and desktop Objective-C development there is no garbage collector
available when creating applications for the iPhone. The reason for this is to
allow the best possible performance. This means that you will have to clean up
after yourself manually. Fortunately, the NSObject class contains functionality
to make manual memory management easier. Every object whose class inherits
from NSObject contains a so called retain count which is used to indicate how
many other objects that are using or “owning” it. If you own an object, you are
also responsible for releasing it when you are done, at which point the retain
count willl go down. When the retain count reaches 0 the system will assume it’s
safe to deallocate the memory for your object. So when is the object considered
“used”, i.e. when does the retain count go up? First of all, the retain count will
implicitly increase if you you create the object yourself by using a method name
beginning with “alloc”, “new” or contains “copy”. Secondly, you must explicitly
add one to the retain counter by calling the NSObject method “retain” whenever
you wish to take ownership of an object that you receive by other means, i.e. as
a parameter or from a getter method.

To reduce the retain count, or say that you no longer need the object in question,
you use [myObject autorelease] or [myObject release], where autorelease
signifies that the object should release later. To show how this works we add the
following to our example:

-(void) setName: (NSString*) newName
{
    [newName retain]; // get ownership, increases retain count for newName
    [name release]; // in case name is already set, we don’t need it anymore
    name = newName; // set name to the new value
} 

We need to retain newName in case we are passing the same object that is
currently assigned to name, or it might be deallocated. When releasing name it’s
possible that it’s not set, but it’s fine to call release on a nil object.

There are situations when you want to autorelease objects. For instance, if you
have a method that returns a NSString that is created inside the method:

//PROBLEMATIC CODE
-(NSString*)formattedName
{
  NSString *formatted = [[NSString alloc] initWithFormat:@”Name: %@”,name];
  [formatted release];
  return formatted;
} 

If you run this code there’ll be problems. The formatted variable will be released
before it’s returned which means that whoever requested the NSString will get
a pointer to a freed object. The solution is to replace release with autorelease.
Objects that are sent autorelease will be added to an autorelease pool. When
the pool is deallocated release is sent to all objects it contains, including our NSString. The pool is created before events and deallocated when the event has
been handled. That way the formatted variable won’t be deallocated right away.

-(NSString*)formattedName
{
  NSString *formatted = [[NSString alloc] initWithFormat:@”Name: %@”,name];
  [formatted autorelease];
  return formatted;
}

All objects that are not created using alloc, new or copy are automatically added
to the current autorelease pool. So if you don’t want to loose those objects you
need to retain them.

Many objects have convenience methods that return autoreleased objects, so
the easiest solution to our problem would be to avoid the alloc and instead use
a convenience method:

-(NSString*)formattedName
{
  return [NSString stringWithFormat:@”Name: %@”, name];
} 

Manual memory management is usually one of the tougher parts to get used to
when coming from a “friendlier” language such as Java. It is important however
to get a good understanding in this area as it often can be the source of nasty
bugs.

Conclusions

That concludes our example and short introduction to Objective-C, the
language you need to master - or at least learn to use - in order to write great
iPhone applications. The syntax and some concepts differ a bit from Java, but
it’s relatively easy to pick up and get started with. There are many other areas
we haven’t even touched upon, such as the frameworks and tools provided by
Apple. Fortunately there’s a wealth of information available online at the iPhone
Dev Center, where you can read API references, download sample code, watch
tutorial guides and videos as well as discuss with other developers. In order to
develop applications for iPhone you need a Mac computer running Mac OS X
and register as a developer (for free) on Apple’s website. Good luck!

Christian Hedin
Stefan Li

Originally published in JayView.