How to Debug iOS Version-Specific Bugs

Here’s the scenario: A bug is reported. But the bug occurs only on the latest version of iOS. On earlier versions, everything’s a-okay. Ack!

Has this happened to you? I’ve dealt with it a couple of times. You can stare at the code as hard as you want, and come up with various theories. But you won’t get far that way. Why? Because on that earlier iOS, everything works. You won’t find any glaring errors just by looking.

So how do you debug iOS-specific problems? What you need is a diagnostic tool. Over on the iPhone Application Development blog, I describe a method that’s helped me crack tough problems. See iOS Version-Specific Bug!

Question: How have you dealt with version-specific bugs? Leave a comment below.

Welcome to This Blog’s New Home!


Welcome to the new home of Quality Coding — I’m glad you made it here!

I plopped down some money to buy a domain (, a hosting service (Dreamhost), and a WordPress theme (Standard Theme). You’ll experience a number of improvements, including:

  • Speed: Pages load quickly. And I mean super-fast!
  • Formatted code: My code fragments are now nicely formatted for easier reading.
  • Comment avatars: Just sign up at Gravatar, and your smiling face will make your comments more fun!
  • Comment threading: Now more than a single level of replies! The threads of conversation will be clearer.
  • Comment subscriptions: No more need to check back manually! Just click the checkbox when you add a comment, and you’ll be notified when anyone adds something new.
  • Easy sharing: Buttons float along the left side of each post. This makes it easy to share a post on Twitter, Facebook, Google+, etc.

I want you to get the most out of the new setup! Here are things you can do to maximize your experience:

Continue reading

Generate Test Scaffolding & Stay Focused

Quickly generate code for either Swift or Objective-C. Code snippets provided for both Xcode and AppCode.

Objective-C Factory Methods: How to Do Them Wrong (and Right)

We all use factory methods, a.k.a. convenience methods. We often write them ourselves. But there’s a wrong way, and a right way, to write a factory method for your Objective-C class. Do it wrong, and you cut off some features of Objective-C. Do it right, and you open yourself up to new object-oriented possibilities.

Big [self alloc] factory

Volkswagen Factory Wolfsburg/Germany by Werner Kunz, used under CC BY-NC-SA 2.0 / Text added to original

Let’s back up and review what we mean by a factory method. This is a convenience method that you invoke on a class to say, “Make me one of your kind.” (Some folks call this a “convenience constructor” which is odd to me, because the underlying mechanics are quite different from Java or C++.)

Factory method: The wrong way

Let’s say we have a simple class:

@interface Foo : NSObject
- (id)init;

To create an autoreleased Foo object, we’d write

Foo *aFoo = [[[Foo alloc] init] autorelease];

But if you do this a lot, it becomes tedious and can clutter your code. So let’s create a factory method.

At this point, it’s tempting to copy and paste into the body of the new method:

+ (Foo *)foo
    return [[[Foo alloc] init] autorelease];

Looks fine. Everything works. So what’s the problem?

Continue reading

How I Switch between Staging and Production URLs

How do you switch your app between a staging URL (for development and testing) and a production URL (for real world use)? I’ve changed my mind about my approach, because one size doesn’t fit all.

In 9 Code Smells of the Preprocessor (and Their Fixes), I originally suggested that instead of using the preprocessor, it would be better to use a plist. Here’s the preprocessor code smell:

static NSString *const fooServiceURL = @"";
static NSString *const fooServiceURL = @"";

I wrote, “Instead of defining these URLs in your code, treat them as resource definitions and place them in a plist, organized by type.”

Continue reading

#imports Gone Wild! How to Tame File Dependencies

Like all C-based languages, Objective-C files usually come in pairs: there’s a header file, and an implementation file. Either can use the #import directive to include other header files. And if you’re not careful, it’s easy to create an explosion of file dependencies. What are the consequences? How do we tame #import dependencies?

#imports (not Girls) Gone Wild

Girls Gone Wild Tech by Thomas Hawk, used under CC BY-NC 2.0 / Altered from original

[This post is part of the Code Smells in Objective-C series.]

File dependencies

Unnecessary #imports in a .m file are a nuisance. Why? Because it forces you to have those other files in your project. This isn’t a big deal when you’re working on a single project, but immediately causes trouble when you start a new project and want to reuse some source files.

But unnecessary #imports in a .h file are even worse: the problem grows exponentially! That’s because a header imports another header, which imports another header, and so on. Think of it as a dependency graph:

Dependency graph

Say A.h imports B.h and C.h. But B.h also imports D.h. So to add A to your project, you have to pull in B, C and D as well. And this graph is about as simple as it comes. If unnecessary #imports aren’t kept pruned away, the dependency graph will get out of hand.

Continue reading

Kent Beck Inspired Video: Oh, the Methods You’ll Compose!


In the spirit of Dr. Seuss, this video begins,

Dr. Seuss's book, "Oh, The Places You'll Go!"

When a coder sits down to start banging out code,
the first thing to start crowding his cognitive load
is whether his program will do what it should.
“Correctness,” he says, “is what makes my code good.”

But it goes on to explain why clean, readable code matters, and ways to get there…

For such a short video, it has a lot of meat. And I love that last sentence! I really should get a copy of the Kent Beck book that inspired it, Implementation Patterns. (Disclosure: This book link is an affiliate link. If you buy anything, I earn a commission, at no extra cost to you.)

Question: What did you think of the video? Leave a comment below.

Objective-C Is Still C (Not Java!)

Do you have your C book?

Do you have your K&R book?

October 2011 saw the passing of giants:

Simplicity. Power.

  • Steve Jobs. You work with his toys everyday.
  • Dennis Ritchie, inventor of the C programming language, co-inventor of Unix. You work with his stuff everyday (but we forget that).
  • John McCarthy, inventor of Lisp. We use the descendants of his invention every day (without realizing it).

By his vested Interweb powers, Tim O’Reilly has declared that October 30 be Dennis Ritchie Day. In his honor, I wanted to write something that’s been bothering me about the way people are learning Objective-C:

Objective-C is still C !

As a programmer, your most fundamental tools are the programming languages you use. If you don’t know the tool, you simply won’t be able to express things with both simplicity and power. And while I’m glad for the sudden interest in Objective-C, I’m troubled that so many people treat it like some kind of bastardized Java. They jump straight into messaging syntax and Foundation classes, while bypassing the powerhouse that’s available to them.

That powerhouse is the C language.

Continue reading

How OCHamcrest’s “hasProperty” Can Make Your Tests Simpler


Whenever test code has repeated patterns, there’s an opportunity to make it more expressive and readable. This can sometimes be done by creating a new OCHamcrest matcher.


Property in Europe by Images Money, used under CC BY 2.0 / Added text to original

OCHamcrest features a great new matcher submitted by Justin Shacklette: hasProperty.

“hasProperty” is something of a misnomer, because it’s not just for properties. Any method, without arguments, that returns an object, is fair game. But I couldn’t think of a better name; I think it communicates well. Let’s take a look at a before-and-after code example.

“hasProperty”: before

A little before-and-after may show you why I’m so excited about this matcher. Here’s a test I wrote before OCHamcrest 1.6:

- (void)testArrayFromURLStringArray
    // given
    NSArray *URLStrings = [NSArray arrayWithObjects:@"one", @"two", nil];

    // when
    NSMutableArray *downloads = [MyDownloader arrayFromURLStringArray:URLStrings];

    // then
    assertThat(downloads, hasCountOf(2));
    MyDownloader *download = [downloads objectAtIndex:0];
    assertThat([download URLString], is(@"one"));
    download = [downloads objectAtIndex:1];
    assertThat([download URLString], is(@"two"));

As you can see, the test creates an array of two strings. It passes this array to the method under test, a convenience method that creates an array of MyDownloader objects. The expectation is that the resulting array will have URLString values matching the original array of strings.

What I don’t like about this test is that the verification has to go through a number of steps:

Continue reading

9 Code Smells of the Preprocessor (and Their Fixes)

With few exceptions, using the C preprocessor is a code smell. C++ programmers have had this beat into them: “Don’t use the preprocessor to do something the language itself provides.” Unfortunately, more than a few Objective-C programmers have yet to get that message.

This post is part of the Code Smells in Objective-C series.

Here’s a handy command to run from Terminal. It examines source files from the current directory down, showing preprocessor use that you should double-check.

find . \( \( -name "*.[chm]" -o -name "*.mm" \) -o -name "*.cpp" \) -print0 | xargs -0 egrep -n '^\w*\#' | egrep -v '(import|pragma|else|endif)'

This command builds in some exceptions. For example, #import directives are vital. #pragma mark can be useful. …But I want to question pretty much everything else! Why does it matter? Because every time you use the preprocessor, what you see isn’t what you compile. And for #define macros used as constants, there are certain pitfalls to avoid — when we could just avoid them altogether.

Here are some common preprocessor idioms, and how to replace them:

  1. #include
  2. Macros
  3. Constants: Numeric constants
  4. Constants: Ascending integer constants
  5. Constants: String constants
  6. Conditional compilation: Commenting out code
  7. Conditional compilation: Switching between experiments
  8. Conditional compilation: Switching between staging and production URLs
  9. Conditional compilation: Supporting multiple projects or platforms

Continue reading

Code Smells in Objective-C

Code smells. I’ve mentioned “code smells” at work, only to discover that my coworkers didn’t know what I meant. It’s basically a diaper-changing metaphor: “If it stinks, change it.”

Code Smells

diaper” by beth darbyshire, used under CC BY-NC-ND 2.0 / added text

“If it stinks, change it.”

A code smell isn’t “awful code that makes you hold your nose.” Rather, it’s a simple indication that something may need to be changed. Quite often, you won’t notice a code smell until someone else describes it. This is what Kent Beck and Martin Fowler did in the Refactoring book: created a list of smells, and what to do about them.

Code Smells Specific to Objective-C

The book’s catalog of code smells relate to good practices of object-oriented programming. I’m going to start a series that is specific to Objective-C code smells. Here’s a tentative list to give you a preview:

  1. 9 Code Smells of the Preprocessor (and Their Fixes)
  2. #imports Gone Wild! How to Tame File Dependencies
  3. 4 Ways Precompiled Headers Cripple Your Code
  4. Is Dot Notation in Objective-C 100% Pure Evil?
    …or maybe not! I switched, see In Which I Embrace Dot Notation…
  5. Objective-C init: Why It’s Helpful to Avoid Messages to self

I think this’ll be interesting, and sometimes even controversial. (Dot notation, anyone?) So be sure to come back — subscribe to keep up with the latest postings!

Other resources:

Question: What common Objective-C practices have you encountered that you might consider code smells? Leave a comment below.