Hollance  iPad + iPhone App Development

The other day I received an email with the following question:

“I have this great idea for a game, but I’m new to iOS development and this goes way over my head. So I’m wondering if you could help with the development or know anyone else who can? Of course, we’ll split the profits.”

Since this isn’t the first time I’ve received such a request, I thought I’d put up my answer here.

It’s not easy getting started, that’s for sure. It can take a long time to go from noob to someone who can make quality apps. Also, not everyone is cut out to be a programmer.

Having a great idea is only the beginning, but the money is in the execution. If you don’t know how to execute, then you might need to take another approach to get the app made.

Even if you can pull off the programming part, that is not enough to make your app a success. You also need to get it to the right people, in the right place, at the right time. That also takes certain skills.

Sell your idea to find your team

Here’s what I would do: To find someone to work on this with you (for a part of the profits rather than work-for-hire), you’ll have to convince them of the potential of your idea. The best way to do that is to make a short demo video. Appsterdam’s Mike Lee wrote a good blog post about that.

With that video you can set up a project on Kickstarter or a similar site, that allows you to raise money from small-time investors and at the same time attract attention from developers and even potential customers. With that money you can hire a professional programmer, designer, and anyone else you need.

Let’s say you raise only $5,000. That by itself won’t be enough to pay for the development of the app, but it will serve as a decent down payment for the people you will hire. With some up-front cash and a convincing demo video, professional developers might be more willing to work for profit sharing.

In other words, if you don’t have the programming or design chops to make the app by yourself, you will have to play the role of a producer (like a movie producer) instead of a programmer, and gather a team of people who are willing to work with you.

Most of these people — if they are any good — aren’t interested in working for profit if you’re not also bringing something to the table. Asking someone to work on your project for a share of the (hypothetical) profits is asking them to invest their time and talent into your idea — and by extension, your leadership — at their expense, based on nothing but a promise of a fat payday. You’d better be ready to deliver on that promise!

But what if someone steals my idea?

You’re putting your great idea out there for the world to see in order to attract investors and talent, so what’s to stop others from simply copying it?

Here’s the thing: it is incredibly hard to make a hit game or app. If your idea is something anyone can build in a handful of days that is guaranteed to sell itself without any effort, then keep it to yourself. These are one in a million ideas and chances are yours isn’t one of them.

Your idea will take many months of dedicated effort to turn into something real and many more to find its way to customers. No one will steal it because no one else will care about it as much as you do or is willing to put in that kind of effort.

It’s not the idea that is worth money, it’s the execution of the idea. Most of the hit games on the App Store are not 100% original ideas — for example, Angry Birds and Tiny Wings are both based on other games — just very well executed versions of those existing ideas.

The idea isn’t really yours to keep

Now personally, I believe that you have to let go of the notion that you can “own” an idea. An idea by itself is nothing. That’s why you can’t really “steal” ideas. On the other hard, you can certainly own the execution of the idea, and that is protected by copyright laws and by the fact that’s it’s just a lot of hard work.

The only way you will ever profit from your idea, is to make sure you are the one with the best version of that idea.

If your idea is truly good but you put out a very basic, average implementation of the game that you programmed and designed yourself, chances are that hardly anyone will care about it. But it might inspire some other developer and a few months later some other team makes a lot of money from your idea but done better. You will have blown your opportunity.

So if you want to be the one with the hit app, you need to be the one making the most amazing version of it. And that requires programming help if you’re not a very good programmer, design help if you’re not a good designer, and marketing help if you’re not a very good business person.

So start working on that video!

Illustration by Oscar S.R. / miutopia (from openclipart.org)

Many of my tutorials (and real apps) have code in AppDelegate.m that looks like this:

- (BOOL)application:(UIApplication *)application
    didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    DataModel *dataModel = [[DataModel alloc] init];
    self.rootViewController.dataModel = dataModel;
    . . .
}

The app delegate creates the data model object and passes it to the root view controller.

The class may be called something different than DataModel, but that’s essentially what it is, the data model for the app. In a Core Data app, this could be an instance of NSManagedObjectContext.

At some point, the root view controller opens another screen, and it passes along the DataModel object to this new view controller:

- (void)tableView:(UITableView *)tableView
    didSelectRowAtIndexPath:(NSIndexPath *)indexPath
{
    SecondViewController *controller = [[SecondViewController alloc]
        initWithNibNamed:@"SecondViewController" bundle:nil];
    . . .
    controller.dataModel = self.dataModel;
    . . .
    [self presentViewController:controller animated:YES completion:nil];
}

Invariably, someone asks: “Why not simply ask the AppDelegate for that data model object?”

They propose code such as this:

// Somewhere in SecondViewController.m:
- (void)someMethodThatNeedsTheDataModel
{
    DataModel *dataModel = ((AppDelegate *)[UIApplication
        sharedApplication].delegate).dataModel;
    . . .
}

That looks a bit ugly, but you can always “work around” that with a macro:

// In your Prefix.pch file:
#define MY_APP_DELEGATE ((AppDelegate *)[UIApplication sharedApplication].delegate)
 
// In SecondViewController.m:
- (void)someMethodThatNeedsTheDataModel
{
    DataModel *dataModel = MY_APP_DELEGATE.dataModel;
    . . .
}

The DataModel object is now a property on the AppDelegate class, and you can “just” ask for it whenever you want. Easy right?

I don’t know who came up with this idea, but it seems widespread, especially among beginners. It’s also a quick fix with harmful consequences.

So what is the difference?

My preferred approach requires you to pass the DataModel object (or objects) from each view controller to the next, or at least to those that need it. That seems like more work, but it has an important advantage: your view controllers only depend on the objects that they directly need.

It is a good object-oriented design principle to limit the dependencies between your objects. The looser your objects are coupled, the better.

This is what the principle looks like in a picture:

However, when all your view controllers depend on the app delegate, the diagram looks like this:

The problem is this: As your app grows, it will have a lot of classes that have many interconnections between them. The greater the number of connections, the harder it is to understand what is going on in your code, and the harder it is to make changes. If you’re not careful, your code will become a big mess — and we all know where bugs love to hide.

By using the app delegate this way, you’re adding even more complexity to the web of connections. Each view controller now has to reach out to AppDelegate to get the data it needs to do its job.

You’re also giving AppDelegate too much to do. Before you know it, it has become this humongous class that is responsible for just about anything in your program.

Passing around objects all the time seems like a chore, but it’s the cleaner design. Consider each view controller in your app an island that can function independently of all the other view controllers, given the data model objects it needs for its calculations.

What should the app delegate do?

The app delegate performs an important function in your app but is not intended to be some magic singleton that holds all your data.

It is the place where you receive notifications that concern the application as a whole: the app is launched, the app is about to go into the background, the app has returned from the background, and so on. You should restrict the role of the app delegate to just handling those notifications.

The app delegate is where your app initializes itself — it creates the window and loads the initial view controller, it creates the data model objects or Core Data store — and then it passes control to that initial view controller. Beyond that, the app delegate should just handle the application-wide notifications and do nothing else.

So if you feel tempted to write,

[UIApplication sharedApplication].delegate

anywhere in your code, then it’s time to rethink your class design.

I’m happy to announce that the latest ebook from my popular iOS Apprentice series is now available.

In this tutorial you’ll build StoreSearch, an app that lets you search the iTunes store for songs, movies, books and software. You’ll learn about making your mobile apps talk to web services, iPad programming, internationalization… and lots more!

You can get the iOS Apprentice at the Ray Wenderlich store.

A year or so ago I wrote a blog post about starting out as a freelance iOS developer. A lot has changed since then. I have no shortage of work and I was able to recently bump up my hourly rate to €150. Because of this, my fiancee and I can afford to take a three-month vacation in Australia soon and I don’t intend to do any work while we’re over there. Of course, I worked hard to make this possible.

If you pay peanuts, you get monkeys

Every day I get inquiries from potential clients, much more work than I could possibly handle. Some of these inquiries are quite unrealistic, but the 150 Euro per hour price tag is quite effective in scaring off the dreamers with a hundred bucks and an idea. (It’s also basic economics: If you can’t keep up with the demand, raise your prices.)

My hourly rate may seem high but one thing I learned over the past year is that I’m a really good developer and that I’m worth it. Asking for big money obviously drives away a lot of potential clients, but the clients that I do get are serious about what they want, their projects are interesting, and they understand what it takes to make a quality product.

As any creative professional can tell you: “The more you pay me, the more you can expect of me, and the harder I will work to make the end result really wonderful.”

Inspired by this excellent rant, I also decided to take on only the really hard projects, the ones that are too hard for other developers. Simple apps are boring — I need challenges that allow me to make the most out of my skills!

How to find work

I received an email today from a fellow freelance developer who found himself in the same spot I was in a year ago:

“I was wondering if you had any more luck finding work via internet resources since your post was written? I figured I’d look around at a couple of the big freelancing sites and see what I can find, but I think it’d be so much better if it was more personal.”

There are two things I did that made all the difference. First off, I started blogging. There’s always a need for good information about any topic in your field, so if you write quality posts you’ll build up a name for yourself and people will come to regard you as an expert.

With a blog full of quality material, you’re no longer some anonymous developer but someone who has already demonstrated his skills. It makes it easier for clients to trust that you can actually deliver.

Putting some of your own code on Github is another way to pull that off. I have created some open source components that people find useful, and that gets my name out there too.

The biggest thing I did, however, was to write for www.raywenderlich.com. That is a popular site with tons of great tutorials and my contributions seem to be appreciated. I also wrote a 750-page ebook called The iOS Apprentice that is sold through Ray’s site, and contributed to the ebook iOS 5 By Tutorials.

A lot of this is hard, unpaid work, but it pays itself back in building up your reputation. I’m probably not as well known in iOS circles as Matt Gemmell or Marco Arment, but I’m working on it.

Not what you know, but who you know

The second thing is to get in touch with other developers. Networking is a great way to get referrals for jobs. Many developers have too much on their plate so they’d be happy to pass on work to other developers they know and trust. Some will also subcontract out certain parts of their projects.

There are many ways to network. You can get in touch with other developers that are local to you through groups such as CocoaHeads and meetings such as NSCoder Night. If no such group exists in your area, you might consider setting one up yourself.

You don’t have to restrict yourself to just meeting iOS developers, of course. Mobile developers, web developers, designers, start-up founders, these are all useful people to get to know.

Face-to-face networking is probably best, but on the internet there are plenty of places to get in touch with other developers as well: forums, blogs, IRC, Facebook, LinkedIn, you name it. Hanging out with your peers has never been easier…

When you distribute images with your app you usually pick the PNG or JPEG format. The advantage of JPEG is that it often compresses better — especially for photos — but unlike PNG it unfortunately does not support transparency.

The transparency in a PNG file comes from the so-called “alpha channel”. For every pixel not only red, green and blue values are stored but also an “alpha” value that determines how transparent that pixel is. A value of 255 means this pixel is fully opaque, 0 is fully transparent, and anything in between will mix the pixel’s RGB values with the underlying color.

This is probably an old trick, but by saving a JPEG image not as one but as two image files you can still have transparent images. The first image is the regular JPEG with as much compression as you can get away with, the second image is the alpha channel. This is a grayscale image with black representing fully transparent, white fully opaque, and gray everything in between.

We can combine these two images at runtime to make the image transparent again. Because of the JPEG compression we lose a little bit of clarity but if you tweak the compression settings you can usually get away with it.

I wrote a simple category on UIImage that lets you do this.

Preparing your images

1) Export your image from Photoshop as a PNG with transparency.

2) Export the image again as a JPEG, using suitable compression settings. The background should have a solid color, typically white or black but any color will do.

3) Save the alpha channel to a separate JPEG or PNG image. I couldn’t find an easy way to do this from Photoshop, but the ImageMagick tool can do it without problems.

If you have ImageMagick installed, open a Terminal and go to the folder that contains the exported PNG image. Then type:

convert -alpha Extract -type optimize -strip -quality 60 +dither \
    Source.png Alpha.jpg

This extracts the alpha channel from the PNG image and saves it as a JPEG file. You can tweak the level of compression with the -quality parameter. If you specify “Alpha.png” instead of “Alpha.jpg”, ImageMagick saves the alpha channel as a grayscale PNG-8 file. You should use whichever one makes the smallest file size.

Combining the images

1) Add the two JPEG images (the non-transparent source image and the alpha channel) to the app.

2) At some point, call the mh_combineWithAlphaImage:backgroundColor: method to combine these two images into a new, transparent, image.

3) Depending on your app you may want to do this only once and then store the transparent image as a PNG in your app’s Caches folder.

That’s it, quite easy.

Some notes

The alpha image does not have to be a JPEG, it can also be a PNG file. If it is a JPEG then it can have different quality/compression settings from the main image.

The current implementation works well but is not as fast as it could be. It also uses more memory than is strictly necessary. I might rewrite this at some point to use the Accelerate framework or Core Image.

Not all images compress better as JPEG. You should use JPEG only where it makes sense.

Check out the source code at Github.

Bird image by Sias van Schalkwyk