As long as the beginners are drifting by, lemme say this:

Every nib you use is a boatload of code you don't have to maintain. Use nibs. Can they solve every problem? Goodness no. But they're a great way to get the basics of your views laid out. They give you an easy way to preview the behavior of your view when layout changes.

And they're very forgiving when you change your mind. Changing text alignment? One click. Want to change the balance or padding of some elements? Nudge them around with a real time preview until you're happy. Mess with different color combinations in your UI to your heart's contentment.

Doing all your view layout in code gets damn tedious when you have to compile and run each time to check your results.

Every now and then some crackpot will come along and tell you never to use nibs. Ignore them. Use nibs when they make sense for your workflow. End sermon.

A surprisingly good list. Beyond the xib issue, which other have talked about, I would add a couple of points:

- If developing a trivial utility app you're expecting to release quickly, target iOS version N-1. Any user who is more that one major iOS version behind won't be the type of user who will download your app (or any app really).

If developing anything more ambitious, target the latest iOS version only and take full advantage its new APIs. By the time you're ready to go mainstream (a few iterations of the app under your belt, nailed your marketing strategy, etc), there will have been at least one new major iOS version released and any time and effort you spent writing code for older iOS versions will have been wasted.

(talking from experience here :)

- Before writing a single line of code, sort out your logging. At the very least, use a handful of macros like [0] to print the class, message name and line number when logging and to exclude debug log statements from release builds. Or check out something like CocoaLumberjack (haven't tried myself yet but writing this made me realize I need to sort out my own logging system so will give it a shot).

[0] http://stackoverflow.com/questions/969130/how-to-print-out-t...

Utilizing storyboards and xibs is one of the best way to decrease development time. Stop the coding madness!!!!

The only people I still know that avoid heavy utilization of these do not understand how to properly use them. Go learn!

Pretty good tips. Re: being aware of retain cycles -- this is not just for blocks but really in general. When you start out you should immediately learn the conventions and adhere to them strictly. (Unfortunately the APIs don't always, I'm looking at you NSURLConnection!)

Another tip: try both Xcode and AppCode: http://www.jetbrains.com/objc/. It's a subjective thing but for myself AppCode is far better (it helps that I also use IDEA for Java, including Android).

I've been programming iOS for a couple of years now and some of those tips where useful to me!

Anyhow as we're contributing top tips, my one is 'Always run your app on target hardware.'

Don't rely on the emulators, especially if your're doing OpenGL work. You will only know your framerate by running your app/game on the real hardware.

The thing I have missed the most with Objective C is the lack of a code tidy/formatting tool. All Xcode can do is alter the indent on each line which isn't useful. Regular indent etc do not support the language. There is an uncrustify tool in various SO answers but it is a good example of how not to do things (eg by default it does nothing - there are no presets, it is very flaky).

I wish Google provided tidy tools with their style guides, or Apple did something with Xcode.

For starters, do go through the iOS development by paul hegarty videos from here, https://itunes.apple.com/gb/itunes-u/ipad-iphone-application...

The 15 hours of video is the best investment of your time if you want to jump start into iOS development.

CocoaPods (http://cocoapods.org/) is a really easy way to integrate 3rd party libraries into your iOS and OSX projects. It follows a similar pattern to bundler for ruby; you just specify a library by name and a version number in your Podfile and CocoaPods handles the rest. Another suggestion is to use categories on Cocoa classes for operations you do often. It cuts down on code duplication and makes your code more readable. One I use in every single project is a category on UIView allowing me to do such things as 'myView.x = 5.f' instead of pulling out the views frame, updating the frame and then setting the frame again. I also agree with the other commenters that IB should be utilized when possible. It makes iterating on UIs much faster, easier and less error prone. +1 for using blocks though, how did we ever get by before?

I wished that when I started out with iOS development, that I knew that to get success on the App Store, 80% is marketing, and 20% is the quality of the app.

If you use ARC from the start, then can you really understand block retain cycles (which are just two bullet items below)?

I would absolutely try to write one or two "Hello World" apps without ARC first. CMIIW but Xcode will highlight any instance where you do things differently than ARC would, there is plenty of feedback on what you are doing. And once you feel confident enough, upgrading the project just takes a few clicks.

And I found ARC to be super easy not in spite, but because I came from C++ :) it is shared_ptr vs weak_ptr all over again. Don't memcpy() them, don't create cyclic references, beware race conditions when testing if a weak_ptr is still there ...

Mostly a really good list. My only nitpick is:

RegexKitLite - Powerful regular expression support

Use NSRegularExpression instead. It's built into the OS (in Foundation) as of iOS 4, which is below the minimum target you have (if you support the iPhone 5).

Thanks - as it happens I'm about 3 months in to learning Objective-c and iOS development. This is super helpful, as many of the tutorials online are dated. Right now I'm working through the Ray Wenderlich stuff which is really good, at least as far as I can tell.

w/r/t using the visual XIB/Storyboard interface vs. coding the views, I've found early on that while the nibs and storyboards make it easy to prototype and visually hook stuff up, looking at some of the apps I admire (apps like Clear, Rise, etc.), makes it pretty clear that I will need to code these views up myself to achieve some of those interactions. Unless I'm missing something (which of course I am, I'm a NOOB) I don't see how most of those can be done right from the nibs.

edit: also, if anyone has any other recommended links/resources, I'd love any recommendations. Thanks.

Good article, I like these because there are a lot of things I wish I knew when I started iOS development as well 'back in the day' :) Couple nits:

-XIBs are awesome and you should strive to use them, falling back to layout in code when the XIB fails to meet your requirements. Though I'm also finding storyboards hard to swallow for complex projects. -Blocks and GCD are great tools but with great power comes a lot of complexity and consideration, they could easily get beginners in trouble. I ain't saying don't use em, but There Be Dragons Here.

Bravo on bringing up Singletons, thats something I only recently discovered and wish I had sooner. Also, I feel like a primer on delegates, protocols, notifications and selectors: when to use what and why, would also go a long way in the beginning.

I would add Crashlytics (http://try.crashlytics.com/) to the list of good crash reporting services.

Thank you. I’m hobby learning iOS development. Have some experience with C, but mostly knowledge of linux, java and devops stuff.

Here are the resources I’m using:

Started with: https://developer.apple.com/library/ios/#referencelibrary/Ge...

Then, plan to get a feel of the language will read http://developer.apple.com/library/mac/#documentation/Cocoa/...

Then I was thinking to go watch https://itunes.apple.com/il/course/coding-together-apps-for-...

Also, a book that seems good to read https://www.bignerdranch.com/book/ios_programming_the_big_ne...

Other suggestions and insights are appreciated.

  Otherwise you can just use git submodules.

I would recommend against it. They become a real pain down the road.

I wish I had something to suggest as a replacement. We're still trying to figure that one out ourselves. We just know we won't use submodules again. For now, we're manually managing disjoint repositories.

My tip for beginners would be that while ARC is great if you use KVO you need to make sure that you consider the object lifecycles and remember to remove observers before they are deleted otherwise you risk occasional crashes in strange places.

Can someone explain to me why I should use dispatch_once at all when a simple check whether the static variable is nil would suffice? It always seems so cluttered.

Compare this:

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

...to this:

  + (MyClass *)sharedClass {
      static MyClass *_shared = nil;
      if (!_shared)
          _shared = [[MyClass alloc] init];
      return _shared;
  }

Is there any difference regarding performance?

I would highly recommend downloading and installing DCIntrospect[0]. It's designed to let you tweak layout in the simulator, but what it's really useful for is probing the UI in large, complex apps. Need to tweak the font size on a specific element, but you have no idea what that view class is? Enable DCIntrospect, click on the element, log its class name and properties. This has saved me, literally, hundreds of hours of debugging time over the years.

[0] https://github.com/domesticcatsoftware/DCIntrospect

I've gotten bit a lot by putting a gesture recognizer on an UIImageView and forgetting to set the image view's userInteractionEnabled property to true.

Good tips. Though I might say that for many tasks NSOperationQueue can be even easier/simpler for someone just starting out than GCD.

Here's a quick tip: you can also disable arc for older libraries should you need to integrate them into your ARC project.

Just use the -fno-objc-arc flag (http://stackoverflow.com/questions/6646052/how-can-i-disable...)

Good list. There is some more great tips at http://stackoverflow.com/questions/155964/what-are-best-prac... .

Thanks for writing this, we're a bit beyond this stage but it certainly reiterates a lot of our learnings. Good to validate that i'm not insane or the only one feeling some of those pain points.

Nice comment about ARC.

I think we need a few programmer generations until everyone is fine with some form of automatic memory management in all programming languages.

I started out using XIBs, but also found myself moving a lot of my controllers away from them as soon as things got non-trivial. The biggest problem I found was weak layout support, so if you had a lot of dynamic content in a screen, it was easier to make a flexible layout in code.

I also agree that the lack of "diffability" for XIBs, despite them being XML, is a pain.

Maybe I was missing something, but my experience matches the OP.

Agreed. If iOS actually had a sane declarative language like Android's xml layouts then I'd do everything in code but since layouts coded in Obj-C are excruciatingly painful to read and edit you're better off with a WYSIWYG tool, even if (IMO) WYSIWYG is fundamentally the wrong approach for UI development.

I actually consider this a big liability for Apple going forward. The explosion of "phablets" and other form factors spells the end of their pixel-perfect design approach and their tools and APIs for managing dynamic, variable layouts are stone age compared to Android's.

Totally agree. It's well worth working closely with your designer to make your interface work with nibs, not against them. Little things like putting button icons on the left side of the button and putting a 20px gutter between elements add up fast.

As someone with experience in several RAD tools, I never understood the design UI in code mentality.

Sure, you can control all your code, but there is so much time that is lost until the UI is finally ready, and than the marketing department wants it redone in one day.

How do I set up view containment in iOS5 with Storyboards so I can have multiple segues in a dashboard view? This is something that I was just looking into last night.