Showing an image based on the battery level
I think this code is easier to read and should result in significantly less comparisons, as it just compares in every step the lower bound, where as your define macro checks twice each. And note that you are checking also equality. this should result into 


at least 2 checks at cpu level and  
checking equality for floats in nver a good idea, as due to rounding errors they tend to be not equal, even if in pure math they should be (a 1 might be save as 0.99 or 1.001)  
and if you would check integer numbers for being in some range it make sense, to have an equal check just on one bound  like if (a &lt;= higherNum &amp;&amp; b &gt; lowerNum)


my code suggestion

-(NSUInteger)batteryLevel
{
    UIDevice *device = [UIDevice currentDevice];
    float level = device.batteryLevel;
    if(level &gt; .99) return 100;
    if(level &gt; .80) return 90;
    if(level &gt; .64) return 75;
    if(level &gt; .40) return 50;
    if(level &gt; .34) return 30;
    if(level &gt; .14) return 20;
    return 10;
}


-(UIImage *)imageForBatteryLevel
{
    NSUInteger level = [self batteryLevel];
    NSString *imageName;
    if(level &gt; 99){
        imageName = @"battery100fullycharged.png";
    } else {
        imageName = [NSString stringWithFormat:@"battery%d.png", level];
    }
    return [UIImage imageNamed:imageName];
}

- (void)observeValueForKeyPath:(NSString *)keyPath 
                      ofObject:(id)object 
                        change:(NSDictionary *)change 
                       context:(void *)context 
{
    if (KEY_PATH_IF_THEN(@"batteryLevel")) {
        LabelBatteryStatus.text = [NSString stringWithFormat:@"%.0f%%", device.batteryLevel * 100];
        batteryImage.image = [self imageForBatteryLevel];
    }
}




I was taught at university, that in assembler code checking equality is actually done by checking, that the value is neither smaller nor greater, this makes it 2 comparisons. I am not sure, that this is true for every CPU, but let's walk through an example with that. 

Let's assume, the level is down to 2%. with your code, it will go liek this:


is .02 * 100 bigger or equal than 100     and
is .02 * 100 smaller or equal than 100    -> No
is .02 * 100 smaller or equal than 99     and
is .02 * 100 bigger or equal than 81 -> No
is .02 * 100 smaller  or equal than 80 and
is .02 * 100 bigger or equal than 65 -> No
is .02 * 100 smaller  or equal than 64 and
is .02 * 100 bigger or equal than 41 -> No
is .02 * 100 smaller  or equal than 40 and
is .02 * 100 bigger or equal than 35 -> No
is .02 * 100 smaller  or equal than 34 and
is .02 * 100 bigger or equal than 15 -> No
is .02 * 100 smaller  or equal than 14 -> Yes


As you see you have 13 comparisons for smaller or bigger and 13 for equal. that yields in 39 comparisons. Additionally you have 13 times the same floating number multiplication (.02 * 100). And a gap between the boundaries: If the percentage would result in 14.5, no rule would be triggered.

Let's use my rules


is .02 > .99 -> No
is .02 > .80 -> No
is .02 > .64 -> No
is .02 > .40 -> No
is .02 > .34 -> No
is .02 > .14 -> No


=> return 10

As you see, I have maximum 6 comparisons and no floating point multiplication.