Ole Begemann: iOS Development

Checking Code Signing and Sandboxing Status in Code

2012-02-22T17:55:00Z

Update February 23, 2012: I put the code for the category on GitHub and added a corresponding link to the article. I also added a custom prefix to the category methods to avoid possible namespace problems.

The codesign Utility

On the command line, you can use the codesign utility to check whether a Mac app is signed. For example, codesign --display --verbose=4 /Applications/Preview.app will display a whole lot of info about Preview’s code signature:

Executable=/Applications/Preview.app/Contents/MacOS/Preview
Identifier=com.apple.Preview
Format=bundle with Mach-O universal (i386 x86_64)
CodeDirectory v=20100 size=12266 flags=0x0(none) hashes=605+5 location=embedded
Hash type=sha1 size=20
CDHash=c8a47e06c8372dca11ab0bf03f121e1f69638a54
Signature size=4064
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA
Info.plist entries=32
Sealed Resources rules=12 files=172
Internal requirements count=1 size=1144

You can also use codesign to determine whether an app is sandboxed and, if so, list its sandboxing entitlements. The command codesign --display --entitlements - /Applications/Preview.app will display the contents of the entitlements property list that is embedded in the application binary:

Executable=/Applications/Preview.app/Contents/MacOS/Preview
??qq?<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-write</key>
    <true/>
    <key>com.apple.security.device.camera</key>
    <true/>
    <key>com.apple.security.print</key>
    <true/>
    <key>com.apple.security.app-protection</key>
    <true/>
    <key>com.apple.security.camera</key>
    <true/>
    <key>com.apple.security.documents.user-selected.read-write</key>
    <true/>
    <key>com.apple.security.temporary-exception.mach-lookup.global-name</key>
    <array>
        <string>com.apple.systemuiserver.screencapture</string>
    </array>
</dict>
</plist>

Doing it in Code

Can we do the same in code? Yes we can. With a lot of help from my coworkers Jörg Jacobsen (see his work on XPC and Sandboxing for the iMedia framework) and Christian Beer (who pointed me to the source code for the codesign utility), I wrote a category on NSBundle that can tell you for any application bundle:

whether it has a valid code signature,
whether it is sandboxed and
whether it was downloaded from the Mac App Store.

The public interface for the category looks like this and should be self-explanatory:

// NSBundle+OBCodeSigningInfo.h
typedef enum {
    OBCodeSignStateUnsigned = 1,
    OBCodeSignStateSignatureValid,
    OBCodeSignStateSignatureInvalid,
    OBCodeSignStateSignatureNotVerifiable,
    OBCodeSignStateSignatureUnsupported,
    OBCodeSignStateError
} OBCodeSignState;


@interface NSBundle (OBCodeSigningInfo)

- (BOOL)ob_comesFromAppStore;
- (BOOL)ob_isSandboxed;
- (OBCodeSignState)ob_codeSignState;

@end

Code Signing Services

For the implementation, we need to look at the Code Signing Services in the Security framework. The SecStaticCodeCreateWithPath() takes the URL of an app bundle and returns a reference to a so-called static code object that represents the bundle’s code. We can then call the function SecStaticCodeCheckValidityWithErrors() on the static code object to obtain information about its code signature.

Additional Requirements for the Signature (Sandboxing)

To determine whether an app is sandboxed, we can call SecStaticCodeCheckValidityWithErrors() again, this time with the additional code requirement (passed as the third argument to the function) that the code object contains a certain entitlement (which is com.apple.security.app-sandbox in our case). The call to create this requirement looks like this:

static SecRequirementRef sandboxRequirement = NULL;
SecRequirementCreateWithString(CFSTR("entitlement[\"com.apple.security.app-sandbox\"] exists"), kSecCSDefaultFlags, &sandboxRequirement);

Have a look at the documentation for the Code Signing Requirement Language to learn how to formulate other requirements you might have.

Mac App Store Receipt Check

The implementation of the last method, -ob_comesFromAppStore, is rather unrelated. It simply checks whether the bundle contains a Mac App Store receipt. OS X 10.7 has a special method to find the App Store receipt in the bundle: appStoreReceiptURL. If 10.6 compatibility is important for you, you have to hard-code the path to the receipt at Contents/_MASReceipt/receipt.

The Source Code

Check out the full source code of the category below. I use associative references to cache the values of some variables that I use in multiple places, such as the code signature state. Update February 23, 2012: The code is now also available on GitHub.

// NSBundle+OBCodeSigningInfo.m
#import "NSBundle+OBCodeSigningInfo.h"
#import <Security/SecRequirement.h>
#import <objc/runtime.h>


@interface NSBundle (OBCodeSigningInfoPrivateMethods)
- (SecStaticCodeRef)ob_createStaticCode;
- (SecRequirementRef)ob_sandboxRequirement;
@end


@implementation NSBundle (OBCodeSigningInfo)

- (BOOL)ob_comesFromAppStore
{
    // Check existence of Mac App Store receipt
    NSURL *appStoreReceiptURL = [self appStoreReceiptURL];
    NSFileManager *fileManager = [[NSFileManager alloc] init];
    BOOL appStoreReceiptExists = [fileManager fileExistsAtPath:[appStoreReceiptURL path]];
    return appStoreReceiptExists;
}


- (BOOL)ob_isSandboxed
{
    BOOL isSandboxed = NO;
    if ([self ob_codeSignState] == OBCodeSignStateSignatureValid) 
    {
        SecStaticCodeRef staticCode = [self ob_createStaticCode];
        SecRequirementRef sandboxRequirement = [self ob_sandboxRequirement];
        if (staticCode && sandboxRequirement) {
            OSStatus codeCheckResult = SecStaticCodeCheckValidityWithErrors(staticCode, kSecCSBasicValidateOnly, sandboxRequirement, NULL);
            if (codeCheckResult == errSecSuccess) {
                isSandboxed = YES;
            }
            CFRelease(staticCode);
        }
    }
    return isSandboxed;
}


- (OBCodeSignState)ob_codeSignState
{
    // Return cached value if it exists
    static const void *kOBCodeSignStateKey;
    NSNumber *resultStateNumber = objc_getAssociatedObject(self, kOBCodeSignStateKey);
    if (resultStateNumber) {
        return [resultStateNumber integerValue];
    }

    // Determine code sign status
    OBCodeSignState resultState = OBCodeSignStateError;
    SecStaticCodeRef staticCode = [self ob_createStaticCode];
    if (staticCode) 
    {
        OSStatus signatureCheckResult = SecStaticCodeCheckValidityWithErrors(staticCode, kSecCSBasicValidateOnly, NULL, NULL);
        switch (signatureCheckResult) {
            case errSecSuccess: resultState = OBCodeSignStateSignatureValid; break;
            case errSecCSUnsigned: resultState = OBCodeSignStateUnsigned; break;
            case errSecCSSignatureFailed:
            case errSecCSSignatureInvalid:
                resultState = OBCodeSignStateSignatureInvalid;
                break;
            case errSecCSSignatureNotVerifiable: resultState = OBCodeSignStateSignatureNotVerifiable; break;
            case errSecCSSignatureUnsupported: resultState = OBCodeSignStateSignatureUnsupported; break;
            default: resultState = OBCodeSignStateError; break;
        }
        CFRelease(staticCode);
    }
    else
    {
        resultState = OBCodeSignStateError;
    }
    
    // Cache the result
    resultStateNumber = [NSNumber numberWithInteger:resultState];
    objc_setAssociatedObject(self, kOBCodeSignStateKey, resultStateNumber, OBJC_ASSOCIATION_RETAIN);
    
    return resultState;
}


#pragma mark - Private helper methods

- (SecStaticCodeRef)ob_createStaticCode
{
    NSURL *bundleURL = [self bundleURL];
    SecStaticCodeRef staticCode = NULL;
    SecStaticCodeCreateWithPath((__bridge CFURLRef)bundleURL, kSecCSDefaultFlags, &staticCode);
    return staticCode;
}

- (SecRequirementRef)ob_sandboxRequirement
{
    static SecRequirementRef sandboxRequirement = NULL;
    static dispatch_once_t onceToken;
    dispatch_once(&onceToken, ^{
        SecRequirementCreateWithString(CFSTR("entitlement[\"com.apple.security.app-sandbox\"] exists"), kSecCSDefaultFlags, &sandboxRequirement);
    });
    return sandboxRequirement;
}

@end

Passing Data Between View Controllers

2012-02-21T19:10:00Z

A very common pattern on iOS is for one view controller to react to a user action (such as tapping on a button or table cell) by creating and presenting another view controller. In code, this looks something like this:

- (IBAction)nextScreenButtonTapped:(id)sender
{
    DestinationViewController *destinationController = [[DestinationViewController alloc] init];
    [self.navigationController pushViewController:destinationController animated:YES];
}

In all but the simplest cases this code is not sufficient because we usually have to configure the new screen before we present it. The calling view controller (self in this context) has information that needs to be shown on the view that is to be presented by the new view controller. Let’s assume the destination view contains a text field whose text must be set. Since the text field can be accessed via a public property in DestinationViewController, many beginners extend the code in the most straightforward way: just set the text field’s text directly from the source view controller.

- (IBAction)nextScreenButtonTapped:(id)sender
{
    DestinationViewController *destinationController = [[DestinationViewController alloc] init];
    destinationController.nameTextField.text = self.myModel.name;
    [self.navigationController pushViewController:destinationController animated:YES];
}

Don’t Misuse Views For Storing Data

This approach fails because at the time the line destinationController.nameTextField.text = ... is executed, the DestinationViewController’s view has not yet been loaded and therefore the text field (one of the controller’s view’s subviews) does not yet exist. nameTextField will be nil and the line of code above does nothing. Now, the easiest way to fix this is to make sure the view controller’s view gets loaded before the code is executed. You can do this by accessing the view controller’s view property, which automatically will attempt to load the view:

- (IBAction)nextScreenButtonTapped:(id)sender
{
    DestinationViewController *destinationController = [[DestinationViewController alloc] init];
    if (destinationController.view) {
        destinationController.nameTextField.text = self.myModel.name;
    }
    [self.navigationController pushViewController:destinationController animated:YES];
}

Now this works, but you should not do it this way. There are at least three reasons why this piece of code is bad design:

To people who don’t know that accessing the view property implicitly loads the view, this code is very obscure. Why the need for the if (destinationController.view) { ... } statement? The could would require an explanatory comment to make its purpose clear. If you find yourself having to add comments to simple-looking code, it is often a sign of bad design. In my opinion, the vast majority of your code should be able to explain itself without any comments.
It breaks encapsulation. A view controller’s view and all its subviews should only be accessed by the view controller that owns these objects. It is that view controller’s job and sole responsibility to manage its view(s), and no other object should have to interfere in this relationship. Instead, the view controller should offer a clean public interface to allow outside objects to configure it.
You must not use views to store data. In this example, the nameTextField is the only object managed by the view controller that stores the string to be edited. This is an absolute no-go. It is not only bad design in the model-view-controller context but can also potentially lead to data loss. In iOS, view controllers are expected to destroy their views under memory pressure when those views are not currently visible. If this happens to a text field that is the sole storage for an edited model property, data has been lost.

The Solution

The solution for this problem is to declare another public property NSString *name in the DestinationViewController class and assign the data to this property first:

- (IBAction)nextScreenButtonTapped:(id)sender
{
    DestinationViewController *destinationController = [[DestinationViewController alloc] init];
    destinationController.name = self.myModel.name;
    [self.navigationController pushViewController:destinationController animated:YES];
}

Then, in -[DestinationViewController viewDidLoad], we know the view (and with it our text field) has been loaded and we can assign the text to the text field:

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.nameTextField.text = self.name;
}

The view controller must also take care to update its name property whenever the user edits the text in the text field. That way, the name property acts as storage for the user’s data and the view controller remains in a safe state when its view gets unloaded.

Update February 24, 2012: Several people have pointed out to me that there are other ways to pass data to the target view controller that in many cases might even be better. One such method is to define a custom init... method in the target view controller that takes the data the view controller needs as arguments. This makes the purpose of the class even clearer and does avoid possible problems when another object assign a new value to the property when the view is already on screen. In code, this would look like this:

- (IBAction)nextScreenButtonTapped:(id)sender
{
    DestinationViewController *destinationController = [[DestinationViewController alloc] 
        initWithName:self.myModel.name];
    [self.navigationController pushViewController:destinationController animated:YES];
}

And in DestinationViewController.m:

// DestinationViewController.m
- (id)initWithName:(NSString *)theName
{
    self = [super initWithNibName:@"DestinationViewController" bundle:nil];
    if (self) {
        _name = [theName copy];
    }
    return self;
}

- (void)viewDidLoad
{
    [super viewDidLoad];
    self.nameTextField.text = _name;
}

Others proposed to declare a custom datasource protocol that DestinationViewController uses to obtain the data it needs from its data source (usually its parent view controller), much like UITableView works. This is also a good suggestion. It involves a few more lines of code but makes the coupling between the objects even looser.

Finally, several readers asked me why I opted to pass self.myModel.name to the destination view controller instead of passing the entire model object (self.myModel). Both are definitely possible. Which approach is the better one depends on the purpose of the destination view controller in my opinion. If the view controller is designed to display and/or edit all or most of the model object’s attributes, it is definitely better to pass the whole object along. On the other hand, if the view controller is a generic editing controller whose purpose is to edit an arbitrary string, you should just pass this string to it. In this case, the destination view controller should not need to know anything about the model object whose attribute it edits.

Thanks to everybody who sent in their comments.

What iOS Should Learn from Android and Windows 8

2012-02-20T20:05:00Z

Following up on my post about the new Share sheets in Mountain Lion and what they might mean for the future of content sharing in iOS, let’s take a more technical look at how Apple’s competition implements content sharing across apps. In this article, I will first investigate how Android and Windows 8 solve the issue and then hopefully come to a conclusion what Apple could learn and/or adopt from these implementations.

Note that I am no expert on either of the two platforms so my remarks will probably contain some mistakes. I will gladly update the post with any corrections you send me.

Android

Activities

Android displaying a list of apps that can receive the content to be shared.

A typical Android app consists of several so-called Activities. An activity is an app component that provides a single screen¹ in an app and manages how users can interact with this screen. As such, the concept is somewhat comparable to view controllers in iOS.

But there is an important difference: while iOS view controllers are pretty tightly coupled to the app they belong to, activities on Android are more loosely bound to each other. An Android app can not only launch its own activities but also access and launch activities that have been provided by other apps. This way, activities from many different apps can end up on the activity stack. The user can use the device’s back button to navigate back up the stack, thereby implicitly switching from app to app.

Android uses activities to enable sharing between apps. An Android app has a manifest file (an XML config file similar to Apple’s Info.plist) in which it can list all its activities and how they can be activated from other apps.

Intents

The launch of an activity is done with so-called Intents. Intent is just another name for a message data structure that contains an operation to be performed by the system. One of the several possible message types is to start an activity. Activities to be launched can be either named directly (if you want to launch a specific activity in a specific app) or the intent can specify the predefined action ACTION_SEND to indicate that it wants to send data from one activity to another. Based on the data and its type that your app passes to the intent object, the OS will then identify all activities from all apps that can handle this type of data² and present them to the user in a list.

When the user selects the activity/app he wants to use, the system launches the activity and passes it the data contained in the intent object. By default, activities do not report anything back to their caller. A backchannel from the launched to the launching activity can optionally be established by using the startActivityForResult() method, however.

Windows 8

I have chosen to take a look at the Windows 8 APIs rather than Windows Phone 7 here for two reasons. Firstly, Windows Phone 7 has no generic content sharing API. There do exist classes to share links and status messages on selected social networks but the list of sharing services does not seem to be extensible. A feature called “app-to-app communication” (whatever that means) is rumored to be part of Windows Phone 8. Secondly, it seems at least possible (if not probable) that Windows Phone will soon be based on the Windows 8 platform and Microsoft’s new WinRT API will also be relevant for Windows Phone development.

Charms

Windows 8 displaying the Share action in the Charms bar.

In the Windows 8 Metro interface, users can swipe from the screen edge to display the so-called Charms bar, regardless of the app they are currently using. The Charms bar contains buttons for several often-used actions, such as going back to the start screen or accessing the current app’s settings. Other charms include Search (to search for content from your app, other participating apps, or the file system) and Share (to share content from your app with other users, web services, or other apps).

Contracts

Each of those charms is related to and governed by a so-called Contract. The documentation describes contracts as

agreements between Windows and one or more Metro style apps, called contract participants, to support some kind of user interaction. There is a contract for each type of interaction, like playing music from an application to a connected stereo, and the contract specifies the types of capabilities the participant has. For example, Windows lets users share content from one application to another. The application that shares content out supports a source contract by meeting specific requirements while the application that receives the shared content supports a target contract by meeting a different set of requirements. Every application that participates in the sharing contract can be confident that the sharing workflow is completely supported, end-to-end.

Similar to Android, Metro apps must declare the contracts they support. They can do this either by specifying them in the app’s manifest file or even dynamically at runtime. In the current developer preview release, Windows 8 supports five contracts:

Search: to search an app’s locally stored content or have an app control a search query that goes out to the web for searching. For example, a YouTube app could offer YouTube online search through this contract.
Sharing: to share content from your app with another app or web service.
Play To: to play music and video from an app on other connected devices that support the DLNA standard. This looks similar to Apple’s AirPlay.
Settings: to provide access to an app’s settings.
App to App Picking: to let an app directly pick files from another app. This looks like a very elegant solution to the problem that, when all apps are sandboxed, there does not exist a shared folder on the file system that users could use to exchange files between apps. With this contract, a Dropbox client for Windows Metro could offer the user the option to open files that are in the Dropbox directly from within another app, for example.

The Sharing Contract

Let’s have a look at how content sharing works with the Sharing contract. To make this work, the source application must first declare to the OS that it supports the role of acting as a sharing source. The application listens for an event that signifies to the app that the user activated the Share charm. In response to this event, it will then create a DataPackage object that contains the content to be shared. DataPackages are very flexible: they can contain any combination of plain text, URLs, HTML, rich text, images, files or arbitrary binary data. The source application passes the packaged data on to the operating system.

If large amounts of data should be shared, or if the format of the data is not yet determined because it is up to the target application to select one of multiple supported formats, the source application can also set up a sharing delegate that only prepares and packages the data once it has been requested by the target application.³

The OS will now present the user with a list of apps that can handle the shared content. Again, the set of suitable apps is determined by parsing the manifest files of all installed apps. Valid apps are those that support the “Receive Shared Content” contract and have indicated that they can handle the data types the OS is currently dealing with.

When the user selects an app from the list, the OS will activate the target app and pass it the shared DataPackage object. The app is now expected to deal with the shared data. Depending on the size of the data, it has the option to do this synchronously or asynchronously in the background, thereby letting the user return to the source application before the actual processing is complete. The target app is free in its decision whether to display its own UI or not. When the operation is completed, the SDK provides APIs for the target app to report success or failure to the source app.

Learnings for iOS

Comparing the two approaches, Android’s system of intents and activities seems extremely flexible. It cannot only be used for sharing content between apps but also for sharing functionality. For example, a Twitter client on Android can seamlessly launch a web browser activity to display a web page, and the user can always go back to the tweet list by using the device’s back button. For a Twitter app on iOS, launching the browser to read an article would result in a very bad user experience.

Microsoft’s concept of contracts seems to be better suited to iOS’s application model. Rather than directly accessing parts of an app (activities/view controllers), the target application of a sharing charm is launched normally and has to decide upon activation how to react to the sharing operation in process. This is very similar to how iOS deals with push notifications or app launches through a URL scheme.

So far, Apple’s approach to content sharing in iOS seems to be offering piecemeal solutions. Over the years, Apple has gradually added system-defined view controllers for system-defined actions: as of iOS 5, apps can share stuff via e-mail, SMS or Twitter using the built-in view controllers. In addition, apps have write access to the device’s photo library and can sort of share images that way.

We Need a Generic Sharing API

What’s missing is the generic design. Even if we will see FBFacebookShareViewController and IGInstagramSharePhotoViewController in the next iOS release, Apple will never be able (or willing) to support a large enough number of sharing services and apps. And interaction between apps via custom URL schemes as currently implemented in iOS also doesn’t cut it: since a source application would need to know about and implement the URL schemes of all potential target apps, this idea just doesn’t scale to 500,000 apps.

A generic sharing API like the ones described above would solve tons of developer issues at one go. For instance, Instapaper developer Marco Arment has been complaining for a long time that requiring your users to install a bookmarklet in Mobile Safari sucks. If both Safari and the Instapaper app supported the sharing of URLs and/or web page content, this problem would be solved. Similarly, developers of Twitter apps would no longer have to talk to the Instapaper API directly if they could just share a link with the Instapaper app on the device.⁴

My dream feature for iOS 6 is a combination of the share sheets introduced in Mountain Lion (for displaying the available sharing options) and an implementation similar to Windows 8 contracts that allow for both silent (non-invasive, no UI) and more explicit (with a custom UI like the current mail or tweet compose view controllers) content sharing between apps. If you agree, please file an enhancement request with Apple.

Activities are usually presented covering the entire screen but this is not a requirement. An activity can also be displayed in a floating window or embedded inside of another activity. These features will remind iOS developers of popover views on the iPad and container view controllers in iOS 5.↩
Identified by the data’s MIME type. The matching of data types and activities is performed based on the information in every app’s manifest file where the developer can list the data types any of their activities can deal with.↩
OS X uses the same mechanism for drag and drop operations.↩
Especially if the sharing process could optionally be non-interactive so as to make it a one-tap operation. Windows 8 supports the innovative concept of QuickLinks where the target app can return a link that corresponds to the last sharing operation that the OS can then display in the Charms bar.↩

Share Sheets: Only Half Way There

2012-02-17T20:45:00Z

When I read the news about OS X Mountain Lion yesterday, one of the most exciting new features was the concept of Share Sheets, the system-wide component that enables any app to let users easily share content with a number of popular OS and web services.

Not Extensible by Third-Party Apps

At the time, I assumed that this service was completely open to third party apps. Apps should not only be able to show the system-wide sharing UI; they should also be allowed to offer additional sharing services that would then be displayed among the built-in options by any other app that supported share sheets.

This seems to be a sensible idea, after all. Different users have different sharing preferences and while the list of built-in services includes some high-profile sites like Twitter, Flickr and Vimeo, it is hardly complete (not to mention the dozens of new services that spring up every year, like Instagram).

Sadly, according to Nilay Patel’s Mountain Lion preview for The Verge, this is not the case:

There’s an API that lets developers add share buttons to third party apps, but there’s no way to add additional services — a pity, since Facebook and YouTube are notable omissions.

On OS X, this limitation is actually not that big a deal. In fact, OS X makes manual sharing between one app and another or between an app and the web so easy that the whole idea of a system-wide UI component for sharing seems almost superfluous. I can just as quickly copy and paste or drag and drop a URL from the browser to the Twitter app as I can tweet about it using a share sheet.

What I am worried about is what this means for iOS.

A Missed Opportunity for iOS?

On iOS, sharing content between apps is hard. Yes, there is copy and paste but repeatedly switching between apps still takes a lot of effort. And sharing content via URL schemes only works if the sending app explicitly supports the receiving app’s format, which is a problem whose solution just doesn’t scale.

Moreover, iOS could soon be at a major disadvantage compared to its competitors when it comes to sharing content. Both Android (with its existing system of Activities and Intents) and soon Windows (Phone) (with Contracts coming in Windows 8) offer a system-wide solution for apps to interact with each other. Meanwhile, iOS only offers built-in sharing via e-mail, SMS/iMessage and Twitter.

Extensible Share Sheets in iOS 6?

Imagine if Apple not only ported the existing share sheets API to iOS 6 but also added third-party extensibility along the way. Any app, be it from Apple or a third-party developer, could announce via its Info.plist the types of content (text, URLs, photos, videos, etc.) it understands. And every app that had something to share would, when the user taps its share button, ask the OS to display a list of apps that can deal with the current content. The system’s sharing service would automatically launch the app the user selected and ask it to display its special sharing view controller¹.

Any app that implemented share sheets would automatically support any other app that can deal with the same content type. You could send URLs from Safari directly to the Instapaper app, without having to install a bookmarklet. A photo editing app would support uploading to any photo service without having to implement dozens of APIs². You could post your high score from any game to your social network of choice. The possibilities are endless.

I can only hope Apple will still do this for iOS 6. Seeing only part of it in Mountain Lion makes me pessimistic.

Update February 20, 2012: I wrote a follow-up to this article: What iOS Should Learn from Android and Windows 8.

Optionally, an app could perhaps act to share things silently without displaying its own UI. In that case, the sharing service could just call a special block of code in the receiving app’s executable that automatically uploads the content. In such a scenario, sending a URL to Instapaper would be even more seamless.↩
And the companies that run the photo services could concentrate on an app that excels in uploading new content and browsing the existing site rather than investing in photo editing and filtering capabilities that other, specialized apps could do better.↩

Revisiting the App Launch Sequence on iOS

2012-02-09T20:20:00Z

In June 2011, I blogged about the App Launch Sequence on iOS for the first time, illustrating what really happens under the hood between the launch of an iOS app and the application:didFinishLaunchingWithOptions: method.

Since that time, Apple has revised the default launch sequence in their iOS app project templates, so it is time for an update to the original post.

Flowchart

Flowchart of the default app launch sequence in iOS as of Xcode 4.2 for a non-storyboarded app. Feel free to share this image under a Creative Commons Attribution license (CC-BY). In a storyboarded app, UIApplicationMain() would additionally initiate the loading of the app’s main storyboard file, which in turn would create the window and initial view controller.

Changes to `main()`

Let’s have a look at the changes to the main() function, which still is the starting point for our app. The function now looks like this:

int main(int argc, char *argv[])
{
    @autoreleasepool {
        return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
    }
}

main() uses the new @autoreleasepool { } syntax introduced with LLVM 3.0, but that change doesn’t concern the app’s launch sequence. More importantly, the call to UIApplicationMain() changed from UIApplicationMain(argc, argv, nil, nil); to the one shown above. Note the change in the fourth argument.

Looking at the documentation, we learn that the fourth argument to UIApplicationMain() specifies

The name of the class from which the application delegate is instantiated. … Specify nil if you load the delegate object from your application’s main nib file.

So apparently our app delegate, which was previously created with Interface Builder inside MainWindow.xib, is now created directly by the UIApplicationMain() function.¹ In fact, there isn’t even a MainWindow.xib file anymore in our project!

No MainWindow.xib

Before Xcode 4.2, all default project templates did create a MainWindow.xib file. Because this file was specified in the app’s Info.plist as the main NIB file, the UIApplicationMain() function would load it automatically right after it had created the UIApplication instance for the app.

It was then inside the NIB file that both the application delegate object and the app’s main window were created and wired together via outlets. More often than not, MainWindow.xib would also include the app’s root view controller, already connected to a custom outlet in the application delegate class and the window’s rootViewController outlet.

With so much work done inside the main NIB file, the default application:didFinishLaunchingWithOptions: method could be kept almost empty. All it had to do was bring the window on screen:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Override point for customization after application launch.
    [self.window makeKeyAndVisible];
    return YES;
}

For Xcode 4.2 and later, Apple has decided to remove the main NIB file from the iOS project templates. The immediate reason for this change was most likely the introduction of storyboarding.

Storyboards are based around view controllers, not views or windows. Sticking to the concept of a main NIB file for a storyboard-based app would make no sense (and is impossible since the Info.plist keys NSMainNibFile and UIMainStoryboardFile are mutually exclusive). And abandoning the main NIB file only for storyboard-based apps but keeping it for others would lead to project templates differ from each other more than necessary.

More Work To Do in `application:didFinishLaunchingWithOptions:`

With the main NIB file gone, the tasks that were performed in the NIB file must now move elsewhere. We have already seen that UIApplicationMain() takes over one of them: the creation of our application delegate. Since the function now has control over both the UIApplication instance and its delegate, we can also safely assume that it will assign the delegate to the application instance.

At this stage, the application:didFinishLaunchingWithOptions: message will be sent. Since nobody has created a window or view controller yet, the method now performs these tasks in code, at least for an app that is not storyboard-based:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    self.window = [[UIWindow alloc] initWithFrame:[[UIScreen mainScreen] bounds]];
    // Override point for customization after application launch.
    self.viewController = [[ViewController alloc] initWithNibName:@"ViewController" bundle:nil];
    self.window.rootViewController = self.viewController;
    [self.window makeKeyAndVisible];
    return YES;
}

If your app uses storyboarding (by specifying a UIMainStoryboardFile in Info.plist), the app will automatically load the main storyboard file at launch, just like the main NIB file. It will also create a window and place the storyboard’s initial view controller inside it, and bring the window on screen. Therefore, there is nothing left to do for us in application:didFinishLaunchingWithOptions::

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    // Override point for customization after application launch.
    return YES;
}

A Litte More Code But Clearer

Initializing our (non-storyboard) app now takes a few more lines of code than before, but I think this change made the application launch sequence a lot clearer than before. I know many iOS developers who have had problems understanding the launch process because the role the main NIB file played was not clear to them.

Im a generally a big proponent of using NIB files/storyboards but in some cases they can confuse more than they help.

The syntax NSStringFromClass([AppDelegate class]) might seem a little strange. Why did Apple not just use a plain string @”AppDelegate” here? The result would be the same. They probably did it the more complicated way to simplify refactoring: if you want to rename the AppDelegate class, the built-in refactoring tool would detect its use in main() and rename it there as well. That would obviously not work if it were just a string.↩

CGPath Hit Testing

2012-02-03T18:00:00Z

In OS X 10.7 and iOS 5.0, Apple added an inconspicuous new function named CGPathCreateCopyByStrokingPath() to the Core Graphics framework. As the documentation says and the name implies, this function

[c]reates a stroked copy of another path. … The new path is created so that filling the new path draws the same pixels as stroking the original path.

This may sound like a pretty obscure use case that is rarely needed but in fact, this functionality can be extremely useful for a number of problems:

Stroking a path with fancy graphics. You can normally only stroke a path with a single color. If you want to do something fancier like, say, draw a gradient, CGPathCreateCopyByStrokingPath() lets you convert the area that would be stroked into a new path. You can then use this new path as the clipping path for the gradient you want to draw.
Stroking a stroke. If you want to draw a stroke around a path’s stroke, use CGPathCreateCopyByStrokingPath() to create a new path from the original path’s stroke, and stroke the new path.
Hit testing. The CGPath APIs can only help you if you want to hit test the for interior of a path, not if your hit target is the path’s contour. Since CGPathCreateCopyByStrokingPath() can convert the countour into a new path’s interior, it can help with this problem, too.

In this article, I want to show you an example app that covers the second and third of these problems.

The Demo App

Imagine you have a vector drawing app that lets the user draw both regular shapes like rectangles and ellipses and “irregular” ones like freeform paths and bezier curves. In your app, you represent the shapes that make up the current document with an array of CGPath objects (or an array of UIBezierPath (iOS)/NSBezierPath (Mac) objects, which themselves wrap a CGPath – the difference is not important for this discussion).

The user can add new (random) shapes to the view, select shapes by tapping on their outline, drag shapes across the view and delete a selected shape. Watch this short video for an overview:

The sample iPad app. Download the video (H.264, 2 MB).

The source code for the demo app is available on GitHub.

Hit Testing with `CGPathCreateCopyByStrokingPath`

You need to provide the functionality that existing shapes can be edited at a later time and for that, you need a way for the user to select shapes by tapping on them. To help you with this, the CGPath API provides the CGPathContainsPoint() function¹, which

[c]hecks whether a point is contained in a graphics path. … A point is contained in a path if it would be inside the painted region when the path is filled.

This function is helpful if you want to hit test on the entire region the path covers. As such, CGPathContainsPoint() doesn’t work with unclosed paths because those don’t have an interior that would be filled. The method of selecting shapes by tapping anywhere in their interior can also be problematic from a user interface perspective? What if the user taps at a location where multiple shapes overlap? What shape should the app select?

Such ambiguities can be minimized if shape selection only works on the shape’s outline and not its entire interior.² And here is where CGPathCreateCopyByStrokingPath() comes into play: whenever the user creates or modifies a shape, we call CGPathCreateCopyByStrokingPath() on it to create a mirroring tapTarget object that only covers the stroked area of the path (ensuring a certain minimum width to make the tap target big enough). When the user taps on the screen, we iterate over the tap targets rather than the actual shapes, now using CGPathContainsPoint() on the area that would be filled by the shape’s outline, to determine which shape was selected. In the sample app, the Shape class contains a method named tapTargetForPath: that generates such a tap target for a given path object (which is a UIBezierPath in this instance). Note that I am using a minimum width of 35 points for the tap target, regardless of the path’s lineWidth:

- (UIBezierPath *)tapTargetForPath:(UIBezierPath *)path
{
    if (path == nil) {
        return nil;
    }
    
    CGPathRef tapTargetPath = CGPathCreateCopyByStrokingPath(path.CGPath, NULL, fmaxf(35.0f, path.lineWidth), path.lineCapStyle, path.lineJoinStyle, path.miterLimit);
    if (tapTargetPath == NULL) {
        return nil;
    }
    
    UIBezierPath *tapTarget = [UIBezierPath bezierPathWithCGPath:tapTargetPath];
    CGPathRelease(tapTargetPath);
    return tapTarget;
}

The containsPoint: method in the Shape class then uses its tapTarget (rather than its path) to test whether it contains a given point or not. The result is that it returns YES only for points on the path’s outline (again, with a minimum width of 35 points).

- (BOOL)containsPoint:(CGPoint)point
{
    return [self.tapTarget containsPoint:point];
}

Now the hit testing code in the view controller is trivial. We just enumerate over all existing shapes and return the index of the first shape whose tap target matches the given location:

- (NSUInteger)hitTest:(CGPoint)point
{
    __block NSUInteger hitShapeIndex = NSNotFound;
    [self.shapes enumerateObjectsWithOptions:NSEnumerationReverse usingBlock:^(id shape, NSUInteger idx, BOOL *stop) {
        if ([shape containsPoint:point]) {
            hitShapeIndex = idx;
            *stop = YES;
        }
    }];
    return hitShapeIndex;
}

Drawing a Selection Outline with `CGPathCreateCopyByStrokingPath`

We use the hitTest: method to determine which shape the user has selected. In the demo app, she can drag the selected shape to another location or opt to delete it. To show the user which shape, if any, is currently selected, we should highlight the selected shape in some way. Let’s do that with a dashed outline.

I want the dashed outline to appear around the shape’s regular outline, so in CGPath parlance, I have to stroke the path’s stroke. As mentioned above, we can do that with our new favorite Core Graphics function. In our drawRect: method, we check whether the shape we are currently drawing is selected, and if it is, we use CGPathCreateCopyByStrokingPath() to create a new path of the shape’s outline and then stroke this copy with a dashed line:

- (void)drawRect:(CGRect)rect
{
    NSUInteger numberOfShapes = [self.dataSource numberOfShapesInDrawingView:self];
    NSUInteger indexOfSelectedShape = NSNotFound;
    if ([self.dataSource respondsToSelector:@selector(indexOfSelectedShapeInDrawingView:)]) {
        indexOfSelectedShape = [self.dataSource indexOfSelectedShapeInDrawingView:self];
    }
    
    for (NSUInteger shapeIndex = 0; shapeIndex < numberOfShapes; shapeIndex++) 
    {
        UIBezierPath *path = [self.dataSource drawingView:self pathForShapeAtIndex:shapeIndex];
        if (CGRectIntersectsRect(rect, CGRectInset(path.bounds, -(path.lineWidth + 1.0f), -(path.lineWidth + 1.0f)))) 
        {
            UIColor *lineColor = [self.dataSource drawingView:self lineColorForShapeAtIndex:shapeIndex];
            [lineColor setStroke];
            [path stroke];

            if (shapeIndex == indexOfSelectedShape) {
                UIBezierPath *pathCopy = [path copy];
                CGPathRef cgPathSelectionRect = CGPathCreateCopyByStrokingPath(pathCopy.CGPath, NULL, pathCopy.lineWidth, pathCopy.lineCapStyle, pathCopy.lineJoinStyle, pathCopy.miterLimit);
                UIBezierPath *selectionRect = [UIBezierPath bezierPathWithCGPath:cgPathSelectionRect];
                CGPathRelease(cgPathSelectionRect);

                CGFloat dashStyle[] = { 5.0f, 5.0f };
                [selectionRect setLineDash:dashStyle count:2 phase:0];
                [[UIColor blackColor] setStroke];
                [selectionRect stroke];
            }
        }
    }
}

Note that we are using the delegation pattern to have our view ask its data source for the shapes it should draw, their colors, and which one is the currently selected shape. We then take care to only draw a shape if its bounding box intersects with the rectangle we actually need to redraw to make drawing more efficient. The drawing of the selection outline takes place inside the if (shapeIndex == indexOfSelectedShape) { … } block. Note that the first line in the block (UIBezierPath *pathCopy = [path copy];) should not be necessary but I found it to be so to make sure that pathCopy always reflects the latest changes to the path³.

Replicating `CGPathCreateCopyByStrokingPath` in iOS 4 and Mac OS X 10.6

Since OS X 10.4 (and iOS 2.0), Core Graphics included the function CGContextReplacePathWithStrokedPath(). It essentially works the same way CGPathCreateCopyByStrokingPath() – with the large downside that it requires a graphics context to work on, which is usually not the case when doing hit testing. But it remains the best workaround I know of if you need to support older OS versions.

For a hit testing example, look at the code listed in this Stack Overflow question. Unlike the author claims in the question (which dates from 2009), the necessary CGContextCopyPath() function is a public API since iOS 4.0/Mac OS X 10.6.

Or the equivalent containsPoint: method of UIBezierPath or NSBezierPath. Again, the distinction is not important because we can assume that these methods either just call the function on the internal CGPath object they manage or work the same way.↩
As always, this method has its own user interface issues. Users might assume that a shape’s interior is indeed the selectable region and fail to select a shape that only reacts to taps on its outline. Also, a narrow outline is much harder to hit so we have to ensure our tap targets are big enough.↩
When the user moves the shape to another location, the Shape class would create an appropriate transformation matrix for the translation and then apply the translation to the UIBezierPath it manages by calling [path applyTransform:…];. Even though these transforms are supposed to be applied on the path itself, accessing the path repeatedly from drawRect: always returned the original, untransformed object, thereby drawing the selection outline in the wrong location. Only when I made an explicit copy of the path, it seemed to finally apply the cumulated transformations. What’s curious about this is that this issue does not affect the [path stroke]; line above, so it only seems to be a problem if you access the UIBezierPath’s underlying CGPath.↩

Schulung iOS-Entwicklung für Einsteiger im März 2012

2012-02-02T18:31:00Z

Update 13. Februar 2012: Leider musste ich die Schulung im März absagen, eine Anmeldung ist daher nicht mehr möglich.

On March 5-7, 2012, I will be teaching another three-day workshop on iOS Development for Beginners. The course will be held in Berlin and the teaching language will be German. If you read this blog it is (a) likely that you already know quite a bit about iOS development and (b) relatively unlikely that you speak German, but if you know someone who does (b) but not (a) and would like to learn (a) and (c) is in Berlin, please point them here.

Es ist mal wieder soweit: wie schon im letzten Jahr veranstalte ich auch 2012 wieder eine Schulung zur iOS-Entwicklung für Einsteiger in Berlin, und zwar vom 5. bis 7. März 2012 (Montag bis Mittwoch). Nachdem der zweitägige Workshop letztes Jahr sich zeitlich als etwas knapp herausgestellt hat, habe ich die Schulung noch einmal neu konzipiert und nun auf drei Tage ausgelegt. Zielgruppe sind alle, die schon etwas Programmiererfahrung in anderen Umgebungen mitbringen, sich mit dem iOS SDK, Xcode und Objective-C aber noch nicht auseinandergesetzt haben. Wenn du schon immer einen Einstieg in die iOS-Programmierung gesucht, aber bisher nie die Zeit dafür gefunden hast, dich richtig damit zu beschäftigen, glaube ich, dass dieser Workshop genau das Richtige für dich ist. Ich würde mich freuen! Infos zu Preisen und Anmeldung findest du auf der Schulungsseite.

DocSets App for iOS

2012-01-31T14:28:00Z

Update May 10, 2012: In the meantime, Ole has submitted DocSets to the App Store and perhaps surprisingly, Apple approved it. I encourage you to buy the app on the App Store both to support Ole and make future updates easier.

Have you ever tried to use Apple’s developer documentation on your iOS device? While Apple does have a special iPad version of their online documentation at developer.apple.com/library/ios/ipad/, I find it quite frustrating to use. And that’s not so much because Apple did a bad job with it but because of the inherent problems of a web-based solution: the whole thing is just too slow.

Now there is a better solution: my friend and officemate (and namesake) Ole Moritz wrote a native iOS app named DocSets for reading Apple’s developer documentation on the iPad or iPhone. DocSets is not available on the App Store. Instead, you can download the source code from GitHub for free and build it for yourself.

The DocSets app on iPhone and iPad. Screenshots: Ole Moritz.

The app does not come with the actual documentation, but it includes links to all of Apple’s current doc sets (iOS SDK 5.0, 4.3, 4.2 and Mac OS X 10.7, 10.6) and lets you download the ones you’re interested in with a single tap. When the download is complete, you have full offline access to the documentation. Other documents in Apple’s docset format can be added manually via iTunes File Sharing or by adding the link to the docset directly to the AvailableDocSets.plist file in the Xcode project.

Edit this property list to add more downloadable doc sets to the app.

If you ever wanted to have offline access to Apple’s developer documentation on your iOS device, the DocSets app is a great tool.

PS: Ole also wrote AppSales, another open-source app that is worth checking out if you don’t have it. AppSales is an iOS app for downloading and analyzing your sales numbers from the iOS and Mac App Stores.

New Videos at developer.apple.com

2012-01-27T18:10:00Z

Most of you probably know of the WWDC session videos Apple posts to its developer site each year. These videos are invaluable resources for learning about new technologies and APIs directly from their creators. Since 2010, the WWDC videos are free for all registered Apple developers so you really have no excuse for not watching them.

New Videos with iOS 5 Tech Talk Content

Occasionally, Apple even updates its selection of developer videos outside the annual WWDC cycle. In fact, Apple just posted 10 new videos to developer.apple.com/videos/ios/ in December 2011:

The list of new videos posted to developer.apple.com/videos/ios/ in December 2011.

Some of these new videos deal with the same topics that Apple focused on in its recent iOS 5 Tech Talk world tour, so if you haven’t had the chance to attend one of the Tech Talks, watching the videos brings you much of the same content. For instance, the video titled Optimizing App Performance with Instruments, presented by Michael Jurewitz, follows Michael’s Tech Talk session on Performance Measurement pretty closely.

Gesture Recognition on iOS with Attention to Detail

2012-01-25T17:08:00Z

One of the things that sets the iPhone’s user interface apart from the competition is Apple’s incredible attention to detail. This attention does not only extend to every single pixel on the screen but, perhaps even more important, also to gesture recognition: the standard iOS controls do a lot of smart things in order to identify the gesture the user intended to make and to allow multiple gestures to be executed at the same time if appropriate.

For example, scroll views must distinguish between a simple tap and the beginning of a swipe gesture. Similarly, the built-in map view control allows pinching and scrolling in one simultaneous gesture (put two fingers on the screen and you can switch seamlessly between pinching and scrolling without having to “restart” the gesture).

Half-assed Gesture Recognition Is Not Good Enough

We should set ourselves the same high standards for our own apps. In this article, I would like to show you an example where the half-assed implementation of gesture recognition seems to work well enough at first glance. But as the user continues to use the app, they quickly stumble upon little irritations, small annoyances in the user interface that they perhaps cannot even pinpoint but notice nevertheless. And while these irritations do not seem to be a big deal to many developers, I want to show you how getting rid of them can improve the user experience tremendously.

The sample app: using the standard gestures, you can drag the image across the screen, make it bigger or smaller by pinching, and rotate it. A double tap resets the image to its original state.

For our example, imagine a simple app that lets the user play around with an image on screen. Using gestures, they can:

Drag the image across the screen.
Make it bigger or smaller.
Rotate it.

In addition, a double tap should reset the image to its original position and size.

To implement this app we need to create four gesture recognizers, one for each required gesture. The setup code for the app would look like this:

- (void)viewDidLoad
{
    [super viewDidLoad];
    
    self.imageView.userInteractionEnabled = YES;
    
    UIPanGestureRecognizer *panRecognizer = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(panDetected:)];
    [self.imageView addGestureRecognizer:panRecognizer];
    
    UIPinchGestureRecognizer *pinchRecognizer = [[UIPinchGestureRecognizer alloc] initWithTarget:self action:@selector(pinchDetected:)];
    [self.imageView addGestureRecognizer:pinchRecognizer];
    
    UIRotationGestureRecognizer *rotationRecognizer = [[UIRotationGestureRecognizer alloc] initWithTarget:self action:@selector(rotationDetected:)];
    [self.imageView addGestureRecognizer:rotationRecognizer];
    
    UITapGestureRecognizer *tapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(tapDetected:)];
    tapRecognizer.numberOfTapsRequired = 2;
    [self.imageView addGestureRecognizer:tapRecognizer];
}

This is pretty straightforward code. Enable user interaction on our image view (which is disabled by default) and then create the gesture recognizers one by one and add them to the image view. The implementation of the gesture recognizer actions is equally simple:

- (void)panDetected:(UIPanGestureRecognizer *)panRecognizer
{
    CGPoint translation = [panRecognizer translationInView:self.view];
    CGPoint imageViewPosition = self.imageView.center;
    imageViewPosition.x += translation.x;
    imageViewPosition.y += translation.y;
    
    self.imageView.center = imageViewPosition;
    [panRecognizer setTranslation:CGPointZero inView:self.view];
}

- (void)pinchDetected:(UIPinchGestureRecognizer *)pinchRecognizer
{
    CGFloat scale = pinchRecognizer.scale;
    self.imageView.transform = CGAffineTransformScale(self.imageView.transform, scale, scale);
    pinchRecognizer.scale = 1.0;
}

- (void)rotationDetected:(UIRotationGestureRecognizer *)rotationRecognizer
{
    CGFloat angle = rotationRecognizer.rotation;
    self.imageView.transform = CGAffineTransformRotate(self.imageView.transform, angle);
    rotationRecognizer.rotation = 0.0;
}

- (void)tapDetected:(UITapGestureRecognizer *)tapRecognizer
{
    [UIView animateWithDuration:0.25 animations:^{
        self.imageView.center = CGPointMake(CGRectGetMidX(self.view.bounds), CGRectGetMidY(self.view.bounds));
        self.imageView.transform = CGAffineTransformIdentity;
    }];
}

Download the code for the sample app at this stage.

Works But Does Not Feel Great

Build and run this app, preferably on a device (testing the effectiveness of gestures on the simulator is not the best idea). If you are like me, using the app feels okay but not great. In fact, there are several problems with the gestures:

The gestures only work when all fingers are placed on the image view. This can get quite difficult when the target view is small, especially when two fingers are required as for pinching and rotating. It is possible for the user to make the image so small that it is almost impossible to recover from the situation.
None of the gestures work simultaneously with others. If I want to rotate the image but accidentally begin a pinch gesture, I have to release my fingers and start over. I cannot pinch, rotate and drag the image in one fluid motion.
There is no momentum at play here. All movements stop immediately when the user lifts their fingers off the screen.

We will solve points 1 and 2 in this post. I will cover the third issue in another article.

Solving the UX Issues

The first problem is trivial to solve: rather than adding the gesture recognizers to the image view, we add them directly to its superview (the view controller’s view). That way, the user can use the entire screen for gestures. It does not matter whether two, one or no fingers hit the image view. Modify viewDidLoad to implement this change:

- (void)viewDidLoad
{
    [super viewDidLoad];
    
    UIPanGestureRecognizer *panRecognizer = [[UIPanGestureRecognizer alloc] initWithTarget:self action:@selector(panDetected:)];
    [self.view addGestureRecognizer:panRecognizer];
    
    UIPinchGestureRecognizer *pinchRecognizer = [[UIPinchGestureRecognizer alloc] initWithTarget:self action:@selector(pinchDetected:)];
    [self.view addGestureRecognizer:pinchRecognizer];
    
    UIRotationGestureRecognizer *rotationRecognizer = [[UIRotationGestureRecognizer alloc] initWithTarget:self action:@selector(rotationDetected:)];
    [self.view addGestureRecognizer:rotationRecognizer];
    
    UITapGestureRecognizer *tapRecognizer = [[UITapGestureRecognizer alloc] initWithTarget:self action:@selector(tapDetected:)];
    tapRecognizer.numberOfTapsRequired = 2;
    [self.view addGestureRecognizer:tapRecognizer];
}

For the second issue, we need to tell the gesture recognizers to work simultaneously. The default behavior of gesture recognizers is to block each other: only one gesture can be recognized at a time. Fortunately, that behavior is easy to modify. Every gesture recognizer will ask its delegate (if it has one) whether it should be allowed to recognize gestures simultaneously with any other gesture recognizer it comes in conflict with. By setting our view controller as the delegate of all our gesture recognizers and simply returning YES from the gestureRecognizer:shouldRecognizeSimultaneouslyWithGestureRecognizer: delegate method, we can tell them to work together.

Don’t forget to add the UIGestureRecognizerDelegate protocol to our view controller’s interface declaration and extend the viewDidLoad method as follows:

- (void)viewDidLoad
{
	...
	
    panRecognizer.delegate = self;
    pinchRecognizer.delegate = self;
    rotationRecognizer.delegate = self;
    // We don't need a delegate for the tapRecognizer
}

And implement the delegate method:

- (BOOL)gestureRecognizer:(UIGestureRecognizer *)gestureRecognizer shouldRecognizeSimultaneouslyWithGestureRecognizer:(UIGestureRecognizer *)otherGestureRecognizer
{
    return YES;
}

Download the code for the sample app at this stage.

Now try out the app again. With a few simple changes, the gestures feel much more fluid and natural. It is attention to detail like this that distinguishes the really good iOS apps from the mediocre one. As mentioned, stay tuned for a future post on how to handle momentum when working with gesture recognizers. The code for the sample app is hosted on GitHub.

initWithNibName:bundle: Breaks Encapsulation

2012-01-23T18:00:00Z

Update January 27, 2012: Aaron Hillegass himself blogged about this same topic already in August 2009. Be sure to also read his post. Thanks to Cédric Luthi for pointing this out to me.

Here is an interesting approach that I recently learned from reading Joe Conway’s and Aaron Hillegass’s excellent introductory book iOS Programming: The Big Nerd Ranch Guide.

If you have done any iOS programming, you have probably encountered a pattern like this countless times:

- (IBAction)openNextView:(id)sender
{
    MyCustomViewController *nextViewController = [[MyCustomViewController alloc] 
        initWithNibName:@"MyCustomViewController" bundle:nil];
    [self presentViewController:nextViewController animated:YES completion:nil];
    // or:
    // [self.navigationController pushViewController:nextViewController animated:YES];
}

In response to an event (the user tapping a button), we create and initialize a new view controller instance, using the designated initializer of the UIViewController class, initWithNibName:bundle:. The we present the view controller on the screen. This pattern is ubiquitous in Apple’s documentation and sample code. But is it good code?

The Name of the NIB File is an Implementation Detail

Does it make sense for a view controller initializer to have an argument for the name of the view’s NIB file? In other words, should the creator of the view controller decide what NIB file it should load its view from? No. As Joe and Aaron mention in the book¹, the name of its NIB file is an implementation detail that should only concern the view controller itself. Exposing this detail to an outside caller breaks the encapsulation principle object-oriented programming is based on.

Since we usually subclass UIViewController to create our own custom view controllers, fixing this design flaw is easy. We just override the standard init method and document it to be our new designated initializer. In that method, we hardcode the values for nibName and bundle and call the superclass’s designated initializer with them:²

@implementation MyCustomViewController
    
// This is the designated initializer
- (id)init
{
    NSString *nibName = @"MyCustomViewController";
    NSBundle *bundle = nil;
    self = [super initWithNibName:nibName bundle:bundle];
    if (self) {
        ...
    }
    return self;
}

We must also override the old designated initializer to reroute it to use the new one:

- (id)initWithNibName:(NSString *)nibName bundle:(NSBundle *)bundle
{
	// Disregard parameters - nib name is an implementation detail
	return [self init];
}

Now, whenever we need to create a new view controller, we just call init rather than initWithNibName:bundle:.

One View Controller, Multiple NIBs

In some cases it can actually make sense to initialize the same view controller with different NIB files. The prime example is different UIs for iPhone and iPad that are contained in separate NIB files but served by the same view controller.³ But in this case, too, it should be the view controller itself that decides what NIB file to load. The logic for the decision should be placed into its init method:

- (id)init
{
    NSString *nibName = nil;
    if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone) {
        nibName = @"MyCustomViewControllerPhone";
    } else {
        nibName = @"MyCustomViewControllerPad";
    }
    NSBundle *bundle = nil;
    self = [super initWithNibName:nibName bundle:bundle];
    if (self) {
        ...
    }
    return self;
}

And even if the logic which NIB file to load depends on an external value that is only known to the creator of the view controller, it is better design to define a custom init... method that takes the external value as a parameter than to expose the name of the NIB file directly. For example:

// This is the designated initializer
- (id)initWithContext:(MyViewControllerContext)context
{
    // Decide which NIB file to load depending on the value of context
    ...
}

Conclusion

Even though the flaw in Apple’s design of the UIViewController initializers is pretty obvious, it never occurred to me before I read about it in the Big Nerd Ranch book. So thanks again to Joe and Aaron for pointing it out. In the future, I will define my own designated initializer for all my custom view controllers and not expose the view controller’s NIB file to outside callers anymore.

On page 174 of the second edition.↩
Update January 27, 2012: Several people pointed out to me that, as long as I give my NIB file the same name as my view controller class (I can even omit the Controller part), it is strictly not necessary to specify the nibName explicitly here. Just call [super initWithNibName:nil bundle:nil];. This is true, but I feel the explicit specification of the NIB file adds a lot of clarity. Also note that implicitly passing nil does not fix the inherent design flaw. You still have to override initWithNibName:bundle: to make sure that no outside caller can specify a different NIB name.↩
Update January 27, 2012: Many readers noted that this contrived example is not the best and I agree. If you name your NIB files following an Apple-specified pattern (iPhone-specific files end in ~iphone.xib, iPad-specific ones in ~ipad.xib), you can just specifiy the base filename in code and the NIB loading system will automatically figure out the correct file (this also works for other resources such as images, by the way). This is the better way to distinguish between different resources for the different platforms. Take the sample code above as a general example on how you would let the view controller decide on the correct NIB file name in different cases.↩

iOS and Mac Development Link Roundup: December 2011

2012-01-01T13:23:00Z

Here is my summary of the past month in links.

Carrier IQ

The story at the beginning of the month was the Carrier IQ software that Trevor Eckhart found on his Android phone, logging a lot of seemingly privacy-related activity. Grant Paul quickly found out that Carrier IQ also is on iOS, although Apple was quick to affirm that it has never used the software for anything that’s not covered by their privacy policy and only collected usage data if users explicitly opted in.

As the days went by, what seemed like a huge scandal at first turned out to have been blown out of proportion. Still, some phone carriers are to be blamed for using Carrier IQ’s software to track things like the applications used or what URLs are visited by a user (information which, admittely, they know anyway).

Programming

Android Graphics Architecture vs. iOS

There has been an interesting discussion about the shortcomings (or not) of Android’s graphics architecture vs. iOS. It’s hard to follow the original discussion now because many of the posts have been edited but let’s recap:

Dianne Hackborn, Android engineer at Google, set out to correct some assumptions about Android’s internals in a post titles How about some Android graphics true facts?. Andrew Munn, former intern on the Android team, followed up with his (misinformed) post The Reason Android is Laggy, claiming the main advantage of iOS’s over Android’s architecture was that iOS used a dedicated UI thread with real-time priority.

In another follow-up post, Dianne Hackborn rejected this claim, instead naming the security model and the design of certain APIs as reasons for Android’s past performance problems. Several people also pointed out flaws in Andrew’s description of how iOS actually works (see Andrew Munn’s updated post). Bob Lee’s post The truth about Android & iOS UI performance on the topic is worth reading, too.

In conclusion, it’s probably fair to say that with Android 4.0, the technical differences between iOS and Android in terms of graphics rendering are pretty small. I really like Brent Royal-Gordon’s take on the topic, quoted by Andrew Munn:

All that stuff you noticed—the way images aren’t drawn into lists while you’re scrolling, the way WebKit rendering stops when the system is tracking a touch—isn’t inherently built-in by a mechanism that pauses the world when a finger is on the screen.* It’s deliberate behavior painstakingly implemented by the developer of each individual app.

This is not a technical difference; it’s a cultural difference. Good iOS developers don’t ship software until it runs at something near 60 fps while scrolling and tracks touches almost perfectly; good Android developers do.

Disassembling the Assembly, Part 3: ARM edition

Gwynne Raskind gives a good introduction to reading ARM assembly language. This can be useful for intense iOS debugging sessions or if you just want to better understand your compiler. Don’t miss part 1 and part 2 of the series covering x86_64 assembly.

QuadCurveMenu

Zhu Levey created an open-source implementation of the animated fly-out menu made popular this month by the redesigned Path app. While I hope we won’t see this kind of menu in every second app in the future, the code can help illustrate some advanced Core Animation techniques.

Attaching an info panel to a UIScrollViewIndicator like in the Path 2 app

Another UI gem in the new Path app is the floating clock that scrolls and animates with the main scroll view to indicate the position of the timeline. Florian Mielke shows how to mimic this behavior in your own view controller.

Update Janurary 1, 2012: TimeScroller by Andrew Roy Carter is another take on this. Andrew’s solution goes a little further and actually reproduces the look of the control in the Path app including the clock.

A Dynamic Siri

Guy English on the possibility of Apple providing developer access to Siri in the future.

I predict that a Siri API is further off than you might think. The integration of services into Siri appears to be on a very case by case basis and even an internal app required special consideration. … Apple doesn’t appear to have an internal API for Siri yet, and it’s my bet that they’re a year or so away from it.

Economies of Scalar

Someone naming herself Subjective Observer points out a very useful new Core Data option in iOS 5 and OS X Lion. The Core Data editor now lets you “use scalar properties for primitive data types” instead of NSNumber, generating accessors based on scalar data types for numeric attributes. That is a great and largely undocumented addition! She also shows how to make use of this new feature while maintaining compatibility with older OS versions.

Nib Segregation

It’s common Cocoa wisdom and the rule to put each window into its own NIB file. Joshua Nozzi argues that it’s not always beneficial, though. Blind adherence to generalizations will get you in trouble.

VendorKit

VendorForge and Vendor, two of the Cocoa package managers I mentioned in last month’s link roundup, have merged to form VendorKit. I hope to see more of this. One package manager to rule them all! (Provided it’s a good one.)

Constant Confusion

Stuart Carnie clears up a syntax rule in C that always eluded me before: where to put the const keyword in a complex declaration? The answer is, of course, it depends on whether you want a constant pointer to a mutable value or a mutable pointer to a constant value or a constant pointer to a constant value. For all these cases, Stuart comes up with an easy-to-remember rule:

Always write const to the right and read the declaration from right to left.

Simple as that.

JSON Libraries for iOS Comparison

“Junior B.” compared the performance of various open-source JSON libraries to Apple’s new built-in JSON parser in Cocoa. Result: on iOS, JSONKit is up to ~30% faster than Apple’s NSJSONSerialization. SBJSON and TouchJSON are much slower than both.

CMPopTipView

CMPopTipView by Chris Miles is a view component that can display a UIPopover-like “bubble”, containing a text message, pointing at a specified button or view. Looks good for help texts.

PNG compression and iOS apps

Mark Edwards analyzes the benefits of trying to optimize PNG images for your apps.

I’m going to come straight out and say it—if you’re spending any effort compressing or optimising your PNG images for iOS app development, you’re wasting your time.

UIStoryboard Issues

Great post by Jonathan Wight on the current shortcomings of Storyboarding in iOS 5 apps. Jonathan’s verdict is that, while Storyboarding is a promising concept, it isn’t yet mature enough to be used in a complex app. I was particularly struck by the section titled “Misuse sender field”. It really seems Apple has forgotten to provide an essential API here.

retainCount is useless

If you ever find yourself logging retain counts while trying to debug a memory management problem, remember Bill Bumgarner’s post and stop what you’re doing immediately.

Trying Out Multisampling On iOS

Noel Llopis investigates the benefits and performance drawbacks of using OpenGL multisampling in iOS. In his testing with the Flower Garden app, the performance impact varied greatly by device: almost none on the iPhone 3GS and iPad 2, huge impact on the iPad 1 and iPhone 4 (whose GPU is less capable relative to the amount of pixels they have to handle).

AQSocket

Jim Dovey wrote a simple socket class that illustrates how to work with Grand Central Dispatch’s dispatch sources and dispatch I/O channels. Both are GCD features that are usually not addressed in your typical GCD tutorial so Jim’s code should be very useful if you want to learn more about the topic.

F3BarGauge

F3BarGauge by Brad Benson is a customizable iOS control to display bar gauges. Useful for your next audio mixer/visualizer app.

Zucchini

Zucchini is a new visual iOS testing framework, inspired by the Cucumber framework, which is very popular in the Ruby community. You write your tests in CoffeeScript, which Zucchini then compiles down to Apple’s UIAutomation Javascript syntax. Jake Marsh already blogged about Zucchini. Looks promising.

Building a Universal Framework for iOS

Justin DeWind wrote an up-to-date tutorial on building frameworks in Xcode that include multiple architectures such as armv6, armv7, and i386. This is especially useful for developers of open-source components. Or you can build your own frameworks if you want to easily mix ARC and non-ARC code without the hassle of specifying per-file compiler flags.

Static Code Analysis

John Carmack talks about the huge benefits he got from using static code analysis in his projects. The discussion of particular tools is C/C++-centric and thus not directly applicable to Objective-C code but his general findings are interesting:

The most important thing I have done as a programmer in recent years is to aggressively pursue static code analysis. Even more valuable than the hundreds of serious bugs I have prevented with it is the change in mindset about the way I view software reliability and code quality. … I feel the success that we have had with code analysis has been clear enough that I will say plainly it is irresponsible to not use it.

Lesson for Cocoa developers: at least use the Clang Static Analyzer that’s built into Xcode regularly.

Siri Authentication

Grant Paul reverse-engineered how Siri authentication works, thereby ensuring that it only runs on an iPhone 4S (or for hacks you need an iPhone 4S device token). This is his overview.

iCloud Demystified

Noel Llopis gives a good tutorial (including a demo project) how to sync files with iCloud in the simplest way possible (without using UIDocument).

Suppressing Xcode Warnings On A Per File Basis

Nice little tip by Shane Crawford. Especially useful if you use some open source library whose author did not care to fix all compiler warnings.

Design

Inspiration vs. Imitation

Great post by Jessica Hische on the fine line between being inspired by others and using this inspiration to create something original and blatantly copying others’ creations.

What Goes into the Sausage – The Creation of an Icon

Michael Shephard from Black Pixel about the iterative and non-linear nature of the design process. Nice insight.

On Magazines and the iPad

Justin Williams shows what happens when media companies create apps for the sake of having an app rather than to create a better user experience.

I’m convinced that the people who actually write for magazines, edit them and publish them have never actually tried using their iPad versions for more than a few moments. If they actually did try to use their publication’s app as the actual means to read each issue, things would have to improve. Right? RIGHT?!

UI Parade

UI Parade is another one of the sites that collect examples of outstanding UI design. I mentioned a number of these over the past months in my blog posts but this one seems particularly well edited.

UX design experiments for a Number 1 mobile app

David McKinney illustrates different approaches how to integrate help into your app’s UI. I like the integrated approach they settled on very much.

The Flipboard for iPhone design process

After Flipboard for the iPhone came out earlier this month, members of the design team tweeted some pictures showing the many, many iterations they did for this one app’s design. I love how the photos illustrate the incredible amount of work that went into it.

UX Critique of Path 2

Brenden Mulligan took a very detailed look at the new Path app from a design and user experience point of view. Very insightful and spot-on.

Texture

Justin Williams on the importance of texture in the iOS UI. Justin gives examples of some new apps that to him feel out of place on iOS because their design is based on solid colors without texture, which seems more fitting in Android and Windows Phone environments. He points out the importance of designing especially for the target platform:

Mobile is young enough that we’ve got three vibrant platforms that offer uniquely identifiable experiences jockeying for position. If your goal is to reach all of those customers, do it with respect and taste. Build something tailored specifically for them, not something that is just “good enough” for all three.

Beth on Brushes

Fraser Speirs posted a video that shows how competently his 4-year-old daughter uses the Brushes app on the iPad to paint a picture. Again and again, it’s amazing to see how much more intuitive these post-PC devices are compared to a classical mouse-driven GUI.

App Store

How to to climb in the App Store, Part II

Oliver Reichenstein continued to analyze and publish iA’s pricing experiments with their app, iA Writer. The takeaway from this for developers seems to be: trying out different price points is fine and all but in the end, the quality and uniqueness of your app will be a much bigger sales driver:

To increase sales: Don’t imitate. You might get some crumbs from some table but ultimately, you’ll help the original by doing so. Innovate. Think different, be different. Take maximum care for details, even if it’s a hassle. Read all feedback and don’t get irritated by feature requests and focus on the next big step.

And now a reminder of how tough the App Store slog really is

Taking the new Path app as an example, Dan Frommer points out how hard it is to be successful on the App Store these days, even if you made a great product and got as much press as those guys did. A few days later, Dan followed up with a post showing that in Path’s case at least, the app finally made it into the top 25. So it may be hard, but it’s definitely not impossible.

Apple’s Mac App Store Downloads Top 100 Million

In a press release, Apple announced some numbers for the Mac App Store now that it is almost one year old. 100 million app downloads in less than a year sure sound impressive until you compare it to the size of the iOS App Store, which registers about 1 billion downloads a month.

In other words, the iOS App Store is about 50-100 times bigger than the Mac App Store in terms of downloads. Interestingly, the relation is about the same when you count the total number of available apps (500,000 for iOS vs. less than 10,000 on the Mac App Store). So arguably, because it’s so much easier to get your share of visibility on the Mac App Store, your chances of making money could be roughly equal on both stores, especially since Mac apps tend to be priced higher.

A look at the Mac App Store, 100 million downloads later

Dan Frommer also takes a look at the numbers in the Mac App Store. According to his statistics, only about 18 apps are added to the Mac App Store each day. Surprising.

App Developers Bet on iOS over Android this Holiday Season

According to Flurry (who have unique data on many mobile app stats thanks to their analytics software), app developers still favor iOS over Android by a wide margin despite Android’s tremendous growth in market share. The main reason seems to be that the App Store is where the money is.

Distimo Releases Full Year 2011 Publication

Research firm Distimo published an updated report on the mobile app store field in 2011. Key findings:

The iOS App Store generates about four times the revenue that the Android Market makes.
In-app purchases and freemium business models have an increasing share of the total revenue.
The app market in China is growing fast.

Free-to-Play Pioneer NimbleBit Says to Put Fun and User Experience First, Not Monetization

Good interview by Kathleen De Vere with David and Ian Marsh, the twin brothers behind Tiny Tower. They talk about monetization strategies on the App Store and the increasing role of “freemium” business models. Surprisingly to me, 30% of the revenue they make with Tiny Tower comes from selling $30 in-app purchases, even though these items only make up 4% of all their in-app purchases. Goes to show that it pays off to give your most loyal users the chance to give you more than $0.99.

Community

Latest Version

Matt Gemmell makes the tongue-in-cheek argument that it is okay to only support the latest OS version. And I actually agree (up to a point).

The Golden Age of the Developer

David Haywood Smith from The Kernel says there has never been a better time to be a developer. There are countless resources and opportunities available to us. The only thiing we have to do is consume them. But at the same time, David reminds us that we all have the responsibility to give something back to this awesome community. Everybody should think about how they can contribute. And to all those who already do contribute, do not sit back:

The big challenge is leading. It’s not as scary as it sounds. It’s really just an extension of contributing. If you make a significant contribution then you automatically become a leader. … I encourage you to start thinking about how to move up the ladder. Whatever kind of developer you are, you’ll find it pays dividends.

Open Source Code

On the same topic, Matt Gemmell has some very useful tips on how to publish some of your code in open-source form. By following Matt’s advice, you increase the chances that your open-source project will actually be noticed significantly. Even if your code is absolutely amazing, almost no one will look at it if you don’t package it nicely and make it easy for others to use.

From Idea to Market: How We Built Gradient

Nicola Armellini from Jumpzero talks about the development process of their Mac app, Gradient. I love how he stresses to start out with a simple idea that solves a real problem and the importance of prototyping and showing what you do to possible influencers far before it’s done.

Competition

10 Billion Android Market downloads and counting

Google reported on their blog that the Android Market has reached 10 billion app downloads. The current growth rate of the Market is 1 billion downloads per month, similar to the current growth of the iOS App Store.

Standing Up For Android

The guys from Shifty Jelly make quite a convincing point for iOS developers to also look at the opportunities of the Android community.

In many ways it’s [the Android Market] a better place to be than iOS, since so many developers are ignoring it, and yet there is a massive install base waiting to give you their money.

I’m sure there are many Android developers who would agree. So why all the controversy? Let everyone decide on their own which platform they want to target (first). I am sure some will follow Eric Schmidt’s prediction and others (probably most, at least in the next 6 months) will not.

Microsoft to drop Desktop App from Windows 8 ARM tablets?

Mary Jo Foley writes that Microsoft may make a 180 degree turn and actually make Windows 8 tablets Metro only, not bringing over the traditional Windows desktop. I think that would be a great move for Microsoft.

Previewing the Windows Store

Antoine Leblond from Microsoft gives developers a preview of the upcoming app store for Windows 8. Their feature set sounds great:

We have full platform support for free apps, trials (both time-based and feature-based trials) and paid apps, including in-app purchase. And we have sales analytics that will help you target customers more effectively.

In addition, developers will get an 80% revenue share (instead of the usual 70%) if their app is successful enough to make it over $25,000 in total revenue. Let’s hope that more competition in the app store space will give Apple the incentive to further improve their offerings.

HP to Contribute webOS to Open Source

Press release by HP. Will it make a difference? Will other major players like Facebook or Amazon now adopt webOS for their own devices? In an interview with Joshua Topolsky for The Verge, HP CEO Meg Whitman and board member Marc Andreessen at least confirmed that HP has plans to make new tablets running webOS, but what I can’t tell you is whether that will be in 2012 or not.

Twenty four hours of Lumia

Alasdair Monk’s is one of a number of very positive reviews of the Lumia 800, Nokia first device running Windows Phone 7.5. The phone is stunning and the software looks great too. Looking at the market reaction, it still seems to have come too late.

Goodbye, Nokia Lumia 800: £400 and one month on, it didn’t work out

Matthew Baxter-Reynolds just published a rather negative review of his Lumia 800 experience over the last month, citing many minor flaws both in the built-in software and in third-party apps.

What’s wrong is the niggles. Windows Phone is a good operating system. But it’s not a great operating system. … It’s the niggles that’s stopped me from developing a deeper relationship with the device that turns it into a ubiquitous tool, as opposed to “just a phone”.

Apple and Steve Jobs

Apple’s Terrific And Tumultuous 2011

MG Siegler summarizes Apple’s 2011 for Techcrunch in a long list of links. Very useful post for reference if you want to find a particular article again.

10 things we learned about Apple this year

Dan Frommer highlights some key points how Apple works and acts. Realizing these traits will probably make it much easier to tell if the next random Apple rumor has any value or not. Most important lesson for developers: The iPad really is special. If you did not know that already.

Apple Made A Deal With The Devil (No, Worse: A Patent Troll)

Apple has been extremely busy recently suing its competitors (and being sued by them) for patent infringement, copycat design, etc. I think it’s fair to say that it has become impossible to say who’s right and who’s wrong overall. Not so in this particular case: Jason Kincaid seems to have uncovered that Apple may have cooperated with a patent troll. To quote Jason, it’s hard to see Apple in a positive light here.

Steve Jobs by Walter Isaacson: A Review

Thomas Q. Brady with a well-written and well-founded critique of the Jobs biography. Brady makes many of the same points I already heard from John Siracusa, so this is a good article to read if you don’t listen to podcasts.

Apple Submits Updated Campus 2 Plans to Cupertino, Reveals Stunning Renderings

Gary Ng’s article includes links to many new renderings and plans of Apple’s stunning plans for the new corporate campus.

The Real Story Behind Apple’s “Think Different” Campaign

In the Steve Jobs biography, Walter Isaacson suggests that Steve Jobs himself wrote much of the “Here’s to the Crazy Ones” text for Apple’s famous Think Different campaign. In this interesting article for Forbes, Rob Siltanen, member of the original advertising team, tells a different story. Obviously, this is not development-related at all, but it is a good read.

UIRequiredDeviceCapabilities Cannot Be Changed in App Updates

2011-12-23T15:53:00Z

Update May 10, 2012: Apple replied to my bug report:

Engineering has determined that this issue behaves as intended based on the following information: Developers can add restrictions to UIRequiredDeviceCapabilities on app updates provided any device that is dropped cannot support the min os version specified.

Update January 11, 2012: Added a screenshot of the Xcode validation error.

Earlier this month, I wrote about How to Restrict Your iOS App to Modern Hardware. One of the suggestions I made was to use the UIRequiredDeviceCapabilities key in your Info.plist file to make your app run only on devices with armv7 CPUs. Several people contacted me afterwards to tell me that this approach only works for new apps.

You heard that right: when updating an app, it seems you cannot add new restrictions to the Required Device Capabilities. One developer who contacted me said he has been fighting with this for more than 2 years, and all due to the simple mistake of omitting the “telephony” requirement in version 1.0 of his app.¹

Automatic Rejection by Xcode’s Validator

According to the feedback I got, this is not even an issue that could be discussed during the app review process. Instead, it seems that the automatic validation service that Apple has integrated into Xcode will reject any update with more restrictive UIRequiredDeviceCapabilities than the earlier version before you can even upload it to iTunes Connect.

Xcode validation error after updating UIRequiredDeviceCapabilities. Screenshot by Noel Llopis.

How About Not Changing the Deployment Target for Your App’s Lifetime?

I think this is a very bad rule on Apple’s side and I wonder how it can be reconciled with other Apple policies regarding app updates. Ultimately, raising the required device capabilities is equivalent to increasing your app’s Deployment Target², something that Apple has no problem with in an app update.

One could argue that from the perspective of the users, a minimum OS version is easier to communicate than changed hardware requirements but I find that unconvincing. If anything, changed hardware requirements should be easier to understand than changes on the software side since every user knows that hardware cannot be updated while it’s a lot harder to grasp why an old device should not be able to run a new OS version. And Apple does a bad job of communicating changed OS version requirements anyway so it strikes me as odd that they should care so much about the hardware side of things.

In addition, there are some hardware features Apple actively pushes, encouraging developers to adopt them in their apps. The prime example is probably the non-backwards compatible OpenGL ES 2.0. During the recent iOS 5 Tech Talks, Apple actively rallied developers to switch to OpenGL ES 2 to make their apps better. But how is a developer supposed to switch from OpenGL ES 1.1 to 2.0 if he is not permitted to add the corresponding UIRequiredDeviceCapabilities key to its updated app? In that case, he would be forced to increase the Deployment Target to iOS 4.3+ (all devices that run iOS 4.3 also support OpenGL ES 2.0) and his Info.plist would not reflect the correct hardware requirements anymore. Looks like a bad workaround to me.

Downgrades are Possible

It is worth noting that the other way – lowering the required device capabilities – is indeed possible. One developer told me that they had no problems when they removed a requirement from their app.

Please File a Bug Report

If you also think this is a bad policy that Apple should change, please file a bug report. Feel free to refer to the bug ID under which I reported the problem: rdar://10623835.

To quote from this developer’s e-mail to me: I exchanged several emails with Apple support but they reject to change this even in this exceptional and logical case.↩
In Apple’s terminology, the Deployment Target indicates the minimum OS version that an app can run on. For instance, setting the Deployment Target of an app to iOS 4.3 has the same effect in practice as using the UIRequiredDeviceCapabilities to restrict the app to the armv7 architecture because the sets of all iOS devices that can run iOS 4.3 and have an armv7-capable CPU are identical. Apple takes measures to avoid the installation of apps on devices that do not fulfill the Deployment Target requirements.↩

Diamond Dash for iOS

2011-12-08T20:45:00Z

Disclaimer: my brother Jens is Wooga’s founder and CEO. It is unlikely that I would have been involved in this project if that were not the case, if only for the fact that I would probably never have learned about it in the first place. That said, I think we managed to separate family and business quite well.

Yesterday at the Le Web conference in Paris, social game developer Wooga launched Diamond Dash for iPhone and iPad, their first native iOS title. Diamond Dash originally launched as a Flash game on Facebook in March 2011 and, with more than 11 million active players per month, today is one of the top 10 games on the platform.

During the past months, I helped port the game to iOS. Our goal was to make the iOS version even more fun to play than the game on Facebook, and I think we succeeded. The simple gameplay makes Diamond Dash a perfect game for touchscreen control and the incredibly fast-paced action comes across perfectly on both iPhone and iPad. Although the gameplay is trivial (tap groups of 3 or more same-colored gems to make them explode), it is highly addictive and I encourage you to try it out.

Diamond Dash on iPad and iPhone. Photo: Wooga.

Facebook Integration

Because of Diamond Dash’s Facebook heritage, it was clear from the beginning that the iOS version should also have a deep Facebook integration. While it is possible to play standalone, it really is a lot more fun to play against your Facebook friends and compete in the Weekly Tournament. Your scores are synced between all three platforms (Facebook, iPhone and iPad) so no matter where you or your friends play, you can always compete with each other. Not every iPhone user may like this deep Facebook integration, but I think for a game that already has such a huge fan base on Facebook, it makes total sense.

From a developer’s perspective, the tight integration with Facebook and the existing game backend turned out to be one of the challenges of the project. In the end, we were able to take advantage of some brand-new Facebook features that were rolled out in Facebook’s latest version of their native iOS app. Viral channels that were limited to the Facebook website until a few weeks ago can now be used by developers to link directly to their native iOS or Android app through the Facebook app on the device. My brother (and Wooga CEO) Jens talked about this when he introduced Diamond Dash at Le Web.

Already Featured by Apple

Ratings for Diamond Dash on the German App Store less than 48 hours after it went live.

I am incredibly excited about the huge initial success that Diamond Dash seems to be. Just 24 hours after its announcement, the game has already been featured by Apple and made it to the top 10 free apps all over Europe (3rd in Turkey, 4th in Germany, 6th in France, 7th in Italy, 9th in Spain). It’s currently ranked 79th and climbing among all free apps in the US.

User feedback also seems to be very positive. On the German App Store, Diamond Dash already got more than 700 ratings and reviews with an average of 4.5 stars. Thanks to all players for the positive reception! If you want to be one of them, get Diamond Dash for free in the App Store.

Thanks to the Arcade Team at Wooga

I would also like to say thanks to the incredible team I could work with at Wooga. I think we can be quite proud of the job we did. I wish them the best for the continued development of the game (in which I will no longer be involved).

Tutorial: How to Sort and Group UITableView by Date

2011-12-02T17:40:00Z

The Appointment List sample application. The list of calendar events ids grouped by date.

Let me follow up on last month’s little series about date and time handling in Cocoa with a practical example.

Say you want to implement a list of your future appointments similar to the List view in Apple’s Calendar app on the iPhone. Calendar events should be listed in a table view, with each day getting its own section. So we have to group the dates by day, which is an interesting task to get familiar with the date handling classes.

Project Setup

I am not going to cover the basics here. We need a fresh Xcode project (the navigation-based app template is a good start) with a view controller that displays a UITableView. Since we are going to work with the calendar store on the device, we also need to link our app with the EventKit.framework and import the framework’s header file: #import <EventKit/EventKit.h>.

Getting Events from the Calendar Store

The first thing we have to do is get a list of future events from the calendar store. Our interface to the store is the EKEventStore class. The event store lets us generate a predicate that we can then use to retrieve all events matching the predicate. All we need to do is specify a start and end date for the predicate.

Constructing Start and End Date

Say we want to list all events between today and one year from today. A natural start date for our query would be [NSDate date], which gives us the current date and time. But what about appointments that were scheduled for earlier today? I think we should include them in our list even though they lie in the past. It’s better than to confuse the user by showing only part of today’s events.

So our start date should be the beginning of the current day. How do we determine that date, given that all we have is the current date and time? Think about it this way: we want a date that represents a specific time (00:00) on a given day. The easiest way to do that is to selectively convert the date components of the given date into an NSDateComponents instance, then set the specific time components manually, and convert the whole thing back into an NSDate:

- (NSDate *)dateAtBeginningOfDayForDate:(NSDate *)inputDate
{
    // Use the user's current calendar and time zone
    NSCalendar *calendar = [NSCalendar currentCalendar];
    NSTimeZone *timeZone = [NSTimeZone systemTimeZone];
    [calendar setTimeZone:timeZone];
    
    // Selectively convert the date components (year, month, day) of the input date
    NSDateComponents *dateComps = [calendar components:NSYearCalendarUnit | NSMonthCalendarUnit | NSDayCalendarUnit fromDate:inputDate];
    
    // Set the time components manually
    [dateComps setHour:0];
    [dateComps setMinute:0];
    [dateComps setSecond:0];

    // Convert back       
    NSDate *beginningOfDay = [calendar dateFromComponents:dateComps];
    return beginningOfDay;
}

This method gives us an NSDate representing midnight in the current user’s local time for the specified input date.

For the end date, we want to add exactly one year to the start date. The trivial way to do that would be to add 365 * 24 * 60 * 60 seconds¹ to the start date but this naive approach takes neither leap year nor different calendars into account. The better way is again the one via NSCalendar and NSDateComponents:

- (NSDate *)dateByAddingYears:(NSInteger)numberOfYears toDate:(NSDate *)inputDate
{
    // Use the user's current calendar
    NSCalendar *calendar = [NSCalendar currentCalendar];
    
    NSDateComponents *dateComps = [[NSDateComponents alloc] init];
    [dateComps setYear:numberOfYears];
    
    NSDate *newDate = [calendar dateByAddingComponents:dateComps toDate:inputDate options:0];
    return newDate;
}

The dateByAddingComponents:toDate:options: method is just great. It adds the specified date components to the input date and takes care of everything for us, including leap years and overflows from one unit to the next. For instance, if you were to add 5 months to a date in November, the method is smart enough to return a result in April of next year.

Querying the Calendar Store

Having start and end date, we can construct our search predicate. Add the following code to your view controller’s viewDidLoad method:

- (void)viewDidLoad
{
    [super viewDidLoad];
    
    NSDate *now = [NSDate date];
    NSDate *startDate = [self dateAtBeginningOfDayForDate:now];
    NSDate *endDate = [self dateByAddingYears:1 toDate:startDate];

    EKEventStore *eventStore = [[EKEventStore alloc] init];
    NSPredicate *searchPredicate = [eventStore predicateForEventsWithStartDate:startDate endDate:endDate calendars:nil];
    NSArray *events = [eventStore eventsMatchingPredicate:searchPredicate];
}

This gives us a list of events inside our desired timeframe.

Grouping Events by Day

Next, we have to group the list of events into sections, each section representing a single day. The way we approach this task is this:

Iterate over all events.
Reduce the event’s start date to its date components, i.e. strip off the time (like we did above to determine the start date of our search predicate).
Use the reduced date as key in a sections dictionary.
Each value in the sections dictionary should be an array containing the events that belong to the day represented by the corresponding key.
Create a separate array in which we sort the keys of the sections dictionary. We need this to display the sections in the correct order.

Make sense? Here is the code:

@property (strong, nonatomic) NSMutableDictionary *sections;
@property (strong, nonatomic) NSArray *sortedDays;

...

@synthesize sections;
@synthesize sortedDays;

...

- (void)viewDidLoad
{
    ...

    self.sections = [NSMutableDictionary dictionary];
    for (EKEvent *event in events) 
    {
        // Reduce event start date to date components (year, month, day)
        NSDate *dateRepresentingThisDay = [self dateAtBeginningOfDayForDate:event.startDate];
        
        // If we don't yet have an array to hold the events for this day, create one
        NSMutableArray *eventsOnThisDay = [self.sections objectForKey:dateRepresentingThisDay];
        if (eventsOnThisDay == nil) {
            eventsOnThisDay = [NSMutableArray array];
            
            // Use the reduced date as dictionary key to later retrieve the event list this day
            [self.sections setObject:eventsOnThisDay forKey:dateRepresentingThisDay];
        }
        
        // Add the event to the list for this day
        [eventsOnThisDay addObject:event];
    }
    
    // Create a sorted list of days
    NSArray *unsortedDays = [self.sections allKeys];
    self.sortedDays = [unsortedDays sortedArrayUsingSelector:@selector(compare:)];
}

(The method is getting pretty long here. In practice, I wouldn’t place all this code in viewDidLoad but it should suffice for the example.)

Creating Date Formatters for Output

That’s it! The last thing we need are two NSDateFormatter objects to format the output for the section headers and cells in the table view. We could create those directly in the methods where we need them, but since creating a date formatter is a relatively expensive operation, we are better off creating them once and reusing them. Note that we don’t use specific date and time formats but instead rely on the predefined date formatter styles, which take the user’s preferences into account:

@property (strong, nonatomic) NSDateFormatter *sectionDateFormatter;
@property (strong, nonatomic) NSDateFormatter *cellDateFormatter;

...

@synthesize sectionDateFormatter;
@synthesize cellDateFormatter;

...

- (void)viewDidLoad
{
    ...

    self.sectionDateFormatter = [[NSDateFormatter alloc] init];
    [self.sectionDateFormatter setDateStyle:NSDateFormatterLongStyle];
    [self.sectionDateFormatter setTimeStyle:NSDateFormatterNoStyle];

    self.cellDateFormatter = [[NSDateFormatter alloc] init];
    [self.cellDateFormatter setDateStyle:NSDateFormatterNoStyle];
    [self.cellDateFormatter setTimeStyle:NSDateFormatterShortStyle];
}

Populating the Table View

With the groundwork done, populating the table view is simple. Note that I am using iOS 5 for the sample project so we can configure our prototype table cell directly in Interface Builder:

Configuring the settings of the prototype cell in Interface Builder.

The UITableViewDataSource protocol methods we have to implement are straightforward:

- (NSInteger)numberOfSectionsInTableView:(UITableView *)tableView
{
    return [self.sections count];
}

- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section
{
    NSDate *dateRepresentingThisDay = [self.sortedDays objectAtIndex:section];
    NSArray *eventsOnThisDay = [self.sections objectForKey:dateRepresentingThisDay];
    return [eventsOnThisDay count];
}

- (NSString *)tableView:(UITableView *)tableView titleForHeaderInSection:(NSInteger)section
{
    NSDate *dateRepresentingThisDay = [self.sortedDays objectAtIndex:section];
    return [self.sectionDateFormatter stringFromDate:dateRepresentingThisDay];
}

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    NSString *reuseIdentifier = @"EventTitleCell";
    UITableViewCell *cell = [tableView dequeueReusableCellWithIdentifier:reuseIdentifier];

    NSDate *dateRepresentingThisDay = [self.sortedDays objectAtIndex:indexPath.section];
    NSArray *eventsOnThisDay = [self.sections objectForKey:dateRepresentingThisDay];
    EKEvent *event = [eventsOnThisDay objectAtIndex:indexPath.row];

    cell.textLabel.text = event.title;
    if (event.allDay) {
      cell.detailTextLabel.text = @"all day";
    } else {
      cell.detailTextLabel.text = [self.cellDateFormatter stringFromDate:event.startDate];
    }
    return cell;
}

Download the Sample Project

In this tutorial about date handling, I illustrated how to combine Cocoa’s date handling classes, NSDate, NSCalendar, NSDateComponents, NSDateFormatter, to do date calculations, to derive new dates from existing ones, to group dates according to your own criteria, and to format dates for output on screen. And incidentally, we also learned to query the device’s calendar store.

I uploaded the small sample app to GitHub, please download it from there. Update December 21, 2011: I mistakenly had not included the .xcodeproj file in the repository. This mistake is now fixed, sorry for the confusion. Note that you won’t see anything but an empty table view when you run the app in the iOS Simulator since the simulator does not have a calendar store.

The number of seconds in a normal (non-leap) year. The result is 31,536,000 seconds.↩

How to Restrict Your iOS App to Modern Hardware

2011-12-01T15:30:00Z

Marco Arment posted one of his regular iOS device and OS version stats overviews yesterday. While Marco’s stats obviously only represent Instapaper users and one has to be careful how representative the data is, these updates are nevertheless very welcome as they represent one of very few publicly available data points to estimate the adoption rate of iOS versions.

iOS 5 Adoption Rate Only at 45%

The most striking number to me is the rate of iOS 5 adoption: across Instapaper users on all iOS devices, 45% are running iOS 5. This strikes me as quite low. I would have expected a number in the range of 70–80%, especially considering that Instapaper users are probably significantly more geeky than the average iOS device owner.¹

How to Forcefully Exclude Older Devices From Running Your App

According to Marco’s numbers, having an app that requires iOS 5 would still exclude a lot of users at this time. Most developers should probably wait a least a few more months until they cut off iOS 4 support.² For developers of apps that require a relatively high-performance device to run smoothly, that begs the question: how do I best restrict my app to only run on newer devices?

It is important to implement such a restriction in a way that enforces it not only at runtime but also at install time. Otherwise, you will (rightfully) get lots of e-mail from angry iPhone 3G owners (if your app even makes it through the review process). Here are the options you have:

1. Require a Certain iOS Version

We just learned that it is probably too early to require iOS 5.0 but what about iOS 4.3? iOS 4.3 does not run on anything that’s older than the iPhone 3GS and it has an adoption rate of 88% in Marco’s stats. In fact, that is what Marco recommends:

Developers of CPU-intensive iPhone apps and games can celebrate the continued infiltration of faster hardware, with at-least-3GS-class CPUs in 94.39% of iPhones and iPod Touches. Apps that need high performance can probably start requiring iOS 4.3 (87.8%) to forcefully cut support for the much slower old CPU in the iPhone 1, iPhone 3G, and 1-2G iPod Touches.

2. Require Certain Device Features such as OpenGL ES 2

If your app uses OpenGL ES 2, you are done because the GPUs in devices before the iPhone 3GS do not support that version. All you need to do is specify opengles-2 under the UIRequiredDeviceCapabilities key in your Info.plist file.

This is a convenient option but you should only use it if your app really uses and requires this special feature. Don’t just arbitrarily select a convenient option from the available device capabilities.

3. Require the armv7 CPU Architecture

One convenient way to sort of circumvent this rule is to explicitly require a device with a fast CPU: one of the options for UIRequiredDeviceCapabilities is armv7, which tells Apple and the OS that your app only runs on the modern CPU architecture that is used by the iPhone 3GS and all newer iOS devices. That way, you can allow iOS versions 4.0-4.2 and still restrict your app to modern hardware. (Please only do this if your app is really close to unusable on an iPhone 3G. Users of older hardware are probably used to somewhat slow performance, so they won’t necessarily hold it against you if your app stutters a bit.)

Requiring the armv7 CPU architecture in the UIRequiredDeviceCapabilities key.

Note: Patrick Burleson noted on Twitter that he heard of app rejections when apps added new requirements to the UIRequiredDeviceCapabilities in an update. I find it hard to believe that that is a general rule. It must be allowed for existing apps to switch to OpenGL ES 2.0, for example. But it’s probably good to keep in mind.

Update December 23, 2011: It seems indeed to be true that the required device capabilities cannot be changed in app updates. Please see my follow-up post on the issue.

It is not totally clear to me, however, how Marco arrived at these numbers. Do they represent a snapshot of his user base at the end of November? In that case, I would have expected the iOS 5 adoption rate to be much higher. Or is it an average across a longer period of time, perhaps the entire month or since the release of Instapaper 4.0? In that case, the 45% would not surprise me as much.↩
That said, if I were to start developing a new app now, I would definitely go iOS 5 only.↩

iOS and Mac Development Link Roundup: November 2011

2011-11-30T19:51:00Z

I skipped my customary monthly link roundups in September and October simply because I did not have the time to compile them. Not only did the composition of the interesting links at the end of the month take up an increasing amount of time (which I would be fine with), but the fact that I felt I had to stay up to date with my Twitter timeline every single day in order not to miss anything made this impossible.

Perhaps not surprisingly, the amount of positive feedback I got the roundups increased tremendously once I had stopped doing them. Thanks to everybody who told me they liked these posts. The feedback encouraged me to make another attempt at continuing the series, though note that I am not making any promises. It is quite possible that I abandon the whole thing again as soon as next month.

iOS 5.0.1

Apple released iOS 5.0.1. The update contains, among other small improvements, a way for developers to specify files that should remain on device, even in low storage situations. iOS 5.0.1 thereby fixes the “Cleaning” issue faced by many offline content apps, illustrated by Marco Arment.

To prevent your offline files from both being backed up and deleted by the system, put them anywhere in your Documents or Library folder except /Library/Caches and set an extended attribute to mark them as “should not back up”.

Thanks to Apple for providing such a quick fix. It shows that Apple is indeed willing to make changes to their policies when they realize the consequences for consumers are bad.

Programming

Siri

The guys from Applidium reverse-engineered Siri’s protocol. Basically, Siri uses binary plists over a non-standard-conforming HTTPS to talk with the server. It seems to require an iPhone 4S device ID to authenticate against the server. The binary plists contain raw audio data using the Speex audio codec. Applidium also published a collection of tool.

Using these as a basis, someone named Pete created SiriProxy, a proxy server that allows you to inject custom handlers for certain keywords into Siri’s vocabular. Pete’s demo video is worth watching.

In the meantime, several SiriProxy plugins have been published or demoed, such as one for Spotify from Simon Maddox.

Components and Libraries

MKNetworkKit by Mugunth Kumar is an interesting new iOS networking library, inspired by both ASIHTTPRequest and AFNetworking.
SVGKit by Matt Rajca is a library for rendering SVG files as Core Animation layers. All shapes are represented by instances of the CAShapeLayer class and are animatable.
GMGridView is a promising new grid view component for iOS, written by Gulam Moledina. Supports horizontal and vertical layouts, reordering via drag and drop, and the pinch-to-fullscreen gesture. Requires iOS 5.
Sam Vermette published SVStatusHUD, a replica of Apple’s HUD overlays in iOS. I especially like how Sam prescribes the situations in which you should use the component to stay in accordance with Apple’s usage:

It should only be used in response to hardware or other important notifications (for instance when an accessory is detected by your app).
Matthijs Hollemans wrote MHTabBarController, a custom tab bar controller that illustrates the new view controller container APIs in iOS 5.

Tutorials and How Tos

Matthijs Hollemans has another nice trick up his sleeve: combine two JPEG images (the actual picture and a separate alpha mask) into a single JPEG to make it transparent. Great for the rare case when a PNG file would be too large. Matthijs provides a simple UIImage category that lets you do this.
The folks around Ray Wenderlich published multiple tutorials about some of the new iOS 5 features, such as Storyboards, ARC, and iCloud.
Keith Harrison shows how to replicate the sliding master view of Mail.app in iOS 5. In a follow-up post, Keith illustrates how to create the necessary gesture recognizers directly in Interface Builder.

Miscellaneous

The GNUstep project has release version 1.6 of the GNUstep Objective-C Runtime, bringing it to a level with iOS 5.0 and OS X 10.7. The GNUstep runtime also includes an interesting feature: Support for prototype-style object orientation, Javascript-style.
The LLVM team has started a series of posts outlining major changes in LLVM 3.0. So far, they have published two articles on the type system rewrite and exception handling redesign. This is pretty in-depth stuff that you probably don’t need to know about but it never hurts to understand how the compiler works.
Martin Pilkington continued his series of Xcode reviews, this time with Xcode 4.2.
Nathan de Vries discovered how to enable WebGL (which is publicly only available for iAds since iOS 4.2) in UIWebView (using private APIs).
An article titled Parallel Implementations by John Carmack:

If the task you are working on can be expressed as a pure function that simply processes input parameters into a return structure, it is easy to switch it out for different implementations. If it is a system that maintains internal state or has multiple entry points, you have to be a bit more careful about switching it in and out. If it is a gnarly mess with lots of internal callouts to other systems to maintain parallel state changes, then you have some cleanup to do before trying a parallel implementation.
Daniel Jalkut in response to an old Linus Torvalds e-mail about his hatred of C++: Objective-C is the Language
Chrashalytics is a new contender in the iOS Crash Reporting field.
VendorForge by Keith Pitt is one of several third-party package managers for Cocoa developers that popped up over the last few months. Other similar projects include CocoaPods, kit and vendor. Since managing third-party libraries in Xcode is currently an absolute pain, this is an area where the Cocoa community could really benefit. My hope is that we end up with one great package manager that everybody can agree upon instead of an ugly mess of multiple different approaches.

Design

Wonderful article by Rob Beschizza at Boing Boing about the fundamental differences in the design approach of Apple and its competitors, namely Sony:

Apple competitors are obsessed with copying Apple’s tastes without copying its central design habit, which is solving a problem and then refining the solution until the problem changes.
Former Apple employee Bret Victor published A Brief Rant on the Future of Interaction Design, in which he encourages designers to not be satisfied with a future of Pictures Under Glass (the touchscreen). The future of interaction should be a dynamic medium that we can see, feel, and manipulate.

David Barnard replies: “Pictures Under Glass” is Revolutionary, Not Transitional:

My 2 year old son, Luke, is incredibly adept at using the iPad precisely because it doesn’t require tactile feedback to master, not in-spite of it.

To Edward Tufte, Victor’s essay is a celebration of the hand rather than about interface possibilities.
Andy Mangold sees skeuomorphism as the opiate of the people and argues that’s the underlying reason for the recent trend towards skeuomorphism in UI design:

But what hadn’t occurred to me is that it doesn’t matter if it actually does make it easier to use, all that matters is that it makes the average person think it’s easier to use.
Devin Coldewey: In Defense of the Stylus
Mobile Design Pattern Gallery is another one of those sites that collect design patterns for mobile apps and examples of successful implementations. Looks good. Oliver Drobnik has compiled a list of similar sites showcasing design patterns or outstanding app designs.

Community

Charlie Miller found a serious security hole in iOS that allows apps to download code and execute it outside of their sandbox. The result: Apple removed the offending demo app from the App Store and threw Charlie Miller out of the developer program for 1 year. Federico Viticci wrote about it for MacStories.
Chris Schilling did a fantastic interview with Matt Mills of ustwo, creators of Whale Trail. So much insight about the state of the App Store and the game industry in this one. (Their Making of Whale Trail video is also worth watching.)
Copycats is a great article by Matt Gemmell:

There’s nothing new under the sun, as they say - we’re all inspired and affected by other things. All of our design takes place under constraints. So, be influenced. Incorporate elements. Agree with implementations. Understand an approach. Realise the purpose and function of a design decision. Address a need. Renew something. Be an innovator, not a copycat.
David Barnard talks openly about the rather disappointing launch of this beautiful new app, TweetSpeaker.
The guys from Shifty Jelly wrote a post that describes pretty well how life is as an indie developer.
In A Letter to the Developer Community, Brittany Tarvin raises an important problem: what can we all do to make women feel more welcome in this community? For example, at Apple’s iOS 5 Tech Talk in Berlin this month, less than 1% of the participants were women. It felt just wrong, regardless if you were a man or a woman.
Great, encouraging quote from John Gruber’s keynote speech at the Çingleton Symposium in October:

If you think this app store platform is big now, you really haven’t seen anything yet. … But I say to you, “This is an extraordinary time to be an Apple developer”. This is the right time and the right place. This is a once in a career opportunity. … If things go right, if things go the way I think they are going to go, these next five years, we are never going to work harder, we are never going to be under more pressure, we’re never going to be more stressed, we are never going to feel like we have to work faster and we are never going to have to solve tougher problems. We’re never going to have to move this fast. But the only thing any of us are going to regret is if we don’t aim big enough.

The whole talk is worth watching.

App Store

Sandboxing Deadline Extended

Apple extended its deadline for Mac App Store apps to be sandboxed from the planned November 2011 to March 1, 2012. The nearer the original deadline came, realization probably grew in Cupertino that developers need more time to assess the impact of the sandboxing requirements on their apps and adapt them accordingly. And hopefully, Apple provides enough leeway to allow Mac apps to exist under sandboxing without impairing functionality that users take for granted.

On the occasion of Apple’s announcement, an interesting discussion about the merits (or not) of sandboxing sprung up in the blogosphere:

Wil Shipley wrote a long article about the benefits and drawbacks of sandboxing and other security measures such as code signing and code review. Wil concludes that sandboxing is not the right way and suggests that Lion only run code signed by an Apple certificate. At first, Apple would allow any developer to sign code with their certificate, but could then revoke it on a per-developer basis in case of a security problem.

It’s an interesting idea and I certainly concur that Apple’s sandboxing model is not a good measure against malware. I’d add, however, that sandboxing has other merits, e.g. in the field of privacy.
Pauli Olavi Ojala makes a very convincing case against sandboxing from a functionality perspective: it seems to mean the end of app plugins.
John Martellaro from The Mac Observer interviews MarsEdit developer Daniel Jalkut about his opinion on the Mac App Store and especially sandboxing.

Pricing and Marketing

Oliver Reichenstein experimented with the pricing for iA Writer on iPad and Mac: No matter what price we choose, we always make the same revenue.
Great story by Nathan Barry how you can make money on the App Store not only without prior programming knowledge but also with a high-priced niche product.
Ben Rooney reports on a talk by Greg Joswiak, part of the product marketing team at Apple, about four keys to Apple’s success: Focus, Simplicity, Courage, Best. There is a lot of great quotes in this short piece.
Nicholas Lovell about the tendency of the gaming market towards free: Who Will Survive the Digital Tsunami?
King Sidharth wrote a good post called Apps vs. Business. It takes more than just a good app to take down another business. You need to create a business: Solve a problem, then sell the solution.
Confusion of the month: some company announced that Apple approved a subscription-based gaming app but Apple quickly removed it from the App Store. Probably just a mistake by an app reviewer.
Laugh of the month: Rich Jones reports that the US government apparently paid $200,000 to have an absolute piece of crap app developed (for three mobile platforms). Take a look at the source code yourself.

Update December 1, 2011: Marco Arment updated his regular device and OS version stats. As of the end of November, 45% of Instapaper users have updated to iOS 5. I would have expected a higher adoption rate.

Competition

Adobe finally kills the Mobile Flash Player. Opinions on the decision:
- John Gruber: Everybody wins.
- Matt Drance: It is a victory for Adobe.
Apple Insider reports an estimate by Piper Jaffray analyst Gene Munster saying that the Android Market has generated only 7% of the revenue that Apple’s App Store has made since its inception. This analysis is flawed on so many levels (different launch dates of the two stores; is the Mac App Store included?) that it is hard for me to believe in the numbers, though.
Related to this, Ben Brooks attempts an explanation why Android developers don’t make great looking apps – generally speaking.
Jay Greene from CNET with the story how and why Microsoft killed its promising Courier tablet. I still think this thing could have been a hit.
Google released the source code for Android 4.0.
Nathan de Vries explains the improvements that Android 4.0 made in its rendering pipeline, which should bring graphics performance into the same league as iOS and Windows Phone.

Steve Jobs Biography

Walter Isaacson’s Steve Jobs biography came out in late October and many of you have probably already read the book. If you haven’t, I think you should do so because it really is quite good (although probably not as good as it could and should have been).

In episodes 42 and 43 of the Hypercritical podcast, John Siracusa makes some very strong and well-founded arguments against the book and its author: Jobs picked the wrong guy. The podcasts are not short but if you make the effort to read the book, I think you should also listen to these episodes, it’s worth it.
Jean-Louis Gassée reviews the Jobs biography from his insider perspective as one of the top Apple employees in the post-Jobs era.
A recent Churchill Club panel about Steve Jobs’s Legacy is a very good companion to the book. The panel’s participants Bill Atkinson, Jean-Louis Gassée, Andy Hertzfeld, Regis McKenna, Deborah Stapleton, Larry Tesler are some of the people you also get to know in the early chapters of the biography.
John Gruber, criticizing Malcom Gladwell’s take on Jobs’s personality: Getting Steve Jobs Wrong.
Nick Bilton did a short interview with Walter Isaacson about the book.

He had three things that he wanted to reinvent: the television, textbooks and photography. He really wanted to take these on.
Luke Wroblewski: Memorable quotes from Robert X. Cringely’s rediscovered 1995 interview with Steve Jobs

Date and Time Handling in Cocoa Cheat Sheet

2011-11-23T18:00:00Z

As a conclusion of my little series about date and time handling in Cocoa, I have prepared this cheat sheet that lists the participating classes, their main tasks and interrelations:

Date and Time Handling in Cocoa Cheat Sheet: NSDate, NSDateComponents, NSDateFormatter, NSDataDetector, NSCalendar, NSTimeZone and NSLocale.

Download the cheat sheet as PDF.

Working with Date and Time in Cocoa (Part 2)

2011-11-22T21:58:00Z

In part 2 of my little series on date and time handling in Cocoa I am going to talk about date parsing and formatting. In other words: how to convert strings into date objects and vice versa. You should read part 1 first if you haven’t yet to get an overview of the classes used by Cocoa’s date and time system.

NSDateFormatter

When working with date and time, two very common requirements are, (1) displaying dates in your UI, and (2) reading in date/time values from external sources like a web service or text file. Since humans are not very good at interpreting the second-based timestamps that NSDate uses to store dates internally, both of these tasks usually make it necessary to convert between NSDate and NSString or vice versa.

In the Foundation framework, the class to use for this task (in either direction) is NSDateFormatter. Let me show you how it works.

1. Turning Dates Into Strings

Let’s start with the easier (because less error-prone) of the two directions: turn an NSDate instance into a readable string. Usage of the NSDateFormatter class always involves three steps: (1) create the date formatter; (2) configure it; (3) send it a stringFromDate: message to get the result. Obviously, the configuration step is where the interesting stuff happens. We should differentiate between two separate use cases: do we want to create a human-readable output or do we need to create a string according to a specific format to be read by another API?

Formatting for Humans: Let the User Decide

When displaying dates in your app’s UI, you should always take the user’s preferences into account. Fortunately, that is easy with NSDateFormatter. To simply convert an NSDate into an NSString use code like this:

NSDate *myDate = [NSDate date];
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
[dateFormatter setDateStyle:NSDateFormatterMediumStyle];
[dateFormatter setTimeStyle:NSDateFormatterMediumStyle];
NSString *myDateString = [dateFormatter stringFromDate:myDate];
NSLog(@"%@", myDateString);

With my current locale settings (German), the output looks like this: 22.11.2011 18:33:19, but that’s just me. By default, NSDateFormatter observes the current user’s locale settings so other users might see results like Nov 22, 2011 6:33:19 PM or 2011-11-22 下午6:33:19 or even २२-११-२०११ ६:३३:१९ अपराह्, all for the same input and with the same code.

As a developer, you are not supposed to care about the actual output. Just use the setDateStyle: and setTimeStyle: methods to control how short or long the output should be. Possible values are NSDateFormatterShortStyle, NSDateFormatterMediumStyle, NSDateFormatterLongStyle and NSDateFormatterFullStyle; you can also use NSDateFormatterNoStyle to suppress the date or the time component in the resulting string.

The class method +localizedStringFromDate:dateStyle:timeStyle: provides a shorter way to achieve the same result as the code snippet above.

If you want to have more control over the output format, you can set a specific format using the setDateFormat: method. Note, though, that Apple specifically discourages that approach for human-readable dates since there is no date and time format that is accepted worldwide. NSDateFormatter understands the date format specifiers of the Unicode spec for date formats. If you want to go this route, have a look at the +dateFormatFromTemplate:options:locale: class method. It lets you specify a string of date format specifiers that your output string should include and returns an appropriate date format string for the specified locale.

Formatting for Machines: Controlled Environment Needed

It is a whole other matter if you need to create a date string according to the specification of a certain file format or API. In such a case, you usually have to follow a very strict spec to make sure the other party can read the string you are generating.¹

It should be clear that we must use the setDateFormat: method here. But that is not enough. Remember from part 1 that you can represent the same point in time very differently, depending on the calendar and time zone. By default, NSDateFormatter uses the user’s current calendar and time zone, which are possibly different from the requirements. Most file formats and web APIs use the western, Gregorian calendar, so we need to make sure that our date formatter uses it, too:

NSDate *myDate = [NSDate dateWithTimeIntervalSinceReferenceDate:343675999.713839];
NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
NSCalendar *calendar = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
[dateFormatter setCalendar:calendar];

We must also make sure to set the date formatter’s locale to a generic value so as not to run into conflict’s with the user’s locale settings, which can influence the naming of weekdays and months as well as the clocks 12/24 hour setting. The date formatter’s setLocale: method expects an instance of the NSLocale class. To create one, we need to specify a locale identifiers. These usually consist of a combination of a language and a country code, such as @"en_US". For our needs, however, there exists the special locale identifier @"en_US_POSIX" that is guaranteed to not change in the future.

Note that a locale also includes a calendar setting so setting the calendar explicitly as we did above is no longer necessary (but does not hurt).

NSLocale *locale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
[dateFormatter setLocale:locale];

The date’s time zone can possibly be included in the formatted output string. But as I also mentioned in part 1, time zone identifiers such as “+01:00”, “PST” or “CET” are notoriously ambiguous. In most cases, it’s best to stick with UTC:

NSTimeZone *timeZone = [NSTimeZone timeZoneForSecondsFromGMT:0];
[dateFormatter setTimeZone:timeZone];

Now, we are finally ready to set our date format and create the result string. For example, to format a date according to the common RFC 3339 (ISO 8601) standard:

[dateFormatter setDateFormat:@"yyyy'-'MM'-'dd'T'HH':'mm':'ss'Z'"];
NSString *myDateString = [dateFormatter stringFromDate:myDate];
// => 2011-11-22T17:33:19Z

Again, see the Unicode standard mentioned above for a list of possible format specifiers. Pay special attention to the year format specifier @"yyyy". It is different than the capitalized @YYYY, which represents the year of the date’s week and not the year of the day. 99% of the time, you probably want to use @”yyyy”. I have seen this bug so many times in production code that it’s not funny anymore so make sure your unit tests catch it.²

Also note that I am using the literal character 'Z' to represent the UTC time zone we set on the date formatter before. If you need to include the time zone in your format string, make sure to experiment with the possible time zone format specifiers (z, Z, v, V, each with 1-4 characters) and different time zones to really understand what you’re getting yourself into.³ As I said, dealing with time zones is no fun, especially when it comes to ambiguous abbreviations or daylight savings time. It’s best to avoid if at all possible.

2. Turning Strings Into Dates

Let’s move on to the other side of NSDateFormatter: parsing a string representation of a date and/or time and converting it to an NSDate instance. Your main use case for this should be the parsing of dates you read in from a web service API or a text file.

Parsing Machine-Generated Dates

In this case, you use the class much like in the reverse case that we just discussed:

Create an NSDateFormatter.
Create a controlled environment by setting the formatter’s locale and possibly time zone as specified by the input format. In most cases, this means the en_US_POSIX locale and the UTC time zone.
Set the formatter’s date format string to the specified format.
Call dateFromString:.

For example, here is how to parse a date from an RSS feed entry of the form Mon, 06 Sep 2009 16:45:00 -0900 as specified in RFC 822:

NSString *myDateString = @"Mon, 06 Sep 2009 16:45:00 -0900";

NSDateFormatter *dateFormatter = [[NSDateFormatter alloc] init];
NSLocale *locale = [[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"];
[dateFormatter setLocale:locale];
[dateFormatter setDateFormat:@"EEE, dd MMM yyyy HH:mm:ss Z"];

NSDate *myDate = [dateFormatter dateFromString:myDateString];
NSLog(@"%@", myDate);
// => 2009-09-07 01:45:00 +0000

Note how we did not set the date formatter’s time zone explicitly here. Instead, the Z character in the format string is now a format specifier for the time zone rather than the literal character it was in the example above. Also note that the output format of NSLog() shows date and time in UTC but it really represents the exact same point in time as the input string.

If a date formatter cannot parse the string, dateFromString: returns nil. Your code must be able to deal with this case gracefully.

Parsing Free-Form Date Strings

What if you don’t know the exact format of the string, e.g. because you want to let the user enter a date and time in a free-form text field⁴? I am afraid that NSDateFormatter will probably not be a big help then. The class does have a setLenient: method that enables heuristics when parsing a string. However, even in lenient mode you are still required to specify an exact date format. In lenient mode, the formatter correctly parses a date string containing slashes (@"03/11/2011 11:03:45") when the date format specifies blanks (@"dd MMM yyyy HH:mm:ss") but that seems approximately to be the extent of what it can do.

For really lenient parsing with NSDateFormatter, you would probably have to try multiple formats and check for success after each attempt. The Unicode standard includes some suggestions for lenient parsing if you want to go that route.

Update November 23, 2011: In most cases, you are probably better off providing the user a dedicated control for date and time entry that guarantees valid and unambiguous values, such as UIDatePicker or NSDatePicker.

NSDataDetector to the Rescue!

A more promising approach might be the relatively new NSDataDetector class. Although not a classic member of the date and time handling classes in Cocoa, I want to mention it here for its ability to match, among other things, dates and times in free-form strings such as e-mail messages.

Because NSDataDetector is a special kind of regular expression, its API is completely different:

NSString *myDateString = @"24.11.2011 15:00";
NSError *error = nil;
NSDataDetector *detector = [NSDataDetector dataDetectorWithTypes:NSTextCheckingTypeDate error:&error];
NSArray *matches = [detector matchesInString:myDateString options:0 range:NSMakeRange(0, [myDateString length])];
for (NSTextCheckingResult *match in matches) {
    NSLog(@"Detected Date: %@", match.date);           // => 2011-11-24 14:00:00 +0000
    NSLog(@"Detected Time Zone: %@", match.timeZone);  // => (null)
    NSLog(@"Detected Duration: %f", match.duration);   // => 0.000000
}

In this case, the detection worked great⁵, and the detector can also deal with relative strings such as @"next Monday at 7 pm" or @"tomorrow at noon". NSDataDetector always seems to use the current locale and time zone to interpret dates in strings.

Miscellaneous Findings

Use Thread-Local Storage for NSDateFormatter

The -[NSDateFormatter init] method is quite expensive. If you need the same date formatter repeatedly, you should cache it, either in a static variable as in this example in Apple’s Technical Q&A QA1480 (see Listing 2) or, even better, by using Thread-Local Storage as explained by Alex Curylo in his article Threadsafe Date Formatting.

More Efficient Date Parsing

If you still encounter performance problems with NSDateFormatter, note this suggestion in the same QA1480:

Finally, if you’re willing to look at solutions outside of the Cocoa space, it’s very easy and efficient to parse and generate fixed-format dates using the standard C library functions strptime_l and strftime_l. Be aware that the C library also has the idea of a current locale. To guarantee a fixed date format, you should pass NULL to the loc parameter of these routines. This causes them to use the POSIX locale (also known as the C locale), which is equivalent to Cocoa’s “en_US_POSIX” locale.

For a data point, see Sam Soffes’s article how he improved the performance of his date parsing code by a factor of more than 20× by switching from NSDateFormatter to C-based date parsing.

GMT != UTC

Cédric Luthi discovered a seemingly weird NSDateFormatter behavior last weekend. See the following code:

NSString *dateString = @"0001-01-01 00:00:00 GMT";
NSDateFormatter *df = [[NSDateFormatter alloc] init];
[df setLocale:[[NSLocale alloc] initWithLocaleIdentifier:@"en_US_POSIX"]];
[df setDateFormat:@"yyyy-MM-dd HH:mm:ss zzz"];
NSDate *myDate = [df dateFromString: dateString];
NSLog(@"%@", myDate);

The result of the log statement: 0001-01-01 01:27:24 +0000. Hm, 01:27:24? Where can such a weird result come from? It turns out the answer is the GMT time zone. Do the same with UTC as the time zone and the result is the expected 0001-01-01 00:00:00 +0000. Update November 23, 2011: Cédric notes on Twitter that Snow Leopard doesn’t seem to understand “UTC” and @"0001-01-01 00:00:00 UTC" returns a nil date. I find that very strange.

So it seems that when dealing with historical dates, UTC and GMT are not identical in Cocoa. Instead, the system seems to use past definitions of GMT that were valid at the date in question. When I investigated this further, I found out that only for dates later than 9 April, 1968, GMT and UTC are identical in Cocoa. So beware of the difference if your app deals with the past. Use UTC as your time zone if you want to interpret all dates in today’s time system.

Wouldn’t it be great if all web services used Unix timestamps to represent dates? I could omit this entire section as the conversion from and to NSDate would be trivial. For some reason, however, most APIs use string-based dates, which at least have the advantage of being human-readable.↩
For example, the year-of-week for 1 January 2005 is 2004 because that date belongs to the last calendar week of 2004 rather than the first calendar week of 2005. Use NSDate *testDate = [NSDate dateWithTimeIntervalSinceReferenceDate:126273600.0] in your unit test and assert that you get the correct result for both format strings @"yyyy" and @"yyyy".↩
By the way, CodeRunner, which I reviewed recently here on the blog is an awesome little app to experiment with date formatters. I used it constantly while writing this article.↩
There are a number of apps that let you do just that, for example iCal in Lion, the great Fantastical app and Google Calendar.↩
My time zone is one hour earlier than UTC, hence the time difference between input and output string.↩

Working with Date and Time in Cocoa (Part 1)

2011-11-17T22:55:00Z

One of the most common problems I see newbies to Objective-C and Cocoa struggle with on Stack Overflow is how to deal correctly with dates and times. Cocoa’s approach to date and time handling may indeed seem overly complex at first glance: where other languages’ standard libraries seem to get by with just one or two classes to cover this field, the Foundation framework employs a staggering array of separate classes: NSDate, NSDateComponents, NSDateFormatter, NSCalendar, NSTimeZone. These classes deal directly with date and time and you should be familiar with all of them. In addition, you should also understand the role of the NSLocale class.

Let’s have a look at those classes one by one. As you will see, the Cocoa approach to date and time handling is not only quite easy to understand but also extremely flexible.

NSDate

NSDate is the central class of the date/time handling in Foundation, and at the same time the simplest imaginable. NSDate is nothing more than a wrapper around a single number: the number of seconds since 1 January, 2001, at 00:00 (midnight), UTC¹. For values representing numbers of seconds, the framework uses a custom type, NSTimeInterval, which is currently defined as a 64-bit floating point value. According to the documentation, this is enough to yield an impressive sub-millisecond precision over a range of 10,000 years.

Represents an Absolute Point in Time

An NSDate object always represents an absolute point in time.² This insight has two important consequences:

There is no way to represent a certain date without including a specific time. For instance, to say that a particular NSDate instance represents 17 November 2011 makes no sense; you always have to include the particular time and time zone, such as 17 November 2011 00:00:00 +00:00 (or any other time of your choice).

If your app needs to store dates with less-than-second precision in order to represent entire days, months or years, you should either not use your own custom class for this or, better, define a rule how your app deals with the unused components of the date (e.g., set the time components of the date to 00:00:00 +00:00).

If you are sloppy and store dates with arbitrary time components, you will run into problems later when you want to compare or group multiple dates.
NSDate has no concept of time zones. When it is midnight in London (17 November 2011 00:00:00 +00:00), it is only 6 pm on the day before in New York (16 November 2011 18:00:00 -06:00). Both dates represent the same point in time and are thus absolutely equal as far as NSDate is concerned.

The implication of this is that you cannot store the time zone of a date and time in an NSDate object. If your app needs this information, you will have to store it in a different field. But more often than not, you will find that the time zone is actually not a field that should be stored with a date. Rather, it is a runtime preference of the person that is currently using your app, and your app should probably display most dates in the user’s current time zone.

How To Create An `NSDate` That Represents A Specific Date?

The easiest way to create an NSDate object is [NSDate date];. This will return an instance that represents the current moment and is often useful in code when it comes to storing creation or modification dates of records or to measure certain time intervals in your app.

The more generic task of creating an instance that represents a specific date and time turns out to be not so straightforward. There is the +dateWithTimeIntervalSinceReferenceDate: class method, but it requires you to know the interval in seconds between your desired date and the reference date (1 January 2001 00:00:00 +00:00). Turns out most people don’t count dates that way. That’s where the other classes come in.

NSCalendar

Most people reading this will probably only ever use the same single calendar with its 12 months named January, February and so on, seven-day weeks, counting the years from the reputed birth of Jesus. It is easy to forget that (1) the current “western” Gregorian Calendar has only been introduced in 1582 and (2) there are many more calendars in practical use around the world today. The Foundation framework can currently handle ten different calendars³.

It should be clear that, to specify a date unambiguously, we need to specify the calendar we use. For instance, while today’s date falls into the year 2011 in the familiar Gregorian calendar, the current year is 2554 and 5772 in the Buddhist and Hebrew calendars, respectively.

In Cocoa, a calendar is represented by the NSCalendar class. To create an instance of a specific calendar, pass one of the valid calendar identifiers to the initializer:

NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
NSCalendar *buddhist = [[NSCalendar alloc] initWithCalendarIdentifier:NSBuddhistCalendar];
NSCalendar *hebrew = [[NSCalendar alloc] initWithCalendarIdentifier:NSHebrewCalendar];

There are also two class methods, +currentCalendar and +autoupdatingCurrentCalendar that return the current user’s preferred calendar. Note that the object returned by the latter method automatically adapts to changes in System Preferences.

The rest of the class is pretty straightforward. You can query the calendar for its configuration, i.e., things like the number of days that are in a month or which day is considered the first day of the week. Have a look at the documentation to get a feel for what is possible. There are also methods to split a date into its calendrical components or do the reverse but we are not quite ready to do that yet.

NSTimeZone

Any time specification is not precise enough without also indicating the time zone. I have already discussed that we need a way to reference time zones separately from NSDate and the NSTimeZone class does just that. There are several methods to create a time zone instance, the most straightforward being +timeZoneForSecondsFromGMT:.

Note, though, that the numeric offset from GMT is in many cases not enough to identify a specific time zone due to different daylight saving rules around the world. It is safer to specify a time zone by name using the +timeZoneWithName: method. Valid names are of the form @"Europe/Berlin".⁴

Another method, +timeZoneWithAbbreviation: should be handled with care. It is supposed to create time zones from common abbreviations such as “PST” or “CEST”. The problem is that these abbreviations are not always unique – different countries might use the same abbreviation for different time zones or different abbreviations for the same time zone. You should avoid this ambiguity if possible.

Update November 22, 2011: In addition, the rules which time zone abbreviation is understood under a specific locale setting can change. As Cédric Luthi found out, Apple made a change in iOS 5 that causes the abbreviations “CET” and “CEST” (Central European (Summer) Time, very commonly used in Europe) to be no longer recognized if the user’s current locale setting is en_US. These abbreviations do still work with the en_GB locale, however. Another reason to avoid them completely if you ask me.

Last but not least, use the +systemTimeZone method to get a reference to the user’s current time zone.

NSDateComponents

We have almost everything we need now to manipulate dates in our code. Our fourth class, NSDateComponents, represents kind of the same information as NSDate: a single point in time. Unlike the latter, however, an NSDateComponents instance lets you access and manipulate every single calendrical component of that absolute point⁵, from the year down to the second and including such things as era, calendar, time zone and weekday.

Constructing Dates

Knowing this, let’s construct a date that represents the beginning of Steve Jobs’s Macworld 2007 keynote when he first introduced the iPhone:

NSCalendar *gregorian = [[NSCalendar alloc] initWithCalendarIdentifier:NSGregorianCalendar];
NSTimeZone *pacificTime = [NSTimeZone timeZoneWithName:@"America/Los_Angeles"];

NSDateComponents *dateComps = [[NSDateComponents alloc] init];
[dateComps setCalendar:gregorian];
[dateComps setYear:2007];
[dateComps setMonth:1];
[dateComps setDay:9];
[dateComps setTimeZone:pacificTime];
[dateComps setHour:9]; // keynote started at 9:00 am
[dateComps setMinute:0]; // default value, can be omitted
[dateComps setSecond:0]; // default value, can be omitted

NSDate *dateOfKeynote = [dateComps date];
NSLog(@"Date of Keynote: %@", dateOfKeynote);

The output:


Date of Keynote: 2007-01-09 17:00:00 +0000

Hm, 17:00:00? But remember that NSDate does not care about time zones. When printing an NSDate with NSLog(), the system always uses UTC, which is 8 hours ahead of San Francisco (or 7 hours during daylight savings time). So the resulting date is indeed correct.

Update November 28, 2011: Thanks to Shan for pointing out on Twitter that the code snippet above won’t work on OS X 10.6 or iOS 3.x because the setCalendar: and setTimeZone: methods are quite recent additions to NSDateComponents. To stay compatible with the older OSs, create your NSDateComponents instance just as above (without setting a calendar and time zone) and use the dateFromComponents: method of NSCalendar:

...
[gregorian setTimeZone:pacificTime];
NSDate *dateOfKeynote = [gregorian dateFromComponents:dateComps];
NSLog(@"Date of Keynote: %@", dateOfKeynote);

You see, it’s just as easy.

Now that we have an NSDateComponents instance, you would perhaps expect that you can get more information out of it. For example, let’s try to find out what day of the week the keynote was:

NSInteger weekday = [dateComps weekday]; // => -1 == NSUndefinedDateComponent

The documentation explains this:

An instance of NSDateComponents is not responsible for answering questions about a date beyond the information with which it was initialized. For example, if you initialize one with May 6, 2004, its weekday is NSUndefinedDateComponent, not Thursday. To get the correct day of the week, you must create a suitable instance of NSCalendar, create an NSDate object using dateFromComponents: and then use components:fromDate: to retrieve the weekday.

Let’s try that:

NSDate *dateOfKeynote = [dateComps date]; // or: [gregorian dateFromComponents:dateComps]
NSDateComponents *weekdayComponents = [gregorian components:NSWeekdayCalendarUnit fromDate:dateOfKeynote];
NSInteger weekday = [weekdayComponents weekday]; // => 3 == Tuesday

Note how we can specify in the -[NSCalendar components:fromDate:] method which date components we are interested in (using a bit mask). Some of the components can be expensive so it makes sense to only ask for the information you really need.

Date Calculations

The combination of NSDateComponents and NSCalendar is also the way to go for fancy date calculations. Say I want to create a date that goes back in time by exactly a month, a day and an hour from the current moment (using the current user’s calendar):

NSDate *now = [NSDate date];
NSDateComponents *comps = [[NSDateComponents alloc] init];
[comps setMonth:-1];
[comps setDay:-1];
[comps setHour:-1];
NSCalendar *calendar = [NSCalendar currentCalendar];
NSDate *newDate = [calendar dateByAddingComponents:comps toDate:now options:0];

NSDateComponents is an incredibly flexible und useful class. In combination with NSCalendar, you can probably do all the date calculations you ever thought of.

Continued in Part 2: Date Parsing and Formatting

The classes I presented above give you a complete toolkit to work with date and time in your code. Two things are still missing, though: how to parse dates that come into your app as strings and how to output properly formatted dates as strings? Both of these tasks are handled by the NSDateFormatter class, which I discuss in part 2 of this little series.

Or GMT, which is arguably the same, at least for our purposes.↩
Yes, that means the date and time system does not deal with relativity. Cocoa is deeply rooted in Newtonian physics. Update November 23, 2011: We also pretend that leap seconds do not exist.↩
With some limitations regarding the Chinese calendars. See the description of valid calendar identifiers in the documentation.↩
Apple uses the well-known tz database. Log the result of +knownTimeZoneNames to get a list of all valid names.↩
Implied in this is that NSDateComponents objects are mutable whereas NSDate instances are immutable.↩

Ole Begemann: iOS Development

Checking Code Signing and Sandboxing Status in Code

The codesign Utility

Doing it in Code

Code Signing Services

Additional Requirements for the Signature (Sandboxing)

Mac App Store Receipt Check

The Source Code

Passing Data Between View Controllers

Don’t Misuse Views For Storing Data

The Solution

What iOS Should Learn from Android and Windows 8

Android

Activities

Intents

Windows 8

Charms

Contracts

The Sharing Contract

Learnings for iOS

We Need a Generic Sharing API

Share Sheets: Only Half Way There

Not Extensible by Third-Party Apps

A Missed Opportunity for iOS?

Extensible Share Sheets in iOS 6?

Revisiting the App Launch Sequence on iOS

Flowchart

Changes to main()

No MainWindow.xib

More Work To Do in application:didFinishLaunchingWithOptions:

A Litte More Code But Clearer

CGPath Hit Testing

The Demo App

Hit Testing with CGPathCreateCopyByStrokingPath

Drawing a Selection Outline with CGPathCreateCopyByStrokingPath

Replicating CGPathCreateCopyByStrokingPath in iOS 4 and Mac OS X 10.6

Schulung iOS-Entwicklung für Einsteiger im März 2012

DocSets App for iOS

New Videos at developer.apple.com

New Videos with iOS 5 Tech Talk Content

Gesture Recognition on iOS with Attention to Detail

Half-assed Gesture Recognition Is Not Good Enough

Works But Does Not Feel Great

Solving the UX Issues

initWithNibName:bundle: Breaks Encapsulation

The Name of the NIB File is an Implementation Detail

One View Controller, Multiple NIBs

Conclusion

iOS and Mac Development Link Roundup: December 2011

Carrier IQ

Programming

Android Graphics Architecture vs. iOS

Design

The Flipboard for iPhone design process

App Store

Community

Competition

Apple and Steve Jobs

UIRequiredDeviceCapabilities Cannot Be Changed in App Updates

Automatic Rejection by Xcode’s Validator

How About Not Changing the Deployment Target for Your App’s Lifetime?

Downgrades are Possible

Please File a Bug Report

Diamond Dash for iOS

Facebook Integration

Already Featured by Apple

Thanks to the Arcade Team at Wooga

Tutorial: How to Sort and Group UITableView by Date

Project Setup

Getting Events from the Calendar Store

Constructing Start and End Date

Querying the Calendar Store

Grouping Events by Day

Creating Date Formatters for Output

Populating the Table View

Download the Sample Project

How to Restrict Your iOS App to Modern Hardware

iOS 5 Adoption Rate Only at 45%

How to Forcefully Exclude Older Devices From Running Your App

1. Require a Certain iOS Version

Changes to `main()`

More Work To Do in `application:didFinishLaunchingWithOptions:`

Hit Testing with `CGPathCreateCopyByStrokingPath`

Drawing a Selection Outline with `CGPathCreateCopyByStrokingPath`

Replicating `CGPathCreateCopyByStrokingPath` in iOS 4 and Mac OS X 10.6