All posts by Matthew Campbell

Understanding Subclassing

subcategoriesHere is the definition of subclassing,

In object-oriented programming, inheritance is a way to reuse code of existing objects. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, superclasses or parent classes. The resulting classes are known as derived classes, subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy.

From Wikipedia (2013).

This means that if you have code in one class that you would like to reuse in another class you can create a subclass. The original class is called the superclass and the subclass gets all the code in the superclass. You can also add additional code to the subclass. Programmers do this all the time which creates a hierarchy like the graphic at the top of this page.

The Super And Self Keywords

If you haven’t yet groked the relationship between classes and objects the details of this can get confusing. For instance, take a look at the init override that you get from Xcode’s code library:

-(id)init{
    self = [super init];
    if (self) {
        //initialize here
    }
    return self;
}

NOTE I’m assuming you know about how to create classes in Objective-C here. If you don’t know what I’m talking about click here to read the chapter on creating classes in Objective-C.


So I highlighted some particularly confusing keywords that are in the init function. self and super reference objects from the class that we are currently defining.

While both keywords objects created from the class self references the properties and methods defined in the current class definition while super references the properties and methods defined in the superclass definition.

Objects And Classes

Let’s take another look at that init override so we can see the context where we usually see this function.

#import <Foundation/Foundation.h>

@interface MyClass : NSObject

@property(strong) NSString *name;

@end

@implementation MyClass

-(id)init{
    self = [super init];
    if (self) {
        //initialize here
        _name = @"MyClass Object";
    }
    return self;
}

@end

int main(int argc, const char * argv[]){
    @autoreleasepool {
        MyClass *myObject = [[MyClass alloc] init];
        NSLog(@"myObject.name = %@", myObject.name);
    }
    return 0;
}

Here’s the English version of the code above: we defined a class named MyClass which is a subclass of the NSObject class. MyClass is going to override the init function.

In the main function we are going to instantiate an object named myObject and write out the myObject name value to the console log.

Class Vs Object

A class is a definition of an entity (an abstract model) that is made up of definitions for properties and methods. By itself, a class doesn’t do much other than contain a definition. In the above example all the code that defines the class is between the @interface and @end keywords and the @implementation and @end keywords.

Objects are special variables that are created based on class code definitions. You can see how objects are used in the main function above. Typically, you would create many objects based on one class definition.

How It Gets Confusing

This stuff gets confusing because most people think of classes and objects as the same thing. After all, when you want an object to behave differently you must make changes so rewrite the class definition. So that’s pretty natural. Getting back to the init function though you can see why this gets confusing,

-(id)init{
    self = [super init];
    if (self) {
        //initialize here
    }
    return self;
}

In that first line of code after the function name, self = [super init];, it looks like we are getting an NSObject object from the superclass, assigning this object to self and then returning this to the caller.

This is not really the case. You are simply getting your MyClass object from the superclass. The reason that it seems like you are getting an NSObject object back here is because you are thinking in terms of objects and not class definitions. Even though this code will be used to initialize and return objects at some point right now we are only working on the code definition.

That self keyword doesn’t represent some NSObject object variable out there. It’s simply a way to reference the code from the superclass definition.

What subclassing really does for you is more like a copy and paste. It’s as if you have copied all of the NSObject code and used this code in MyClass. So that init call to super will just initialize the part of the class definition that is contained in NSObject before you finish up initializing.

iOS Code Camp Just Got A Crazy Bonus!

app-globeiOS Code Camp my online boot camp style training program. What I did in the past was take a small group of serious technologists and taught them everything they need to be iOS developers. This all takes place on my website over a period of3 now 6 weeks.

I’m there the whole time via the forums and video conferencing to help you make the most of your investment in the program.

This time around I’m expanding the program to include an entire new Objective-C Boot Camp and a business seminar! It’s going to be fun and if you’re even remotely interested in becoming an iOS developer go here to check it out:

http://institute.mobileappmastery.com/register/

I Mentioned a Crazy Bonus Remember?

You get me for six weeks right out of the box with iOS Code Camp. Another program I have is the Gold Membership subscription to my website. This gives you access to all the training materials plus more ongoing support from me.

I’m giving away these memberships to the next five people who register for iOS Code Camp!

That’s a three month subscription which is a $97 value.

If you think you might want that click here to find out more about iOS Code Camp and register:

http://institute.mobileappmastery.com/register/

frustrated-women

What Are The Two Biggest Complaints That Frustrate Newbie iOS Developers?

Does this sound familiar?

“I would love to do iPhone development but I just don’t have the time to wade through the obtuse and elitist tools required to master iOS programming.”

I’ll bet this describes at least some of you out there right? The reason I know this is that late last year I asked my readers what their biggest sticking points were. The overwhelming response to this question could be summarized by two words: Time and Tools.

Who Has A Massive Time Surplus?

The answer to this is: almost no-one. Maybe if you’re still a student or a recent grad and are very excited about mobile development then you can learn app development instead of burning away hours on the XBox (or whatever you kids are doing these days!).

However, most of the people who responded to my survey though already have tons of completing burdens on their time: family, jobs, hobbies, activities, babies and so on. For this group, taking a few months to struggle through learning something brand new is daunting. Almost no-one has the 6 months to a year it would take to learn this stuff on their own.

Some of the responses I got were:

“No time to explore mobile technologies though I’m trying hard to devote time for this.”
“Having time to work on iPhone apps.”
“Not having enough time.”
“Time. As a father of a young family with many constant and various needs. Husband. Working professional. Like many others.”

Trying to learn something brand new like iOS development on your own is going to take a ton of time. Obviously, learning a new skill will take some time – the question is only how much time will it take?

What’s the solution?

If you’re truly motivated you can find some time in your schedule. Here’s some ideas:

- Re-Prioritizing Projects (maybe that new bathroom can wait a few months)
- Getting Help With Chores (hire a cleaning service and/or a handyman and use your time savings for your education)
- Use your educational time wisely (investing in the right class or training program will be much better than wading through on your own)

The only way around the time problem (outside of magic spells) is to get help so that you use your time wisely.

The Comfy Tool Bias

This applies especially to seasoned software developers. We all have our favorite tools and have mastered our workflow to the point where making new software is as familiar to playing a favorite video game. Other professionals have similar feelings with their own workflows and tools.

Xcode, Objective-C, iOS and UIKit are the four main tools you’ll use to make apps. For most newbies, these tools are unlike anything they’ve worked with before. These are not your typical text editors, photoshops, Visual Studios or Microsoft Words. Many (if not all) newcomers find these tools daunting.

In fact, the words I used at the beginning to describe these tools sum it up pretty well: they seem elitist and obtuse. The truth is: they are. For a programmer used to performing magic feeling lost and stunted with Xcode is overwhelming. For a newcomer to software development who hasn’t used a Mac the experience can be terrifying.

What’s Your Opinion?  What is the biggest sticking point that you see with new iOS developers?  Please comment below…

objective-c-tips

Create a New Mac Cocoa App

Usually, our blog readers are more interested in making iPhone apps (hence the title of the blog). But, with the Mac app store and the demands of many users who want desktop versions of apps many developers also want to implement a Mac app. Here’s how to use Xcode to set up a Cocoa application on the Mac.

NOTE Cocoa is the desktop equivalent to the iOS Cocoa-Touch. The name Cocoa refers to the frameworks that provide developers with user controls and other interface elements among other things. While Cocoa is not identical to Cocoa-Touch, the patterns that you follow are very similar so Mac development and will feel familiar to you. Also, the Foundation frameworks and of course the Objective-C programming language are shared between Cocoa and Cocoa-Touch applications.

Setting up an Mac Cocoa application with Xcode is very straightforward. The process is a lot like creating a new text document or Keynote presentation. Here’s how to do it

Install Xcode

Xcode is the IDE, Integrated Development Environment, used to create Mac apps. This app is a free download that you can get from Apple by using the links below.

Click here to download and install Xcode from your Mac: Install Xcode.

BTW: this is a free tool to use on your Mac. To distribute Mac or Mac apps on the app store you’ll need to pay a yearly fee to Apple ($99 for each).

Start Xcode

Locate Xcode from the Applications folder – it’s the app named Xcode.app and will look like the icon below.

You can also use the Spotlight feature on your Mac to locate and start Xcode.

Add New Project

Make sure that Xcode is selected. Select File > New > Project… .

A dialog box will appear with many options that you have. You can actually create Mac, iPad and iPhone apps from this dialog. Here is what the dialog box will look like:

Choose OSX > Application > Cocoa Application . Then click Next. You should see a dialog box that looks like this:

Fill in the fields with your information. Most importantly, include your app’s name and your website URL for the bundle identifier. Make sure to pick iPhone for Devices. Pick iPad for iPad apps and Universal for apps that run on both iPad and iPhone. Also be sure to choose Use Automatic Reference Counting. Click Next. That’s about it.

Inspect and Test Project

Xcode will take the information that you provided to set up a project that can be used to start building your app. The configuration is all set up and you can even test the app on your Mac by clicking the run button located in the lefthand area of the Xcode screen.

Here is an example of what files you will see in your Xcode Mac Cocoa Application project:

Of course now that you have the project set up you can go ahead and start testing some code. Like iOS applications, you will likely start with the AppDelegate. Mac apps don’t have storyboards (at least as of this writing), so you will need to use the NIB files to work with the interface (the files ending in xib).

objective-c-tips

Working with Multiple Targets in Xcode + Code Reuse, Part One

Have you ever wanted to share code between apps? I have and honestly, code reuse with Xcode (in particular between apps) is not as straightforward as you might imagine. You do have some options which I’ll talk about here and once you get something set up this problem will be solved easily.

The reason I started looking into this was because I wanted to release several variations of my app (or rather my app’s database engine).  Previously, I have done this by simply copying the core libraries as needed.  Essentially, each app of mine would have it’s own Xcode project and point (or have copies) of the code files I needed.

This solution is unsatisfying as hell and it became enough of a chore in terms of app maintenance that I ended up pulling many of my apps from the store in 2011.

So, last month I started to investigate some options that would help with code reuse among apps.  But first, let’s backup and talk about code reuse and why most developers strive to reuse code.

Let’s Talk About Code Reuse

Coders will often be tasked with solving the same or similar problems when making software.  Since most people don’t want to code or copy the same thing over and over again we try to come up with ways of organizing code so that we can avoid repetition.  Instead of writing a few lines of code we will encapsulate that same code in a function that we can reuse over and over again.  Write once and use forever.

Not only does this help us keep our code smaller we can avoid mistakes in the future because we will build on a collection of code we already know works.  When bugs are fixed, they are fixed for anything that uses that code.  Instead of correcting an algorithm in 100 places, we correct it once.

In an Objective-C program like an iOS app, you may see code reuse implemented with functions, classes that support sub-classing and delegation, categories and blocks.  Most developers are comfortable with this practice at the app level.

Tasting Notes and the system behind the app already followed patterns that enabled code reuse since I’m a stickler for object oriented patterns.  However, a problem emerged when I wanted to expand the reach of the Tasting Notes database engine.

The Code Reuse Problem Across Apps

Here’s what I wanted to do:

I wanted a entire suite of applications that used the Tasting Notes database engine.

The database engine is about 40% of the Tasting Notes code.  Some of the apps in the suite could also reuse the user interface elements on the Storyboards, while others like the Mac version would also use the model classes.  Many apps on the app store are a part of a suite like this and I’m sure they reuse the code that they can.

I was very surprised that setting up my app suite didn’t go as smoothly as I thought.  What started as a day or two project ended up turning into a multiple weeks project where I tested my options with Xcode.  Here are the solutions I tried.

Static Library with Xcode Workspaces

Surely this was the way to go right?  My plan was to remove the database engine (and model classes) from Tasting Notes and turned this into a static library.  The same would go for the standard user interface components.  I would have started out with three separate Xcode projects that I could keep organized with one Xcode workspace.

This works in principle, but the reality of managing the three projects even at this level was a pain.  The UI part would need to reference the model part which in turn was referenced by the app.  Each one had it’s own frameworks to link.  Odd linking errors would show up.  This solution was it’s own kind of mess, however with the simplest situation it did work more or less.

Problems really started to happen when I attempted to add a Mac Cocoa app to the workspace.  Obviously, I couldn’t reuse the iOS user interface.  But it turns out that even the database engine couldn’t be added to my Mac app without a lot of very confusing configuration changes to the static library.  This was the point where I gave up to look for better solutions.

BOTTOM LINE While the most obvious solution, the static libraries added too much work to the process to make it worthwhile to use.

Pointing to Code with Workspaces

The next thing I tried still involved using Xcode workspaces (I really thought that this was the way to go).  What I did was create a group independent of any Xcode project in the workspace that held the shared code.  This was once step up from what I did before.

This didn’t really help much either.  First of – the way I set up the group folders meant that there was no Git support which I need.  Of course, I could have added this myself but I wasn’t sure if I could actually integrate with Xcode in this way.  Things were already starting to get to complicated.

Also, this solution didn’t help me as much as I wanted with or without Git.  Each project needed to add each code file and there is almost a hundred of them.  I also had to link to the other frameworks needed by my shared model classes.  Linking to other frameworks isn’t a big deal when its the built in stuff, but including the Google, Dropbox and other third-party frameworks I use because a chore with this approach.

BOTTOM LINE This approach didn’t help at all and actually made some things a bit more difficult.

Multiple Targets

This is something I really didn’t know you could do.  Or rather, I knew about multiple targets but was so entrenched in how I used to set up projects that I never really considered what the purpose or implications of multiple targets were.

Here’s the deal: when you first create a new Xcode project you get one project and one target.  The project contains all the assets like code, graphics and databases while the target defines what goes into the bundle that you use to actually run the application.  A project is what you work on as a developer.  The target is the app that you test in the simulator and ultimately gets sent to the app store.

It’s tempting to assume that the project and the target are the same thing.  They’re not.

You can add as many targets as you like to your Xcode project.  So you have use the same project and have targets for a bunch a iPhone apps, an iPad app and a Mac app. Use the Add Target button or select New > Target from the menu bar to add a new target.  Each target gets it’s own configuration, it’s own Storyboard or starting Nib and it’s own app delegate.

Any file can be included in any target by setting the file’s target membership (located in the identity inspector).  This includes the linked frameworks.  If one target needs a custom version of a file you can add a custom file to the new target’s group and only include that file in the new target.  This gives you a way to override entire code files.

The only issue here is that each time you add a new target you must make sure that each file is included in the new target.  As far as I know the only way to do this is to go and look at each implementation file and add them to the target using the check box.

BOTTOM LINE

This was the way to go for me: I was able to have full Git support and this approach gives me code reuse.  The solution is not very complicated.  The only drawback is that I need to manually go into each file to set it’s target membership.

So, that’s how I did it.

What are you thoughts on this?

Please comment below…

ape-1667x2500

APE: Author, Publisher, Entrepreneur Book Preview

APE is an new eBook by Guy Kawasaki and Shawn Welch about how to publish books in the digital landscape. For those of you who don’t, Guy Kawasaki has written many books about tech and entrepreneurship that are always well done and well received. Shawn Welch is one of us, a mobile app developer.

FULL DISCLOSURE I was contacted to review this book and so didn’t seek this out on my own devices. Also, all the links to books here and on this site in general are amazon affiliate links. This doesn’t assume any endorsement, just that I’m talking about books I think you’ll (and me) will be interested in.

So, APE comes out next Monday, December 10th but you can pre-order the book now. I’m about 25% of the way and so far I’m very impressed. I’ve self-published a book myself (pre-Kindle days) and I have published with a traditional publisher and everything that I’ve read in APE so far checks out.

WHO WILL WANT THIS BOOK

This book will give you the direction you need to really self-publish or traditionally publish your book. You’ll be surprised how possible it is to publish an ebook or even a traditional book (which they seem to recommend). They are also very honest in APE when laying out the sometimes grim realities of being an author (both traditional and self). This is both inside baseball and a roadmap to becoming an author. If that’s your dream this book is well worth the $9.99 price tag (even while I’m only 25% through).

Keep your eye on this blog for my full review when I’m done the book. Or pre-order the book now my clicking through this Amazon link.

hungry-bird

Is It Over for Indy Mobile App Developers?

Here is why I ask: for years, I’ve done pretty well on the app store with Tasting Notes and some other apps. In fact, Tasting Notes still sells copies every single day. Sales are not gangbusters but they are consistent.

However, while Tasting Notes sells it falls way short of what you would need to replace even one developer’s salary.  A handful of sales a day usually nets something like $200 per month.  Tasting Notes has been on sale since 2008.  In 2008 and 2009 the app typically had sales in the realm of a few thousand dollars each month.

In 2009, it was common for me and many others to release simple apps.  By the end of the year, I had a suite of 12 apps each of which made sales.  Some sold better and some sold worse, but they all sold.  My apps were featured two times by Apple.  All of this from one person with little marketing and minimal design.  In 2009, the dream of being an indy app publisher solo-preneur was real.

What Happened?

This past week I released a new app called BeerBro.  BeerBro is essentially a re-release of a beer app that I had on sale in 2009 and 2010.  The former app sold pretty well – in fact it had more sales than Tasting Notes has now.  While I honestly didn’t expect a blockbuster hit here I was very surprised to see no sales coming in at all.  The only hit on BeerBro’s analytics came from Cupertino where the App Store approval must have happened.  To this day, I haven’t made one sale.

Ouch.

At the same time I ran across this article from the New York Times, As Boom Lures App Creators, Tough Part Is Making a Living.  The gist of the article is that making on your own in the app store is hard.  This article contains some heartbreaking stories like the Grimeses couple:

“The Grimeses’ quest cost them more than $200,000 in lost income and savings. So far this year, their eight apps have earned $4,964.”

This couple’s idea (like mine) was to release a new app each month.  What they found is diminishing returns and basically had to work twice as hard to make half as much on each successive app.  BTW: the $200,000 figure includes their 401K and house equity.

Even more heartbreaking, is the story of an app developer that I remember Mr. Nicholas.  Mr. Nicholas is the creator of the iPhone game iShoot which took off early in the app store to the tune of 17,000 copies per day!  Two months later this guy quit his job and soon after that he as a millionaire.  All based on an game that took him 6 weeks to write in his spare time.  In 2009 that was the dream for most of us and the reality for a few.

Mr. Nicholas invested everything back into a new company to make more games hoping for another 1 or 2 million along with a friend whose father took out a second mortgage.  None of their games have sold like iShoot and $4 million has been invested.  Today, they did a pivot and now make free apps for doctors.  They 14 employees but no revenue.

What was So Good About the Good Old Days?

For those of you who don’t know, here is why the early days of the app store were so great:

Before the app store and the iPhone, software products were complex entities that ran on desktop computers.  These products required teams of people to develop and design the product.  Software programs on desktops cost at least $49 and oftentimes were much higher.  These things were distributed primarily through brick and mortar stores and required teams for marketing, sales and distribution.  To have a shot at a successful program pre-2008 you needed to be a big company.

When the app store was announced in 2008, Apple not only removed the need for physical distribution but they offered instant access to a massive audience starved for mobile apps.  In that keynote, part of the message was that the App Store “freed” developers from doing the stuff they hate: marketing, sales and distribution.  An entire class of people, including myself, were able to start software businesses by themselves.  This was *almost* impossible before.

NOTE I say *almost* because there has always been an Indy App culture on the Mac.  These guys were distributed apps via their websites and did there own sales and marketing.  Of course, this is a very small part of the overall software market and pales in comparison to what we see today on the app store.

In 2008 and 2009 the app store was a feeding frenzy.  Apps that are barely good enough to be used as tutorials (like my very first app) could easily make $15,000.  Some developers simply took Apple’s example apps, rebranded them and sold them.  Even in 2010 and 2011 once the excesses settled down most developers could count on some revenue from new apps and decent sales from established apps.

What Does this Mean for the Solo-preneurs?

I’m talking about the dream here: living off of apps that you make by yourself doing little else but coding.  In my opinion – it’s over.  That’s that.  The opportunities now are for consultants and developers working for big business.  Alternatively, the big-idea apps are going to need more than one person and a coffee shop to succeed.  The honeymoon is over.

What do you think?  Please comment below with any insights.

objective-c-tips

Write to the Console with NSLog

Writing to the console log is something that you’ll end up doing sooner rather than later. Usually you’ll write to the log when your testing prototype code. Other times, you may be simply debugging your code (although there are better ways to debug).

NSLog

Objective and primitive type values may be reported to the console using NSLog. Each type has a different specifier that must be used as a placeholder for the value. You will type out the string that you would like to appear in the console while putting in specifers into the string where you would like to see values reported. You can put as many specifers into the string as you like, but you must make sure to include each value in the call to NSLog.

For example, if I had an integer variable named myInteger and a character variable named myCharacter and I wanted to report each of these values to the console I would do something like this:

NSLog(@”myCharacter = %c and myInteger = %i”, myCharacter, myInteger);

Warning Each specifier that you include in the NSLog string must have a corresponding value in the comma-seperated list to the right or the compiler will throw at error more ‘%’ conversions than data arguments at compile time.

How to Use NSLog

NOTE: you will need a Mac or iOS application set to try out these examples of NSLog . Click here to follow instructions on setting up an iOS app using Xcode.

Open up your applications main.m file. Your code will look something like this:

#import <UIKit/UIKit.h>
#import "AppDelegate.h"

int main(int argc, char *argv[]){
    @autoreleasepool {

        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

Stick the code that we want to test on the next line right after the @autorelease statement.

Examples of NSLog

Add and examine these NSLog statements to your application to see different ways that NSLog is used.

//To print out primitive types:
int myInteger = 1;
NSLog(@"myInteger = %i", myInteger);
		
float myFloatingPointNumber = 2;
NSLog(@"myFloatingPointNumber = %f", myFloatingPointNumber);
NSLog(@"myFloatingPointNumber in scientific notation = %e", myFloatingPointNumber);
		
NSLog(@"myFloatingPointNumber = %f", myFloatingPointNumber);
NSLog(@"myFloatingPointNumber in scientific notation = %e", myFloatingPointNumber);
        
char myCharacter = 'A';
NSLog(@"myCharacter = %c", myCharacter);
		
//To print out the % symbol
NSLog(@"Percent Sign looks like %%");
		
//To print out Objective-C objects:
NSString *myString = @"My String";
NSLog(@"myString = %@", myString);
NSLog(@"myString's pointer = %p", myString);
		
//To print out a series of values
NSLog(@"myCharacter = %c and myInteger = %i", myCharacter, myInteger);

To test this code out, hit the Run button located in the upper lefthand area of Xcode. You should see output like this:

myInteger = 1
myFloatingPointNumber = 2.000000
myFloatingPointNumber in scientific notation = 2.000000e+00
myFloatingPointNumber = 2.000000
myFloatingPointNumber in scientific notation = 2.000000e+00
myCharacter = A
Percent Sign looks like %
myString = My String
myString's pointer = 0x35d4
myCharacter = A and myInteger = 1

How to View the Console Log

You may not be able to locate your console window at first. With Xcode you can show and hide many panes that show content, code and utility widgets. Your console window should be located at the middle bottom area of Xcode. If you can see this window make sure that the View button strip located in the upper right hand area of Xcode has the middle button depressed.

Also make sure that the bottom window’s right pane button is depressed. Check out the screenshot below for the locations of these controls in Xcode:

Table of NSLog Placeholders

You can use the same placeholder specifiers with NSLog that you would use with the corresponding C functions to write to the log. Here is a list of the most important:

Specifier Data Type
%@ Objective-C object (looks at description method)
%d, %D, %i int (signed 32-bit integer)
%u, %U unsigned int (unsigned 32-bit integer)
%f double (64-bit floating point number)
%e double (64-bit floating point number in scientific notation)
%c unsigned char (unsigned 8-bit character)
%C unichar (16-bit character)
%p Pointer printed in hexadecimal
%% Escape character so we can print the % sign
objective-c-tips

Using Xcode to Make a New iOS App

Setting up an iOS application with Xcode is very straightforward. The process is a lot like creating a new text document or Keynote presentation. Here’s how to do it.

Install Xcode

Xcode is the IDE, Integrated Development Environment, used to create iPhone, Mac and iPad apps. This app is a free download that you can get from Apple by using the links below.

Click here to download and install Xcode from your Mac: Install Xcode.

BTW: this is a free tool to use on your Mac. To distribute Mac or Mac apps on the app store you’ll need to pay a yearly fee to Apple ($99 for each).

Start Xcode

Locate Xcode from the Applications folder – it’s the app named Xcode.app and will look like the icon below.

You can also use the Spotlight feature on your Mac to locate and start Xcode.

Add New Project

Make sure that Xcode is selected. Select File > New > Project… .

A dialog box will appear with many options that you have. You can actually create Mac, iPad and iPhone apps from this dialog. Here is what the dialog box will look like:

Choose iOS > Application > Empty Project . Then click Next. You should see a dialog box that looks like this:

Fill in the fields with your information. Most importantly, include your app’s name and your website URL for the bundle identifier. Make sure to pick iPhone for Devices. Pick iPad for iPad apps and Universal for apps that run on both iPad and iPhone. Also be sure to choose Use Automatic Reference Counting. Click Next. That’s about it.

Inspect and Test Project

Xcode will take the information that you provided to set up a project that can be used to start building your app. The configuration is all set up and you can even test the app in the iOS Simulator by clicking the run button located in the lefthand area of the Xcode screen.

Here is an example of what files you will see in your Xcode project:

Of course now that you have the project set up you can go ahead and start testing some Objective-C code.