Effective Objective-C 2.0 – Book Giveaway

The winner of the book drawing is Maksim Pavlov.

Congratulations Maksim! Contact me by email to claim your prize.

This week we are giving away a copy Effective Objective-C: 2.0, written by Matt Galloway.

Effective Objective-C covers 52 Objective-C best-coding practices, tips and tricks. In a similar manner to Scott Meyer’s Effective C++, Matt provides background information on a concept (why is it relevant), provides code examples (to illustrate the technique) and ties everything together with good explanations.

I’ve been reading Effective Objective-C over the past few days. The book has good coverage of Objective-C topics that are beyond the basics. It is easy to read and the examples are well written and documented.

When it comes to reading about coding (whether it be a book or blog), I’m all about short examples that lend themselves to a simple copy/paste. Matt’s book follows a similar line of thinking, wherein most all code examples can be used directly without minimal overhead, offering a quick opportunity to try out techniques with minimal fuss.

Here’s a little background on the book in Matt’s words:

I’ve been writing about iOS and Objective-C in general for a while now, having first started on my blog before becoming a tutorial team member over at RayWenderlich. Having gained experience through this, when I was approached by Pearson to write my own book, I decided to take the plunge and go for it. I was extremely excited to get to write in the excellent Effective series and am grateful to Scott Meyers for letting me be part of it.

Effective Objective-C 2.0 is a book that takes you beyond the basics. It goes into more depth than you’ll get from a beginner book. It delves into the internals of important topics such as what a class actually is under the hood, and how the message forwarding system works. If you’re looking to take your Objective-C knowledge further, then I recommend you read this!

I thoroughly enjoyed writing the book and I learned so much from doing the research. I hope that you enjoy reading the book and learn just as much as I did.

Objective-C Questions?

Objective-C question leaving you scratching your head? Good news, Matt will visit iOSDeveloperTips this week and may be able to help.

Enter the Giveaway

Here’s how to enter the giveaway for a copy of Effective Objective-C 2.0:

  • Read the iOS Developer Tips Giveaway Rules.
  • Post a relevant question about Objective-C, share an Objective-C tip or trick, or contribute to an ongoing discussion.
  • The deadline to enter the giveaway will be Friday, 3/7/14 at 12:00PM EST.

The winner be selected sometime on Friday 3/7/14 via random number selection from eligible entries. The winner will be announced here.

Many thanks to Stephane Nakib at Pearson for helping to arrange this giveaway!


  1. Are you using any tools (if so which) for optimizing and refactoring code after completing and/or modifying?
    And are there some continuous integration tools that help in keeping the code sharp at all times, sending notifications on possible optimizations?

    I have not yet used continuous integration and automation so I am curious to know what kind of approach you have used if any.


    • For CI, I thoroughly recommend Jenkins – http://jenkins-ci.org/ . It’s very quick to set up and has excellent plugin support for lots of useful bits, such as HockeyApp.

      As for optimisation and refactoring – well, your best bet is Instruments. Learn it. It’s a fantastic tool. Also the static analyser. Be sure to run it every so often. If you do set up CI, then have it run on every build and submit any warnings to you in an email.

  2. I would recommend using AppCode for refactoring and code inspections. CI with Automation Xcode 5 has added support for it, but we still use Jenkins.

    • What’s the best way to distribute a static library and all their dependencies?

  3. I tried AppCode a while ago and decided it was actually worse than Xcode. I’ve been curious since then – since I am so used to using Xcode, what about AppCode would cause me to want to give it another try? What must-have capabilities does it have?

    • Refactoring, Unused code, TODO’s inspector, optimized imports, unreachable code, etc. their Interface builder replacement is in beta. I prefer Xcode for debugging and AppCode for refactoring.

    • I used AppCode for a while, and realized that I can’t use it as a regular tool and switching between Xcode and AppCode was rather annoying for me. Abhay actually mentioned pros and I’ll review cons:

      – Lack of Interface Builder.
      Yes, it is in beta but doesn’t support Xcode 5 nibs format and nobody knows when it will be available. Xcode 5 greatly improved auto layout support in IB, so I started to use IB more frequently.

      – User interface.
      Xcode has the most pretty interface among other IDEs, and using AppCode after XCode really made my eyes feel uncomfortable.

      – Performance and stability.
      Some tasks take much more time in AppCode, e.g. launching app in a simulator and device; indexing project occur randomly and almost freezes UI, overall while using AppCode I always had a feeling that I use a beta product.

    • I’ve heard lots of good things about AppCode. I haven’t personally used it enough yet to give you informed information about it, but why not just give it a try? I think it’s one of those things that you just need to spend some time with, watch some videos about how to use it, read some tutorials, etc. Then you will know if it’s the right tool for your workflow or not.

    • I like XCTest that was released with Xcode 5. I think it’s great that it’s built in to Xcode and will get Apple’s support going forward.

      There are certainly other frameworks out there and I have used Kiwi in the past. It’s nice. But I fall back to XCTest now. That’s probably mainly because XCTest just comes for free when you create a project in Xcode.

      Your question about what we need to improve is an excellent one. I think there’s not a really good solution yet for automated UI testing. Sure, there are tools, but nothing that really stands out yet. I think this is the area that we need to improve, along with the general attitude toward testing. Open source libraries need to come with more tests, for example.

  4. What’s a memory management “oops” that’s really common in Objective-C? Maybe it’s not a memory leak, but something with objects that just causes excess memory copies that are wasted.

    • Forgetting to `nil` out delegates that are declared as `assign` instead of `weak`.
      Retain cycles with blocks also can still be a pain.

    • I think I’d go with what Samuel says, with retain cycles in blocks. Something like this:

      self.block = ^{
      [self doSomething];

      That’s a retain cycle right there, which is not obvious at first.

      • The way to avoid the retain cycle is usually said to be

        __weak SelfClass *weakSelf = self;

        self.myBlock = ^{
        [weakSelf doSomething];

        however since the pointer to self is weak, self might have deallocated when this block was run. To prevent this, it’s advised to cast weakSelf to a strong pointer in the block.

        __weak SelfClass *weakSelf = self;

        self.myBlock = ^{
        __strong SelfClass *strongSelf = weakSelf;
        [strongSelf doSomething];

  5. AppCode is a *far* better environment in which to navigate code – one area amongst many where Xcode is terribly clumsy.

    Shift the cursor to the next method declaration/definition? How do you even do this in Xcode other than with the mouse or typing in line numbers? In AppCode: ctrl + up / down arrow.

    Jump to related test file? Xcode: multiple keystrokes or clicks to work your way through the nav bar. AppCode: cmd-shift-T

    See all usages of a given symbol? Xcode: again, play with the nav bar at length or mess around in the (terribly-designed) Search Navigator. AppCode: cmd-opt-F7

    AppCode vs Xcode is like this in just about every area: where Xcode is superficially elegant but clumsy and lacking in even many basic capabilities; AppCode is eminently practical.

  6. What’s your opinion on Singletons in obj-c? I use this pattern quite often for my network communication manager class or for Core Data communication manager class, but some argue that it might be dangerous. In my opinion, a singleton done right, with dispatch_once, is thread-safe and there’s nothing dangerous about it.

    • The singleton pattern can be very useful. There’s reasons to use it and reasons not to use it. And also it depends what you mean by “singleton”.

      I’ve heard people say that it’s unsafe because you’re “leaking memory”. Well that’s absurd. If it’s storing data that would otherwise be stored elsewhere, then it’s not leaking anything.

      Others argue that it’s bad because it’s just a glorified global, and “globals are bad”. Well, sure, but where are you going to put the data instead? Maybe you’ll pass it around everywhere, but then you need to ensure something is always holding on to it so that it never dies. So you stick a reference in app delegate or something, because, wait for it, the app delegate is a singleton. Now your object is still a singleton, it’s just harder to get access to it because you have to pass it around everywhere.

      The best argument is that it’s not testable. That’s true to a certain extend. It certainly requires a bit of thought and planning.

      I was talking about this with a colleague the other day. Really it boils down to singleton and global access to the singleton. It is the latter which people take offence to. With global access, singletons can become a dumping ground for functionality required through an application. That’s when they start to break down and become unwieldy and untestable.

      Overall I don’t have a problem with singletons. They can be extremely useful. Just make sure you understand what you’re doing.

  7. What is the singlemost important thing/tip/tweak you would recommend everybody knows/uses when dealing with lots of core data objects? In particular big objects (photos for example).

    In my experience using a NSFetchedResultsController is the normal first step… From there I have seen loads of different approaches to optimizing (optimizing as in application responsiveness and loading times) – does anything spring to mind as a very effective technique… maybe even your go-to solution?

  8. Re testing improvements. Personally I use Expecta matchers and OCMockito within the standard XCTest environment. I’ve tried Kiwi and Specta, but find the deeply nested blocks approach unreadable, too dissimilar from the rest of my code, and lacking in tool support (eg for quickly visualising and navigating code structure).

    But in truth there are plenty of usable testing tools. I think lack of well/commonly-understood Cocoa-idiomatic testing patterns is more of a problem. I know many of us find ourselves abandoning tests for swathes of our codebase largely because of the deep dependencies on Apple frameworks. Both of the obvious approaches to dealing with this (more indirection via adapter classes etc, or lots of mocking) seem to add more complexity than they’re worth. Most publicly-available TDD learning or advocacy materials I’ve seen contain either toy examples which barely reflect testing in real-world situations, or are addressed towards environments less hostile to testing than Cocoa often seems to be.

  9. I note there’s been a recent resurgence of comment about how Apple needs ultimately to replace Objective-C with something more modern (eg http://informalprotocol.com/2014/02/replacing-cocoa/ and http://ashfurrow.com/blog/we-need-to-replace-objective-c).

    I see some sense in this, but OTOH Apple engineers have proven remarkably adept at modernising C and ObjC in-place (GCD, blocks, ARC, object literals, etc). It’s conceivable they might continue with that approach perpetuity.

    @Matt: What do you think?

    • I think Apple will stick with Objective-C for at least the forseeable future. I don’t see why they would switch to something new.

      You’re totally right that Apple have made vast improvements in Obj-C over the recent years. This has been helped by the fact that they now own the entire toolchain including the compiler and debugger. This is brilliant.

      Apple have some very smart people working on Obj-C and I trust that they’ll continue to make improvements.

  10. I’m really new to ios development, and I have a question about what’s the typical or best practice to create development folder hierarchy?

    • I have often used the following approach, for example for an app called MyCoolApp:

      | MyCoolApp.xcodeproj
      | MyCoolApp
      | Controllers
      | Views
      | Models
      | Extensions (<– stuff here like categories on system classes)
      | MyCoolAppTests

      Take a look around at some open source projects as well and get a feel for how they lay their project out.

      • Oh wow that didn’t come out properly! This is what I means:

        ** | MyCoolApp.xcodeproj
        ** | MyCoolApp
        ** ** | Controllers
        ** ** | Views
        ** ** | Models
        ** ** | Extensions (<– stuff here like categories on system classes)
        ** | MyCoolAppTests

  11. What will be the best tool to monitor memory leaking,and also to point out the variables which are utilizing the memory space and in which amount??and the last thing is the tool for finding the complexity of my code..

  12. I’d like to know your best practice for structuring base classes when starting a project (custom uiviewcontroller, custom uitableviewcell). What are the basic functions you like to add that can be useful along the way?

  13. what’s the best way to structure an app? Is it good practice to make a UINavigationController subclass and put all the navigation logic in there?

  14. I’m pretty new to Objective C and was wondering when is best to use delegates versus notifications. They seem like different ways of doing fairly similar things. Is it just a matter of wether your looking at a one-to-one situation (delegate) or a one-to-many situation (notification)?

    • Delegates and notifications are different design patterns used for different situations. When using the model view controller design paradigm, delegates are used for view’s to communicate to their controllers while notifications are used for model’s to communicate with their controllers. There is a good lecture on the stanford iOS course on iTunes University.

  15. Any suggestions on where to start in getting a better understanding on the project and build settings? It is always a frustration for me to get it to do anything out of the ordinary (default).

  16. When setting a block as a property why do we have to use COPY instead of STRONG?

Comments are closed.