High Dynamic Range (or “HDR”) brings a little professional technique to your iOS 7 photos by taking three exposures with one snap: normal, over, and under. The software then combines these three captures into one optimized photo.

In my experience, HDR-optimized photos in iOS 7 take up an average of .8 megabytes more than their normal counterparts. This doesn’t matter for most of us, though if you have a 16GB device and are trigger-happy with the camera, your space will diminish quicker.

You may turn this feature on and off within the camera app by simply tapping “*HDD On/Off*” at the top of the screen. You may also choose (*in Settings > Photos & Camera*) to keep the “normal photo” for every HDR shot you take, effectively having a black sheep twin photo to all your pretty optimized ones.

Some users have complained of their devices “defaulting” to HDR being off upon closing the app and re-opening it sometime later. I’ve discovered that making sure the aforementioned “*keep normal photo*” feature is off in your settings will keep the HDR setting exactly as you left it (either on or off) next time you open your app.

Give it a shot sometime (sorry for the standard issue pun) and compare the enhanced photo to a normal one to see the difference yourself. Any little thing helps with phone cameras!

A small amount of customers have been complaining about some strange behavior coming from their LED cinema displays recently. This issue coincided with upgrading the Mac being used with the display to OS X 10.9. When the display is connected, both the Mac and the display output flickering video, sometimes coupled with noisy images and graphic distortion.

We recently had one of these problematic displays come into our shop, only to realize that the issue was quite a bit simpler of a fix than we had thought. Not knowing at this point that the issue coincided with upgrading to Mavericks, we immediately assumed hardware when the issue was easily replicated on an in-house test machine.

We’ve learned over the years that with an odd issue like this, it’s always best to check around on some Apple blogs and forums for other user experiences and maybe even a solution. We were successful in finding a very simple solution for this issue, which was a SMC reset of the computer. This is a very user-friendly hardware reset performed by holding a group of keys down.

An SMC reset can also resolve certain power issues (like no power at all). To perform an SMC reset on a *portable* Mac, observe the following steps:

# Turn off the machine and unplug all peripherals except the power adapter
# Hold down *Control + Option + Shift + the power button* simultaneously for a few seconds and release

That’s it — you’re done! On a *desktop,* the reset is even easier:

# Unplug your machine for 10 seconds
# Plug it back in, wait five seconds, and power it back on

“*Learn more about SMC resets.*”:http://support.apple.com/kb/ht3964

Like many things in iOS development (and all software development really), there’s the right way to do something, and then there are dozens of articles and forum posts describing various wrong ways to do it.

One I ran into recently was application-wide constants. The top voted answers on stack overflow seemed to be a bit odd looking to me. They usually advocated using some kind of @#define@ to create constants. Further digging revealed what appears to be the safer, more robust and better way to do constants.

To preface this, I’ll say that this is useful for application-wide constants only. If you have a single class with constants, this probably won’t help other than to demonstrate the syntax for constants. This method is definitely the easiest and fastest way to get your constants created and accessible everywhere in your app.

First, you’ll need to create a *AppConstants.h* file and its corresponding *AppConstants.m* file. Next, in the interface, you should add an @extern const @. For example, I could say @extern NSString* const APP_IDENTIFIER@. Now I have a string constant allocated for use. The “extern” allows us to declare this constant here in the interface. Next, we need to initialize or define our constant with the constant value. This is done in the corresponding *AppConstants.m* file. For this example, it would look like @NSString* const APP_IDENTIFIER=@”HELLO_WORLD”@.

Now if you try to start using this constant in your classes, you’ll quickly find it doesn’t work. We need to let the application know about our AppConstants class. The best way to do this is to import it in the prefix header. This file is automatically generated for you and should be found in the supporting files folder. It will have a suffix of *Prefix.pch*. In that file, inside the @#ifdef __OBJC__@, simply #import your *AppConstants.h* file.

You may need to clean the build before Xcode notices the new constant, but after that, you are able to use that constant anywhere in your application.

One of the advantages of this method over something like @#define@ and other methods is that you can actually compare your NSString constant to a string literal directly using == (good job compiler!). This will obviously be much faster than @:isEqualToString@. Xcode will warn about this, and I would personally try to avoid it, but it does work.

As almost always, spending the time looking something up and understanding before using it helps to create a better and more robust product.