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…

Understanding Subclassing

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 theinit function.self andsuper 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.

Chapter Nine: How To Create Your Own Classes

At some point you will want to define your own classes to use in your app. So now let’s expand on the notion of object oriented programming by showing you how to implement your own custom classes. At this point you should be familiar with using existing objects in code; but you also need to be able to create your own types of objects.

Sub-Classes

One of the most common things that you will be doing with classes is something called sub-classing. As you can guess the iPhone has classes already in place to do things like present data tables, present windows and so on. Usually you will be creating your own object that inherits one of these preexisting objects and adding your own custom code to it. This is sub-classing.

Adding a New Class

XCode will help you do the initial set up work when you are creating a new class. To add a class you can simply control-click on a group folder in XCode and select New File… . In the dialog box that pops up select iOS > Cocoa Touch > Objective-C class and click Next . Then name your class and choose NSObject as the subclass.

Let’s do this now and call our class myClass. XCode created both the interface and the implementation files for myClass and added the code we need to get started. The interface file is the one that ends in .h. If you open that file you will see the code that XCode automatically filled in for us.

#import <Foundation/Foundation.h>

@interface myClass : NSObject{

}

@end

Interface File

This interface file uses an import directive to import the Foundation classes (which we always need to use). It also uses the interface keyword with the name of the class (myClass here) to indicate that we are defining a class.

The colon and the name NSObject means that our class will be a subclass of NSObject. Sub-classing and inheritance mean the same thing. You can say that myClass inherits from NSObject or you can say myClass is a subclass of NSObject.

We end the interface declaration with the end keyword @end.

Implementation File

XCode also created an implementation file, in case you did not notice XCode will create a separate file for the interface (header file that ends in .h) and the implementation file (ends in .m). Click on the implementation file to see the code that XCode added on our behalf.

#import "myClass.h"

@implementation myClass

@end

Our implementation file simply imports the myClass interface and includes the @implementation and @end keywords along with the name of our class.

Simple enough – we have created our first class. Right now it behaves exactly like NSObject, but soon we will be adding our own properties and methods to the class.

Adding Properties

When you add a property in a class you end up using a little black magic. That is, the system takes care of some of the implementation details for you if you do things in the typical way. You need to do two things to get a working property into your class: declare the property and then use @synthesize.

Here is what this looks like in the code:

Interface File (myClass.h):
#import <Foundation/Foundation.h>

@interface myClass : NSObject

@property (strong) NSString *name;

@end

The property is defined by using the @property directive. The key thing to note here is strong.

Back in the implementation file we use @synthesize to evoke all the black magic that is required to create the property based on our definition in the interface file.

#import "myClass.h"

@implementation myClass
@synthesize name;

@end

One thing that is significant though is that when you use primitive types as properties the syntax is a little different. For example, I am going to add a number property to my class that is an integer. Notice that it is done in a slightly different way:

#import <Foundation/Foundation.h>

@interface myClass : NSObject

@property (strong) NSString *name;
@property (assign) int number;

@end

The first thing is that there is no asterisk * since this is not an object variable. The other thing is that instead of using the strong keyword it is using assign in the property declaration.

Dot Notation

What all this does for you is give you the ability to assign and retrieve the property values using dot notation. You have already encountered this in the examples. Here is how you use dot notation with a myClass object.

//Instantiate an object from myClass:
myClass *object = [[myClass alloc] init];

//assign properties:
object.name = @"Obie";
object.number = 3;

//Access and use the properties
//with dot notation:
NSLog(@"My object's name is %@", object.name);
NSLog(@"My Object's number is %i", object.number);

Note that we use an alloc and init message even though we never created these in our class definition. Since our class is a subclass of NSObject we can simply use the original NSObject constructer to create objects. We can also code additional constructors if we want to set properties before we return our object to the system.

Class Methods

As you remember from chapter ten , objects have both properties and methods. Properties describe the object (the object’s attributes) while methods are what the object does (the object’s behaviors).

Furthermore, methods can be either class methods or instance methods. Class methods do not require an instance of a class (an object) to be used, you simply send the message to the class itself.

Here is how to declare a class method:

Interface File:

#import <Foundation/Foundation.h>

@interface myClass : NSObject

@property (strong) NSString *name;
@property (assign) int number;

+(void)writeSomething;

@end

Implementation File:

#import "myClass.h"

@implementation myClass

@synthesize name, number;

+(void)writeSomething{
	NSLog(@"I'm writing something");
}

@end

Here, the plus sign indicates that this is a class method and the void in between the parenthesis means that the method will not return a value. This is followed by the name of the method and curly braces. Whatever we want the function to do we put in between the curly braces as code.

Since this is a class method we do not even need an object to use this method. All we need to do is send a message to the class name itself:

[myClass writeSomething];

Instance Methods

Instance methods also are used to code behavior, but these are different than class methods because they may only be used by sending a message to an object. You code them the same way inside the class definition but you prefix the method with a minus sign instead of a plus sign:

Interface File:

#import <Foundation/Foundation.h>

@interface myClass : NSObject

@property (strong) NSString *name;
@property (assign) int number;

+(void)writeSomething;
-(void)writeSomethingForAnObject;

@end

Implementation File:

#import "myClass.h"

@implementation myClass

@synthesize name, number;

+(void)writeSomething{
	NSLog(@"I'm writing something");
}

-(void)writeSomethingForAnObject{
	NSLog(@"I'm writing something, but only as an object");
}

@end

To use an instance method we must have an object available.

myClass *object = [[myClass alloc] init];
[object writeSomethingForAnObject];

Method Parameters

Like functions in C you can pass parameters to methods in Objective-C. The syntax looks different. To put a parameter into the method declaration you must add a colon after the method name and then declare the object type and name the parameter:

Interface File:

#import <Foundation/Foundation.h>

@interface myClass : NSObject

@property (strong) NSString *name;
@property (assign) int number;

+(void)writeSomething;
-(void)writeSomethingForAnObject;
-(void)aMethodWithThisParameter:(NSString *)param;

@end

Implementation File:

#import "myClass.h"

@implementation myClass

@synthesize name, number;

+(void)writeSomething{
	NSLog(@"I'm writing something");
}

-(void)writeSomethingForAnObject{
	NSLog(@"I'm writing something, but only as an object");
}

-(void)aMethodWithThisParameter:(NSString *)param{
	NSLog(@"%@", param);
}

@end

To use this method you would do this (this will be familiar to you):

myClass *object = [[myClass alloc] init];
[object aMethodWithThisParameter:@"Say What?"];

Multiple Parameters

You may have your methods take more than one parameter. Objective-C has a unique way of doing this where you may include a descriptive phrase in the method declaration.

Interface File:

#import <Foundation/Foundation.h>

@interface myClass : NSObject

@property (strong) NSString *name;
@property (assign) int number;

+(void)writeSomething;
-(void)writeSomethingForAnObject;
-(void)aMethodWithThisParameter:(NSString *)param;
-(void)aMethodWithThisParameter:(NSString *)param 
		   andThisParameter:(int)num;

@end

Implementation File:

#import "myClass.h"

@implementation myClass
@synthesize name, number;

+(void)writeSomething{
	NSLog(@"I'm writing something");
}

-(void)writeSomethingForAnObject{
	NSLog(@"I'm writing something, but only as an object");
}

-(void)aMethodWithThisParameter:(NSString *)param{
	NSLog(@"%@", param);
}

-(void)aMethodWithThisParameter:(NSString *)param
               andThisParameter:(int)num{
	NSLog(@"%@ + %i", param, num);
}

@end

The key difference between methods with one parameter and methods with two is that starting with the second parameter each gets its own descriptive text prefix. Above it is andThisParameter: which is in front of the parameter num.

Your probably already guessed that you send a message to an object using two parameters like this:

[object aMethodWithThisParameter:@"One" andThisParameter:2];

Constructors

We know that constructers are special methods that return an instance of an object back to the system. We are already using the constructer that we inherited from NSObject, init to instantiate an object from myClass. We can create a custom constructor if it is needed.

In general, we always prefix our constructor with init. This is a matter of convention. Let’s start by defining our constructor in the myClass implementation file:

#import 

@interface myClass : NSObject

@property (strong) NSString *name;
@property (assign) int number;

+(void)writeSomething;
-(void)writeSomethingForAnObject;
-(void)aMethodWithThisParameter:(NSString *)param;
-(void)aMethodWithThisParameter:(NSString *)param 
				andThisParameter:(int)num;
-(id)initWithName:(NSString *) aName;

@end

Instead of being declared as a void type as our previous methods our constructor will be declared as an id. id means that our method will be returning a value that not yet defined. Whenever you replace the void with another type you are saying that this method will be returning a value (like a function in C).

Our constructor will also be taking a parameter which we will use to assign a name to the object’s name property. Here is how we implement this constructor:

#import "myClass.h"

@implementation myClass
@synthesize name, number;

+(void)writeSomething{
	NSLog(@"I'm writing something");
}

-(void)writeSomethingForAnObject{
	NSLog(@"I'm writing something, but only as an object");
}

-(void)aMethodWithThisParameter:(NSString *)param{
	NSLog(@"%@", param);
}

-(void)aMethodWithThisParameter:(NSString *)param 
				andThisParameter:(int)num{
	NSLog(@"%@ + %i", param, num);
}

-(id)initWithName:(NSString *) aName{
	if (self = [super init]){
		self.name = aName;
	}
	return self;
}

@end

In the if-then statement above we assign the object returned from the constructor that we inherited from NSObject to the current object (notice that there is only one equals sign). The self keyword always refers to the object in which the self keyword was placed while the super keyword refers to the class it is being inherited from (sometimes called the superclass).

Once we have successfully retrieved the object from the super init we can assign values to our properties.

Here is how you would use your new constructor to create an object:

myClass *object = [[myClass alloc] initWithName:@"MyObject"];

Hands On Time

Practice creating your class by first thinking all some attributes and behaviors could represent a person in your code. Keep it simple but meaningful. Use the techniques that you learned in this chapter to create a class definition for a person. Instantiate and use objects created from this class definition. Try using a NSMutableArray to hold a list of your person objects.

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.

Multiple Targets in Xcode

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. [Read more…]

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.

hungry-bird

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 was 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. [Read more…]

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 specifiers into the string where you would like to see values reported. You can put as many specifiers 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 .

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:

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

Your First iOS App

After you’ve set up your iOS SDK toolset, the very next thing you should do is make sure that you can get make a simple iOS application that works.

The main reason that we want to do is is to make sure that your Xcode setup is working properly. Also, it just helps you with the confidence game. This is why everything programming training program has a so-called Hello World app.

Launch Xcode

The first thing that you need to do is open the Xcode application. Of course, you should have already followed the steps we outlined before in this guide to set up your iOS SDK toolset.

Once Xcode has been set up you can open up the application by going to Applications directory in Finder and then double-clicking on the Xcode icon.

When Xcode is done launching and ready for you, the Xcode menu bar will appear in the top of your Mac’s screen.

Create New Project

Xcode organizes our work based on this idea of projects. Projects are collections of material like source code, storyboards, images, sounds, databases and movies that will ultimately be used to generate an application.

To create a new project in Xcode, go to the Xcode menu bar and choose Xcode > File > New > Project….

A dialog will pop up here. Choose iOS > Application > Single View Application.

Click Next

Another dialog box will pop up here. You can enter in a name for your Xcode project along with any other identifying information. Make sure to pick Use Storyboards and Use Automatic Reference Counting.

Click Next and then click Create.

You’ll be left with a screen that looks something like this:

This is the main area that will use to work with your Xcode project.

Click the Run button in the top left area of your Xcode project. In a few seconds you will see an iPhone with a blank screen running in your Mac. This is the iOS simulator running the iOS application that was created based on your Xcode project settings.

In the most basic sense, that’s all there is to it. Of course, this is not all that interesting. So, let’s make it a little more interesting by using a Storyboard to say Hello World.

Hello World

In the left hand side of your Xcode project, locate the file named MainStoryboard.storyboard and click on it. You will see an editor show up that is displaying what looks like a blank user interface. This is your app’s storyboard. Storyboards are used to manage most aspects of an application’s user interface. This is what you should be seeing:

Now locate the Object Library. This is the widget in the lower right hand corner of your Xcode project screen. It will be a list of objects that start with an object named View Controller. If you don’t see this, click on the third tab.

Look through the Object Library until you locate the Label object. See the screen below to get an idea of what I’m talking about.

Click and hold the label object then drag the label object into the blank screen on your storyboard. Try to stick the label in the middle of the screen.

Once you are satisfied that the label is securely in place, double click on the label in the storyboard. Type in the worlds Hello World.

You should see something like this in your Xcode project storyboard:

Run and Test Your App

Click the Run button. Xcode will turn your project into an app and then run the app on the iOS simulator. This time you should see the Hello World text appear in the iOS Simulator like this:

Really, That’s It

And so there you have it… Apple has done lots of the work for us already and that’s why this process is so easy. Many other things we’ll be doing with iOS apps are similar – you’ll find many tools, patterns and best practices already set up for you ready to be used.

How Mobile Apps Can Make a Difference, the Critical Case Study

In the keynote at Apple’s World Wide Developer’s Conference (WWDC) in San Francisco this year, we were all reminded that mobile apps can make a significant difference for real people with real world problems.

Tim Cook, the CEO of Apple, shared stories of apps that have helped blind people walk through unfamiliar forests and help autistic children. Frankly, this was an inspiring moment and a refreshing change of perspective for a developer community that can at times learn toward more opportunistic motivations.

These stories reminded me of an app that Jadie Barringer  created. Jadie isn’t a software developer at all – in fact he is a doctor and he wanted to make an app that would help other medical professions. Jadie’s app is called Critical.

Critical

 

Critical is an educational tool and reference guide that seeks to provide healthcare professionals with the framework to become better clinicians.

Critical contains detailed medical guidelines, including:

 

  • Critical Care & Course of Action
  • Emergency Medicine
  • First Aid Care
  • Para Medicine
  • Drug Calculators
  • Formulary & Drug Interaction Checking
  • Pediatric Advanced Life Support
  • Ventilator Management
  • Special Procedures, such as CTs and Chest Tubes
  • Monitoring Information – Electrocardiograms & IABPs

 

Advanced Cardiac Life SupportCritical – Medical Guide also features images, diagrams, and interactive videos in high-definition to teach you what to look for in real life. Videos and Imagery to Assist in the Critical Care …and much more… All medical staff, including doctors, nurses, paramedics, EMTs and support staff will benefit from having this fundamental medical material – while on-the-go or in a medical facility.

What Really Sets Critical Apart

Not only has Critical reached the 15th spot in the Medical category on the App Store (no small feat for a $9.99 app), but Critical has also been reviewed in the blogsphere in medical blogs like the New Nurse Blog and iLadies. Critical has also made appearances in journals like JEM (Journal of Emergency Medicine).

What’s really great about Critical is that the app is helping people for real. Not only that, but Critical is helping people who help us (first responders, EMTs, nurses). This app is making a difference. For example, here is what a medic in Africa had to say about Jadie’s app:

I work as a remote site medic in West Africa and in the 2 days I have had this app I already find myself thinking

“How did I get by without this?!”

I find the material to be accurate, easy to navigate, and suitable for self education in my down time. This easily replaces the 4 (!) other apps I was using before for reference. Thank you to the developers for taking the time to make this app as good as it is!

– Matt The Medic

How Did Jadie Pull This Off?

Critical is a success story financially while being a legitimately beneficial app. Jadie didn’t start off as a software developer but he did have some things working in his favor: a legitimate niche idea that he was an expert in, determination and discipline and he also had some ideas on how to market this application.

Keeping It Legit

Jadie knew the problem he was trying to solve because he had to deal with this problem himself. So, he knew his idea was legit. My own app was similar, I knew about the problem of keeping track of wine notes. The easiest way to keep it legit is to work on a problem that you are familiar with and then to use the app yourself. [Read more…]

Indie App Business and The Secrets Behind Them

Normally, I write and talk about software development skills that you can take to your job, apply to your hobby or put to work in your own business. Mobile app software development is something that will help you in many areas. But, many people that I talk to are interested in the garage startup style so-called indie app businesses that are out there.

What are Indie App Businesses?

This is a tradition that has been with Windows in the Shareware market and Mac with lone wolf software developers who sell their products directly to customers. The term “Indie” means that these developers create, market and support their own software on their own separately from big box traditional software vendors like Microsoft or Inuit.

For many, this is the dream: to have complete control over one Indie product that does well enough to support a family.

Many Indie app businesses are just one person and they do pretty well. For instance, Daniel Jalkut, the well known owner of Red Sweater Software that has the app MarsEdit has been working on this own business since he left Apple. Daniel has been working with his own suite of Mac apps since before the iPhone and iOS dramatically expanded the Mac and iOS universe.

With the advent of the Apple App Store and its cousins over at Android and Windows, we have seen an upsurge of Indie app developers on mobile platforms. Marco Arment of Instapaper, Rubicon Mobile of “Great Big War Game” and F5 Games of “Pocket Heroes” are just a few of the outfits doing this.

Myself, I spent the first two years of my post-job life as an entrepreneur working exclusively on apps and was indeed able to make it work. So, I can say from a lot of different sources that the Indie developer phenomenon is not a myth. What I can say this that being an Indie developer is:

 

  • Exhilarating
  • Extremely Difficult
  • Rewarding
  • Challenging
  • Mind Altering
  • Profitable
  • Freeing *

 

Basically, as the list above suggests being an Indie app developer can pay the bills but it may be more difficult than you think and definitely more difficult than most day jobs. Notice that I put the adjective Freeing with an asterisk because for me that was the real reason I did it – as an Indie developer your free to pursue your own projects, you can manage your own time and basically its easier to be your own person.

Did you notice what’s not in the list above? many people think that going out on your own is “risky”, but yet that didn’t make my list. IMHO this is not risky at all. In reality, if you totally fail as an Indie developer then you may walk away embarrassed (Oh no!). You’ll also walk away with skills to help your run businesses and work as a software developer where people routinely get $150,000 job offers and $200/hour consulting work. That’s my kind of risk…

Ok, let’s move on to talk about the kinds of business models Indie developers seem to pursue. These fall into two categories that I call the Niche App Suite and the Monolithic App.

The Monolithic App

MarsEdit is an example of this – the idea is that you focus all your energy on making the best possible app that targets a very specific problem or niche. MarsEdit is a desktop program for blogging and Daniel spends all his time making MarsEdit the best possible Mac blogging app.

The hope here is that you in fact succeed in actually becoming the best possible app (and maybe pick up an Apple design award while you’re at it) and that customers see this and you become hugely successful. In fact, the hope is that you are so in-tune to your customers, are obscenely responsive and have a parkour-like nimbleness that it becomes impossible for the “big guys” to compete; even though you’re only one person.

Note I realize that the above statement sounds like absolute madness when written down like that. But, that is the mentality of a successful Indie developer.

Your Monolithic App may literally be one app on one platform or it could be a suite of apps across related platforms. For instance, it makes a whole lot of sense to have an iPhone app first and then a iPad and finally Mac version of an app. Having an Android app can’t hurt either.

Here are some things that you are going to need to follow the Monolithic App model:

 

  • Persistence
  • Solid Idea
  • Runway
  • Self-Disciple

 

You’ll probably need more but I want to talk about two in particular: Persistence and Runway. It may be a while before you app is ready to be released to the public and probably a while after that until your app starts to sell. That’s why you’ll need persistence and expect to stick to your app idea for a while without sales while continuing to work on it. Even in the app world, few things are overnight successes and you’ll likely need to actively develop, market and promote your app for a while before you get rewarded or even noticed. [Read more…]

Overcoming the 3 Major Roadblocks to Mastering New Technology

Have you gotten really excited about a new technology, but when you dug into the nuts and bolts lost interest?

Honestly, I can’t tell you how many times this has happened to me and this phenomenon isn’t limited to new software development techniques. The psychologist in me has to ask:

Why is it that stop ourselves from mastering these really cool and lucrative skills?

This is even more frustrating to software developers who’ve learned to program before and *just know* that the new tech is very very similar to what they’ve done before (just different syntax and scope).

I’m not talking about the things out there that are ultimately just a novelty. What I’m talking about are those technologies you know are compelling and will have a direct impact on your career. In my past these included: Javascript, web services, Ruby on Rails, Android and so on. I’m sure you have your own list. Maybe even iOS and Mac development are on your list.

Anyway, I’m assuming that we are talking about a new platform (like iOS) that is very interesting and truly compelling and that you have a very good practical reason to learn. Then, the only explanation that I can muster as to why you are not getting up to speed on something like iOS is that you are experiencing these 3 overwhelming roadblocks:

  • Confusion
  • Disengagement
  • Doubt

All of these things are really just in your head and have very little to do with the reality of learning the new technology. What you really need is a little bit of help to deal with each of these. Here’s some ideas on how to do that.

Overcoming Confusion

If you’re like me, your first instinct when getting up to speed is to look to the blogosphere to see what your peers are doing. Sometimes you will get to your first Hello World app and if you’re lucky, you’ll get a taste of what’s available to you. However, the reality with blogs is this: you either get very specific answers to very specific questions or you get long exposes on novel edge cases. That’s great and all, but when you have no context all this just leads to lots of confusion and disconnected facts.

The problem with this confusion is that it leads to inaction,

because there are so many little bits of disconnected information coming at you that you just don’t know where to start. Of course, if you don’t start with the platform you are not going to be able to move on to master the platform. Honestly, I believe that this initial confusion enough to stop most new developers right in there tracks especially when learning this tech is competing with all the other life demands we have (family, jobs, kids, social life).

To Overcome: use the experience of someone else who’s been through the process and can help you focus of what is important right now. Accept that you won’t learn the entire platform overnight. If you just focus on the subset of information that you need to actually build something using the accepted best practices then you’ll be well on your way. This is the key to get past the roadblock that holds the other 90% back.

Overcoming Disengagement

Let’s assume that you have access to exactly the right type of content which simply lists out all the facts that you need to be a successful developer. Maybe an experienced developer handed you his or her playbook. This, by itself, probably still isn’t enough for you to succeed. [Read more…]