iOS Development Tips I Would Want If I Was Starting Out Today
January 15, 2013
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.
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 are still times when delegates/protocols or NSNotifications make sense, but blocks should be your first consideration.
Beware Of Retain Cycles With Blocks
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:
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:
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:
- AFNetworking – Block based networking library, so easy to use and so powerful.
- RegexKitLite – Powerful regular expression support
- Facebook iOS SDK – Facebook support
If you Google for a component you need chances are there is one out there to at least get you started.
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.
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).
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.
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
Product -> Analyze can pick up a lot of potential issues (and a lot of red herrings).
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.
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.