Check if a BOOL is set (can't be done with ==nil)

Checking Boolean Values in Objective-C: Beyond == nil

Understand the correct way to check BOOL values in Objective-C and avoid common pitfalls associated with nil comparisons.

In Objective-C, BOOL is a C-style typedef for signed char, not an object. This fundamental difference means that BOOL variables cannot be compared to nil (which is a pointer to NULL). Attempting to do so will lead to incorrect logic and potential bugs, as nil is only relevant for object pointers. This article clarifies why == nil is inappropriate for BOOL and demonstrates the correct methods for evaluating boolean states.

Understanding BOOL vs. Objects and nil

Objective-C's BOOL type is defined as a signed char. By convention, YES is 1 and NO is 0. When you declare a BOOL variable, you are allocating a small piece of memory for a character value, not a pointer to an object. nil, on the other hand, is a macro that expands to (id)0 or (void *)0, representing a null object pointer. Comparing a primitive type like BOOL directly to a pointer value like nil is a type mismatch and will not yield the expected results for checking truthiness or falsiness.

flowchart TD
    A[Start]
    B{Is variable an Objective-C object?}
    C{Is variable a primitive type (e.g., BOOL, int)?}
    D[Use `== nil` or `!= nil`]
    E[Use `== YES`, `== NO`, or implicit boolean evaluation]
    A --> B
    B -->|Yes| D
    B -->|No| C
    C -->|Yes| E
    C -->|No| F[Other data type]
    D --> G[End]
    E --> G
    F --> G

Decision flow for checking variable types and their appropriate comparison methods.

Correct Ways to Check a BOOL

Since BOOL is a primitive type, you should treat it like any other primitive integer type when checking its value. The most straightforward and idiomatic ways are to compare it directly to YES or NO, or to use its implicit boolean evaluation.

BOOL myBoolean = YES;

// Correct way 1: Direct comparison to YES
if (myBoolean == YES) {
    NSLog(@"myBoolean is YES");
}

// Correct way 2: Direct comparison to NO
if (myBoolean == NO) {
    NSLog(@"myBoolean is NO");
}

// Correct way 3: Implicit boolean evaluation (preferred for YES)
if (myBoolean) {
    NSLog(@"myBoolean is true (non-zero)");
}

// Correct way 4: Implicit boolean evaluation (preferred for NO)
if (!myBoolean) {
    NSLog(@"myBoolean is false (zero)");
}

Demonstration of correct BOOL checking methods.

Why == nil Fails for BOOL

When you write if (myBoolean == nil), the compiler will likely issue a warning about comparing a BOOL (a signed char) with a pointer type (void *). Even if it compiles, the comparison myBoolean == nil effectively becomes myBoolean == 0. While this might seem to work for NO (since NO is 0), it's misleading and incorrect practice. It fails to convey the intent of checking a boolean and can lead to confusion, especially if myBoolean were to hold an unexpected non-YES/NO value (though rare, it's possible with direct memory manipulation or type casting).

BOOL myBoolean = NO;

// Incorrect and misleading comparison
if (myBoolean == nil) { // Compiler warning: Comparison of distinct types
    NSLog(@"This might print, but it's bad practice and misleading.");
}

myBoolean = YES;

if (myBoolean == nil) { // This will never print
    NSLog(@"This will not print, as YES is 1, not 0 (nil).");
}

Example of incorrect BOOL comparison with nil.