The blog of Matthijs Hollemans, indie app maker and author of The iOS Apprentice

If you still haven’t caught up with all the new APIs in iOS 5 and iOS 6 — which wouldn’t surprise me as these releases added a ton of new stuff — then do yourself a favor and get the books iOS 5 by Tutorials and iOS 6 by Tutorials.

Of course, I’m biased because I co-wrote these books, but if you enjoy reading the tutorials from www.RayWenderlich.com, then you’ll enjoy these books too. It’s the first place I go to when I want to learn a new API.

Both are now available as printed books and they are huge, two volumes each:

If you already bought the PDF version, then you get a discount on the printed books. Sounds like a pretty good deal to me (log in to the private forums for the instructions).

This is a good opportunity to get up-to-date on the latest and greatest that the iOS SDK has to offer — at least until iOS 7.

Grab your copy at the raywenderlich.com online store

About a week ago I signed up for One Game a Month, a challenge to make twelve games in 2013, roughly one per month. I already planned to release five new iPhone and iPad games on App Store in the first half of this year, so adding another seven isn’t such a big deal.

This is a screenshot of the game I made for January, Galaxy Apocalypse:

It’s a pretty simple game where you have to swipe planets into portals of the matching color before those portals run out of power and the whole galaxy explodes. You don’t want that to happen on your watch…

The game took five days to make from scratch to finish. If I had more time I would polish it more and put it on the App Store. In its current shape it’s not a bad game but still a bit below the level of what I think is good enough for the App Store, so I will clean up the source code (it’s quite messy right now) and put it on Github as a programming example.

Update: Here’s the code, github.com/hollance/GalaxyApocalypse

Here is a video of the game in action:

I have to say I like these sorts of challenges. I’ve done similar challenges in the past, such as composing at least one piece of piano music or coming up with at least one app idea each day for 30 days in a row. It’s a lot of work but it also pushes your creativity to higher levels.

When you limit yourself to making a game in a very short time, then by necessity you have to limit the scope of the game. Such constraints can be quite inspirational. How small can you make a game that is still interesting?

One of my most successful games, Ultimate Countdown (now removed from the App Store but coming back later this year in an all-new version), was done in a single weekend as a similar kind of challenge. It ended up being downloaded over 250,000 times, which I found quite impressive back in 2008, even for a free game.

So if you’re into game development — or if making games is something you’ve always dreamed of — then head on over to www.onegameamonth.com and sign up! Make games, not excuses.

Good news! iOS 6.0 was just released and that means I and my co-authors can finally make our latest ebook, iOS 6 by Tutorials, available!

If you want to take advantage of all the new features from iOS 6, such as Auto Layout, Pass Book, UICollectionView, the new Social Framework, and much more… then this is the book for you.

In fact, there is so much to tell that the book ended up being over 1500 pages! That should keep you busy until iOS 7 comes out.

You can get iOS 6 by Tutorials exclusively from RayWenderlich.com.

And there is no better time than now, because we’re running a launch special that gets you a nice discount, especially if you buy it in combination with our previous iOS 5 by Tutorials ebook.

As part of the launch celebration we’re currently giving away a lot of free stuff in the “iOS 6 Feast” at raywenderlich.com, so head on over and see if you can score some!

P.S. I also updated my iOS Apprentice series for Xcode 4.5 and iOS 6. It doesn’t really go into depth on all the new features of iOS 6 — that’s what iOS 6 by Tutorials is for — but it does give you instructions for working with the latest versions of Xcode, so it’s totally up-to-date again.

If you’ve already purchased The iOS Apprentice (thanks!) then you can find the latest downloads in the forums.

Have fun playing with iOS 6! I know that we did when we were writing this book.

When you have two objects A and B, say two view controllers, that you want to make talk to each other, you can choose from the following options:

• NSNotificationCenter. This is anonymous one-to-many communication. Object A posts a notification to the NSNotificationCenter, which then distributes it to any other objects listening for that notification, including Object B. A and B do not have to know anything about each other, so this is a very loose coupling. Maybe a little too loose…

• KVO (Key-Value Observing). One object observes the properties of another. This is a very tight coupling, because Object B is now peeking directly into Object A. The advantage of KVO is that Object A doesn’t have to be aware of this at all, and therefore does not need to send out any notifications — the KVO mechanism takes care of this behind the scenes.

• Direct pointers. Object A has a pointer to Object B and directly sends it messages when something of interest happens. This is the tightest coupling possible because A and B cannot function without each other. In the case of view controllers you generally want to avoid this.

• Delegates. Object B is a delegate of Object A. In this scenario, Object A does not know anything about Object B. It just knows that some object performs the role of its delegate and it will happily send messages to that delegate, but it doesn’t know — or care — that this is Object B. The delegate pattern is often the preferred way to communicate between view controllers, but it takes some work to set up.

• Blocks. Essentially the same approach as delegates, except that Object B now gives Object A one or more blocks (closures) to be executed when certain events take place. There is no formal delegate protocol and the only thing that Object A sees of Object B is the blocks it is given.

That is quite a few possibilities, each with its advantages and disadvantages, and the trick is to pick the one that is best suited for the particular communication problem you’re trying to solve.

In the end, they are all variations on the observer-notifier pattern. And if none fit, you can always write your own version.

Choose your channels

I was playing with another mechanism that I call “channels” that is a mix of NSNotificationCenter, delegates and blocks. Rather than making Objects A and B communicate directly, they do this through an intermediary, the channel:

This is perfectly achievable using NSNotificationCenter (either the global one or a private one for each channel), but I wanted something a bit more lightweight that is simpler to use.

A channel is identified simply by a name, an NSString. If two or more objects use the same channel name, then they are communicating. An object can post a message to the channel and/or listen for messages from other objects.

To listen to a channel you simply do:

[self mh_listenOnChannel:@"MyChannel" block:^(id sender, NSDictionary *dict)
{
    // do something with the dictionary
}];

To post a message to that same channel:

NSDictionary *dictionary = [NSDictionary dictionaryWithObjectsAndKeys:...];
[self mh_post:dictionary toChannel:@"MyChannel"];

Or with the new Objective-C literal syntax:

[self mh_post:@{ @"Success" : @YES } toChannel:@"MyChannel"];

The dictionary contains any data that you wish to send along. For example, a view controller that is closing could set a field that indicates which button the user tapped, Cancel or Save.

And that’s all you have to do to make these two objects communicate. When an object calls mh_post:toChannel:, any blocks that were registered by listeners for that channel will be executed.

There is no need to unregister from a channel (although you can if you want to). The channel only keeps weak references to its listeners, so if a listener gets deallocated the channel will no longer try to send it notifications.

This functionality is implemented as a category on NSObject. You can find the source code at Github.

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)