iOS Development Tips I Would Want If I Was Starting Out Today

Making iOS apps is getting easier and easier with each new release of Xcode. However, all the new features and approaches means there are more options to choose from, outdated books and old documentation.

Back in my day it was so much harder - that's is true in many respects, but a much higher level of quality and features is expected now. The bar keeps rising, and that's a very good thing.

If I was starting out with iOS development today these are the things I would hope somebody would tell me.

Use ARC!

ARC is awesome, it removes a lot of the complexity of memory management we had to deal with previously. Although it's valuable to understand memory management, ARC makes life a whole lot easier.

As a (still) recovering C++ developer from many years ago, I fought it for quite a while. Also many popular libraries have gone ARC only, so don't fight it, go with it.

Prefer Blocks Where Possible

Blocks are awesome. They mean you write less code and clearer code.

There is a great tutorial on blocks here.

There are still times when delegates/protocols or NSNotifications make sense, but blocks should be your first consideration.

Beware Of Retain Cycles With Blocks

This can be nasty, rather than go into the details here check out this link.

Forget Threads, Use GCD

"A programmer had a problem, so he used threads, then he had two"

GCD has made life a lot easier, just don't forget to switch back to the main thread before doing anything with the UI:

dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^(void) {
 // Your code
 dispatch_async(dispatch_get_main_queue(), ^(void) {
 // Now you can interact with the UI
 });
});

There is a good explanation of GCD, including making your own queues, here.

Singletons / Shared Objects

Carrying on with GCD, dispatch_once is really useful:

 + (MyClass *)sharedClass {
static MyClass *_shared = nil;
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{
 _shared = [[MyClass alloc] init];
}); 
return _shared;
}

You'll be doing this a bit, especially when you see how costly it is to create things like NSDateFormatter many times.

Story Boards Are Just For Rapid Prototypes

In my opinion they are more pain than they are worth once you move beyond a basic project. Purely my opinion, some people love them. Make your own mind up on this one.

Only Use XIBs For Very Basic Layouts

There is so much you can't do in Interface Builder (IB). Any slightly "non standard" app with custom views move beyond IB's capabilities quickly. Still, I do use .xib's sometimes for the initial basic layouts, but I've read many people don't bother at all.

XIB's can also be a pain with source control and merging, it's much easier to merge code.

Keep Your Project Organised

I've done a bit of Ruby on Rails development and quite like the way they organise a project, so I do something similar in Xcode:

However you do it, try and keep it in some sort of order, it will get out of hand pretty quickly.

Embrace Open Source

There are so many amazing libraries and components available for iOS development. Github is full of great source code that you can just drop into your project, you can also use sites like Cocoa Controls to find components.

Some libraries I use in almost every project include:

If you Google for a component you need chances are there is one out there to at least get you started.

Dependency Management

With all these great open source components you'll need a way to manage them. CocoaPods has done an amazing job at making something similar to Ruby's gems. Otherwise you can just use git submodules.

Learn To Love Stack Overflow

There are a lot of really smart iOS developers on Stack Overflow, and chances are they have solved your current issue. Please search before asking a question, more often than not it has been answered before.

Graceful Degradation

Often you want to use functionality from a new version of iOS, but you also need to support older versions. There are many examples of this, Tweet Sheets in iOS 5, SKStoreProductViewController & UIActivityViewController in iOS 6, there are many examples.

Luckily at run time you can check if the class exists and fall back (or just throw up an unsupported message).

if (NSClassFromString(@"SKStoreProductViewController")) {
// Class is supported, iOS 6+
 SKStoreProductViewController *storeController = [[SKStoreProductViewController alloc] init];
….
}
else {
 // Not iOS 6
}

Custom Fonts

In early iOS versions (pre 3.2) this was a nightmare, so everyone just used Helvetica. Luckily now it's simple!

Here is a quick guide. If you get stuck with the name of the font open up Font Book and look for the PostScript name.

Localize From The Start

Localization is pretty easy to do in Xcode, especially if you avoid xibs. But add localization support from the start of your project, it's a long painful experience to extract them later.

Here is a great guide to localizing an iPhone app.

Track Crashes

Crash logs are a pain, a real pain. Use a service that captures and symbolicates them for you. Two great services are HockeyApp and TestFlight

Analyze

Product -> Analyze can pick up a lot of potential issues (and a lot of red herrings).

Instruments

Product -> Profile builds your code and launches Instruments. Instruments is a collection of invaluable tools to profile your app. First stop should be "Time Profiler" where you can see what is eating the CPU in your app. If you want to get your table view scrolling like butter you will be spending a lot of time in here.

Track Reviews

<shameless self promotion>You'll have bugs, and people will write bad reviews in countries you may never heard of. Get them in your inbox daily with AppBot.</shameless self promotion>

I'm sure I've forgotten a bunch of things and not everyone will agree with everything above. Hopefully it will be useful to at least a few people just starting out in iOS development.