Additionally, iOS 5 introduces a new compile-time memory management feature known as Automatic Reference Counting (ARC) (opens in a new window) . The abridged version is you will never need to type retain or release again, which dramatically simplifies the development process while reducing crashes and memory leaks. The compiler has a complete understanding of your objects, and releases each object the instant it is no longer used, so apps execute much faster, with predictable, smooth performance. However, it’ll take the community some time to refactor various open source libraries to support ARC. Therefore, we have a much larger need today than ever before to move these source files into static libraries that are compiled with ARC disabled so we can compile our primary applications with ARC enabled.

Alternatively, if you are including files that don’t yet support ARC in a project that is ARC enabled, you can set the -fno-objc-arc compiler flag for each of these files. To do this in Xcode, go to your active target and select the “Build Phases” tab. In the “Compiler Flags” column, set -fno-objc-arc for each of the source files. Of course, this can be a very laborious process.

Apple defines a framework (opens in a new window) as a bundle (a structured directory) that contains a dynamic shared library along with associated resources, such as nib files, image files, and header files. When you develop an application, your project links to one or more frameworks. For example, iOS application projects link by default to the Foundation, UIKit, and Core Graphics frameworks. Your code accesses the capabilities of a framework through the application programming interface (API), which is published by the framework through its header files. Because the library is dynamically shared, multiple applications can access the framework code and resources simultaneously. The system loads the code and resources of a framework into memory, as needed, and shares the one copy of a resource among all applications. A universal (or multi-architecture) file is nothing more than an application bundle.

As I mentioned above, iOS does not support dynamic shared libraries but using lipo (opens in a new window) (a tool which comes with iOS SDK (opens in a new window) ) we are able to merge several static libraries into a single static library. By using lipo, we are able to create a static library that supports all architectures (armv6, armv7, and i386) packaged as a universal framework. Here’s how.

Within Xcode, either create a new iOS project or open an existing iOS project. If you do decide to create a new project then feel free to choose any application template you prefer. Which one you choose is irrelevant. Add a “Cocoa Bundle” target (not Cocoa Touch Bundle). Select the newly created bundle target in the left navigation panel, select the “Build Settings” tab and modify the following settings (opens in a new window) as required:

• Architectures (ARCHS): Standard (armv6 armv7 armv7s). In Xcode 4.2, use the value of $(ARCHS_STANDARD_32_BIT). If you wish to compile for older devices then add a new line with a value of armv6. Please see this (opens in a new window) Apple Developer forum post for more details.
• Base SDK (SDKROOT). Latest iOS (iOS X.X).
• Build Active Architecture Only (ONLY_ACTIVE_ARCH). No. This allows us to compile for armv6 and armv7.
• Valid Architecture (VALID_ARCHS): Standard (armv6 armv7 armv7s). In Xcode 4.2 and greater, use the value of $(ARCHS_STANDARD_32_BIT). If you wish to compile for older devices then add a new line with a value of armv6.
• Dead Code Stripping (DEAD_CODE_STRIPPING): No
• Link With Standard Libraries (LINK_WITH_STANDARD_LIBRARIES): No
• Mach-O Type (MACH_O_TYPE): Relocatable Object File. This is the most important change. Here, we instruct the compiler to treat the Bundle as a relocatable file, by doing this, we can turn it into a framework with the wrapper setting.
• Wrapper Extension (WRAPPER_EXTENSION). framework. Here we change the Bundle to a Framework. To Xcode, frameworks is just a folder with the extension .framework, which has inside one or more compiled binary sources, resources and some folders, a folder, usually called Headers, contains all the public headers.
• Generate Debug Symbols (GCC_GENERATE_DEBUGGING_SYMBOLS): No.
• Generate Position-Dependent Code (GCC_DYNAMIC_NO_PIC): No
• Targeted Device Family (TARGETED_DEVICE_FAMILY). iPhone/iPad.

Here are the steps…

• With the bundle target still in focus, select the “Info” tab and ensure the “Bundle OS Type code” is equal to FMWK.
• Add any source code and resources to the bundle. With the bundle target selected, click the “Build Phase” tab. At the bottom, press the “Add Phase” button and then “Add Copy Headers“.
• Open the newly created “Copy Headers” section and separate your public headers from private or project headers.
• Open the “Compile Source” section and add any .m, .c, .mm, .cpp and any other compilable source file. If your framework contains any non-compilable files such as images, sounds, and other resources, you can add them to the “Copy Bundle Resources” section.

You can access any non-compilable resources by using NSBundle.

[[NSBundle mainBundle] pathForResource:@"MyFramework.framework/Resources/FileName" ofType:@"fileExtension"];

Next we’ll create a new Aggregate Target. As mentioned earlier, to join both architectures products into one, we must to use lipo.

• Add a new target by pressing the “Add Target” button.
• Under the Cocoa Touch section, select the “Other” subcategory and then choose the “Aggregate” target. The “Product Name” is arbitrary.
• Add a new “Run Script” phase under this newly created target. Copy and paste the following script into the “Run Script” phase.

# The framework name and version
X_FRAMEWORK_NAME=CoreFramework
X_FRAMEWORK_VERSION=A

# This folder contains the final output of the framework.
X_INSTALL_DIR=${SRCROOT}/Products/${X_FRAMEWORK_NAME}.framework

# This working directory will be deleted after completion.
X_WORKING_DIR=build
X_DEVICE_DIR=${X_WORKING_DIR}/${CONFIGURATION}-iphoneos/${X_FRAMEWORK_NAME}.framework
X_SIMULATOR_DIR=${X_WORKING_DIR}/${CONFIGURATION}-iphonesimulator/${X_FRAMEWORK_NAME}.framework

echo "******************************************************"
echo "X_DEVICE_DIR = ${X_DEVICE_DIR}"
echo "X_SIMULATOR_DIR = ${X_SIMULATOR_DIR}"
echo "******************************************************"
echo "SYMROOT = ${SYMROOT}"
echo "OBJROOT = ${OBJROOT}"
echo "PROJECT_DIR = ${PROJECT_DIR}"
echo "CONFIGURATION_BUILD_DIR = ${CONFIGURATION_BUILD_DIR}"
echo "CONFIGURATION = ${CONFIGURATION}"
echo "CONFIGURATION_TEMP_DIR = ${CONFIGURATION_TEMP_DIR}"
echo "DERIVED_FILE_DIR = ${DERIVED_FILE_DIR}"
echo "BUILD_PRODUCTS_DIR = ${BUILT_PRODUCTS_DIR}"
echo "BUILD_DIR = ${BUILD_DIR}"
echo "TARGET_TEMP_DIR = ${TARGET_TEMP_DIR}"
echo "PROJECT_TEMP_DIR = ${PROJECT_TEMP_DIR}"
echo "PRODUCT_NAME = ${PRODUCT_NAME}"
echo "******************************************************"

# Build both simulator and device architectures.
xcodebuild clean
xcodebuild -configuration ${CONFIGURATION} -target "${X_FRAMEWORK_NAME}" -sdk iphoneos -SYMROOT=${SYMROOT} -OBJROOT=${OBJROOT}
xcodebuild -configuration ${CONFIGURATION} -target "${X_FRAMEWORK_NAME}" -sdk iphonesimulator -SYMROOT=${SYMROOT} -OBJROOT=${OBJROOT}

# Clean the oldest.
if [ -d "${X_INSTALL_DIR}" ]
then
rm -rf "${X_INSTALL_DIR}"
fi

# Recreate the folder structure for the final product binaries.
mkdir -p "${X_INSTALL_DIR}"
mkdir -p "${X_INSTALL_DIR}/Versions"
mkdir -p "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}"
mkdir -p "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources"
mkdir -p "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Headers"

# Create the required symbolic links. Please note the paths MUST relative, 
# otherwise the symbolic links will be invalid when the folder is copied/moved.
ln -s "${X_FRAMEWORK_VERSION}" "${X_INSTALL_DIR}/Versions/Current"
ln -s "Versions/Current/Headers" "${X_INSTALL_DIR}/Headers"
ln -s "Versions/Current/Resources" "${X_INSTALL_DIR}/Resources"
ln -s "Versions/Current/${X_FRAMEWORK_NAME}" "${X_INSTALL_DIR}/${X_FRAMEWORK_NAME}"

# Copy the headers and resources files to the final product folder.
cp -R "${X_DEVICE_DIR}/Headers/" "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Headers/"
cp -R "${X_DEVICE_DIR}/" "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources/"

# Remove artifacts from the resources folder.
rm -r "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources/Headers" "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/Resources/${X_FRAMEWORK_NAME}"

# Use lipo to merge both binary files (i386 + armv6/armv7) into one universal files.
lipo -create "${X_DEVICE_DIR}/${X_FRAMEWORK_NAME}" "${X_SIMULATOR_DIR}/${X_FRAMEWORK_NAME}" -output "${X_INSTALL_DIR}/Versions/${X_FRAMEWORK_VERSION}/${X_FRAMEWORK_NAME}"

# Remove the working directory
rm -r "${X_WORKING_DIR}"

You’ll need to modify the first non-comment line in the script to be equal to the product name of your framework bundle target.

Now build the Aggregate target. It does not matter which architecture you select to build (iOS Device or Simulator) since the script creates a working folder, compiles the framework target twice (once for the iOS device and once for the iOS Simulator) and generates the output to a folder named “Products” located in the $(SRCROOT) root folder

If you previously upgraded from Xcode 3.x to 4.2, then your existing (SYMROOT) value will very likely cause the above script to fail. The failure is caused because the script expects your (SYMROOT) value to be set to the new Xcode 4 value of “build”, which refers to a relative path to $(SRCROOT). Unfortunately, you are not able to modify this setting in Xcode 4 due to an already reported bug. To work around this bug, close Xcode and simply delete the existing SYMROOT key and value from your com.apple.dt.Xcode.plist file, which is located in ~/Library/Preferences/.

Isn’t it about time for the WWDC to be here again?

I suggest reading Apple’s Thread Programming Guide (opens in a new window) as a prerequisite, which also covers some of the basic concepts behind Blocks and Grand Central Dispatch (GCD) (opens in a new window) .

Singletons

For purposes of this discussion, a singleton is a class that only allows a single instance of itself to be created within an operating system process.

Apple’s documentation (opens in a new window) on creating a singleton recommends a pattern that works for most iOS applications but is not thread-safe. Beginning with iOS 2.0 and prior to iOS 4.1, one of the most widely used methods to introduce a thread-safe singleton was through the use of the @synchronized (opens in a new window) directive.

+ (MyClass*) instance {
    static MyClass *gInstance = nil;
    @synchronized(self) {
        if(nil == gInstance) {
            gInstance = [[MyClass alloc] init];
        }
    }
    return (gInstance);
}

There are a few inefficiencies with this approach because not only generates a recursive mutex lock but also introduces an exception handler. Specifically, Apple’s documentation indicates that as a precautionary measure, the @synchronized block implicitly adds an exception handler to the protected code. This handler automatically releases the mutex in the event that an exception is thrown. This means that in order to use the @synchronized directive, you must also enable Objective-C exception handling in your code. If you do not want the additional overhead caused by the implicit exception handler, you should consider using the lock classes.

At the time of this writing, the @synchronized directive turns into this basic pseudo-code:

id _eval_once = ;
objc_sync_enter( _eval_once );
@try {
    /* code goes here */
}
@finally {
    objc_sync_exit( _eval_once );
}

For implementation details see: http://www.opensource.apple.com/source/objc4/objc4-437.1/runtime/objc-sync.m (opens in a new window)

Much of Apple’s sample code prior to iOS 4.0 use this approach. There is a technically more efficient and lock-free approach for applications that target operating systems earlier than Mac OS X version 10.5 or iOS 4.0.

+ (MyClass*) gInstance {
    static void * volatile gInstance = nil;
    while (!gInstance) {
        MyClass *temp = [MyClass [alloc] init];
        if(!OSAtomicCompareAndSwapPtrBarrier(0x0, temp, &gInstance)) {
            [temp release];
        }
    }
    return (gInstance);
}

You can read more about preferred versions of the atomic and synchronization operations here (opens in a new window) .

For applications that target operating systems equal to or greater than Mac OS X 10.6 or iOS 4.0, the recommended singleton pattern uses dispatch_once, which relies on components of Grand Central Dispatch (GCD).

+ (MyClass *) instance {
    static MyClass* gInstance = nil;
    static dispatch_once_t pred;
 
    dispatch_once(&pred, ^{
        gInstance = [[MyClass alloc] init];
    });
    return (gInstance);
}

It should go without saying but I’ll do so for completeness. All instance-level methods of classes that implement a singleton pattern MUST (opens in a new window) be thread-safe.

NSCache

I suspect this class remains relatively unused by most iOS developers. NSCache (opens in a new window) is essentially a container that it stores key-value pairs but unfortunately does so without an O(1) time complexity (like that of NSMutableDictionary (opens in a new window) ) but does automatically evicts objects from its store when the ‘cost’ (a heuristic that of course involves memory pressure) of the cache rises above a configurable threshold.

Per Apple’s documentation, NSCache objects differ from other mutable collections in a few ways:

• The NSCache class incorporates various auto-removal policies, which ensure that it does not use too much of the system’s memory. The system automatically carries out these policies if memory is needed by other applications. When invoked, these policies remove some items from the cache, minimizing its memory footprint.
• You can add, remove, and query items in the cache from different threads without having to lock the cache yourself.
• Retrieving something from an NSCache object returns an autoreleased result.
• Unlike an NSMutableDictionary object, a cache does not copy the key objects that are put into it.These features are necessary for the NSCache class, as the cache may decide to automatically mutate itself asynchronously behind the scenes if it is called to free up memory.

Though not required, NSCache works in conjunction with objects that implement the NSDiscardableContent (opens in a new window) protocol in that the discardContentIfPossible (opens in a new window) method is called when an object is removed.

The two most widely used caching strategies are proactive and reactive loading.

1. Proactive Cache Loading. A proactive cache loading strategy attempts to retrieve all required state when a process or application starts and cache it for the lifetime of the process or application. A decision to use a proactive cache loading strategy is generally done so in conjunction with either asynchronous pull loading based on expected not actual usage of the information being cached or notification-based loading whereby an application’s services are notified when cached state changes.
2. Reactive Cache Loading. A reactive cache loading strategy retrieves data as it is requested by the application and caches it for future requests. A decision to use a reactive cache loading strategy is generally done so in conjunction with synchronous pull loading since the pattern is relatively easy to test and implement.

Regardless of the selected caching strategy, determining a cache expiration policy is is key for most applications. There are a plethora of expiration policy patterns but the majority of them fall into the following general categories:

• Time-based. Cached information is invalidated based on relative (sliding window) or absolute time periods.
• Notification-based. Cached information is invalidated based on instructions from a source.
• Counter-based. Cached information is invalidated based on a reference counts.

Regardless of the expiration policy, scavenging based on memory pressure and other heuristics are key to a proper cache design and symmetry of that design is a key component in any distributed algorithm.

For most applications, a reactive cache loading strategy with a synchronous pull model is the most appropriate option. NSCache does evict objects based on memory pressure and so I strongly recommend you implement the NSDiscardableContent protocol for any objects you plan to store in NSCache. NSDiscardableContent is a simple counter-based pattern. For information stored in NSCache that represents NSData objects, Apple provides the NSPurgeableData (opens in a new window) class. NSPurgeable data inherits from NSMutableData and is available in iOS 4.0 and Mac OS X 10.6 and later. A description of how to use this class can be found be reading Caching and Purgeable Memory (opens in a new window) .

I’d like to make one last point. Please be careful not to over-engineer your caching strategy but be elegant about your design.

Here are a few very interesting statistics at the time of this writing:

• There are over 225 million iOS devices worldwide.
• Apple represents a 48% share of the tablet and mobile market.
• 25 million iPads have been sold to date.
• There are 425,000 applications in the App Store with 90,000 of those applications specifically designed to run on the iPad.
• The App Store has enjoyed over 14 billion downloads
• Apple has 225 million credit card accounts.
• Apple has shipped 54 million Macs and growing, which is a 28% growth over last year. To contrast this, PC growth is at a negative 1% growth over the same year.
• 73% of the Macs shipped today are notebooks

These statistics are astounding. I am of course not at liberty to discuss any information not made public by Apple regarding the upcoming technologies but it is sufficed to say Mac OS X Lion + iCloud (opens in a new window) + iOS 5 (opens in a new window) represents another leap in market share for Apple and a set of very useful features for consumers.