Skip to Content

How I got into iOS Development

Posted on 5 mins read

I recently got an email asking how best to get into iOS development - a request for links, tutorials, and so on. Now, I don’t necessarily know how best to get into developing for iOS, but I know I didn’t have a predefined set of links to run through, or even much reading material outside of some upcoming books, which I didn’t really bother with anyway.

tl; dr:

The method I used to get into iOS dev was to build stuff. Constantly.

More Detail

I’m not sure how much C you know, but when I started in Obj-C, I already had a good grasp of C and C++ and many concepts from these two languages map directly into Obj-C (Obj-C is a superset of C). I’d definitely recommend getting a basic grasp of C before jumping into Obj-C. The only book you need on C is called “The C Programming Language” by Brian Kernighan and Dennis Ritchie.

There are lots of projects on Github that you can clone and comb through the source of. Try to pick one that has an active and well regarded community - so you don’t begin studying crap unintentionally. As I was building sync stuff into my apps, I first looked through ObjectiveSync and ObjectiveResource (from Ryan Daigle), though dev seems to have slowed somewhat. Facebook’s three20 library is also worth a look, too. If you look on this page, you’ll find lots of links to really good, interesting projects on Github right now.

If you just want to dive right in to iOS development, then the path I took was:

1. Get the single dev plan

If you want the enterprise plan, then do whatever you see fit. It’s a detail that is of little consequence. The enterprise plan will give you more support requests and provisioning for more developers, but if you’re working alone, then the single plan works just fine.

2. Think of a non-trivial app

I chose to build an app for rock climbers - a universal guidebook, and includes things like synchronisation, mapping, image manipulation and location services. It needs to be ambitious enough for you to think you’re not going to be able to do it.

3. Begin building version 1

This version will be awful, but you’ll learn a lot.

Strip your idea down to a minimum. The first version of Bouldr was read-only, and simply displayed a list of climbs nearby with a detail screen for each entry. It had no sync - it required a connection, no editing and only basic map integration. My code at this point was pretty ropey, but I learned how to put things together, and I could see where I was going wrong when I came back to add additional features.

I didn’t buy any books - the developer resources on Apples site are really good, so long as you actually use them. Additionally, StackOverflow is an amazing source of information - all of the problems you run into will already be covered somewhere on the web, and most likely, there will be a question and answer right there on StackOverflow. I’ve not read any books, so I can’t recommend any.

4. Release

This is important - get your version 1 out. You’ll gather some interest, and have some users you can later get to help you beta test. Note that being able to set up and manage a beta test is not trivial. Once your first version is out, you’ll get feedback.

5. Begin version 2

Don’t leave it at that - dive back into the code and begin adding features that you think are needed. Learn how to use Mixpanel to gather data on what people are actually using. Integrate Hoptoad to get better error reporting. You’ll probably begin to notice how bad the code is in your first version.

This next bit scared me, and took longer than anticipated, but it also taught me a massive amount, and let me improve my codebase:

6. Scrap your first version, and build a new version from scratch

Re-implement all of the functionality, but concentrate on making your code maintainable - don’t add new features. I started building out a test-suite at this point, too.

7. Beta test your next release

Get a beta group together. Gather their UDID’s and send them a beta build. Gather feedback and bug reports, and fix your app up as you need to.

8. Release version 2

It’s important to make sure you’ve covered migrating your data store if you’re using Core Data, and you should test as much as you can to ensure that you’ve not fundamentally broken your app. I’ve submitted a version of the Bouldr app before that contained a crashing bug. Apple won’t necessarily catch problems with your app unless they are obvious. If the upgrade process within your app is complex (migrations, moving data files around, etc…), then it’s vital you test, and test on actual devices.

Keep building out your app and you’ll keep learning. Start new apps, and try implementing individual features as standalone apps to get an understanding of how it works. I built a GPS tracker as a separate app along with a basic line drawing app and image resizing app. These were simple systems I put together just so I could isolate the functionality I was implementing, and build without needing it to fit into any existing design.

Keep building, keep learning, get on StackOverflow and try answering some questions, and you’ll find you pick up the language and SDK with time and effort.