Show Categories & Top Posts

release

Xcode’s “Analyzer” is normally a great way to determine where most memory leaks will occur in your project without actually running it. If you follow Apple’s Memory Management Guidelines the Analyzer is pretty accurate. By no means is it a replacement for the Profiler, but offers some quick checks.

This is an email sent to our clients on launch of the New iPad today Team, You may have heard that a “New iPad” (that’s the name) was released overnight. This will impact clients with native iPad apps. The major differences are: 1. High resolution screen with 4 times more pixels than the iPad 2. This means

When using delegates in an object in Objective-C it is important that the delegate is only assigned within your object, and never retained. The reason for this is to prevent a retain loop, where two objects retain each other; they will never be released. The fix is simple, but can catch you off guard if you want to create an array or dictionary of delegates (using an NSDictionary or NSArray).

If you have ever needed to store a password or other sensitive data in an iPhone app, you have probably used Keychain Access, Apple’s solution to storing data securely. You have also probably used Apple’s KeychainWrapper class, offering a very easy wrapper to storing info in the keychain.

The KeychainWrapper worked well in debug mode, but when building for release it didn’t seem to be writing objects to the keychain. I was fumbling around with this for hours, going over my own code thinking I had made a mistake somewhere. In the end I figured out what the problem was, in Apple’s code for KeychainWrapper the actual line that executed the commit to the keychain was inside an NSAssert, which is used for development, but as soon as you build for release or distribution every NSAssert is nullified, giving the same effect of commenting out anything on that line, removing the keychain commit code.