iOS 7 marked the biggest user interface change to Apple’s mobile platform since it was introduced back in 2007. The entire UI (and all of Apple’s native apps) was redesigned with a minimum of skeumorphism, with thinner fonts, and with a cleaner “flattened” look for buttons, icons, and tool/navigation/action bars. For applications and frameworks with customized UI, such as the Socialize SDK, a general UI overhaul was needed while still preserving backward compatibility.

Here’s what we did to make the Socialize SDK iOS 7 compliant:

Class Clusters

It’s quite easy to detect what version of iOS an iDevice is running by doing the following:

[[UIDevice currentDevice] systemVersion]

Given that, one obvious solution to creating iOS 7-compatible UI is to test for this every time a UI element is styled. This not-so-elegant solution is typically improved upon in object-oriented languages by creating different implementation variants of the relevant classes — each of which implement a common interface — and having the correct implementation load at runtime.

However, since Objective-C doesn’t have the traditional constructors found in other object-oriented languages, its object creation mechanism necessitates (and makes possible) a different scheme known as class clusters. As we Objective-C developers know, an object is created by calling the alloc method:

+ (id)alloc

This returns a reference to the object created — and it is here that the class cluster paradigm comes into play. Instead of alloc-ing itself, a class can override this method to return an instance of a different class, typically a subclass that overrides the base class’s functionality. In the case of OS version-specific code, this means all UI logic for a given version variant can be in its own implementation, and implementing users don’t need to worry about which version is which — they simply call alloc as they always have, and the correct implementation is automatically returned. This is a pattern already used extensively within iOS — for instance, when creating datatypes such as NSArrays and such. As an example, here’s the logic for the Socialize SDK SZActionBar class:

    if([self class] == [SZActionBar class] &&
       [[UIDevice currentDevice] systemMajorVersion] < 7) {
        return [SZActionBarIOS6 alloc];
    }
    else {
        return [super alloc];
    }
}

In general, classes containing “legacy” (iOS 6.1 and earlier) UI display logic are suffixed in the Socialize iOS SDK by “IOS6″ and are intended for use as part of a class cluster. There’s no need to alloc them directly.

For more information on class clusters and OS versioning, check out this article.

Updated Assets

While standard iOS UIKit controls (such as UISwitches depicted in the screen shots above) display automatically with the iOS 7 look, the Socialize SDK contains quite a few image and user interface XIB files that reflect the older iOS look. These were comprehensively updated; some assets were simplified or removed altogether as appropriate. However, to retain compatibility for implementors referencing these assets, they’ve remained intact; any new assets are suffixed with “ios7″. As an example, here’s what the generic user profile image looks like in the Socialize SDK in iOS 6 versus iOS 7:

As with all previous assets, the iOS 7 assets are available for implementors to use and are typically located in the same directories as their legacy variants.

Available Now!

The Socialize iOS SDK with iOS 7-compliant UI is available in version 3.0.0 and higher. Download it today at getsocialize.com/sdk.

Leave a Reply